RE: (ngtrans) Re: IPv6 dns

[Jim.Bound@nokia.com]

-----Original Message-----
  | 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).

No it will not scale at all its not nonsense. Also I agree with Dan on the
NS
and MX records too. In fact so far Dan has provided technical arguments and
I
have seen no one counter them.

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.

Dan and I are arguing different points.  I am telling you and others that
the
"C" code to make this work is not going to scale and will have to be changed
and
evolved.  But if we put the indirection at the server we can build it in
BIND, DENT,
MS-DNS, et al and leave the clients alone.  The A6 specs now force the
client DNS
code to deal with major caching and roundtrip requests to get the complete
A6 record
in the worst case.  If we put that burden on the servers engineers can
develop the 
"C" code to make it work and deliver it in releases so we can extend it
tomorrow.
Dan's position on the cost of queries is 100% correct.  That data means we
should
put the A6 processing on the server.  Or at least have that option in the 
DNS development community to make this work and IMO scale.

So I am not debating this from a system administrators view but an engineers
view
who ships products.  Its an implementation red flag I am raising per this
new conversation.

  | We know it won't work now.

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

If the BIND code is used for more than 2 or maybe 3 levels it WILL NOT WORK.
Now work
to me means:  Production code in Production Networks for real Business
operations. 
So I don't agree with your claim we don't know.  We do know.  Have you
looked at the BIND 
9 code for this?  I have.

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

Of course it can be enforced at the server within the NS delegations.  But I
may
have misunderstood your point above?

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

That may work I just am not 100% convinced.  I would like to see someone
refute
what Dan is saying I have not seen that.

/jim