Subject: handling of additional data (fwd)

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

[ Moderators note: Post by non-subscriber.  With the massive amount of
   spam, it is easy to miss and therefore delete relevant posts 
   by non-subsrcibers. Please fix your subscription addresses. ]

FYI,

This issue was raised in DNSOP, but I was advised to also solicit 
opinions from here.

(I'm not subscribed so please keep in Cc:)

---------- Forwarded message ----------
Date: Tue, 4 May 2004 12:24:15 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: handling of additional data [Re: [dnsop] WGLC for
    draft-ietf-dnsop-ipv6-dns-issues-06.txt]

Hi,

Let's take an issue separately from the rest.  Me and Jinmei discussed
this, but were OK with as it is.  However, if WG has clear opinions,
now might be time for modifying the text and/or recommiding changes to
the additional data processing.

As described by ipv6-dns-issues, section 4.4, there are two kinds of 
additional data:

   1.  "critical" additional data; this must be included (all the
       possible RRsets) in all scenarios, and
                                                                                             
   2.  "courtesy" additional data; this could be sent in full, with only
       a few RRsets, or with no RRsets, and can be fetched separately as
       well, but which could lead to non-optimal results.

[[ see examples of each in the draft.]]

Imagine the event where the additional data section would include both
A and AAAA RRsets and would be too large, but omitting one RRset would 
make it small enough.

Now, the questions are:

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

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

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?

Opinions?  Discussion? Etc.?

As for my personal preference:
 A) probably yes (not sure).
 B) yes, omit everything.
 C) possibly yes, not sure. (Doesn't matter if "yes" to B)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--
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: 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

---

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: Paul Vixie <[email-masked]>
Date: Fri, 07 May 2004 01:49:24 +0000

> the following text in RFC2181 section 9 which seems to contradict it:

oops.  you're right.

>    fit may be left in the response.

which is why, if TC was set, BIND assumes that the last nonempty section
has a partial rrset inside it therefore doesn't cache it.  sorry to confuse.

---

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: Paul Vixie <[email-masked]>
Date: Fri, 07 May 2004 19:57:43 +0000

> question using the RFC 1034 definition of glue.

by that definition, i agree, and if the rule change being considered is
just "if necessary glue won't fit, truncate; if helpful glue won't fit,
omit it" then i'd agree with that also.

---

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: Mark Andrews <[email-masked]>
Date: Sat, 08 May 2004 08:50:30 +1000

> That is, 1034 is not self-consistent.

	Sure there can be circular dependancies.  We don't however
	have to support them if it makes management of the DNS in
	the whole impossible.  We tried it and is was a failure.
	Stricter rules were needed.

	Can anyone else here remember when NS.UU.NET has 26 different
	addresses for it floating around in the DNS?  In reality
	it only had one address and it had been changed since it
	was initially assigned.  Only accepting glue when it was below
	the top of zone when loading/transfering zones and rejecting
	additional data when it was not below the currrent query domain
	basically fixed the problem.  It took a few years for nameservers
	which did this to get to be deployed on all the servers which
	served zones that were also served by NS.UU.NET but in the
	end the bogus records were removed.

	We don't have that problem today because nameservers actually
	enforce a heirachical glue acceptance rules.  Yes they
	prevent configurations with circular dependancies but they
	make the DNS managable.

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

---

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: Masataka Ohta <[email-masked]>
Date: Tue, 11 May 2004 05:00:00 +0900

Mark Andrews;

> 	the whole impossible.  We tried it and is was a failure.

That "we tried" means others will try.

> 	Stricter rules were needed.

It certainly is a solution.

> 	basically fixed the problem.

What is the problem? Those who buy service from UUNET and their
peers suffer that it is a problem of UUNET, doesn't it?

>  It took a few years for nameservers

Are you saying we should modify protocols/operations, merely
because of a stupid act of an ISP harming its own business?

							Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 May 2004 11:15:02 +1000

> That "we tried" means others will try.

	It means that older nameservers didn't have restrictions
	and it ended up being a management nightmare.  Been there,
	done that, don't want to go there again.

> peers suffer that it is a problem of UUNET, doesn't it?

	No *everyone* suffered.  It wasn't just UUNET.  UUNET was
	a example of what when wrong.  It happened to lots of ISP's,
	basically anyone who wasn't serving their own zones.  UUNET
	was just a prime example of the problem.

	It was a matter of "there is bad data out there, where is
	it coming from".   The answer to that used to be "anyone
	of several thousand servers for NS.UU.NET" and the servers
	could "learn" the bad addresses after or as a side of
	checking them.  Today you look at the parent servers for
	the zone.  We can do this because modern servers reject
	"out of zone" glue.
 
> because of a stupid act of an ISP harming its own business?

	No.  The protocol didn't scale on the management side.
	Placing constraints on glue restored the ability to manage
	the DNS.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 11 May 2004 11:50:22 +0900

Mark Andrews;

> 	done that, don't want to go there again.

That is a wrong analysis.

> 	was just a prime example of the problem.

So, only those who buy service from stuppid ISPs and
their peers suffered that it is a problem of stupid
ISPs.

It is not a problem for the rest of the world and to
be solved automatically as bankrupcies of stupid ISPs.

> 	No.  The protocol didn't scale on the management side.

It is merely a problem of mismanagements.

						Masataka Ohta

---

From: Edward Lewis <[email-masked]>
Date: Thu, 13 May 2004 14:14:48 -0400

...
>	done that, don't want to go there again.

Was there ever documentation of that?

>>  > 	Stricter rules were needed.

Did any of these ever get put into a document?

I don't doubt your words, I just want to know if the lessons have 
been recorded.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Even the voices inside my head are refusing to talk to me anymore.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 13 May 2004 19:36:30 +0000

> Was there ever documentation of that?

not in the form of an FYI or BCP, and it appears to have been left out
of 2181/2182 as well, but it was discussed on the old dns-security@TIS
mailing list back in april of 1994.

> I don't doubt your words, I just want to know if the lessons have been
> recorded.

here you go:

--------

From: [email-masked] (Paul A Vixie)
Newsgroups: local.mail.dns.security
Subject: Re: DNS security draft
Date: 20 Apr 94 14:47:20
Organization: Vixie Enterprises
Lines: 27
Distribution: local
Message-ID: <[email-masked]>
References: <[email-masked]>
NNTP-Posting-Host: office.home.vix.com
In-reply-to: [email-masked]'s message of 20 Apr 1994 10:03:42 -0700

>What it boils down to seems to be this.  Any resolver or server which
>preserves the distinction between authoritative and non-authoritative
>(example: glue) data better than BIND does will break the proposed
>scheme of cross-authentication of zones.
>
>[...]

BIND as of 4.9 preserves the distinction between authoritative and
nonauthoritative data; a future (post-4.9.3) version will probably answer
with a NOERROR/referral if a query arrives without RD for a name with
non-authoritative matching RR's.  as of 4.9 we are already deleting
all previous data in a node when more-authoritative info comes in.

credibility levels are, in increasing order:

        additional or authority data
        nonauthoritative answer
        authoritative answer
        authoritative local zone (pri or sec)

more details wouldn't be relevant to this thread.  i just wanted to keep
everybody from believing the BIND is still as brain-dead as it used to be.
--
Paul Vixie
Redwood City, CA
decwrl!vixie!paul
<[email-masked]>

--------