or just put <http://www.isc.org/pubs/tn/?tn=isc-tn-2002-1.txt> into effect.
I am confused. Are DNAMEs deprecated or not (RFC3363, section 4)?
A6 and bitstring labels are deprecated. DNAME remains in full force.
or just put <http://www.isc.org/pubs/tn/?tn=isc-tn-2002-1.txt> into effect. I am confused. Are DNAMEs deprecated or not (RFC3363, section 4)? A6 and bitstring labels are deprecated. DNAME remains in full force.
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? itojun
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.
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.
i understand some implementation (BIND 9.3?) does this, but is the behavior documented somewhere in the set of RFCs? for instance, does djbdns do it? does MS DNS server do it? i'm very skeptical about the possibility (or reality) of DNAME-based transition. itojun
[itojun]
i understand some implementation (BIND 9.3?) does this,
i think it's all bind9, but certainly all bind 9.2 and later.
but is the behavior documented somewhere in the set of RFCs?
yes. marka just quoted all of that.
for instance, does djbdns do it? does MS DNS server do it?
i'm very skeptical about the possibility (or reality) of DNAME-based transition.
as a practical matter, it is impossible to ensure that all name servers and resolvers understand DNAME. but it is very possible to ensure that a given zone, such as "8.f.4.0.1.0.0.2.ip6.arpa" in ISC's case, is only served by authority servers who understand DNAME and do CNAME synthesis. therefore it is very practical to consider a DNAME-based transition.
On Wed, 11 Feb 2004, Paul Vixie wrote: : as a practical matter, it is impossible to ensure that all name servers : and resolvers understand DNAME. but it is very possible to ensure that : a given zone, such as "8.f.4.0.1.0.0.2.ip6.arpa" in ISC's case, is only : served by authority servers who understand DNAME and do CNAME synthesis. Would it be too much to try to get the RIRs to agree that "ip6.int." get a DNAME and all other zones get unlinked in a shorter timeframe? i.e. why go through the motions of many different subzones of ip6.int. having DNAMEs when just one record will do for the world? In any other Internet context, I can see this as being too many cooks in the kitchen, but the entities serving up ip6.int. zones are of a reasonably small number. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com>
On Wed, 11 Feb 2004, Paul Vixie wrote:
: as a practical matter, it is impossible to ensure that all name servers : and resolvers understand DNAME. but it is very possible to ensure that : a given zone, such as "8.f.4.0.1.0.0.2.ip6.arpa" in ISC's case, is only : served by authority servers who understand DNAME and do CNAME synthesis.
Would it be too much to try to get the RIRs to agree that "ip6.int." get a DNAME and all other zones get unlinked in a shorter timeframe? i.e. why go through the motions of many different subzones of ip6.int. having DNAMEs when just one record will do for the world?
In any other Internet context, I can see this as being too many cooks in the kitchen, but the entities serving up ip6.int. zones are of a reasonably small number.
-- Todd Vierling <tv@duh.org> <tv@pobox.com>
-IF- (its a big one) we can get the IANA to agree, then the DNAME haq would be implemented post haste. --bill
participants (4)
-
bill -
itojun＠itojun.org -
Paul Vixie -
Todd Vierling