North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: IPv6 reverse lookup - lame delegation?

  • From: Paul Vixie
  • Date: Wed Feb 11 15:43:25 2004

> > ... <http://www.isc.org/pubs/tn/?tn=isc-tn-2002-1.txt> ...
> 
> last i heard from you, you said that DNAME would be evaluated by recursive
> resolver and will not be visible to end client... what changed?

according to this experiment:

+---
| ;; QUESTION SECTION:
| 3.7.a.1.5.0.e.f.f.f.b.5.9.0.2.0.b.b.0.0.3.0.0.0.8.f.4.0.1.0.0.2.ip6.int. \
|     IN PTR
| 
| ;; ANSWER SECTION:
| 8.f.4.0.1.0.0.2.ip6.int. 7200   IN      DNAME   8.f.4.0.1.0.0.2.ip6.arpa.
| 3.7.a.1.5.0.e.f.f.f.b.5.9.0.2.0.b.b.0.0.3.0.0.0.8.f.4.0.1.0.0.2.ip6.int. \
|     0 IN CNAME \
|     3.7.a.1.5.0.e.f.f.f.b.5.9.0.2.0.b.b.0.0.3.0.0.0.8.f.4.0.1.0.0.2.ip6.arpa.
| 3.7.a.1.5.0.e.f.f.f.b.5.9.0.2.0.b.b.0.0.3.0.0.0.8.f.4.0.1.0.0.2.ip6.arpa. \
|     7200 IN PTR sa.vix.com.
+---

...there is a DNAME provided, which most resolvers will just ignore, and
there is a synthesized (TTL=0) CNAME provided.  the main purpose of the
DNAME is to tell the authority server to synthesize these CNAMEs.

what we need, however, is a DNAME at ip6.int, renaming the entire tree
to ip6.arpa.  last time i asked bill manning about this he used the word
"disenfranchise" in his answer.  failing that, we need a DNAME at
e.f.f.3.ip6.int renaming *that* tree to e.f.f.3.ip6.arpa, but last time
i asked bob fink about that he used the word "prolong" in his answer.

therefore it's going to be up to every network owner to do their own DNAME
in order to rename ip6.int to ip6.arpa one subsubsubtree at a time, until
that date in the ultimate and distant future when the last ip6.int-style
implementation of gethostbyaddr() (et al) disappears.  (which i guess means
that this time, the sausage-making is getting done in public.)

so, isc published <http://www.isc.org/pubs/tn/?tn=isc-tn-2002-1.txt>, and
we made sure that BIND9 authority servers handle DNAME RRs properly.