Subject: An easy example of A6 unreliability

From: "D. J. Bernstein" <[email-masked]>
Date: 23 Jan 2001 20:02:47 -0000

Brian E Carpenter writes, on three other mailing lists:
> I think it was recognized a long time ago that the initial deployment
> of A6 records should be limited to two (or at most 3) levels. The question
> is whether that is enough to avoid the horrors described by Dan Bernstein 
> over on IPNG.

The answer is ``of course not.'' Here's an example with just one level
of A6 records:

   aol.com NS dns-01.ns.aol.com
   aol.com NS dns-02.ns.aol.com

   aol.net NS dns-01.ns.aol.com
   aol.net NS dns-02.ns.aol.com

   dns-01.ns.aol.com A6 ... prefix.aol.net
   dns-02.ns.aol.com A6 ... prefix.aol.net

Now aol.com and aol.net are unreachable. AOL already has these NS
records, and it's _encouraged_ to set up these A6 records, right?

Details of the failure: Say a cache needs the address of www.aol.com.
It contacts the .com servers and learns

   aol.com NS dns-01.ns.aol.com
   aol.com NS dns-02.ns.aol.com
   dns-01.ns.aol.com A6 ... prefix.aol.net
   dns-02.ns.aol.com A6 ... prefix.aol.net

but it won't accept the address of prefix.aol.net from the .com servers
even if that address is provided. (Yes, it's theoretically possible for
caches to see that this isn't poison because the .com servers are the
same as the .net servers, but let's fast forward to a time when the .com
servers and the .net servers have been separated.)

The cache now puts the www.aol.com query on hold. It needs the address
of prefix.aol.net. It contacts the .net servers and learns

   aol.net NS dns-01.ns.aol.com
   aol.net NS dns-02.ns.aol.com

but it won't accept the addresses of *.aol.com from the .net servers
even if those addresses are provided. It puts the prefix.aol.net query
on hold; it needs the addresses of dns-*.ns.aol.com. Repeat ad nauseam.

---Dan
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 23 Jan 2001 14:35:17 -0600

Dan, Your message is incomplete.  You failed to include the
alternative scheme which would have made it impossible for a
careless zone administrator to shoot himself in the foot.

Also, note that server synthesis of address records would
require a DNSSEC zone-signing key to be kept on-line, which
would lead to widespread theft of keys and secured spoofing
of DNS records.

It's possible to do the synthesis in a somewhat less
insecure "outboard" way with A6 just as with AAAA (at the
cost of one extra byte per record) if desired.

Finally, I point to 2874's text on glue, which includes

   [...]
   any of

   o  a minimal set of A6 records duplicated from the X.EXAMPLE zone,

   o  a (possibly smaller) set of records which collapse the structure
      of that minimal set,

   o  or a set of A6 records with prefix length zero, giving the entire
      global addresses of the servers.

   The trade-off is ease of maintenance against robustness.  The best
   and worst of both may be had together by implementing either the
   first or second option together with the third.

Following this suggestion would turn your example into

   aol.com NS dns-01.ns.aol.com
   aol.com NS dns-02.ns.aol.com
   dns-01.ns.aol.com A6 <len> <suffix bits> prefix.aol.net
                     A6 0 <full address>
   dns-02.ns.aol.com A6 <len> <suffix bits> prefix.aol.net
                     A6 0 <full address>

The full address is usable with no other data cached, and
the broken-up record may save the day in *some* cases if the
full-address record becomes incorrect while still "live".
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "D. J. Bernstein" <[email-masked]>
Date: 23 Jan 2001 21:47:40 -0000

Matt Crawford writes:
> You failed to include the alternative scheme which would have made it
> impossible for a careless zone administrator to shoot himself in the
> foot.

How can you call it ``careless'' for AOL to set up A6 records from
*.aol.com to prefix.aol.net? Your spec encourages people to use A6
records this way. These records simply happen to interact badly with
AOL's existing NS records to destroy AOL's reachability.

Your ``alternative scheme'' is server-side indirection. The server
provides full addresses. That's precisely my point: the reliability
problems are an artifact of client-side indirection.

You go on to complain about the occasional effort required for the
server to sign records after renumbering. This complaint applies to your
``alternative scheme'' too. You haven't proposed any way to avoid this
without creating reliability problems.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Wed, 24 Jan 2001 16:10:30 +0700

Date:        23 Jan 2001 21:47:40 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Your ``alternative scheme'' is server-side indirection.

Matt's scheme was server side indirection, but done by humans, not by
the server.   That solves the worst of the problems (how to sign the
data) but introduces all the others that are typical of human maintained
data.

  | You go on to complain about the occasional effort required for the
  | server to sign records after renumbering.

It isn't the effort, it is access to the key that matters.   If the
server (software) is doing the indirection, the software needs access
to the key, or it cannot sign the records.   Software access to the
key (on an on-line system like a DNS server) makes it available to
other software to misappropriate.

  | This complaint applies to your
  | ``alternative scheme'' too. You haven't proposed any way to avoid this
  | without creating reliability problems.

Not really - Matt's scheme gave two A6 record chains to the host.
One of them might happen to contain an invalid address sometimes, if
the server hasn't been updated with the new one yet.  That address may
turn out to be unreachable on occasion.   Nothing different to what we
have now really.   It didn't have the server reaching out and building
its own address.

But if we stop postulating servers that are irrational about what glue
they accept from where -- they're willing to take an NS, or A6 record, but
not the glue necessary to make it work?  The glue is less reliable than
authoritative data, certainly, but simply refusing it out of hand is
irrational - if the querying server (cache, resolver) doesn't have any
better data available, it ought start by accepting the glue and using it,
not just claiming "that isn't your data to give me" and ignoring it.
If it wants, it can go verify the glue with an authoritative server
after making use of it the first time.

If clients can be expected to use the glue they're given, then the
hard cases can mostly be gotten around by supplying appropriate glue
from the server.   Glue has been a part of the DNS from the beginning,
invented precisely to get around the client side indirection in NS
records.   I wasn't around that far back, but I wouldn't be surprised
if the client/server side argument wasn't held back then as well,
and we know what the outcome of that obviously was.

I have had about enough of this debate for now - we need to get some
real experience of using A6 records, rather than theories of why they
might not sometimes work.   We know that NS and MX records work, despite
client side indirection (even if it is possible to find some odd cases
where the configuration is bad enough that it causes problems).  Let's
just find out whether A6 works or not.   If it doesn't, we will change
it, or drop it.   If it does, they arguments based upon the theory of
why it cannot possibly work (despite the evidence) can be put where they
belong.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 24 Jan 2001 17:11:55 -0000

Robert Elz writes:
> We know that NS and MX records work,

I'd like to see you explain that to the owner of www.monty.de.

As for your insane suggestion that caches should stop rejecting poison:
That wouldn't save www.monty.de; servers don't even _try_ to provide
out-of-bailiwick glue any more. For example, the .de servers don't know
the addresses of the monty.de servers (in .norplex.net), and the .net
servers don't know the addresses of the norplex.net servers (in .de).

---Dan

---

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

Date:        24 Jan 2001 17:11:55 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Robert Elz writes:
  | > We know that NS and MX records work,
  | I'd like to see you explain that to the owner of www.monty.de.

I didn't say it wasn't possible to configure them to not work.
I said that they work usually, with any sane configuration.
The wild bouncing of delegations between .DE and .NET that exists
in that case is just too absurd for belief.   To the owner of www.monty.de
I'd simply suggest that they go find an ISP who has half a clue how to
set up DNS delegations that work in practice.  Let those who don't
just vanish from the scene.

  | As for your insane suggestion that caches should stop rejecting poison:
  | That wouldn't save www.monty.de; servers don't even _try_ to provide
  | out-of-bailiwick glue any more. For example, the .de servers don't know
  | the addresses of the monty.de servers (in .norplex.net), and the .net
  | servers don't know the addresses of the norplex.net servers (in .de).

Yes, there does seem to have been rather a "going overboard" on
avoiding glue recently.   This is an unfortunate effect of the way
the IETF and the markets work - anything that is ever seen as having
some kind of bad effects (in almost any circumstances) is condemned.
Then all traces of that are likely to be burned at the stake, whether
good of bad, needed or not.

It used to be that servers (caches really) would believe any old glue
from anywhere, and treat it as valuable as authoritative data direct
from an authoritative server.  That was obviously stupid.   So, that
gets fixed, fine.   But because we can't trust people to upgrade their
old servers (caches) and we have to save them from themselves, we also
"fix" the servers to not send any glue, except when it is obvious from
simple inspection that it must be required.   It has long been known
that delegations each of which name the other's servers breaks with
this overly restrictive glue methodology.   If a server knows the address
records (which includes any case where they have been configured into it)
it should be sending them as the DNS specs call for.  Then if the
recipient of that information decides that it has better information that
it would prefer to use (or would prefer to obtain more reliable information
from elsewhere) that's its choice.

kre

---

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

ps:...

brandenburg$ dig www.monty.de. a

; <<>> DiG 8.2 <<>> www.monty.de. a 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;;      www.monty.de, type = A, class = IN

;; ANSWER SECTION:
www.monty.de.           1D IN CNAME     monty.de.
monty.de.               1D IN A         151.189.12.194

;; AUTHORITY SECTION:
monty.de.               1D IN NS        ns.norplex.net.
monty.de.               1D IN NS        ns2.norplex.net.

;; ADDITIONAL SECTION:
ns.norplex.net.         1D IN A         151.189.12.193
ns2.norplex.net.        1D IN A         151.189.26.234

;; Total query time: 1850 msec
;; FROM: brandenburg.cs.mu.OZ.AU to SERVER: default -- 192.100.77.5
;; WHEN: Thu Jan 25 16:44:35 2001
;; MSG SIZE  sent: 30  rcvd: 146

The RTT from where I am at the minute to most of the world is 800ms
approx (or more):

PING ns.uu.net (137.39.1.3): 56 data bytes
64 bytes from 137.39.1.3: icmp_seq=1 ttl=235 time=791.274 ms
64 bytes from 137.39.1.3: icmp_seq=2 ttl=235 time=771.218 ms
64 bytes from 137.39.1.3: icmp_seq=3 ttl=235 time=828.094 ms

so to find that A record, all that could have been needed (in practice)
was just 2 round trips... (to get into Germany if that was ever actually
needed would take longer per round trip).

So, in practice, I suspect that the owner of we.monty.de is probably
not too worried, despite the absurd setup of the various nameservers
that leads to that domain.

Note that the answer had the AA bit set - it didn't just appear out
of some local cache.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 25 Jan 2001 10:32:27 -0000

Here's what the bind-users report said about www.monty.de: ``I recently
had to explain to customers that no it's not our fault that our name
servers can't resolve that name. And by the way, no it doesn't work on
the second try or the third.''

C'mon, everybody, try it! Ask your cache for the www.monty.de address.
I tried several BIND caches; they all failed. I've already explained in
detail how much work dnscache has to go through to find the address.

Elz seems to understand that the www.monty.de disaster is a powerful
argument against the relevant aspects of the DNS design. So now he's
denying the facts. He wants you to believe that www.monty.de is okay.

> ;; Total query time: 1850 msec

That's nice. Try again from an empty cache.

> Note that the answer had the AA bit set - it didn't just appear out

Don't be an idiot. That packet is straight from {ns,ns2}.norplex.net.
What you had in your cache was the addresses of those servers.

> was just 2 round trips...

Don't be an idiot. In practice, most caches don't have the *.norplex.net
addresses lying around when they are asked about www.monty.de.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Thu, 25 Jan 2001 18:42:48 +0700

Date:        25 Jan 2001 10:32:27 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Elz seems to understand that the www.monty.de disaster is a powerful
  | argument against the relevant aspects of the DNS design. So now he's
  | denying the facts. He wants you to believe that www.monty.de is okay.

No I don't.   Read the messages).  Their setup is bogus (and probably not
directly their fault - other than by choosing an inept ISP).   The
difference is that you're arguing that because it is possible to abuse the
delegation process, the process should be changed.   On the other hand
I say that most of the time it all works just fine, and that altering
the process because of a few hard cases (I'm sure you can find more
than just this one if you look) is the wrong attitude.   There are millions
of delegations that work just fine - they all could work just fine if
configured rationally.

  | Don't be an idiot. That packet is straight from {ns,ns2}.norplex.net.
  | What you had in your cache was the addresses of those servers.

Yes, most likely.   As I said, in practice, accesses to that name
probably work well enough that the name owner isn't too bothered
about it.   The setup is still bogus, and should be fixed though.
If the owner of the domain were worried, the correct recourse would
be to change to an ISP that knows how to setup the DNS properly
(or at least has lucked upon something that is adequate).

  | Don't be an idiot. In practice, most caches don't have the *.norplex.net
  | addresses lying around when they are asked about www.monty.de.

They probably do, if they're asked about the name often enough for it
to matter.   If you start at a clean cache and ask once, you're
probably right, it will fail.   The vast majority of the users probably
don't even give that a second thought - things failing is somehow
treated as "normal".   So they try again - and by this time the
cache has more info, either enough for it to succeed, or at least
get a lot further (and then perhaps third time lucky).

And no, this is not good - but it is because the delegation system
has been abused.   And no, I do not think we need to make the system
idiot proof.   And I also don't know of any way of doing server
side indirection that would both be any better (which means that
human maintenance is out of the question) and actually implementable
the way the DNS should be working (the difficulty of signing a
record the server invents out of other data makes it a non-trivial
problem).

kre

---

From: "Matt Crawford" <[email-masked]>
Date: Thu, 25 Jan 2001 09:00:19 -0600

> So they try again - and by this time the cache has more info,
> either enough for it to succeed, or at least get a lot further (and
> then perhaps third time lucky).

(I got it on the third try, starting from nothing cached.)

But let me bring up a related problem ...

I've had occasions of users (and servers) here that couldn't
communicate because they had screwed up their default route and/or
netmask.  Obviously setting these parameters is an error-prone
procedure that leads to operational instability.  Even DHCP is not a
reliable solution because the server gets its information from human
hands.

What I've implemented on all our systems and routers is much more
robust and I think it should be added to a new rev of the host &
router requirements docs immediately:

    Every host sending a packet SHALL encapsulate that packet using
    the appropriate IP-in-IP header and send it to the all-routers
    multicast address.  Routers receiving such a packet SHALL
    decapsulate and forward it.

Sure, this leads to some duplicatation, but that's allowed by the IP
spec.  It does prevent the occasional configuration error from
stopping the communication.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Robert Honore <[email-masked]>
Date: Thu, 25 Jan 2001 11:54:39 -0400

Dear Matt Crawford,

You said,

> stopping the communication.

Your wording seems to indicate to me that that SHALL is to be interpreted as
MUST.  To me that is disagreeable, as it punishes properly configured nodes as
badly as incorrectly nodes.  Perhaps the behaviour you recommend should be set
as a default for hosts and routers and giving the operators some kind of
mechanism to change that default behaviour.

Yours sincerely,
Robert Honore.

---

From: [email-masked]
Date: Fri, 26 Jan 2001 01:04:54 +1100

Dan stop assuming things about BIND 9's behaviour based on
	BIND 8's behaviour.  We have said many times that there
	are architectual flaws in BIND 8.  BIND 9 was written from
	scratch to get around those problems.  The server in question
	is running BIND 9.1.

	The elasped time also includes retries due to EDNS probes.

drugs# ps ax | grep named
  150  ??  Ss     0:00.77 /usr/local/sbin/named
  719  p0  S+     0:00.00 grep named
drugs# kill 150
drugs# /usr/local/sbin/named
drugs# dig www.monty.de

; <<>> DiG 8.3 <<>> www.monty.de 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;;      www.monty.de, type = A, class = IN

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:
ns.norplex.net.         23h59m58s IN A  151.189.12.193
ns2.norplex.net.        23h59m58s IN A  151.189.26.234

;; Total query time: 6887 msec
;; FROM: drugs.dv.isc.org to SERVER: default -- 127.0.0.1
;; WHEN: Fri Jan 26 00:36:21 2001
;; MSG SIZE  sent: 30  rcvd: 138

drugs#

	Now with A6 and DNSSEC stub resolvers are being pushed as
	both potentialy require a deal of work to be performed
	before a answer is returned.  A full service resolver
	is much better suited to dealing with A6 and DNSSEC.

	With A6 you *can* follow all the address delegations but
	you don't *have* to.  Personally I expect sites to be too
	paraniod to have chains that go outside their administrative
	control and you will, likely as not, get the full chain
	returned.

	Mark

--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ian Jackson <[email-masked]>
Date: Thu, 25 Jan 2001 19:38:45 +0000 (GMT)

> 	control and you will, likely as not, get the full chain

In which case A6 degenerates into an extremely complicated,
special-purpose and generally badly-designed macro substitution
feature.  Surely that isn't the kind of thing that anyone would want
in an IETF protocol.

So we must conclude that the people who think A6 is a good idea must
have some other reason.  What is that reason ?

Ian.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 25 Jan 2001 19:12:39 -0000

Apparently Elz tried again from an empty cache and was unable to resolve
the www.monty.de address.

Robert Elz writes:
> Their setup is bogus

Please explain why the www.monty.de configuration is ``bogus.'' Which
records should have been set up differently? The A6 examples in RFC 2874
have tons of gluelessness too; are they ``bogus''?

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 25 Jan 2001 19:29:40 -0000

[email-masked] writes:
> Dan stop assuming things about BIND 9's behaviour

I didn't say anything about BIND 9. Please read my message again; I'm
criticizing the protocol, not BIND. Think about your gigantic 6887ms
lookup time when you get to the ``fourteen queries'' part.

---Dan

Date: 18 Jan 2001 09:13:40 -0000
Message-ID: <[email-masked]>
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: A6 unreliability

A recent bind-users report pointed out that BIND 8 can't find the IPv4
address of www.monty.de, even though the monty.de configuration is valid
and the relevant servers are responding quickly.

Here's one way to understand what's going wrong.

I'd like to write a program that talks to DNS servers to find an address
given an FQDN. How much memory do I need? How many servers do I need to
contact?

Well, I might need 64KB for an incoming DNS message, during the brief
moment before I parse it. There's not much persistent data:

   * The name I'm looking up.
   * The name of the closest zone found so far.
   * The addresses of servers for that zone. 16 is more than enough.

A response from a server will give me the answer, or refer me to a
closer zone. The number of queries is at most 4 for www.blah.com.
Simple, isn't it?

Oops, that's not quite right. I might receive a CNAME. In that case I'll
have to change the name and start over. This may happen several times.
RFC 1034 says that the first CNAME ``should always'' get me to the
canonical name, to avoid ``extra indirections,'' but it also says that I
should follow chains if they do happen.

Suddenly there's no limit to the number of queries. I have to set my own
artificial limits to catch loops, and pray that they're not too small.

But wait. The algorithm still doesn't work. The referral can include
some glueless server names---names without addresses. I need to put the
query on hold while I look up _those_ addresses. So here's what I
actually have to store:

   * The name I'm looking up.
   * The name of the closest known zone.
   * The known addresses of servers for that zone.
   * The names of servers whose addresses I still have to look up.
   * The name of a server whose address I'm looking up.
   * The name of the closest known zone to _that_.
   * The known addresses of servers for that zone.
   * The names of servers whose addresses I still have to look up.

It doesn't end there. If there are names in the last list, I'll have to
put the second lookup on hold while I look for the addresses of _those_
names. And so on.

The servers for monty.de, for example, are {ns,ns2}.norplex.net. The
servers for norplex.net are vserver.neptun11.de and ns1.mars11.de. The
servers for neptun11.de are {ns,ns2}.germany.net. The servers for
mars11.de are ns1.neptun11.de and www.gilching.de. The servers for
gilching.de are ecrc.de and name.muenchen.roses.de. What an amazing
display of gluelessness!

Suddenly there's no limit to the amount of space I need. I don't have a
single small array of addresses; I have an unlimited-length array of
small arrays of names and addresses. This isn't so simple any more.

The problem with BIND is that it doesn't set aside this space. It uses
the naive data structure. The only way it can put a query on hold, and
look up a server name, is by dropping the query. It hopes that the
server name lookup (``sysquery'') will find the server name before the
original client tries again.

My DNS cache can handle several levels of gluelessness, so it's able to
find www.monty.de---but it has to send _fourteen_ queries. That takes
quite a bit of time. Even worse, there are fourteen opportunities for
delays.

I encourage my users to avoid CNAMEs. I encourage them to avoid glueless
domains. My software automatically uses a.ns.fqdn, b.ns.fqdn, etc. as
the default server names for fqdn. My users appreciate the speed and
reliability.

Now I'm looking at the IPv6 DNS proposals. Here's what I see:

   * ip6.int is similar to in-addr.arpa. The format is slightly less
     compact but allows many levels of delegation without CNAMEs. The
     final names are large but tolerable. Okay. It works.

   * AAAA requires a fairly clumsy transition; extending the A format
     would have been much cleaner. But AAAA in a future IPv6-only world
     will function the same way that A does today. Okay. It works.

   * DNAME exacerbates all the problems of CNAME. DNAMEs can be wrapped
     inside DNAMEs---and this is _encouraged_! We'll have people setting
     up huge CNAME/DNAME chains to match their corporate structures.

   * A6 exacerbates all the problems of glueless names in NS records.
     Suddenly there's another reason that a lookup will have to be put
     on hold---and, again, this is _encouraged_!

DNAME and A6 are moving in the wrong direction: more gluelessness,
slower lookups, more frequent delays, and more outages like monty.de.
A6 creates reliability problems that are not present in AAAA.

I object to DNAME and A6. I would object to them even if they were the
only way to support easy renumbering. I cannot bring myself to inflict
such a rickety system on future Internet users.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 25 Jan 2001 19:45:53 -0000

I agree with Elz that the following two steps would (1) eliminate the
reliability problems of out-of-bailiwick NS records (2) without allowing
caches to be poisoned:

   1. Servers fetch glue, and provide glue in their responses, so that NS
      is always accompanied by A: e.g., aol.net NS dns-01.ns.aol.com and
      dns-01.ns.aol.com A 152.163.159.232.

   2. Caches save the NS+A combination: aol.net NS+A 152.163.159.232.
      They don't save the A record separately.

Of course, this is functionally identical to putting IP addresses into
NS records, which is exactly how the protocol should have been designed
in the first place.

---Dan

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Jan 2001 16:35:29 -0600

Christian explained the reason. You can disagree, but
that was the resason.

  Brian

---

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

Date:        25 Jan 2001 19:45:53 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I agree with Elz

I'm not sure how you know you agree with me, or how much, but ...

  |    1. Servers fetch glue,

This is something I have wanted for a very long time, and have
asked about on the odd occasion.   I keep getting told that the
load on the servers for the big zones (COM especially of course)
would simply be too much - considering the number of domains that
have servers that are unreachable (or simply don't know they're
supposed to be servers at all) much of the time, and the number
of queries to be made, the theory is that without spending too
much of the server resources on this, the data for the whole zone
couldn't be fetched before the parts fetched first had timed out
and need to be fetched again.

I've never run a server for a zone that big, so I don't know if this
is an accurate assessment or not of course, but it is hard to argue
against - especially when I know how busy my server gets, serving
a lot more zones it is true, but a lot smaller and less frequently
accessed ones.

  |    2. Caches save the NS+A combination: aol.net NS+A 152.163.159.232.
  |       They don't save the A record separately.

I'm not sure that this as a requirement makes a lot of sense though.
The NS and A records are likely to have different TTLs, and one expire
before the other.   Further, should the cache receive the A record from
its authoritative server, and it happens to be different, I think I'd
prefer the cache to keep (and use) that one.

  | Of course, this is functionally identical to putting IP addresses into
  | NS records,

It is functionally equivalent from the point of view of solving the
problem that you have been referring to recently, yes.  Aside from
that though, it is barely even similar.   In particular, this way,
the SIG that accompanies the A record would have been fetched by the
server from the auth server for the A record, when the A record was
fetched, and will be passed back to the cache (along with the SIG
for the NS record which comes from the child zone, though there's
probably some technicality of DNSSEC I'm skipping there, DNSSEC around
zone cuts is a mysterious thing).

If the NS record had been designed with the A record in it directly,
then that address would be being signed by the owner of the zone that
uses the nameserver, instead of the owner of the server that uses the
address, which would be the wrong place indeed (correct from a DNSSEC
point of view, but incorrect from a rational point of view).

On the other hand, if the A in the NS was being generated by the
parent zone server as part of the delegation (automatically) then
either it isn't going to be signed at all (and would this be
rejected out of hand by some servers that are configured to only
accept signed data - sometime in the future when this is practical)
or would be signed by the parent zone, which is simply bogus all
around (even assuming that the server can get some kind of access
to the key to do the signing).

  | which is exactly how the protocol should have been designed
  | in the first place.

And there we don't agree at all.

But I think we should cease discussing the DNS protocols on the
ipng list - this has slipped rather far away from issues directly
relating to A6 records.   If there is to be any more on this, perhaps
it ought to be raised again on namedroppers, where there are far
more DNS experts around, including some who were part of the
original DNS design (which I don't think this WG includes any of).

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 26 Jan 2001 17:29:10 -0000

Robert Elz writes:
> I keep getting told that the load on the servers for the big zones
> (COM especially of course) would simply be too much

In fact, those servers provided glue for all NS records until recently,
and they still provide glue for the vast majority of NS records.

How do they avoid the efficiency problems? Easy: the glue is pushed to
the servers by the registrants, rather than being pulled.

> before the other.

The TTL on the combination is the minimum, of course. This doesn't make
a big difference in cacheability; see my analysis of MX records. (In
fact, the TTLs are typically the same.)

> server from the auth server for the A record,

Excuse me? A moment ago you didn't want to generate extra queries. You
wanted to use the out-of-bailiwick glue. I'm explaining how to make that
happen without allowing caches to be poisoned.

The SIG semantics don't have to be modified. When the server copies the
A record, it can also move it into its own zone, sign it, and change the
NS record accordingly.

Of course, this is functionally identical to signing an NS record that
contains an IP address. You have to do a lot more parsing, and check
more signatures, but the end result is the same.

> this has slipped rather far away from issues directly
> relating to A6 records.

No. The issues are exactly the same.

---Dan

---

From: Ian Jackson <[email-masked]>
Date: Fri, 26 Jan 2001 22:11:18 +0000 (GMT)

> A record, it can also move it into its own zone, sign it, and change the

This would I think be rather poor practice on the part of the server.
Signing something just because someone else signed something is not
usually a good idea, and usually indicates a design error somewhere.
Now you'll probably just agree with me and tell us that the design
error is that the NS record contains an A :-).

Still, at first glance it doesn't seem like a very good idea.  If
people still seem to think it is then I suppose I should think about
it harder and see what potential attacks there are.

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Sat, 27 Jan 2001 01:31:16 +0000 (GMT)

Ian Jackson writes ("Re: An easy example of A6 unreliability"):
> Now [Dan]'ll probably just agree with me and tell us that the design

Err, I mean, contains a domain but should contain an A.

Ian.

---

From: Robert Elz <[email-masked]>
Date: Sat, 27 Jan 2001 12:48:40 +0700

Date:        26 Jan 2001 17:29:10 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | In fact, those servers provided glue for all NS records until recently,
  | and they still provide glue for the vast majority of NS records.

Yes, it isn't providing the glue that is hard.

  | How do they avoid the efficiency problems? Easy: the glue is pushed to
  | the servers by the registrants, rather than being pulled.

Which is exactly what turns out to not work at all well.  Either there
is what we have now, a (potentially anyway) secure out of band channel
with which to advise on updates, which then just doesn't get used, or
we have the client's server do the pushing.   But it is quite common for
there to be several servers configured to serve the same domain (client
has left one ISP and gone to another - the old one doesn't take down
the server for ages sometimes).  Then we have two servers, each wanting
to update the A record for the glue to match what it believes it
ought be (and if the client has used the ns.my.domain type NS value
in both cases, then the registry doesn't even get a clue which is
correct from the name of the glue being updated).  Further, it is
quite likely that both might be signed, with SIGS that have not
expired.

All this just gets hard, which is why server pull is the simple
implementation - it just means extra work for the server (actually
receiving and processing the updates is about the same either way,
but the server has to do more checking).

  | The TTL on the combination is the minimum, of course.

Which removes useful functionality.

  | This doesn't make
  | a big difference in cacheability; see my analysis of MX records. (In
  | fact, the TTLs are typically the same.)

You mean that not a lot of people know how to use TTLs intelligently,
so let's not allow anyone to do so?

  | Excuse me? A moment ago you didn't want to generate extra queries.

I don't think I said that: extra queries will sometimes be necessary.
(I did say that an argument against doing server pull of glue is the
extra work - that isn't my argument though).  But that wouldn't be a
result here.  The SIG accompanies the A record when the server obtains
it (which would happen with pull or push methodology).  It then attaches
it to the answers it sends others (and the others verify it if they
feel inclined, the parent server doesn't need to).

  | The SIG semantics don't have to be modified. When the server copies the
  | A record, it can also move it into its own zone, sign it, and change the
  | NS record accordingly.

No, you keep failing to understand - the server cannot sign anything,
it has no keys available (in general).  Signing is (sometimes) done
only by a human (or for even better security, perhaps even a team of
humans).

  | Of course, this is functionally identical to signing an NS record that
  | contains an IP address. You have to do a lot more parsing, and check
  | more signatures, but the end result is the same.

It would be if it were done that way, but that isn't the way to do it
(quite apart from which, the server can't "change the NS record" or
the NS RRSet from the server, and the NN RRSet from the client wouldn't
be the same - which is a configuration bug - a fairly common one, but
still not one we should be encouraging).

  | > this has slipped rather far away from issues directly
  | > relating to A6 records.

  | No. The issues are exactly the same.

But these are all internal DNS issues now, none of it is specifically
related to IPv6 - it would still be better discussed on the namedroppers
list where there is more DNS expertise available than exists here.

kre

---

From: Ian Jackson <[email-masked]>
Date: Sat, 27 Jan 2001 14:44:30 +0000 (GMT)

I complained:
> usually a good idea, [...]

In fact, you can set it up so that it's not necessary for the server
to re-sign the A's for the nameservers into the parent zone.

Consider a nameserver for example.com.  If we have something like
  example.com           NS      ns0.iana.org
  foobar.iana.org       A       10.0.0.1
then the obvious problem is that the client can't verify the signature
on the A because the packet syntax makes it hard to make it clear
which key signed it, and that the client doesn't necessarily have (and
maybe will have trouble finding and verifying) the relevant zone key.

However, in fact this is just the this surface problem.  It arises
because of the deeper problem that the cryptographic delegation
structure is wrong.

The key which signs the A doesn't really have anything to do with the
key for example.com.  The example.com key doesn't explicitly delegate
to the key to [foobar.]iana.org; instead, it merely names iana.org and
expects the general secure DNS infrastructure to find the right key to
sign that record.  The crypto delegation path is from example.com via
(implicitly) the global root key to the keys for org, iana.org and
then possibly another zone key for foobar.iana.org if that's a
subzone.  This is totally insane.

Instead, if you do this
  example.com           NS      ns0.iana.org
  ns0.example.com       A       10.0.0.1
and forbid that ns0 is delegated, then the delegation path problem
doesn't arise.  Here the delegation path is quite simple: com
delegates by signing the NS RR and the example.com zone key, and the
example.com zone key itself signs the A.

A client which has all of the relevant RRs can check the certificate
chain, and hence the validity of the nameserver address, straight
away.

If the client *doesn't* get both the address RR and its signature from
the original server for com, they have a problem.  They can't check
the signature on the A, so they don't know that it's valid.  They
probably shouldn't cache it and should vaoid using it.  At best they
could use it as a hint to try to find authenticated copies of the same
data - or alternatively, they could make queries for the delegation
address and its signature record from the parent server, which
hopefully has a copy.

So I'm coming to the conclusion that to get delegation to work
sensibly with secure DNS, we have to require something like this:

* Delegation NS hostnames must be in the zone being delegated to
(and must have exactly one extra label?)

* When serving up a delegation, the parent server must pass on the
glue, including the glue's signature.  What if it won't fit in the
packet ?  Perhaps the server should set TC and the client should retry
with TCP, or perhaps the parent server for a delegation must be
willing to serve up the glue, including its signature, in response to
an explicit request.

Ian.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Jan 2001 22:19:39 -0000

> usually a good idea, and usually indicates a design error somewhere.

As the owner of cr.yp.to, I hereby declare that whitehouse.cr.yp.to has
addresses 198.137.240.91 and 198.137.240.92.

I copied those addresses from whitehouse.gov. Why do you care? Why do
you think it isn't a good idea for me to do this?

---Dan