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

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

oops.  you're right.

>    Where TC is set, the partial RRSet that would not completely
>    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: Paul Vixie <[email-masked]>
Date: Fri, 07 May 2004 19:57:43 +0000

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

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

> Matt Larson;
> 
> > 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.
> 
> 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.

	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.

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