if i try to log into my machines back in tokyo by IPv6 SSH, it takes very long time. i guess i found the reason - (possible) lame delegation of blah.ip6.int. ip6.arpa. query returns instantly. how could we fix it? itojun % dig e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.int. ptr ; <<>> DiG 9.2.3 <<>> e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.int. ptr ;; global options: printcmd ;; connection timed out; no servers could be reached % dig e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.arpa. ptr ; <<>> DiG 9.2.3 <<>> e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.arpa. ptr ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19137 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.arpa. IN PTR ;; AUTHORITY SECTION: ip6.arpa. 10569 IN SOA dns1.icann.org. hostmaster.icann.org. 2003080400 3600 1800 604800 10800 ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(0.0.0.0) ;; WHEN: Tue Feb 10 21:57:17 2004 ;; MSG SIZE rcvd: 151
-----BEGIN PGP SIGNED MESSAGE----- Jun-ichiro itojun Hagino wrote:
if i try to log into my machines back in tokyo by IPv6 SSH, it takes very long time. i guess i found the reason - (possible) lame delegation of blah.ip6.int. ip6.arpa. query returns instantly. how could we fix it?
By fixing the software as ip6.int was deprecated 2 years+++ ago as you should already know. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / http://unfix.org/~jeroen iQA/AwUBQCjXjCmqKFIzPnwjEQJilgCeKzUx5e212QcmT7x8gyi8nlyFvPQAoKDI B2LrHqnVxx81JMDaEr/RmGvr =hUYQ -----END PGP SIGNATURE-----
if i try to log into my machines back in tokyo by IPv6 SSH, it takes very long time. i guess i found the reason - (possible) lame delegation of blah.ip6.int. ip6.arpa. query returns instantly. how could we fix it? By fixing the software as ip6.int was deprecated 2 years+++ ago as you should already know.
for backward compatibility reasons many software do query ip6.arpa; if (not found) query ip6.int; i'm not too sure if we can remove the "query ip6.int" part today. itojun
if i try to log into my machines back in tokyo by IPv6 SSH, it takes very long time. i guess i found the reason - (possible) lame delegation of blah.ip6.int. ip6.arpa. query returns instantly. how could we fix it? By fixing the software as ip6.int was deprecated 2 years+++ ago as you should already know.
for backward compatibility reasons many software do query ip6.arpa; if (not found) query ip6.int; i'm not too sure if we can remove the "query ip6.int" part today.
i mean, e.f.f.3.ip6.int. is not even delegated. itojun
-----BEGIN PGP SIGNED MESSAGE----- Jun-ichiro itojun Hagino wrote:
if i try to log into my machines back in tokyo by IPv6 SSH, it takes very long time. i guess i found the reason - (possible) lame delegation of blah.ip6.int. ip6.arpa. query returns instantly. how could we fix it? By fixing the software as ip6.int was deprecated 2 years+++ ago as you should already know.
For people wanting to know the real date: RFC 3152 - Delegation of IP6.ARPA, BCP 49, dated August 2001
for backward compatibility reasons many software do query ip6.arpa; if (not found) query ip6.int; i'm not too sure if we can remove the "query ip6.int" part today.
Not yet indeed, unfortunatly. The RIR prefixes under ip6.int, at least for RIPE, seem to exist though if they don't take it up with them. RIPE does require 2 mails to marvin, one for ip6.int and one for ip6.arpa. Personally I would say, don't delegate ip6.int, only use ip6.arpa and identify the software to be fixed and fix it. Btw XP will support it in SP2, I heared the 5500 build beta (or something) did it correcly. New software should just *only* do ip6.arpa and not even bother with ip6.int or fallbacks unless you explicitly need it. IRC servers are really the only thing I can think of so that is not really important. SSH on the otherhand is handy though. Oh and yes, I still use 3ffe:8114:2000:240::/60 at home thus indeed I have the problem when the ip6.arpa delegation is not there and the software doesn't resolve it anymore...
i mean, e.f.f.3.ip6.int. is not even delegated.
You obviously mean e.f.f.3.ip6.arpa. Check the following: "RFC 3681 - Delegation of E.F.F.3.IP6.ARPA" BCP 80, January 2004, hmmm more than 2 years difference, that took a lot of backhall politics to solve for such a simple thing. My estimate is that it will work around 6/6/6 (2006 that is ;) Then the 6bone will be gone anyways so it won't hurt. Apparently the powers that be are setting it up, but as for the complete debate on where the NS's will come nothing is happening, there where quite a number of messages on the 6bone mailinglist about this. See: http://mailman.isi.edu/pipermail/6bone/2004-January/008242.html and the following thread ;) Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / http://unfix.org/~jeroen iQA/AwUBQCjgRSmqKFIzPnwjEQKWngCfd7fnZsvXvvVhYSArzLon+Idb8McAn14i 2R3Pw2OEBz/5f3dahLc4MXYw =BlSl -----END PGP SIGNATURE-----
Jeroen Massar <jeroen@unfix.org> wrote: [...]
Not yet indeed, unfortunatly. The RIR prefixes under ip6.int, at least for RIPE, seem to exist though if they don't take it up with them. RIPE does require 2 mails to marvin, one for ip6.int and one for ip6.arpa.
Just to clarify, two domain objects are needed, one for each domain. But you can request delegation of both domains in a single e-mail. Regards, -- leo vegoda RIPE NCC Registration Services Manager
if i try to log into my machines back in tokyo by IPv6 SSH, it takes very long time. i guess i found the reason - (possible) lame delegation of blah.ip6.int. ip6.arpa. query returns instantly. how could we fix it? By fixing the software as ip6.int was deprecated 2 years+++ ago as you should already know. for backward compatibility reasons many software do query ip6.arpa; if (not found) query ip6.int; i'm not too sure if we can remove the "query ip6.int" part today.
if, as you say, there was instant response to the ip6.arpa query, then jeroen's response that the software was broken seems even more clear. and i don't believe in 'do-gooder' software that tries to make broken things work anyway. if it succeeds, no one notices and says thanks. if it fails, boy does it look bad. randy
-----BEGIN PGP SIGNED MESSAGE----- Randy Bush wrote:
if i try to log into my machines back in tokyo by IPv6 SSH, it takes very long time. i guess i found the reason - (possible) lame delegation of blah.ip6.int. ip6.arpa. query returns instantly. how could we fix it? By fixing the software as ip6.int was deprecated 2 years+++ ago as you should already know. for backward compatibility reasons many software do query ip6.arpa; if (not found) query ip6.int; i'm not too sure if we can remove the "query ip6.int" part today.
if, as you say, there was instant response to the ip6.arpa query, then jeroen's response that the software was broken seems even more clear.
The piece of software itojun describes is quite common, simply because it already has taken two years for even getting an RFC for ip6.arpa reverse for the 6bone. Now all we have to do is wait for the nameservers to actually appear and not to forget for them to get populated, 6/6/6 is quite a good estimate I guess ;) The problem only is that many software implementations only check ip6.int even though it is has been deprecated, fortunatly now that the RFC for the 6bone is out some manufacturers have been implementing ip6.arpa support by basically doing the simple g/ip6.int/s/ip6.int/ip6.arpa/g over their code. As the ip6.arpa doesn't exist at all for 6bone space at the moment he got a correct NXDOMAIN back from those and what itojun saw then where recursive looping dns servers which where not authoritive for the reverse thus pointed back to the root, software retries a number of times causing the shown delay. (dig +trace is ones friend)
and i don't believe in 'do-gooder' software that tries to make broken things work anyway. if it succeeds, no one notices and says thanks. if it fails, boy does it look bad.
ip6.int should indeed be gone completely from all software. It should have been 2 years ago, but due to 6bone not having ip6.arpa there was kind of a reason not to, but there is now... If developers start fixing their software it will be enough time for the NS operators to set the reverses up correctly. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / http://unfix.org/~jeroen iQA/AwUBQCkCdymqKFIzPnwjEQITeACgu4fzV0Q9KAhhbck/nyhyh6tPHGMAoIUR wOMIZoVaOys39hvPR4E18GHj =++66 -----END PGP SIGNATURE-----
Jun-ichiro itojun Hagino wrote:
if i try to log into my machines back in tokyo by IPv6 SSH, it takes very long time. i guess i found the reason - (possible) lame delegation of blah.ip6.int. ip6.arpa. query returns instantly. how could we fix it?
jeroen@unfix.org ("Jeroen Massar") writes:
By fixing the software as ip6.int was deprecated 2 years+++ ago as you should already know.
or just put <http://www.isc.org/pubs/tn/?tn=isc-tn-2002-1.txt> into effect. -- Paul Vixie
Jun-ichiro itojun Hagino wrote:
if i try to log into my machines back in tokyo by IPv6 SSH, it takes very long time. i guess i found the reason - (possible) lame delegation of blah.ip6.int. ip6.arpa. query returns instantly. how could we fix it?
jeroen@unfix.org ("Jeroen Massar") writes:
By fixing the software as ip6.int was deprecated 2 years+++ ago as you should already know.
or just put <http://www.isc.org/pubs/tn/?tn=isc-tn-2002-1.txt> into effect.
if zonefile for e.f.f.3.ip6.int does not have $ORIGIN nor "ip6.int" inside, we could just point the zone file twice: zone "e.f.f.3.ip6.int" { type master; file "3ffe.zone"; }; zone "e.f.f.3.ip6.arpa" { type master; file "3ffe.zone"; }; itojun
On Wed, Feb 11, 2004 at 00:36:19 +0000, Paul Vixie wrote:
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)? rvdp
In article <20040211105437.GA506@rvdp.org> you write:
On Wed, Feb 11, 2004 at 00:36:19 +0000, Paul Vixie wrote:
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)?
rvdp
RFC 3363 does NOT say that DNAME is deprecated. All it says is that since A6 was moving the exprimental using DNAME to support renumbering is deprecated. isc-tn-2002-1.txt describes renaming. DNAME is still very much standards track. If you actually think about renumbering you still need what DNAME gave you, the ability to renumber high (close to the root) in the delegation tree without having to redelegate every subzone. Mark
On Wed, 11 Feb 2004, Mark Andrews wrote:
RFC 3363 does NOT say that DNAME is deprecated. All it says is that since A6 was moving the exprimental using DNAME to support renumbering is deprecated.
Which part of: Therefore, in moving RFC 2874 to experimental, the intent of this document is that use of DNAME RRs in the reverse tree be deprecated. do you difficulties in parsing? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Having been present at the meeting that gave rise to the document (at the IETF meetings held in London, August 2001), I'd say that the material quoted in the document is at fault. (There was quite a lot of controversy at the meeting, perhaps my recollection isn't shared with all others. But this is my story and I'm sticking to it.) The changes in status of bit labels, the A6, and DNAME were discussed in the context of DNS's support of IPv6. At the time the main debate was whether or not DNS records ought to be defined to support renumbering (among other features, but renumbering was the star). A6 and bit sting labels (forward and reverse) proved to be too much for the DNS to handle, the new thought was that such functionality ought to be pulled out of DNS and into tools the pre-processed zone definitions. E.g., something that generated AAAA records from a database, etc. DNAME was kind of the "third record in." The change in it's "status" pertained to the role it played in supporting bit sting labels - which is why the "reverse tree" is mentioned in the deprecation. Looking at the document now, the document ought to have read "the use of DNAME RRs in the support of bit string labels is deprecated" - based on my memory. PS - Note that DNAMEs are defined in RFC 2672, not in 2874. If you want to get all "IETF document lawyerish" about it (;)), the quoted material is referencing a discussion of DNAME in the context of supporting renumbering, not the definition DNAME itself. RFC 2672: Non-Terminal DNS Name Redirection RFC 2874: DNS Extensions to Support IPv6 Address Aggregation and Renumbering At 14:45 +0200 2/11/04, Pekka Savola wrote:
On Wed, 11 Feb 2004, Mark Andrews wrote:
RFC 3363 does NOT say that DNAME is deprecated. All it says is that since A6 was moving the exprimental using DNAME to support renumbering is deprecated.
Which part of:
Therefore, in moving RFC 2874 to experimental, the intent of this document is that use of DNAME RRs in the reverse tree be deprecated.
do you difficulties in parsing?
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer History repeats, therefore my life is a rerun.
edlewis@arin.net (Edward Lewis) writes:
... DNAME was kind of the "third record in." The change in it's "status" pertained to the role it played in supporting bit sting labels - which is why the "reverse tree" is mentioned in the deprecation. Looking at the document now, the document ought to have read "the use of DNAME RRs in the support of bit string labels is deprecated" - based on my memory.
I wasn't there, but that's what the meeting notes seem to say, and that's what the people who were there all seem to agree on. Not that it matters; the type is defined and at least one authority server implementation will synthesize protocol-compliant CNAME RRs in the presence of DNAMEs, and so the approach documented at www.isc.org/pubs/tn/ will universally work OK. -- Paul Vixie
-----BEGIN PGP SIGNED MESSAGE----- Paul Vixie wrote: <SNIP>
the type is defined and at least one authority server implementation will synthesize protocol-compliant CNAME RRs in the presence of DNAMEs, and so the approach documented at www.isc.org/pubs/tn/ will universally work OK.
In that case why don't the RIR's setup their parts of the ip6.int tree to DNAME to the relevant ip6.arpa part until say 6/6/2005 ? And the 6bone does it in reverse, setup a DNAME from ip6.arpa to ip6.int, taking care of the deployment issues as the pTLA's will have to either do a DNAME etc... People using 6bone space will need to renumber out onto RIR space per 6/6/6 anyways and thus will also have the chance to 'renumber/rename' into ip6.arpa at the same time. The only problem here is that when ip6.int goes away, that is per my proposed data of 6/6/2005, 'suddenly' all the software, which effectively has been broken already for the last two years will 'break', that is not resolve as ip6.int will return NXDOMAIN after that date. Also see my note on v6ops. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / http://unfix.org/~jeroen iQA/AwUBQCqkaimqKFIzPnwjEQLdKACfU53VVR8R0IGweS+t3sJkVkCbWEMAnjdg G+XG/wTmFcRcnUJLtg4bH+PQ =M4eC -----END PGP SIGNATURE-----
Having been present at the meeting that gave rise to the document (at the IETF meetings held in London, August 2001), I'd say that the material quoted in the document is at fault. (There was quite a lot of controversy at the meeting, perhaps my recollection isn't shared with all others. But this is my story and I'm sticking to it.)
The changes in status of bit labels, the A6, and DNAME were discussed in the context of DNS's support of IPv6. At the time the main debate was whether or not DNS records ought to be defined to support renumbering (among other features, but renumbering was the star). A6 and bit sting labels (forward and reverse) proved to be too much for the DNS to handle, the new thought was that such functionality ought to be pulled out of DNS and into tools the pre-processed zone definitions. E.g., something that generated AAAA records from a database, etc.
DNAME was kind of the "third record in." The change in it's "status" pertained to the role it played in supporting bit sting labels - which is why the "reverse tree" is mentioned in the deprecation. Looking at the document now, the document ought to have read "the use of DNAME RRs in the support of bit string labels is deprecated" - based on my memory.
PS - Note that DNAMEs are defined in RFC 2672, not in 2874. If you want to get all "IETF document lawyerish" about it (;)), the quoted material is referencing a discussion of DNAME in the context of supporting renumbering, not the definition DNAME itself.
RFC 2672: Non-Terminal DNS Name Redirection RFC 2874: DNS Extensions to Support IPv6 Address Aggregation and Renumbering
Also neither RFC 3363 nor RFC 3364 update RFC 2672. Note the second paragraph quated from RFC 2672. DNAME is still very much alive. DNAME RRs [RFC2874] also proposes using DNAME RRs as a way of providing the equivalent of A6's fragmented addresses in the reverse mapping tree. That is, by using DNAME RRs, one can write zone files for the reverse mapping tree that have the same ability to cope with rapid renumbering or GSE-style routing that the A6 RR offers in the main portion of the DNS tree. Consequently, the need to use 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. Other uses have also been proposed for the DNAME RR, but since they are outside the scope of the IPv6 address discussion, they will not be addressed here.
At 14:45 +0200 2/11/04, Pekka Savola wrote:
On Wed, 11 Feb 2004, Mark Andrews wrote:
RFC 3363 does NOT say that DNAME is deprecated. All it says is that since A6 was moving the exprimental using DNAME to support renumbering is deprecated.
Which part of:
Therefore, in moving RFC 2874 to experimental, the intent of this document is that use of DNAME RRs in the reverse tree be deprecated.
do you difficulties in parsing?
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer
History repeats, therefore my life is a rerun. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org
if i try to log into my machines back in tokyo by IPv6 SSH, it takes very long time. i guess i found the reason - (possible) lame delegation of blah.ip6.int. ip6.arpa. query returns instantly. how could we fix it?
the ip6.int entry times out, no servers reached. the ip6.arpa entry fails immediately w/ NXDOMAIN. the delegation for 3ffe:37:: is 7.3.e.f.f.3.ip6.int. in ns gemini.psc.edu. in ns charon.psc.edu. ..... these servers are -NOT- responding to queries. perhaps you should contact Michael Lambert for more detail.
itojun
% dig e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.int. ptr
; <<>> DiG 9.2.3 <<>> e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.int. ptr ;; global options: printcmd ;; connection timed out; no servers could be reached
% dig e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.arpa. ptr
; <<>> DiG 9.2.3 <<>> e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.arpa. ptr ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19137 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION: ;e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.arpa. IN PTR
;; AUTHORITY SECTION: ip6.arpa. 10569 IN SOA dns1.icann.org. hostmaster.icann.org. 2003080400 3600 1800 604800 10800
;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(0.0.0.0) ;; WHEN: Tue Feb 10 21:57:17 2004 ;; MSG SIZE rcvd: 151
In article <20040210125840.0C2C9EB@coconut.itojun.org> you write:
if i try to log into my machines back in tokyo by IPv6 SSH, it takes very long time. i guess i found the reason - (possible) lame delegation of blah.ip6.int. ip6.arpa. query returns instantly. how could we fix it?
itojun
% dig e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.int. ptr
; <<>> DiG 9.2.3 <<>> e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.int. ptr ;; global options: printcmd ;; connection timed out; no servers could be reached
% dig e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.arpa. ptr
; <<>> DiG 9.2.3 <<>> e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.arpa. ptr ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19137 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION: ;e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.arpa. IN PTR
;; AUTHORITY SECTION: ip6.arpa. 10569 IN SOA dns1.icann.org. hostmaster.icann.org. 2003080400 3600 1800 604800 10800
;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(0.0.0.0) ;; WHEN: Tue Feb 10 21:57:17 2004 ;; MSG SIZE rcvd: 151
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. Mark
-----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 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. I guess DNAME is getting used more for a purpose for which it wasn't intended at first ;) Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / http://unfix.org/~jeroen iQA/AwUBQClxTCmqKFIzPnwjEQLsEACfTWllm2ul5Eb8Umo1wFOca+KHuC8An3yh Vaz4pe0/rWXv6km0/7/nNzu4 =cGP8 -----END PGP SIGNATURE-----
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
participants (11)
-
bill -
Edward Lewis -
itojun＠itojun.org -
Jeroen Massar -
leo vegoda -
Mark Andrews -
Mark.Andrews＠isc.org -
Paul Vixie -
Pekka Savola -
Randy Bush -
Ronald van der Pol