RE: IPv6 reverse lookup - lame delegation?

[Jeroen Massar]

-BEGIN PGP SIGNED MESSAGE-

Nico Schottelius [mailto:[EMAIL PROTECTED] wrote:

> Hello!
> 
> I am more or less new to nanog (reading it about half a year),
> so please correct me, if I do something wrong.
> 
> Jeroen Massar [Tue, Feb 10, 2004 at 02:07:27PM +0100]:
> > 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.
> 
> I've read the RFC and also talked to some people using IPv6 adresses,
> especially some using 6to4 (2002:/16).
> 
> As far as I know the reverse mapping for 2002 is only 
> available through ip6.int, or am I wrong? 

Not wrong but correct. Delegations for that block can
be requested by emailing [EMAIL PROTECTED]

But Geoff Huston has already published this draft:
http://www.ietf.org/internet-drafts/draft-huston-6to4-reverse-dns-01.txt
Which should solve the 6to4 problem.

Personally I would say that 6to4 shouldn't be given reverse
though, if people require that they are better off getting
either native or tunneled IPv6 instead of this transition
method especially because of the low deployment of 6to4 relays.

> I think this is because 2002: is a test zone. But for me using
> it almost always the only way to have reverse mapping is ip6.int.

Get yourself a tunneled or native prefix from a LIR closeby.
6to4 is not testing, it is transition and it works(tm).

Greets,
 Jeroen

-BEGIN PGP SIGNATURE-
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / http://unfix.org/~jeroen

iQA/AwUBQD8r8CmqKFIzPnwjEQKKHgCgqUR7Pj9cTamJlNBTEknTyF7k4BcAoKQP
mum12QVg91rWgM2R2sqNDjU8
=6MzS
-END PGP SIGNATURE-

Re: IPv6 reverse lookup - lame delegation?

[bill]

> 
> 
> 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 <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

-IF- (its a big one) we can get the IANA to agree, then the 
DNAME haq would be implemented post haste.

--bill

Re: IPv6 reverse lookup - lame delegation?

[Todd Vierling]

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 <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: IPv6 reverse lookup - lame delegation?

[Paul Vixie]

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

Re: IPv6 reverse lookup - lame delegation?

[Jun-ichiro itojun Hagino]

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

RE: IPv6 reverse lookup - lame delegation?

[Jeroen Massar]

-BEGIN PGP SIGNED MESSAGE-

Paul Vixie wrote:


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

Re: IPv6 reverse lookup - lame delegation?

[Mark . Andrews]

> 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  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 Oykingdom 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: [EMAIL PROTECTED]

Re: IPv6 reverse lookup - lame delegation?

[Paul Vixie]

[EMAIL PROTECTED] (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

Re: IPv6 reverse lookup - lame delegation?

[Paul Vixie]

> > ...  ...
> 
> 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 , and
we made sure that BIND9 authority servers handle DNAME RRs properly.

Re: IPv6 reverse lookup - lame delegation?

[Jun-ichiro itojun Hagino]

> > > or just put  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

Re: IPv6 reverse lookup - lame delegation?

[Paul Vixie]

> > or just put  into effect.
> 
> I am confused. Are DNAMEs deprecated or not (RFC3363, section 4)?

A6 and bitstring labels are deprecated.  DNAME remains in full force.

Re: IPv6 reverse lookup - lame delegation?

[Edward Lewis]

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

Re: IPv6 reverse lookup - lame delegation?

[Pekka Savola]

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 Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: IPv6 reverse lookup - lame delegation?

[Mark Andrews]

In article <[EMAIL PROTECTED]> you write:
>
>On Wed, Feb 11, 2004 at 00:36:19 +, Paul Vixie wrote:
>
>> or just put  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

Re: IPv6 reverse lookup - lame delegation?

[Ronald van der Pol]

On Wed, Feb 11, 2004 at 00:36:19 +, Paul Vixie wrote:

> or just put  into effect.

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

rvdp

Re: IPv6 reverse lookup - lame delegation?

[leo vegoda]

Jeroen Massar <[EMAIL PROTECTED]> 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

Re: IPv6 reverse lookup - lame delegation?

[Jun-ichiro itojun Hagino]

> 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?
> 
> [EMAIL PROTECTED] ("Jeroen Massar") writes:
> > By fixing the software as ip6.int was deprecated 2 years+++ ago as you
> > should already know.
> 
> or just put  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

Re: IPv6 reverse lookup - lame delegation?

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

[EMAIL PROTECTED] ("Jeroen Massar") writes:
> By fixing the software as ip6.int was deprecated 2 years+++ ago as you
> should already know.

or just put  into effect.
-- 
Paul Vixie

Re: IPv6 reverse lookup - lame delegation?

[Mark Andrews]

In article <[EMAIL PROTECTED]> 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

RE: IPv6 reverse lookup - lame delegation?

[Jeroen Massar]

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

Re: IPv6 reverse lookup - lame delegation?

[Mark Andrews]

In article <[EMAIL PROTECTED]> 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

RE: IPv6 reverse lookup - lame delegation?

[Jeroen Massar]

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

RE: IPv6 reverse lookup - lame delegation?

[Randy Bush]

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

Re: IPv6 reverse lookup - lame delegation?

[bill]

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

RE: IPv6 reverse lookup - lame delegation?

[Jeroen Massar]

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

RE: IPv6 reverse lookup - lame delegation?

[Jun-ichiro itojun Hagino]

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

RE: IPv6 reverse lookup - lame delegation?

[Jun-ichiro itojun Hagino]

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

RE: IPv6 reverse lookup - lame delegation?

[Jeroen Massar]

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

IPv6 reverse lookup - lame delegation?

[Jun-ichiro itojun Hagino]

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