[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Jim.Bound@nokia.com
cc: seamus@bit-net.com, users@ipv6.org, dnsop@cafax.se, ngtrans@sunroof.eng.sun.com
From: Robert Elz <kre@munnari.OZ.AU>
Date: Wed, 24 Jan 2001 15:11:43 +0700
In-reply-to: Your message of "Tue, 23 Jan 2001 12:15:31 CST." <B9CFA6CE8FFDD211A1FB0008C7894E4603063B3F@bseis01nok>
Sender: owner-dnsop@cafax.se
Subject: Re: (ngtrans) Re: IPv6 dns

    Date:        Tue, 23 Jan 2001 12:15:31 -0600
    From:        Jim.Bound@nokia.com
    Message-ID:  <B9CFA6CE8FFDD211A1FB0008C7894E4603063B3F@bseis01nok>

  | Those debates were before running code.  The running code is not going to 
  | scale and is not scaling.  Or does that not mean anything anymore?  Granted 
  | this is an extrapolation to BIND 9 code base as its not widely deployed.

Exactly.   I don't think I have come across an A6 record yet (not that
I have been looking hard though).

  | Just the points D. Bernstein raised by definition
  | implies BIND 9 resolvers will not scale hacking A6 hierarchies.

Nonsense.  He also claims that NS and MX records should contain addresses,
rather than names, for the same reasons (exactly).

And that is supposed to be evidence that NS and MX records don't work???
I think we have rather more evidence the other way.

Certainly it is possible to badly configure NS and MX such that they
won't work, and it will be possible to configure A6 so that it won't
work.   That doesn't mean that it will never work however.

  | We know it won't work now.

No we don't.    You think it won't.   That's as far as it goes.

  | ALso 3 or a few more levels can be enforced in the BIND
  | code if we put it there.

You can easily enforce it in the resolver end (just as it is, or
would be, possible to enforce NS's not being aimed at CNAMEs, etc).
It is almost impossible to enforce at the server end, which is
where it would need to be to actually be effective.   Otherwise you
just get names that don't resolve (and whether that is because your
resolver detected what it considers to be an error, or because it
was still out there working when you or the application decided to
give up in frustration doesn't really matter).

  | I do see your point but I think a compromise is to reduce the hiearchy to
  | some value folks can agree to and when that works and we learn more
  | about A6 we can later address increased hieararchy.

I have no problems suggesting to people that resolvers might not be willing
to chase the chain longer than N steps, and that if they make it longer than
that they're going to likely cause name failures.   That could even go in the
docs (resolvers SHOULD NOT follow A6 chains more than N long) if that will
help.   But I don't think anything more than that is rational.

kre


Home | Date list | Subject list