Subject: Re: handling of additional data (fwd)

From: Robert Elz <[email-masked]>
Date: Thu, 06 May 2004 18:57:10 +0700

Date:        Wed, 5 May 2004 08:00:58 +0300 (EEST)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | A)  Is there consensus that it's better to set TC bit than to return 
  |     only some RRsets of critical additional data?

I have no idea if there's consensus or not (consensus among whom?), but
assuming the question intended there was really "Is it better..." (as in
questions B & C) then I think the answer is probably yes, but I am not
certain that is necessarily true - it is certainly better to set TC than
to send no "critical" additional data, but if some is sent, and even better,
if which of it is sent can vary from one response to another, then I am
not certain that just sending it, without TC isn't the better solution
(I'd really like to see some performance measurements with things done both
ways).

  | B)  Is it better to omit all the courtesy addional data, rather than 
  |     omit some RRsets?

No.   Provided that only complete RRsets are omitted, not just parts of
RRsets, if a complete "courtesy" RRset will fit, and the server wants to
send it (ie: my answer isn't a demand upon servers to include such data),
include it, regardless of how many others won't fit (again, better if the
implementation doesn't have a fixation on which of the available RRsets
it should include when they won't all fit, but allows that to vary).

  | C)  (This is relevant if you answered "no" to B) Is it better to set
  |     TC bit rather than return only some RRsets with courtesy 
  |     additional data?

No.

You should also be asking those who said yes to B whether it is better to
set TC rather than dropping all the RRsets.

kre

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 07 May 2004 06:11:29 +0900

Kre;

> then I am

The problem is that glues can be provided only with referral
and there is no way to separately ask glues.

By definition, glues are things which can not be asked without
the glues itself.

Worse, there is no way for the resolver know that some glues
are missing, unless glues are under the zone cut, which is
not always the case, even in which case, separate asking
causes the same referral still with missing glues.

						Masataka Ohta

---

From: Robert Elz <[email-masked]>
Date: Fri, 07 May 2004 06:20:51 +0700

Date:        Fri, 07 May 2004 06:11:29 +0900
    From:        Masataka Ohta <[email-masked]>
    Message-ID:  <[email-masked]>

  | The problem is that glues can be provided only with referral
  | and there is no way to separately ask glues.

Yes, true, but there should never be a need to ask specifically for glue,
asking for the data should return the same thing - if the glue has been
made different than the authoritative data, and something is depending upon
that, then I don't much care what happens.

  | By definition, glues are things which can not be asked without
  | the glues itself.

I'm not sure I quite agree with that definition, but nothing depends upon
it here, so it doesn't matter.

  | Worse, there is no way for the resolver know that some glues
  | are missing,

True, but does it really matter?

If all the glue is omitted, then, of course, there's a problem - that's
why I said ...

	it is certainly better to set TC than
	to send no "critical" additional data,

but if some glue is included, then the resolver has a path to the next set
of servers.   It doesn't have all the information, and may not be able to
reach all of the servers, but it should be able to reach at least one.
If it desires it can start A/AAAA queries to look for any missing data
that may exist.

Now I'm not saying this is necessarily better than having the resolver try
again with TCP after receiving a TC reply - what I'm saying is that I don't
know, and I don't know (perhaps just due to my ignorance) of anyone who has
done any kind of experimentation to find out which is the better approach.

I'd be hesitant about claiming that one is necessarily better than the other
based upon no more than superstition and guesswork.

kre

---

From: Paul Vixie <[email-masked]>
Date: Fri, 07 May 2004 00:47:15 +0000

> based upon no more than superstition and guesswork.

same here.  the definition of "helpful" vs. "necessary" glue is at best
subjective.  please just set TC if anything does not fit, and that you
truncate on rrset boundaries, just like 1035 recommends.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 07 May 2004 10:14:57 +0900

Paul;

> the definition of "helpful" vs. "necessary" glue is at best
> subjective.

It is a problem of the definition of the draft.

However, "glue" is necessary while other additionals are
merely helpful.

						Masataka Ohta

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 6 May 2004 18:29:17 -0700 (PDT)

> truncate on rrset boundaries, just like 1035 recommends.

While do I agree with your recommendation (for the specific case of
glue), I'm unable to find the RFC1035 text you refer to.  There's also
the following text in RFC2181 section 9 which seems to contradict it:

   Where TC is set, the partial RRSet that would not completely
   fit may be left in the response.

-- 
Andreas Gustafsson, [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 07 May 2004 10:34:26 +0900

kre;

> reach all of the servers, but it should be able to reach at least one.

Say "fault tolerance".

It is required that each zone has at least two name servers.

Moreover, administrators of a zone with more than three name
servers are doing so with *REASONS* that addresses of all of
them should be tried by the client.

So, it is still OK if a reply includes "at least one" address
of name servers chosen randomly for every query and clients
retry original query.

However, they are new requirements. Worse, because of cached referral,
clients will continue to receive the same answer and are helpless if
the received addresses are not useful.

As we agreed:

> Yes, true,

it is impossible to separately ask glue informaion unless
you have glue information.

> done any kind of experimentation to find out which is the better approach.

I'm saying I do know larger message size (over UDP or TCP) is
the only way, if glues cause message size overflow.

						Masataka Ohta

---

From: Matt Larson <[email-masked]>
Date: Fri, 7 May 2004 14:18:47 -0400

> the definition of "helpful" vs. "necessary" glue is at best

There are two issues lurking here.  The first is the definition of
"glue".  The second is whether there is any ambiguity surrounding
including a name server's A record in the additional section of a
response.

First, to the definition of glue.  The end of Section 4.2.1 of RFC
1034 appears to make it clear that glue RRs are always A records
corresponding the RDATA of an NS record, and that these records are
required to solve the circular dependency problem when the name of the
name server is at or below the zone cut created by the NS record.
Here's the exact text:

  To fix this problem, a zone contains "glue" RRs which are not part of
  the authoritative data, and are address RRs for the servers.  These
  RRs are only necessary if the name server's name is "below" the cut,
  and are only used as part of a referral response.

Using this definition, not all A records in the additional section of
a message corresponding to NS RDATA are glue: only those meeting the
at-or-below-a-zone-cut criterion above.

But lest terminology disagreements get in the way of the second issue,
I don't understand the subjectivity you refer to, Paul.  A name
server's A record would appear to be able to be classified as
"helpful" or "necessary" simply by its name relative to the zone in
question using the RFC 1034 definition of glue.

Matt

---

From: Rob Austein <[email-masked]>
Date: Fri, 07 May 2004 15:05:57 -0400

At Fri, 7 May 2004 14:18:47 -0400, Matt Larson wrote:
> ...

Right, with the obvious change that these days we'd be talking about
all of the address types (AAAA and A), not just A.

> question using the RFC 1034 definition of glue.

Paul can of course speak for himself, but one way of looking at this
is that if all addresses were equally useful, we wouldn't need so many
addresses.  That is: part of the point of providing redundant servers
(and the whole point of providing redundant addresses) is that stuff
happens (routing problems, backhoe induced deep fade, whatever), and
when stuff happens, some addresses may be better than others.

So, completely punting on additional data that's just an optimization
and concentrating on glue as defined above: if there's more glue than
will fit in the response message, the name server doesn't really know
which glue will be most useful to the resolver.  It can, in theory,
attempt to guess, using arbitrarily complex (and fragile) criteria,
but it can't know.

---

From: Robert Elz <[email-masked]>
Date: Sat, 08 May 2004 02:00:23 +0700

Date:        Fri, 07 May 2004 10:34:26 +0900
    From:        Masataka Ohta <[email-masked]>
    Message-ID:  <[email-masked]>

  | Say "fault tolerance".

Otha-san - consider the context here please.   We're not concerned with
zones with 2 (or 3) nameservers, each with a couple of addresses -  those
things just don't cause packet overflow (even with AAAA records, SIG
records, and the 512 byte limit) in a referral or NS query (perhaps when
the NS is just in the auth or additional section as extra info, but
those cases don't matter).

To overflow the limits there are either going to be a large number of
NS records or the servers are going to have lots of addresses.
Even with some of the data missing, there is going to be plenty of
fault tolerance - maybe not all the zone admin had hoped for, but
perhaps enough (once again, all I am saying here is that I don't know,
and I haven't seen any data that would convince me one way or the other).

  | Moreover, administrators of a zone with more than three name
  | servers are doing so with *REASONS* that addresses of all of
  | them should be tried by the client.

The admin also knows how big a referral packet containing their NS
list can get - they can plan to avoid the problem in the first place.
The question is how best for the software to deal with cases where
the admin has no idea what is good, and makes a mess.

After all this, I still don't know which practice will result in the
optimal behaviour for any of the server, the resolver, or the net as a
whole - nor do I know that the practices optimising those three are
necessarily all the same, and if they're not, I also have no idea just
which one someone is attempting to specify, or why that one rather than
the others.

But that may be because I haven't been following the dnsops WG for a
while now, all might be quite clear over there.

kre

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 08 May 2004 05:57:55 +0900

Matt Larson;

> at-or-below-a-zone-cut criterion above.

A problem is that " at-or-below-a-zone-cut" is wrong that
circular dependency occurs, for example, by a "org" zone served
by a server in a "edu" zone and the "edu" zone served by a server
in the "org" zone.

That is, 1034 is not self-consistent.

However, the problem above does not affect the current problem as
authoritative servers have full knowledge on what is "glue".

Paul's confusion is to have assumed "helpful glue".

There is no such thing as "helpful glue" that name servers should
simply put all the "glue" in response, even if it causes
truncation.

Resolvers may try addresses in truncated referral. But, it should
never be cached and if all of them fails, it should get untruncated
referral with longer messages.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 08 May 2004 06:19:26 +0900

kre;

Things can get a little more complicated.

Consider, for example, scalable (w.r.t. global routing table
size) multihoming where sites receives multiple prefixes each
from its upstream ISPs, whichi is considered in multi6 WG.

Then, a name server connected to three LANs of a triply
homed site has 9 addresses.

If there are three such servers, there will be 27 addresses,
which is too many to fit in 512B with AAAA.

> and I haven't seen any data that would convince me one way or the other).

As "enough" is primarily judged by the zone admin, if the admin hoped
for more, it is not "enough" or the admin is too greedy.

See above for an example how difficult to say an admin is "greedy"
as merely 3 servers can cause overflow.

Things can get even more complicated if some of the servers are
in other sites (it is important for fault tolerance) operated by
other admins.

> the admin has no idea what is good, and makes a mess.

If we have a broken protocol and fix is impossible, then, let
admins avoid the problem.

If we are designing a protocol or revising it in backward
compatible way, never assume admins are intelligent.

Admins already have a lot of things to consider.

						Masataka Ohta

---

From: Robert Elz <[email-masked]>
Date: Sat, 08 May 2004 06:05:34 +0700

Date:        Sat, 08 May 2004 06:19:26 +0900
    From:        Masataka Ohta <[email-masked]>
    Message-ID:  <[email-masked]>

  | Then, a name server connected to three LANs of a triply
  | homed site has 9 addresses.

Yes, it would.   But that the addresses exist doesn't mean they have to
all be listed in the AAAA records of the name that is listed in the NS
record.   Listing one address (perhaps one from a different LAN) from
each ISP's prefix is sufficient, more than that just adds more useless
retries in the common failure case where the problem is that the nameserver
(or its host) is down.

We should be encouraging better use of resources, not just "stick it
all in because that's the thoughtless way" - especially in docs from
dnsops.

  | Things can get even more complicated if some of the servers are
  | in other sites (it is important for fault tolerance) operated by
  | other admins.

The server can be in another site, in my NS records however, I decide
what I will call it, and if I give it a name from my space, I also
decide what addresses it will have.

kre

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 11 May 2004 04:44:29 +0900

kre;

> retries in the common failure case where the problem is that the nameserver

The problem is that the situation will be common that you can't
expect much on operators there.

> decide what addresses it will have.

Not all the operators are like you.

							Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Fri, 28 May 2004 14:24:50 +0000

robert wrote:

> The "problem" of AXFR is that it requires a stable zone image to
> transfer, and so the server must (somehow) create that stable zone,
> when the AXFR request is made, and then transfer the zone as it was at
> the instant the initial SOA of the response was sent - regardless of
> any later changes that are made to the zone.
> 
> Since the server has no idea whether or not any changes may be made to
> the zone while the transfer is in progress, it has to do something to
> prepare for the possibility that they may occur (as it also has no way
> to know how long the zone transfer will take to complete, it also
> can't just delay updates until after that has happened - that could be
> hours, or more, into the future).
> 
> This is what makes AXFR costly, [...]

RFC 1035 makes a provision for killing in-progress AXFR if the zone changes
while it's being transferred, and BIND4/BIND8 work that way.  this causes
problems for extremely-dynamic zones, like when UPDATE is used by dhcp in
an enterprise or wireless context, and so BIND9 has extensive (and expensive)
internal versioning and refcounting so that a zone at a certain serial number
can continue its AXFR even though newer zones (with different serial numbers)
are being used for subsequent queries (or even subsequent AXFR).  robert is
quite right, this is the biggest reason why a TLD registry (or anyone else)
would find AXFR expensive.

however, back in the days when f-root served COM, we were alone among the
root servers in supporting AXFR for it.  network solutions hated this
practice, and ultimately had someone in USGov send us a letter asking us
to turn it off, which we did.  but while it was on, our puny little 8GB
4x500MHz alphas handled a hell of a lot of outbound AXFR traffic for what
was, even then, the largest zone on the planet.  we did it on BIND8 and we
did it on BIND9.  the load, while expensive in exactly the ways that robert
suggests above, was never a noticable problem for a little nonprofit without
a hardware budget who was totally dependent on the kindness of our friends.

in these days when a dual or quad Opteron with 16GB and 2x2GHz or 4x2GHz
can be had from reputable vendors like sun, ibm, hp, or a hundred whitebox
vendors for a couple thousand USD, no serious commercial entity can complain
that any zone, even one the size of COM, cannot support AXFR.

> ...
> 
> It is also worth noting that the oft made claim that NSEC allows pristine
> zone copies to be made is false - it improves the chances of that happening
> over some other methods, but it is certainly not a technique that will
> guarantee the successful transfer of a zone.

agreed.  an NSEC chainwalk would have none of AXFR's guaranteed stability.
if the zone changes during a chainwalk, then you get part of the old and
part of the new.  not that this makes much difference to the zone operators,
who are clearly more concerned with competition and abuse than with copyright
or resources.

paul