Subject: Re: Joint DNSEXT & NGTRANS agenda

From: Robert Elz <[email-masked]>
Date: Wed, 01 Aug 2001 17:26:40 +0700

Date:        Tue, 31 Jul 2001 16:17:17 -0700
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | In the aol.com example, the sysadmin sets up dns-01.ns.aol.com A6 ...
  | prefix.aol.net, and similarly dns-02.ns.aol.com A6 ... prefix.aol.net.
  | What's ``ludicrous'' about that? It's exactly what the A6 specifications
  | encourage him to do.

The A6 specs don't encourage anything.  They indicate some ways that A6
might perhaps be used.  It also says that for NS records, A6 0 should be
used...

  | But it destroys connectivity to AOL.

Even though this fictional example doesn't follow the suggestions for
NS records, it only "destroys connectivity" when accompanied with one
perverse method of ignoring "glue".

What's more, one method which isn't even consistent with its proponent's
views of how the DNS ought to have been designed.

With any reasonable implementation, the setup described would work.

[Aside: it really would be better to use fictional domains - like example.com
 or .xx for illustrative purposes, as best I can tell, AOL have never deployed
 A6 records this way, however dumb some of their other DNS setups might have
 been]

  | All the efficiency issues are minor. The reliability issues are crucial.

Reliability is important.  Yes.

But we cannot go to the extreme of preferring reliability over
everything else - if we did, the DNS protocol would probably require
a database retained at every node, containing a complete list of all
the other nodes on the internet and their addresses (etc).   That way,
lookups would never fail, and they'd be as quick as we care to make
them.   We could even call that database HOSTS.TXT.

  | The A6 proponents keep claiming that a limited form of A6 is safe, but
  | they never answer when I ask them to identify the exact limitation that
  | has this magical effect.

Because there is none.  A6 is safe in any event.  But just like NS, etc,
some configurations make more sense than others (are more likely to work
in more environments).

  | How is the DNS administrator supposed to tell
  | the difference between ``ludicrous'' A6 records and normal A6 records?

Valid point - we certainly need more written on how to use A6 well.

That's some of what I am hoping to achieve in the near future - after
the experiments have actually been done that collect the data that will
have been analysed so as to actually have some basis for giving this
kind of advice.

kre

--------------------------------------------------------------------
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: 1 Aug 2001 12:44:45 -0000

Robert Elz writes:
> it only "destroys connectivity" when accompanied with one

This ``perverse method'' has been used by all versions of BIND since
1997, and of course by every version of my cache. The need for it is
explained in detail in http://cr.yp.to/djbdns/notes.html.

> as best I can tell, AOL have never deployed A6 records this way

Of course they haven't. We have a wonderful opportunity to abort the A6
and DNAME proposals before anyone starts relying on them.

> for NS records, A6 0 should be used...

How is that going to be enforced? How is the DNS administrator supposed
to know which machines might later be used as name servers? Are caches
going to abort NS lookups that involve A6 indirection? What about all
the other ways that A6 can lead to loops?

---Dan

---

From: Robert Elz <[email-masked]>
Date: Wed, 01 Aug 2001 20:52:13 +0700

Date:        1 Aug 2001 12:44:45 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | This ``perverse method'' has been used by all versions of BIND since
  | 1997, and of course by every version of my cache. The need for it is
  | explained in detail in http://cr.yp.to/djbdns/notes.html.

I haven't looked to see whether BIND really does that or not, but there
is certainly no need for it (and I actually doubt it a bit).

To be more clear, the web page (originally) referred to suggests that
the DNS should have originally used

	foo.example.com.	IN	NS	192.168.1.17

instead of

	foo.example.com.	IN	NS	ns.example.com.
	ns.example.com.		IN	A	192.168.1.17

That is, advocating server resolution of indirection.

If one were to assume that that is how things should be done, then
one must also assume that a DNS packet containing

	foo.example.com.	IN	NS	192.168.1.17

encoded in some DNS format binary form would be acceptable.

But apparently it isn't, if the DNS binary form is ...

	foo.example.com.	IN	NS	trash-name.
	trash-name.		IN	A	192.168.1.17

where the 2nd occurrence of "trash-name." is, of course, just a pointer
back to the first one using internal DNS name compression techniques.

Given the currently adopted format for DNS packets, which contains a
(compressible) label as the value of a NS RR, encoding the server side
resolution of the NS record indirection in this (2 RR) way is the obvious
thing to do - it retains compatability with the rest of the deployed DNS.

The pair of RRs given there allow the IP address of the nameserver for
the foo.example.com. domain to be located, which is what is needed to
actually use it to lookup names in the foo.example.com. domain of course.

That's exactly the same as if the NS record had contained the address
in the first place.  The two encoding methods are isomorphic.

For anyone to seriously claim that server side resolution of the
indirection is the way things should be done, and that for some
security or reliability related reason, this cannot be be made to
work, begs credulity.

Note: no-one said anything about caching the "trash-name. IN A .."
record anywhere, or using it for any purpose at all, other than
for finding the address of the nameserver for the domain.

This works for NS records, it works for A6, it works for anything else,
and is exactly as reliable and secure as would putting all of the data
into one RR.

The only difference is in the cases where the extra A record is not
included with the original response, which is a deliberate choice to
trade off some extra round trips (queries) (and hence lower reliability
a little) for the extra flexibility it gives.

  | > for NS records, A6 0 should be used...
  | How is that going to be enforced?

I didn't say it needed to be enforced - I was reacting to the suggestion
that people were being encouraged to use A6 in the way your web page suggests.

But if it were to be enforced, the place to do it would be when the
delegation is done.

eg: right now, if you attempt to delegate a domain in a zone I manage,
your listed NS list will be checked, and if any of those is a CNAME,
rather than having an A record (for IPv4 delegations) then I simply
won't do the delegation.  You either give the name an A record, or
use a different NS name, or your domain isn't delegated.  For IPv6
I can, if I desire, simply check that the A6 record of the NS is an
A6 0 format - if that turns out to be the right thing to do (which the
A6 RFC suggests it probably will be, but until we get it tested it is
hard to know for sure).

  | Are caches going to abort NS lookups that involve A6 indirection?

I expect not, as they don't necessarily abort NS lookups when a CNAME
is found.   That the resolver (a cache is just a storage mechanism for
results that have been obtained previously, it is the resolver that is
doing the lookup) is able to translate the name doesn't mean that it
is the way that it should be deployed.

  | What about all the other ways that A6 can lead to loops?

They will result in lookup failures - just as do CNAME loops, and NS
loops, and all of the other ways that people can shoot themselves.

If you want your names to be useful for people, you make sure they're
entered in a way that works.  If you don't care, then you don't, and
people won't be able to use your name.   That's the way it is now, it
is the way it should remain.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 1 Aug 2001 18:44:27 -0000

> security or reliability related reason, this cannot be be made to

You are, as usual, massively confused.

The reliability problems are not caused by the normal anti-poisoning
rules. The problems are caused by servers that DO NOT HAVE ALL THE
INFORMATION THE CLIENT NEEDS.

For example, when a .com server says barclays.com NS ns1.barclays.co.uk,
the client has to go look up the ns1.barclays.co.uk address. Is this
because the client is protecting itself against poison? No. It's because
the .com servers DO NOT HAVE THAT ADDRESS.

Server-side indirection means that the server _does_ have the address.
In this case, the server can easily use an in-bailiwick name for the
address, so the normal anti-poisoning rules once again have no effect.
The client avoids the extra lookups and the possibility of loops.

The reason I recommend in-bailiwick names within the existing DNS
architecture is that those names force the server to collect the
address. Putting IP addresses into NS records directly would have the
same beneficial effect.

Summary:

   * Good situation: The server has the information.
   * Bad situation: The server doesn't have the information.

The bad situation produces reliability problems. The point of A6 and
DNAME is to move from the good situation to the bad situation; this is
why I oppose A6 and DNAME.

Of course, all of this is already explained on my web page.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Thu, 02 Aug 2001 17:49:38 +0700

Date:        Wed, 01 Aug 2001 14:11:23 -0700
    From:        [email-masked] (Andreas Gustafsson)
    Message-ID:  <[email-masked]>

  | When resolving, BIND 8 and 9 do reject
  | all records that are not within the domain whose authoritative
  | qservers are being queried.

That's broken, and should be fixed.  If it really is as you have
explained it, it guarantees that some perfectly legal DNS configurations
can never be properly resolved.

  | If they did not, we would
  | be seeing much more cases of cache poisoning that we do now.

How?   No-one is suggesting that these records be put in the cache.
How can the cache be poisoned without that?

kre

---

From: Robert Elz <[email-masked]>
Date: Thu, 02 Aug 2001 17:47:23 +0700

Date:        Wed, 01 Aug 2001 11:44:37 -0700
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | For example, when a .com server says barclays.com NS ns1.barclays.co.uk,
  | the client has to go look up the ns1.barclays.co.uk address. Is this
  | because the client is protecting itself against poison? No. It's because
  | the .com servers DO NOT HAVE THAT ADDRESS.

What your web page said was ...

       Even if the address is provided, the cache won't accept it
       because .net addresses are not within the bailiwick of a .com server;
       this is the standard protection against poison.

If the address is needed for correct operation, it is trivially easy
for the COM server to be told it (or even go look it up, as a part of
a server side indirection, other than the volume requirements in that
particlar case).   This is just standard glue processing (the way it
is supposed to be done anyway).

It is only this "standard protection against poison", which is totally
bogus, as I showed in my last message, that would actually cause this
to be a problem that can't easily be fixed.

  | Server-side indirection means that the server _does_ have the address.
  | In this case, the server can easily use an in-bailiwick name for the
  | address, so the normal anti-poisoning rules once again have no effect.

But there's no poison involved, no-one ever said anything about
putting anything in the cache.   All that's relevant is that the
address be associated with the NS record for the purposes of finding
the nameserver, right now.   What the name is should be 100% irrelevant.

  | The client avoids the extra lookups and the possibility of loops.

And instead, the server does the extra lookups, and gets the possibility
of loops?

One of the design goals of many protocols (I wasn't around for the original
DNS design, so I can't say for sure it was one here, but I wouldn't be
surprised if it was) is to take the hard work away from the critical point,
and distribute it.   In this scenario, the DNS server is the critical
point, the clients are distributed all over.   DNS servers typically have
lots of queries to answer - clients usually have nothing much else to do
while doing the name lookup.  Having the client do more work to make less
work for the server is an attractive proposition - even if that means more
overall work for the internet as a whole.

  | The reason I recommend in-bailiwick names within the existing DNS
  | architecture is that those names force the server to collect the
  | address. Putting IP addresses into NS records directly would have the
  | same beneficial effect.

As my previous message showed, if implemented properly, any name can have
the same benefit of the server knows the address, so can supply it.
If the server doesn't know the address, then we're asking that the
additional work be done at the point where it can be done with less impact.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 2 Aug 2001 12:37:50 -0000

Robert Elz writes:
> This is just standard glue processing (the way it is supposed to be
> done anyway).

That's not what the DNS standards say. RFC 1034 states quite clearly
that glue is necessary only for in-bailiwick names.

RFC 1537 says the same thing, and specifically recommends against glue
for out-of-bailiwick names. So does RFC 1912. So does the c.p.t-i.d FAQ:
``Adding [out-of-bailiwick glue] is a very bad idea.'' Of course, BIND
has thrown away out-of-bailiwick glue for years.

You claim that discrimination against out-of-bailiwick glue poses ``a
problem that can't easily be fixed.'' That's absurd. The fix is trivial:
use in-bailiwick names.

What's important---what avoids the reliability problems---is to have all
the information available on the server. This is why I tell my users to
select in-bailiwick names (the server _must_ collect the address in this
case) and to avoid CNAME records. It's also why I oppose A6 and DNAME.

>        this is the standard protection against poison.

You are taking this out of context. The crucial point is that the
address is _not_ provided. The next paragraph on my web page explains
this in more detail.

> And instead, the server does the extra lookups, and gets the possibility

Wrong. Server-side indirection never causes loops. You would understand
this if you read my web page: http://cr.yp.to/djbdns/killa6.html

---Dan

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 4 Aug 2001 16:15:15 +0859 ()

Kre;

> How?   No-one is suggesting that these records be put in the cache.

I have been suggesting that these records be put in a referral-local
cache content of which is not used for usual A query nor glue A of
other referral points.

Other approaches are broken w.r.t. performance.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 5 Aug 2001 06:53:33 +0859 ()

Andreas;

> I think that's an excellent approach, and one that should be seriously
> considered when designing new resolver implementations.  BIND 8 and 9
> have the concept of a single, global cache too deeply ingrained to be
> changed at this point.

As I have been suggesting it long before BIND 8 or9, I have no
intention to check them specifically by myself.

But, if they are implemented rationally, the modification would be:

	Add a field of referral point for a cache entry structure.

	Referral point would be null pointer unless it is cached from
	additional A for NS. Otherwise the referral point for the NS
	would be stored.

	Cache entries are matched considering the referral point, unless
	the answer is used for additional A for NS. Additonal A for NS
	may use cache entry with null referral point

	As all the referral points of a zone share the same glue
	information, zone may be used instead of referral point.

I estimate the modification is a lot easier than several generations of
misdirected attempts to obtain the true weak security.

						Masataka Ohta

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Aug 2001 00:47:36 -0000

> cache content of which is not used for usual A query nor glue A of

What records are you talking about?

Typical A6 reliability problems involve servers that don't know the next
step in the A6 chain. How is the server going to provide records that it
doesn't have?

Of course, we can eliminate the reliability problems by making sure that
the servers have the entire A6 chain---in which case it's far simpler to
use AAAA.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Sun, 05 Aug 2001 20:30:07 +0700

Date:        Sat, 04 Aug 2001 23:05:03 -0700
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | What records are you talking about?

Otha-san was talking about glue A records that accompany NS records,
which is a side avenue that this discussion was taking.

  | Typical A6 reliability problems involve servers that don't know the next
  | step in the A6 chain. How is the server going to provide records that it
  | doesn't have?

It isn't.   Obviously.   Whether or not there's a reliability problem
in this case will depend upon how reliable the other servers, that have
the rest of the data are of course.   This is no different than an MX
record that names a host served by a different server, or a similar NS
record.

And, yes, I know that you recommend to your users that they don't do that.
And that's fine.   And you can do the same with A6 as well...

  | Of course, we can eliminate the reliability problems by making sure that
  | the servers have the entire A6 chain---in which case it's far simpler to
  | use AAAA.

But if A6 is used, each site has 3 choices.   It can use A6 0, which is
identical in effect to AAAA.   Or it can use an A6 chain, where all the
RR's are available at the same server.  Or it can use an A6 chain, with
one or more of the A6 records at some other server (hence requiring more
lookups).   Each site gets to make that choice, and make it indiviually
for each v6 address to be placed in the DNS.

That is, each site gets to choose between the degree of reliability, and
the degree of flexibility that meets its needs best.

You are, of course, free to keep recommending to your users that they
only use A6 0 if you want to.   You could even (assuming you ever implement
any of this) refuse to allow your server to load any A6 record other than
A6 0.   But is there any good reason that you can give us why others
shouldn't be free to make other choices?

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Aug 2001 16:06:47 -0000

> the degree of flexibility that meets its needs best.

You're saying that the I.AM administrators _chose_ to make their domain
only sporadically reachable by BIND 8 caches around the Internet?

Sure, BIND 9 and dnscache have higher gluelessness limits, but those
limits can be exceeded too. A cache can't let a single lookup consume
arbitrary amounts of memory! See RFC 1034, section 5.3.3.

If people start relying on A6 and DNAME, this type of failure---and the
other two types described in http://cr.yp.to/djbdns/killa6.html---will
become much more common. Are you going to claim that the victims _chose_
to screw up their own DNS service?

---Dan

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 6 Aug 2001 01:53:30 +0859 ()

Dan;

> What records are you talking about?

Just a history on glue A.

You can apply it to glue AAAA (if any) and glue A6.

							Masataka Ohta

---

From: Robert Elz <[email-masked]>
Date: Mon, 06 Aug 2001 14:31:58 +0700

Date:        Sun, 05 Aug 2001 09:18:47 -0700
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | You're saying that the I.AM administrators _chose_ to make their domain
  | only sporadically reachable by BIND 8 caches around the Internet?

No, of course not.   That seems to have been the result of a straight out
implementation bug.   When that kind of thing happens, the domain admins
will generally find a way to avoid the bug (which seems to be what happened
here), at the same time, the implementation should be fixing the bug
so it doesn't bite others.

  | A cache can't let a single lookup consume
  | arbitrary amounts of memory! See RFC 1034, section 5.3.3.

Of course it can't.   So an administrator will make sure not to ask too
much of caches, by creating  rational configuration that remains well
within reasonable limits.

That's what people are doing now - the DNS actually works... (despite
all these theoretical demonstrations that it can't possibly work... and
the occasional reported case of things not working).

  | If people start relying on A6 and DNAME, this type of failure---and the
  | other two types described in http://cr.yp.to/djbdns/killa6.html---will
  | become much more common. Are you going to claim that the victims _chose_
  | to screw up their own DNS service?

No, and perhaps for a while, we will see some more failures, while people
experiment, and before they learn what works.  Everything has costs, A6
included, A6's added complexity, and hence more opportunities to accidentally
configure things badly is one of those costs.  Fortunately, A6 also has a
trivial workaround for anyone who isn't sure what is a good config, and
what isn't - they can always just use A6 0, and be just as safe as if they
had used AAAA.   No question about it.   But with A6, I can use a more
complex config if I feel confident of it.   With AAAA I cannot.

What's more, you can always use A6 as a chance to demonstrate your server
indirection if you like - implement A6, and for any A6 n (n > 0) that gets
loaded, have your server go and fetch all of the rest of the chain, and keep
it up to date, so it is always there to be sent to clients in one packet,
so the client can always get all of the data quickly.  Sure the client will
need to expend a little more CPU time combining the RR values (either
the end resolver, or some back end resolver doing AAAA synthesis), but in
the grand scheme of things, that's trivial.

[Aside: just in case anyone thinks otherwise, this isn't just a challenge
to do something I think is a dumb idea - on the contrary, I have for a long
time believed that this is just what servers should be doing, for MX, and
NS, and everything else where there could be a benefit - it is only the
"too much work" arguments that have persuaded me not to try to make this
at the very least a BCP as recommended practice for all servers].

kre

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 1 Aug 2001 13:55:58 -0700 (PDT)

> is certainly no need for it (and I actually doubt it a bit).

This time, DJB is correct.  When resolving, BIND 8 and 9 do reject
all records that are not within the domain whose authoritative
qservers are being queried.  If they did not, we would
be seeing much more cases of cache poisoning that we do now.
-- 
Andreas Gustafsson, [email-masked]

---

From: Greg Hudson <[email-masked]>
Date: Thu, 02 Aug 2001 02:08:55 -0400

> qservers are being queried.  If they did not, we would be seeing
> much more cases of cache poisoning that we do now.

To be precise: to avoid cache poisoning, out of domain records must
not be used for future queries.  There is no problem with using them
for the purpose of the current query, although that may be considered
too complicated to implement.

---

From: [email-masked] (Andreas Gustafsson)
Date: Sat, 4 Aug 2001 08:36:00 -0700 (PDT)

---

From: bert hubert <[email-masked]>
Date: Thu, 2 Aug 2001 14:20:40 +0200

> can never be properly resolved.

We had that problem. This leads to frantic phonecalls from Verisign, who
explained it all very clearly and kindly suggested we move to using glue
records ASAP. Verisign sees a very large number of requests on the (gtld?)
rootservers for your nameservers otherwise.

The situation was like this:

At Amnic:
	I.AM			NS 	select.powerdns.com.
	I.AM			NS 	mincore.powerdns.com.

At the GTLD servers:

	powerdns.com		NS	dns-us1.powerdns.net.
	powerdns.com		NS	dns-eu1.powerdns.net.
	dns-us1.powerdns.net	A	63.123.33.130
	dns-eu1.powerdns.net	A	213.244.168.217

on the dns-{us,eu}1.powerdns.net:

	select.powerdns.com 	A	212.72.48.170
	mincore.powerdns.com	A	204.198.135.70

This sequence does not allow WWW.I.AM to be resolved by Bind 8.2.3. If you
start from an empty cache, bind will not believe the answers it gets, and
get stuck.

We've now moved the I.AM NS records to the glued ns1.i.am and ns2.i.am,
which get sent in the additional section, thus helping bind.

I'm by nature not a bind-basher since I think it is unwise for competitors
to throw mud at eachother, but this *is* rather silly behaviour. Having said
that, writing a recursing nameserver is very difficult - so far we stick to
only being authoritative.

Regards,

bert

-- 
http://www.PowerDNS.com      Versatile DNS Services  
Trilab                       The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet