Subject: Re: AAAA/A6 thing

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Apr 2001 19:09:48 -0000

Ohta is wrong. This is a bug in the protocol, not in any particular
implementation. All of my comments apply to BIND's A6 implementation;
BIND discards out-of-bailiwick records for security, just as djbdns
does. Ohta's ``fix'' comments are nonsense.

As for non-A6 examples: http://cr.yp.to/djbdns/killa6.html already
covers this, and explains why A6 and DNAME make the problem much worse.
See the ``DNS reliability problems'' section.

---Dan

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Greg Hudson <[email-masked]>
Date: Tue, 01 May 2001 10:29:44 -0400

> implementation. All of my comments apply to BIND's A6
> implementation; BIND discards out-of-bailiwick records for security,
> just as djbdns does. Ohta's ``fix'' comments are nonsense.

I don't understand this argument.  How can NS glue work if BIND and
djbdns completely discard out-of-bailiwick records during a query?

I thought BIND and djbdns would use out-of-bailiwick records to
complete the current query (which is not a security problem, since the
server who gave you those records could have simply given you a
different answer) but wouldn't cache them for future queries.

Pardon my slowness.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 2 May 2001 02:53:29 -0000

RFC 1034 does not correctly describe the behavior of real DNS caches,
such as BIND and dnscache. In particular:

   * The RFC 1034 resolution algorithm loops and eventually fails when
     glue A records expire before NS records. Real caches fall back to
     the roots and succeed.

   * The RFC 1034 resolution algorithm saves information from servers
     that are not authorized to provide the information. Real caches
     reject the unauthorized information.

Yes, these are differences between RFC 1034 and reality. RFC 1034 is
clearly wrong in both cases: it creates a reliability problem in the
first case and a security problem in the second case.

http://cr.yp.to/djbdns/notes.html explains these issues in detail. The
section on gluelessness includes the same type of example that Ohta is
talking about now, with servers that follow the RFC 1034 rules but that
can't be reached by DNS caches:

   espn.tv NS ns-1.disney.corp
   espn.tv NS ns-2.disney.corp

   disney.corp NS zone.espn.tv
   disney.corp NS night.espn.tv

Ohta is wrong when he blames the DNS cache for throwing away the glue
here. RFC 1034 _does not_ require glue in this situation. The espn.tv
servers don't know the ns-1.disney.corp address.

http://cr.yp.to/djbdns/killa6.html explains why A6 and DNAME will make
these failures much more common.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 4 May 2001 04:07:49 -0000

Greg Hudson writes:
> How can NS glue work if BIND and djbdns completely discard
> out-of-bailiwick records during a query?

dns-01.ns.aol.com, for example, is in the .com servers' bailiwick, so we
can follow a referral from the .com servers to the aol.com servers. See
http://cr.yp.to/djbdns/notes.html for further background.

As for your suggestion: Yes, we can eliminate the reliability problems
caused by gluelessness, without introducing security problems, by

   (1) having the server provide the A for every NS and
   (2) having the cache save the A only in the context of that NS.

This is (aside from the unnecessarily difficult parsing) functionally
identical to putting addresses directly into NS records, which is my
suggested fix. Applying the same fix to A6 produces AAAA.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Fri, 04 May 2001 13:45:57 +0700

Date:        4 May 2001 04:07:49 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | dns-01.ns.aol.com, for example, is in the .com servers' bailiwick,

This is gibberish - a best a rationalisation of broken behaviour.

Since we know aol.com is delegated, dns-01.ns.aol.com belongs to either
the aol.com zone (and hence the serves authoritative for that), or the
ns.aol.zom zone (if it exists).

No other servers on the planet have any special relationship with the
name, and nothing that any of them might say about is to be trusted or
believed any more than any of the others.   There might be something about
the data retrieved (such as a dnssec signature) which might make some
responses able to be trusted more than others, but there's not a thing about
the server that it comes from (aside from the authoritative servers for
the zone that contains the name - and even then, only if you have some
expectation it hasn't been spoofed) that would make an answer from one
server any more trustworthy than any other.

  | so we can follow a referral from the .com servers to the aol.com servers.

The .com servers might need glue A records for that name, that's true.
So might the .net servers (and given they're the same thing it would be
a bit hard for one of them to have the glue and not the other...).  Even
the .TO servers might need A records for those names as glue (though one
might assume that is less likely - it isn't impossible).   Glue isn't
particularly authoritative (or believable) though.   But it is necessary
when no other information is available, and of course, usually works.

  | This is (aside from the unnecessarily difficult parsing) functionally
  | identical to putting addresses directly into NS records, which is my
  | suggested fix.

It isn't even close to functionally identical.   It would be if the requirement
was that only the (glue) A record in the NS response could be used to
"complete" the NS lookup - but no-one would ever make such a suggestion.
If a resolver has a cached A record to match the name in the NS record,
or even more, if it happens to be authoritative for that name, it should
use the record it has, rather than random glue it receives.

And that doesn't even begin to touch on the dnssec issues.

We keep seeing this "server side indirection is equivalent and simpler"
fiction over and over.   It keeps being refuted.   I guess you can just
keep repeating it over and over, and hope we all get tired of refuting it.
That won't make it any more true, even if there are no responses.

If you really believe it - implement it in your server for the NS/A case.

You have just claimed that other than the parsing issue (a NS/A pair is
unquestionably more work to parse than an NS record containing an address
would be) the NS/A combination in a response is functionally identical
to the server side indirection you aspire to.   Changing the specs the way
you want (and all the other implementations) isn't going to happen any
time soon no matter what was decided here now - so just ignore the parsing
issue, and implement the server side indirection using the NS+A method.
That is, have your servers *never* send an NS record in a response without
the accompanying A record(s).

That's actually easier (packet assembly/disassembly aside, which is really
pretty trivial anyway) than it would be if you had to put the address into
the NS record, as you don't have to deal with any of the dnssec or
maintenance issues (depending on whether you were to do it by simply having
the human maintain it - no dnssec issue particularly, but a maintenance
nightmare, or by having the server go query and maintain the address from
a configured server name (and perhaps associated glue A), which makes human
maintenance much easier, but the dnssec issues much harder).   But let's
just leave that part of it aside for now.

Come back to us after you have the server which never sends NS records without
the associated A records deployed at a significant number of servers (including
some which handle "public" domains containing 10K or more delegations).
Then we will be able to evaluate whether server side indirection (in the
simplest of possible scenarios) is able to work or not.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 4 May 2001 08:51:36 -0000

The root bailiwick includes all zones. The .com bailiwick includes all
zones under .com. And so on.

The power of the aol.com servers over www.aol.com exists only by grace
of the .com servers. If the .com servers want to change the address of
www.aol.com, they can. This power of the .com servers, in turn, exists
only by grace of the root servers.

These facts are built into the DNS architecture. We implementors didn't
invent the DNS hierarchy or the concept of delegation. We give special
powers to these central servers because we have no choice.

> If a resolver has a cached A record to match the name in the NS record,

Sorry, but we can't cache records from outside the server's bailiwick.
See http://cr.yp.to/djbdns/notes.html, under Poison, first example.

> If you really believe it - implement it in your server for the NS/A case.

I already did. The normal way to add an NS record, for example, is

   add-childns elysium.heaven.af.mil 1.2.3.144    (for the parent)
   add-ns elysium.heaven.af.mil 1.2.3.144         (for the child)

The software automatically creates NS records pointing to in-bailiwick
names, and A records for those names. Consequently caches receive glue.

The only reason that I allow out-of-bailiwick NS records is for
compatibility with certain parents (notably .com) that can't handle two
A records pointing to the same IP address. Child servers and parent
servers have to agree on NS names, thanks to a widespread BIND bug.

---Dan

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 5 May 2001 15:00:28 +0859 ()

Dan;

First of all, it should be noted that you are not anymore arguing
aginst the fact that A6 is as good as NS.

> such as BIND and dnscache. In particular:

RFC1034 is a specification, not an implementation note.

>      glue A records expire before NS records. Real caches fall back to

An implementation may expire a cached NS RR when its glue expires,

>      reject the unauthorized information.

That is broken part of your implementation.

Glue or an additional A of an NS should be cached, though, for
security purpose, the cache content may be used only as glue.

> first case and a security problem in the second case.

With correct implementation, there is no security problem in the
second case.

> here. RFC 1034 _does not_ require glue in this situation.

The reality is that people have been putting glue to some or
all the NSes, even though it does not required by RFC 1034.

Then, some of them learned that glue should be there only
when it is necessary.

My example (with proper glue added) is conformant to RFC 1034
and the real world practice.

							Masataka Ohta

---

From: Robert Elz <[email-masked]>
Date: Sat, 05 May 2001 15:31:06 +0700

Date:        4 May 2001 08:51:36 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | The root bailiwick includes all zones. The .com bailiwick includes all
  | zones under .com. And so on.

Where does this bailiwick notion come from?   I see no reference to
that anywhere in the DNS specs, etc.   This looks to be an invention
that you believe rationalises your approach to glue, and your private
theories as to how people should name their nameservers.

  | The power of the aol.com servers over www.aol.com exists only by grace
  | of the .com servers.

That's true, to an extent.   They created the aol.com name, and allow it
to continue to exist.

  | If the .com servers want to change the address of
  | www.aol.com, they can.

Only by removing the existing servers and substituting new ones.   Otherwise
the existing servers rule.   They may sometimes be able to interject
a bogus A record for a name - but only until clients discover the NS
records, after that, queries for names inside aol.com will never go near
the com servers (and any data received from the com servers, including the
NS records, should be treated as untrustworthy glue, until verified from
the authoritative servers)

  | Sorry, but we can't cache records from outside the server's bailiwick.

You can, nothing prohibits it.    But nor did anyone ask you to cache anything,
I'm not about to require that.   You misunderstood my intent.   I didn't
say anything about "if the resolver has cached an A record from some random
source", I just said "if the resolver has a cached A record".  The details of
under what conditions it would make that cache entry weren't stated - for
this purpose you can imagine them to be under however stringent conditions
you desire (for example, it may have received the A record directly from
the authoritative server for the name - it may in fact be that authoritative
server).

The point was that the NS name + name A case was not identical to NS address
as in the former, the resolver that receives the response is free to ignore
the A that accompanied the NS and use the A that it already has from a better
source.   Hence the two are not functionally equivalent, as claimed.

  | > If you really believe it - implement it in your server for the NS/A case.
  | I already did. The normal way to add an NS record, for example, is

That isn't what I asked, I don't care what the local admin procedures are.

What I asked was for your server to *never* send an NS record without the
accompanying A record in the additional info section.   Now you may very
well do that too - I have no idea, perhaps you can point us at one or more
servers that do lots of delegations of unrelated names (ie: one of the
public registries somewhere in the world) so I can do some queries of the
server and see for myself?

  | The software automatically creates NS records pointing to in-bailiwick
  | names, and A records for those names. Consequently caches receive glue.

If that's true, as written, then great.   And if you're sending that glue
(in all cases) then I assume that your resolver will also use it whenever it
is needed.   If all that is the case, then I can't imagine why we're even
discussing the issue.

That is assuming "automatically creates NS records pointing to in-bailiwick
names" is just saying that you won't allow people to create a child domain
out of a domain that they don't control (eg: I don't get to delegate
rc.yp.to as I don't run yp.to).   But if I did, then I could make that
delegation, and the server names could be anything (that has an A record)
I want them to be.

  | The only reason that I allow out-of-bailiwick NS records is for
  | compatibility with certain parents (notably .com) that can't handle two
  | A records pointing to the same IP address.

The com/net/.. registry service is truly broken there, stupid for reasons
difficult to fathom.   Never mind, that isn't the issue.   But if you're
saying that were it not for them you wouldn't allow me (were I to use your
implementation) to use whatever names I like for the nameservers, then your
implementation would be defective - and I'd be very surprised if you'd ever be
able to get such an implementation deployed at any registry (where they have
to list the NS records as the client specifies them - registries can't just
go inventing new names out of the client's name space and usurping them for
their own purposes).

  | Child servers and parent
  | servers have to agree on NS names, thanks to a widespread BIND bug.

No comment on the bind bug - there have been very many of those over
the years.

But parent servers have to agree with child servers on NS names to
get one of the basic assumptions of the DNS to work.  That is, that
it doesn't matter who you ask for information, the answers you get
(if you get answers) will all be the same.

Then, if there are no config errors, implementation errors, and
leaving aside the race conditions that occur when information is
changing (which the DNS deliberately leaves to be handled other
ways) this is easy to achieve, provided there is only ever one source
for the information.   In this case, the authoritative source is the
child's zone file - the parent is supposed to have an identical copy.

Certainly in the zones in which I do delegations, I largely ignore the
information that people fill in on the form - using what is there
(aside from the domain name that specifies what is to have its delegation
updated) only to locate the servers - as soon as I have found one of the
new servers for the domain, the NS records that go in the parent domain come
from that server (glue A records come from the authoritative servers for
the names concerned).   That is, provided all the servers to be listed
agree on the contents of the domain (etc) but the rest of that validation
isn't relevant here.

I'd like to automate that - have the parent go and continually update its
info from the child zones, but the practical issues with doing that are
simply astoundingly difficult (for large zones, and especially those that
need to deal with delegations to servers that tend not to be very reliable).

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 May 2001 08:43:22 -0000

> security purpose, the cache content may be used only as glue.

That is not what RFC 1034 says. It is, however, similar to the RFC 1034
algorithm in that it fails to stop the attack. See the Poison section of
http://cr.yp.to/djbdns/notes.html.

> An implementation may expire a cached NS RR when its glue expires,

That isn't the RFC 1034 algorithm either. If you're going to claim that
the IETF specifications are right and that all of us cache implementors
are wrong, perhaps you should start by reading the specifications.

> aginst the fact that A6 is as good as NS.

On the contrary. http://cr.yp.to/djbdns/killa6.html explicitly covers
both situations together, and then explains why A6 and DNAME are worse:

   DNS reliability problems

   Out-of-bailiwick pointers destroy DNS lookups in three ways:

      * Every out-of-bailiwick pointer means more queries and more
        opportunities for delay: packets are lost and have to be resent.
        The chance of finding an answer before client timeout decreases
        exponentially with the number of out-of-bailiwick pointers.

      * Caches have to limit the number of queries and the amount of
        memory that they dedicate to a single lookup. When these limits
        are exceeded, lookups fail.

      * As illustrated by the AOL suicide example, every
        out-of-bailiwick pointer is another opportunity to create a
        loop. When a loop appears, lookups fail.

   These problems are not new. Lookups occasionally fail because system
   administrators have used too many out-of-bailiwick NS records, for
   example. (I tell my users to select in-bailiwick server names. My
   software automatically uses a.ns.fqdn, b.ns.fqdn, etc. as the default
   server names for fqdn. I also tell my users to avoid CNAME records.)

   What is new with A6 and DNAME is that out-of-bailiwick pointers are
   _encouraged_. System administrators are _encouraged_ to set up giant
   A6 chains and giant DNAME chains reflecting their corporate
   structures and network structures. The result will be a tremendous
   increase in the frequency of DNS lookup failures.

   I refuse to implement A6 and DNAME. I cannot bring myself to inflict
   such a rickety system on future Internet users. As of February 2001,
   nobody is relying on A6 or DNAME; I recommend that the A6 and DNAME
   proposals be terminated.

http://cr.yp.to/djbdns/notes.html and http://cr.yp.to/djbdns/killa6.html
provide all the background you need to understand these points.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Sat, 05 May 2001 16:51:50 +0700

Date:        5 May 2001 08:43:22 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | > An implementation may expire a cached NS RR when its glue expires,
  | 
  | That isn't the RFC 1034 algorithm either. If you're going to claim that
  | the IETF specifications are right and that all of us cache implementors
  | are wrong, perhaps you should start by reading the specifications.

Huh?   That was about records in the cache, right?   Implementations are
free to expire any cache record any time they like, up to when the TTL
expires.   Bind used to (maybe still does) wind down the TTL quickly as
more queries were made on a name - which sounds exactly backwards, but was
very convenient if you noticed some bad data in a cache somewhere and wanted
it to go away (just send a lot of queries for the name, the TTL would
quickly drop to 0, and the record would be dropped).   Of course, bind
most likely should never have had the bad record to begin with, but that's
beside the point - which is that how or when you expire records in your
cache (provided it is done no later than when the TTL expires, or at least
immediately before the next query which would have found the entry, which
from outside looks the same) is your business - use whatever algorithm you
feel best meets performance and reliability aims.

  |    DNS reliability problems
  | 
  |    Out-of-bailiwick pointers destroy DNS lookups in three ways:
  | 
  |       * Every out-of-bailiwick pointer means more queries and more
  |         opportunities for delay: packets are lost and have to be resent.
  |         The chance of finding an answer before client timeout decreases
  |         exponentially with the number of out-of-bailiwick pointers.

True.   Then we have a balancing act between what is more convenient for
me to maintain, and what is going to work well (enough) in practice.
There's nothing very unusual about that kind of cost/benefit trade off.
The important part is that it is for me, as a zone administrator, to make
that decision.   And that is the same for NS records and A6 records.

  |       * Caches have to limit the number of queries and the amount of
  |         memory that they dedicate to a single lookup. When these limits
  |         are exceeded, lookups fail.

Also true.   And that is certainly something that I need to take into
account when I am deciding how I will set up my zone.

  |       * As illustrated by the AOL suicide example, every
  |         out-of-bailiwick pointer is another opportunity to create a
  |         loop. When a loop appears, lookups fail.

Nonsense.   With proper glue, not being improperly ignored, the aol
example is just fine.

  |    These problems are not new. Lookups occasionally fail because system
  |    administrators have used too many out-of-bailiwick NS records, for
  |    example.

Yes, there can be problems - it is possible for people to break their
setups.

  |    (I tell my users to select in-bailiwick server names. My
  |    software automatically uses a.ns.fqdn, b.ns.fqdn, etc. as the default
  |    server names for fqdn. I also tell my users to avoid CNAME records.)

That's fine - if I were setting up my domain(s) now for the first time, I'd
be naming my nameservers something like that (I might just use ns1 ns2
instead of a.ns - just to save one byte in each name in the packets - but
that's so trivial as to be close to irrelevant).   That's for when I am
delegating my domain to nameservers I run myself.   On the other hand, if
I were an ISP with 5000 clients domains delegated to me, then the very last
thing I am going to be doing is creating 5000 different names for each of
my servers, and then having the absolute maintenance nightmare any time I
want to change one of their IP addresses.

CNAMES are often best avoided, but when used in the simple case "a CNAME b"
(where neither "a" nor "b" contains any dots) they work just fine, and
doing this can make maintenance easier.

But by all means, continue to give operational advice to people on what
works well, and why, and what the costs are both ways.   Do that for A6
as well as NS records and CNAMES.

  |    What is new with A6 and DNAME is that out-of-bailiwick pointers are
  |    _encouraged_. System administrators are _encouraged_ to set up giant
  |    A6 chains and giant DNAME chains reflecting their corporate

Nonsense - we don't yet know what is to be encouraged.   What is in the
doc is just some possibilities on how they might be used.   Until we get
operational experience we don't know what to encourage, and what to
discourage.

But you would certainly be free to give whatever you consider to be
good advice to your users as to how to use the things.   By all means tell
people that only "A6 0" will ever be reliable enough to use, and that
they should only ever use A6 in that format.   That may even turn out to
be correct, though I doubt it.

  |    I refuse to implement A6 and DNAME.

That's fine, except ...

  |    I recommend that the A6 and DNAME proposals be terminated.

You will therefore certainly be ignored now.   What is relevant at this
point is operational experience, how easily they can be implemented, and
what effects they have on operations when deployed.  If you're not even
trying to implement them, then you cannot possibly have anything relevant
to say on either issue.

kre

---

From: Greg Hudson <[email-masked]>
Date: Sat, 05 May 2001 11:21:18 -0400

I'm finding it a little hard to follow parts of this argument for lack
of knowledge of BIND's behavior with regard to out-of-bailiwick
records.  For instance, kre has argued that the bailiwick should not
give special status to a record, but I believe I've seen Dan claim
that BIND applies bailiwick-related logic to prevent malicious cache
poisoning.  Is kre arguing against BIND behavior as well as djbdns
behavior?

Anyway:

> As for your suggestion: Yes, we can eliminate the reliability
> problems caused by gluelessness, without introducing security
> problems, by

> This is (aside from the unnecessarily difficult parsing)
> functionally identical to putting addresses directly into NS
> records, which is my suggested fix. Applying the same fix to A6
> produces AAAA.

But with that standard, you lose the flexibility of not providing glue
records, or (in the case of A6) providing partial glue.  For instance,
a resolver providing an A6 record with a non-zero prefix could provide
glue NS and A6 (with 0-length prefix) records for the name server
which knows the prefix, but not the prefix itself, if the prefix
changes frequently but the relevant name server addresses do not.

I'm not sure whether that's a compelling argument for A6.  It does
seem, though, that (a) DNS is pretty much built on client-side
indirection, even if server-side indirection would have been more
robust; (b) A6 provides some kind of quick renumbering support
consistent with the client-side indirection model; (c) if caches would
accept out-of-bailiwick glue records in the context of the query they
came from, then glue could be added to solve reliability problems as
they crop up.

> Sorry, but we can't cache records from outside the server's
> bailiwick.  See http://cr.yp.to/djbdns/notes.html, under Poison,
> first example.

I believe you misread.  kre was saying that a cache might just happen
to be holding a cached authoritative record matching the glue record,
and could use the cached record instead of the glue record, so that a
query might succeed (by chance) even if there is stale glue involved.
Doesn't seem like a very big win.

---

From: Robert Elz <[email-masked]>
Date: Sun, 06 May 2001 12:55:04 +0700

Date:        Sat, 05 May 2001 11:21:18 -0400
    From:        Greg Hudson <[email-masked]>
    Message-ID:  <[email-masked]>

  | For instance, kre has argued that the bailiwick should not
  | give special status to a record, but I believe I've seen Dan claim
  | that BIND applies bailiwick-related logic to prevent malicious cache
  | poisoning.  Is kre arguing against BIND behavior as well as djbdns
  | behavior?

Last time I investigated anyway, BIND drops glue A records from zone transfers,
where the glue isn't within the domain delegated (which isn't the same as
djb's "bailiwick" definition).   And yes, that's broken.

I don't think that BIND ignores glue A records in NS responses though,
whatever the name of the server concerned (which isn't to say that it
necessarily caches them, or that it necessarily uses them, just that
they will be used if there isn't better info available).

  | It does
  | seem, though, that (a) DNS is pretty much built on client-side
  | indirection, even if server-side indirection would have been more
  | robust;

Yes, it is - but no, it wouldn't, it would be a maintenance nightmare.
That is, if one assumes that the people running things always get it
right, but that the software is possibly broken, then server side
indirection would be a win.   On the other hand, if you assume that the
humans get things wrong more often than the software implementors do,
then client side indirection wins more often (but yes, it is still possible
for the humans to screw that one too - they just need to try harder).

  | (c) if caches would
  | accept out-of-bailiwick glue records in the context of the query they
  | came from, then glue could be added to solve reliability problems as
  | they crop up.

Yes, though you don't mean caches, you mean resolvers.   There's no
requirement that this data be cached (as with all caches, one must weigh
the benefits against the costs of adding an entry).

kre

---

From: Sam Trenholme <[email-masked]>
Date: Sun, 6 May 2001 04:04:08 -0700 (PDT)

> (I might just use ns1 ns2 instead of a.ns - just to save one byte in
> each name in the packets - but that's so trivial as to be close to
> irrelevant).

Minor point:

a.ns.tld and b.ns.tld take up a total of 11 bytes when compressed.
ns1.tld and ns2.tld take up 12 bytes when compressed.

The savings gets better as you add more name servers, since each instance
of c.ns.tld, d.ns.tld, and so on take up four bytes, but ns3.tld, ns4.tld
and so on take up six bytes a piece.

- Sam

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 7 May 2001 00:51:24 +0859 ()

Dan;

> That is not what RFC 1034 says.

RFC 1034 is a protocol specification, not an implementation note.

It does not specify details of cache management.

Still, implementations which can not handle cache properly are
broken.

> It is, however, similar to the RFC 1034

You have been told it several times already.

: From mohta Sun Mar 18 07:53:47 2001
: Subject: Re: Extra records in zone transfers
: To: [email-masked] (D. J. Bernstein)
: Date: Sun, 18 Mar 1 7:53:47 JST
: Cc: [email-masked]

: Glue information is local to a zone (actually, local to a referral point
: that same name server may have different A records referral by referral,
: though such information can not be represented by standard zone file or
: zone transfer format), that same name server may have different A
: records zone by zone.
: 
: That is the reality of the database and the behaviour is not forbidden
: by the specification.
: 
: Thus, glue information may be chached not in global cache but in
: cache local to a zone (or, better, local to a referral point).
: 
: Then, different A records from different referral points can be cached
: independently and replies can choose appropriate chache.
: 
: Note that your server is wrongly implemented in a way not directly
: related to AXFR nor IXFR that, if you want to continue this thread
: on correct chaching, you should better use a subject like "multiple
: chache".

: Subject: Re: AAAA/A6 thing
: To: "D. J. Bernstein" <[email-masked]>
: Date: Mon, 30 Apr 2001 18:16:21 +0859 ()
: CC: [email-masked], [email-masked]

: > Legitimate standards organizations never have any trouble showing people
: > the justifications for their decisions.
: 
: As we already discussed with AXFR, you must put glue information in
: a separate cache local to a zone (or, better, a referral). RFC 1034
: does not prohibit to do so.
: 
: I thought you had already fixed your broken implementation.

> both situations together, and then explains why A6 and DNAME are worse:

I think you who ignores all the imformation in mails above are not
expecting me go all the way to look at your home page.

>    DNS reliability problems

There is none.

>         loop. When a loop appears, lookups fail.

It is certainly stupid that people worrying about using up v6
address space hegitated to specify a few fixed address allocation
boudaries in A6.

However, the stupidity is covered by

	DNS impelemantations dedicating limited amount of resource
	to a single look up

	actual allocation policy considering the DNS implementations.

>    I refuse to implement A6 and DNAME.

For DNAME, that's fine.

For A6, your statement is unfounded and you are refusing to implement
DNS.

							Masataka Ohta

---

From: Paul A Vixie <[email-masked]>
Date: Sun, 06 May 2001 10:19:58 -0700

> Last time I investigated anyway, BIND drops glue A records from zone
> transfers, where the glue isn't within the domain delegated (which isn't
> the same as djb's "bailiwick" definition).   And yes, that's broken.

BIND4 and BIND8 lacked the data structure capability to store out-of-zone
glue and use it constructively (which means: pass it on in outbound zone
transfers, and include it as additional data for authority sections, and
use it when following downward delegations.)  BIND9 was built with this
kind of capability in mind, though I'm not sure as I type this whether that
latent capability has been instantiated or tested.

In Ohta's case where the only AOL.COM servers are inside AOL.NET and vice
versa, the _appropriate_ place for the glue is: below the bottoms of the
NET and COM zones.  The AOL.COM zone server should not accept tranfers of
AOL.NET RR's, but rather, should seek "upward" when these are needed.  This
raises an unfortunate chicken-and-egg problem to which all known solutions
are as bad as the problem they address.  Ick.  So, "don't do that."

> they will be used if there isn't better info available).

Out-of-zone glue is nonauthoritative and likely (from my own operational
experiences) to be less accurate (more "stale") than real zone data.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 7 May 2001 04:26:50 +0859 ()

Paul;

> are as bad as the problem they address.  Ick.  So, "don't do that."

You still don't understand what the problem is.

> experiences) to be less accurate (more "stale") than real zone data.

For seurity, it is meaningless to say "less accurate".

You are adding more and more patches to your implemenation to make
it give more and more accurate answer.

However, something is secure or not secure. A concept of "weak security"
may confuse you, but security is security.

Glue or additional A for an NS is secure as glue for the referral. It
may be cached as glue for the referral but is not secure for other
purposes.

							Masataka Ohta

---

From: Ian Jackson <[email-masked]>
Date: Mon, 7 May 2001 14:54:13 +0100 (BST)

> theories as to how people should name their nameservers.

It isn't written down in 1034/5.  However, it is a necessary concept
to avoid cache poisoning.  A servers' bailiwick(s) include all the
data that that server is listed as a nameserver for (ie, which the
cache considering bailiwicks might ask for the data).  That includes
all zones delegated to that server and all their subzones.

Clearly, the security property for the DNS (without DNSSEC) should be
that servers' ability to cause answers to be used should be limited to
their bailiwick.  In order for that to be true then out-of-bailiwick
RRsets which appear in answers (eg in the additional section)
shouldn't be used (except perhaps as glue - here be dragons).

> Only by removing the existing servers and substituting new ones.

No, that's not true.  Supposing a cache knows nothing about any
servers for aol.com.  Then if it wants the address of www.aol.com it
will ask the servers for .com (ie, it will send them the query
`www.aol.com IN A ?'), and if those servers give an answer
(www.aol.com A ...) then that answer will be cached and used.

This is not an uncommon situation: for example, if a foolish aol.com
administrator has listed www.aol.com as a nameserver with the .com
servers, then the .com servers *will* return the address of
www.aol.com when asked, and the aol.com servers will not be asked in
that common case.

Indeed, not all subdomains are subzones, and the design of the DNS
arranges that caches do not need to know the delegation points unless
they actually get a referral.

>   Otherwise the existing servers rule.  They may sometimes be able
> to interject a bogus A record for a name - but only until clients
> discover the NS records,

The .com servers have the ability to make the delegation to aol.com
effectively disappear by answering all the queries themselves.  That
way clients will never discover the NS records, and always ask the
.com servers directly.  This would even be a trivial configuration
change with most server software.

Ian.

---

From: Robert Elz <[email-masked]>
Date: Tue, 08 May 2001 16:01:32 +0700

Date:        Mon, 7 May 2001 14:54:13 +0100 (BST)
    From:        Ian Jackson <[email-masked]>
    Message-ID:  <[email-masked]>

  | It isn't written down in 1034/5.  However, it is a necessary concept
  | to avoid cache poisoning.

Rubbish.   It is one broken theory of a technique that might help.
It doesn't actually avoid cache poisoning (I don't think anyone would
claim that - though there is this silly argument that it was really
all mine to alter as I see fit anyway ... by that argument, I get to
change anything about cr.yp.to as I'm one of the servers for TO...
That's ludicrous).

  | In order for that to be true then out-of-bailiwick
  | RRsets which appear in answers (eg in the additional section)
  | shouldn't be used (except perhaps as glue - here be dragons).

Forget the "out of bailiwick" nonsense - you really mean answers that
don't come from the authoritative servers for the data.   And
"except as glue" which is exactly what this discussion has been about.
The "here be dragons" is just FUD, which carries no weight at all.

  | No, that's not true.  Supposing a cache knows nothing about any
  | servers for aol.com.  Then if it wants the address of www.aol.com it
  | will ask the servers for .com (ie, it will send them the query
  | `www.aol.com IN A ?'), and if those servers give an answer
  | (www.aol.com A ...) then that answer will be cached and used.

It might be - but the com server cannot guarantee that.   It cannot even
guarantee that a client seeking www.aol.com will ask the com servers for
the A records for www.aol.com.   All it can expect is a request for the
NS records for aol.com, which is all that some clients might request.

And even if the client did request the A record, all it will get is a
non-auth answer - which might be enough to cause the answer to be ignored
and for it to go seen answers from the auth server.

Hence, the only way that a com server can reliably redirect www.aol.com
is to alter the servers for aol.com.

It might sometimes be able to direct traffic to a different address, but
it can't do that reliably enough to make the change permanent.

  | Indeed, not all subdomains are subzones, and the design of the DNS
  | arranges that caches do not need to know the delegation points unless
  | they actually get a referral.

Of course, and if there are no NS records for aol.com, then www.aol.com
would be in the COM zone, and the com servers would be entitled to
hand out whatever address they like - authoritatively.

Also, note that none of this is ever going to be any protection against
someone deliberately setting out to maliciously alter data - only dnssec
type techniques can achieve that.   In the non-signed cases, all we're
really interested in is inadvertent data errors (mistakes).

kre

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 08 May 2001 09:07:15 -0500

> really interested in is inadvertent data errors (mistakes).

And even then, a subversion that starts from a trusted higher level
in the tree will still work (barring the occasional manual
configuration of non-hierarchically related keys).

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 8 May 2001 22:22:53 +0859 ()

Kre;

> don't come from the authoritative servers for the data.

"authoritative" is not a useful concept because anyone can turn
on the authoritative bit.

We can rely on answers from non-authoritative servers, as long as
the servers do not use cached glue information for non-glue reply,

The entire system is weakly secure.

> really interested in is inadvertent data errors (mistakes).

Properly implemented DNS is as secure as telephone network that
as long as providers' routing is reliable, the system is secure,
which is called weak security.

Given that people rarely mind lack of security of telephone network,
the Internet without DNSSEC is secure enough.

Those wanting even more security can privately exchange shared secret.

Anyway, DNSSEC is not secure if parent zones are compromised.

							Masataka Ohta

---

From: Greg Hudson <[email-masked]>
Date: Tue, 08 May 2001 10:26:57 -0400

> Also, note that none of this is ever going to be any protection
> against someone deliberately setting out to maliciously alter data -
> only dnssec type techniques can achieve that.  In the non-signed
> cases, all we're really interested in is inadvertent data errors
> (mistakes).

I think you're in the margin on this one.  Without poison protection
similar to the djb variety, it becomes trivial to mass-produce cache
poison, and there have been highly publicized events where malicious
parties have done so.  With bailiwick-related poison protection,
maliciously altering data requires (a) forging DNS responses (by
sniffing the network path between sender and receiver, or by spamming
the sender with replies containing altered IDs), or (b) subverting the
DNS hierarchy.  (a) is definitely achievable for a targeted attack,
but is not practical for most attackers to do on a massive scale,
especially if resolvers use unpredictable query IDs and query ports;
(b) requires successfully attacking one of a small number of points to
subvert a particular domain.

(The specific scheme advocated by djb is not the only one which would
work.  You could, for instance, use all glue records only for the
completion of the particular query they come with, and never cache
them, thus avoiding the application of "bailiwick" logic.  What is
required for poison protection is that you never cache an
out-of-bailiwick glue record for use with queries other than the one
you received it with.)

As long as I'm here, some smaller points we don't actually have a
reason to care about:

> And even if the client did request the A record, all it will get is
> a non-auth answer

What keeps the .com servers from marking the answer as authoritative?

> All it can expect is a request for the NS records for aol.com, which
> is all that some clients might request.

What resolvers ask the .com servers for aol.com NS without asking for
www.aol.com A first?

You seem to be assuming that resolvers are aware, a priori, of a zone
boundary between com and aol.com.  Why would they be, if the .com
servers don't want them to be?

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 9 May 2001 02:59:52 +0859 ()

Greg:

> similar to the djb variety,

As Dan finally understood just recently, poison protection
is easy, if one understand the problem correctly.

His approach is overkill and broken.

> parties have done so.  With bailiwick-related poison protection,

Could you stop saying "bailiwick"?

> sniffing the network path between sender and receiver, or by spamming

It is called weak security.

> it becomes trivial to mass-produce cache
> poison,

Yes. But, Paul ignored it when I said so about 10 years ago
and later added wrong fixes.

						Masataka Ohta

---

From: Robert Elz <[email-masked]>
Date: Wed, 09 May 2001 18:17:22 +0700

Date:        Tue, 8 May 2001 22:22:53 +0859 ()
    From:        Masataka Ohta <[email-masked]>
    Message-ID:  <[email-masked]>

  | > Forget the "out of bailiwick" nonsense - you really mean answers that
  | > don't come from the authoritative servers for the data.
  | 
  | "authoritative" is not a useful concept because anyone can turn
  | on the authoritative bit.

No, I said "from the authoritative servers", not "replies with the AA
bit set".   I do understand the difference.

  | Anyway, DNSSEC is not secure if parent zones are compromised.

Sure.

But all that is relevant here is avoiding trusting bogus data.   The world
is in a paranoid state now, because of the typical overreaction to the
bogosity of earlier versions of BIND (which would trust any random data
in an answer in preference to the data loaded out of its own master file).

Anyway, this discussion seems to have gone beyond reasonable now, so
I think it is time to end it - and particularly to end it with the
current subject line.

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 09 May 2001 18:35:04 +0700

Date:        Tue, 08 May 2001 10:26:57 -0400
    From:        Greg Hudson <[email-masked]>
    Message-ID:  <[email-masked]>

  | What keeps the .com servers from marking the answer as authoritative?

Nothing.  But recall we're not discussing malicious attacks, we're
discussing what happens when bad data (stale glue particularly) is
floating around.   So, postulating what an evil com server administrator
might do isn't really relevant.   What matters is what happens when
the com administrators are generally trying to do the right thing (or
even just their definition of that).

  | What resolvers ask the .com servers for aol.com NS without asking for
  | www.aol.com A first?

No idea.   But any can.   If you treat me as a resolver, it is what I
do when I am looking for problems.

  | You seem to be assuming that resolvers are aware, a priori, of a zone
  | boundary between com and aol.com.  Why would they be, if the .com
  | servers don't want them to be?

Same as the first answer above.   And I'm not assuming any a priori
knowledge, just the availability of the information that leads to that
knowledge.   If the com servers aren't deliberately being manipulated,
they will have the NS delegation RRset, and will return that when queried.
That's all the resolver needs to see.  Bad glue A records floating around
won't have any effect.   Of course, the com servers can change (or delete)
the NS records for any sub-domain - that's part of their function, and
nothing we can do can alter that at the technical level (that's just
doing what they're designed to do).   What is correct there is decided at
a higher level - between humans - and typically involves human protocols
(contracts and such).

But given that a com server has delegated to the correct nameservers, it
is *not* within the com server's function to give out any other random
information about a sub-domain.   And most particularly, resolvers should
not be being built which assume that it is within the com server's
responsibility to do that, and that is what all this bailiwick nonsense
is about.

Sure, most resolvers in use on the net today might just blindly assume that
what a com server tells it is correct (more accurately, assume that what any
server they ask tells it is correct).  For many purposes that's even the
right thing to do, as Otha-san pointed out.  But if a resolver decides not
to simply trust what any other server tells it, there is absolutely no
basis at all for trusting the information from the .com servers for some
random answer about www.aol.com more than there is for trusting any other
random server's answer.   The two are equivalent.  That is, either do things
properly, or don't do it at all - don't invent bogus half way measures.

kre

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 09 May 2001 17:17:18 -0400

An alternate way to avoid cache poisoning which avoids the need to
invent a new "b**l*w*ck" concept:

 - never enter glue into any part of the cache's namespace

 - attach glue records to the NS records they came with; when a cache
resolves an NS record into a set of locations, fall back to the NS
record's attached glue records if there isn't a "real" cached entry.

					- Bill