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.