Subject: RE: (ngtrans) Re: IPv6 dns

From: [email-masked]
Date: Tue, 23 Jan 2001 12:15:31 -0600

| I also think the
  | processing of A6 should not be done on clients but on the servers.

>That argument was made (by you, and others) back when A6 was being
>debated.   If you care to look back over the archives (IPNG, and
>perhaps DNSIND) you will see why things are the way they are.
>I'm sure you will recall that it wasn't just that no-one thought
>of the possibility...

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

that is what good engineers do.  Just the points D. Bernstein raised by
definition
implies BIND 9 resolvers will not scale hacking A6 hierarchies.  I am not
comfortable
just saying then let it be if people do stupid things.  The reason is that
the 
engineers at the vendors who ship BIND as software get the calls to fix it.
We 
know it won't work now.  ALso 3 or a few more levels can be enforced in the
BIND
code if we put it there.

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.

regards,
/jim

---

From: Robert Elz <[email-masked]>
Date: Wed, 24 Jan 2001 15:11:43 +0700

Date:        Tue, 23 Jan 2001 12:15:31 -0600
    From:        [email-masked]
    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

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Jan 2001 09:03:03 -0500

>  But I don't think anything more than that is rational.

What would be rational is for the complete address to be updated
at the primary server for the zone and propagated from there to
secondaries, caches, etc.  That way, everyone gets the same view
of those addresses (modulo old cached entries), and if the address
is wrong, it's more likely to be noticed by "locals".  With A6,
the various parts of an address arrive by different paths and 
there is a greater potential not only for delay and failure, but
also for incorrect information that is not detected by the "locals"
for that address.

Keith

---

From: Robert Elz <[email-masked]>
Date: Thu, 25 Jan 2001 16:26:22 +0700

Date:        Wed, 24 Jan 2001 09:03:03 -0500
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | What would be rational is for the complete address to be updated
  | at the primary server for the zone and propagated from there to
  | secondaries, caches, etc.

Unless you mean just using AAAA, or using only A6 0 (ie: some person
updates the address at the primary server, just like they do an A
record), how is the primary server supposed to sign this new record it
has formulated?

Remember that one of the scenarios for use of DNSSEC (not necessarily
one everyone will use, but one that has to be supported), is for the
zone file to be written to demountable media (floppy, zip, tape, ...)
and carried to a 100% isolated system, signed there, written (along
with the DNSSEC records generated) back to the magnetic media, and
physically carried back to the nameserver.

All that is a little difficult for a DNS server to accomplish all
by itself.

  | With A6,
  | the various parts of an address arrive by different paths and 
  | there is a greater potential not only for delay and failure, but
  | also for incorrect information that is not detected by the "locals"
  | for that address.

Yes.   There are trade offs involved here.   Once again, what is needed
is for some experimentation with the things, so we can see how well (and
in fact, if) they work well enough to use, and less theorising about how
they cannot possibly work...

kre

---

From: Keith Moore <[email-masked]>
Date: Thu, 25 Jan 2001 09:48:00 -0500

> record), how is the primary server supposed to sign this new record it

practically speaking, renumbering is a LONG way from being automatic,
even with A6, mods to DHCP, etc.  you still have firewall access control 
lists to update, for example.  manually re-signing the zone is just one 
more thing.

but even if you use A6 with nonzero prefix lengths, how do you verify
the authenticity of any DNSSEC signed record?  it's not sufficient 
to verify that they were signed by whom they say they were signed -
you also need to verify that those people had the authority to make
assertions about that prefix and that portion of DNS name space.
I won't say that you can't work out a way of doing this with DNSSEC,
but I will claim that the number of additional records that you need 
to do this (beyond just the chain of A6 records) makes it prohibitive  
in all but extreme cases.

> they cannot possibly work...

when you can predict the limitations of A6 using engineering analysis,
expreimentation on a live population doesn't seem necessary.

Keith

---

From: Robert Elz <[email-masked]>
Date: Fri, 26 Jan 2001 23:20:39 +0700

Date:        Thu, 25 Jan 2001 09:48:00 -0500
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | but even if you use A6 with nonzero prefix lengths, how do you verify
  | the authenticity of any DNSSEC signed record?

Huh?   If it is my name you are looking up, and I have an A6 record
that lists a name in your namespace as providing the upper bits of
the address, then I have just delegated that authority to you.   The
SIG on my A6 record will verify that.   The regular chain of SIG/NS/KEY
records will verify that the A6 record from your server is authentic,
and the SIG on your A6 will verify its authenticity.

What's the problem here?

It is known that you have the authority about that part of the
address space, because my A6 record (which would have given the
entire address had it been an AAAA record, and could have, even
as an A6 record) says so.  At least it says so for the purposes of
this particular address, but that's all that is relevant.

kre