IPv6 reverse lookup - lame delegation?

Mailman List Mirror (Read Only)
1

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

2

-----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

3

> 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

4

> > 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

5

-----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 :wink:
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 :wink:

Greets,
Jeroen

6

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

7

-----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 :wink:

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

8

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

9

-----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 :wink:

Greets,
Jeroen

10

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 :wink:

  No. RENAMING was a explicitly intended use.
  
  Mark

11

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&gt; into effect.

12

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&gt; 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

13

[...]

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,

14

I am confused. Are DNAMEs deprecated or not (RFC3363, section 4)?

  rvdp

15

In article <20040211105437.GA506@rvdp.org> you write:

or just put <http://www.isc.org/pubs/tn/?tn=isc-tn-2002-1.txt&gt; 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

16

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?

17

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

18

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.

19

-----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