Re: IPv6 reverse lookup - lame delegation?

[Mark Andrews <marka () isc org>]

In article <013301c3f032$787aca50$210d640a () unfix org> you write:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Mark Andrews wrote:
>
> >      The correct fix to this will be to just stop making IP6.INT
> >      queries.
> >
> >      The best think that could be done is for the PTB to install
> >      "IP6.INT. DNAME IP6.ARPA." *now*.  This will allow the legacy
> >      resolvers to get a answer and allow vendors to stop shipping
> >      legacy aware resolver in the vague hope that they will get
> >      a answer from IP6.INT that they didn't get from IP6.ARPA.
>
> From RFC3363:
> 8<----
> 4.  DNAME in IPv6 Reverse Tree
>
> The issues for DNAME in the reverse mapping tree appears to be
> closely tied to the need to use fragmented A6 in the main tree: if
> one is necessary, so is the other, and if one isn't necessary, the
> other isn't either.  Therefore, in moving RFC 2874 to experimental,
> the intent of this document is that use of DNAME RRs in the reverse
> tree be deprecated.
> - ---->8

        This is was for *supporting* RENUMBERING not RENAMING. 

        The whole section should just be excised from this RFC.  It
        is just wrong to say you can't use DNAME in a part of the
        tree.  It also gives the wrong impression that DNAME is
        deprecated when it is most definitely not.  As part of the
        working group at the time this went through I apologise for
        dropping the ball by letting this section stay.

        If you talk to others in the WG you will find similar
        opinions.

> It will indeed work, but not work everywhere. Redhat boxes for
> instance apparently croak on it. Legacy resolvers might quite
> possibly include support for it though so one might be on the
> safe side there.

        Well DNAME is not going away.  Broken resolvers need to
        be fixed.

> I guess DNAME is getting used more for a purpose for which it
> wasn't intended at first ;)

        No.  RENAMING was a explicitly intended use.
        
        Mark