Subject: Re: handling of additional data [Re: [dnsop] WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt]

From: Pekka Savola <[email-masked]>
Date: Wed, 5 May 2004 07:48:04 +0300 (EEST)

On Wed, 5 May 2004, Masataka Ohta wrote:
> > 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.
> 
> The classification is not enough.
> 
> For an authoritative server answering a query, there are
> "glue", that is, "critical", additional data and all the
> other additionals are "courtesy". So, please don't invent
> new terminologies and just say "glue".

I used this terminology at first, but others have stated that "glue"  
is where the additional data comes from.  So just saying "glue" did
not appear to be sufficient unambiguous.
 
> For a resolver receiving a response, it is not distinguishable
> whether A for NS of referral response is "glue" or not.

Sorry for confusion -- I'm mostly interested in the _authoritative
servers_ sending the response packets.  They should be able to tell
rather easily.  The resolvers can probably have some checks as well,
but as you explain, those seem to be quite a bit more complicated..

Obviously, the resolvers receiving a response have a difficulty 
telling what it is..
 
> On the
> other hand, for resolvers, there can be "safe" and "unsafe"
> additonal data distinguishable. "safe" data is on node in
> or below the zone of the current server (zone of a server
> is available from SLIST). Other data is "unsafe".

Good to know.

> To make "safe" data really safe, which can not be expected
> with the current implementations, there are additional
> requirements.

These are what I've been interested of.

> An authoritative server should add additionals
> if it is "glue" and only if it is "glue", "authoritative" or
> cached as "safe". 

But the question now here is, what if the additional data does not fit 
in the packet due to multiple RRsets (just one RRset would fit)?  What 
would be the reasonable approach then?

> Complicated?

Yes! :)

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

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 05 May 2004 14:56:01 +0900

Pekka Savola;

> not appear to be sufficient unambiguous.

There are various sources of the additionals, including MX,
as explicitely specified in 1034.

> Obviously, the resolvers receiving a response have a difficulty 

And the complication affects an authoritative server combined
with a resolver and cache.

> would be the reasonable approach then?

First, add glues only. If data does not fit, set TC.

If data fits, attempt to add useful "authoritative" or "safe"
data unless it causes truncation.

That's all. There is nothing v6 specific except that there may
be glues other than A.

						Masataka Ohta

.

---

From: Peter Koch <[email-masked]>
Date: Wed, 05 May 2004 09:07:21 +0200

> not appear to be sufficient unambiguous.
 
and it really isn't, but I'm not too sure Masatake Ohta is challenging this.

> rather easily.  The resolvers can probably have some checks as well,

There are cases where an authoritative server is not only authoritative
for the zone in question but also for one or more zones "owning" the
NS server names.

-Peter
.