Subject: [dnsop] incomplete cached additional data and A/AAAA records

From: Pekka Savola <[email-masked]>
Date: Wed, 17 Dec 2003 21:20:58 +0200 (EET)

Hi,

I'm not sure whether I'm imagining things or whether this is a real 
problem .. comments please! :-)

There seems to be an obvious problem with caching and additional data,
if the additional data is partial, and the additional data is filtered
using some criteria to avoid going over the 512 byte limit.

For example, assume that www.example.com has A record to 1.2.3.4 and 
AAAA record to 2001:db8::1, and some other records which imply that 
the response (with full additional data) does not fit in the response.

Assume that the implementation at the servers is made so that instead 
of giving back Truncated response, it filters the response somehow: in 
this example by omitting AAAA records.

Now, assume a host queries www.example.com through a couple of caching 
servers.   Due to the response size limits, the caching servers 
cache only the A records (etc.).

Now, everybody whose queries for www.example.com go through these 
caching servers gets back only A records, or?

So, in some sense I think "it's better to have no data at all than
impartial cached data".

Am I imagining things or is "additional section selection/filtering" a
really bad idea especially if at least one entry of each available
record type is not represented?  And the filtering methods proposed
earlier and in particular in draft-hall-qtype-addr-01.txt section 4
are pretty broken?

If so, maybe there should be some kind of data on how many records of
each type exist (or at least, "at least one record of type Foo
exists"), even though there was no space for all the records to be
sent?

-- 
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: [email-masked]
Date: Thu, 18 Dec 2003 08:46:04 +1100

The only part of the DNS that really cares about additional
	data are iterative resolvers.  They can't work unless they
	can get the glue they need.  Every other client MUST be
	able to cope with missing additional data.

	Iterative resolvers only care when they can't get the glue
	address records they require.  In most cases a iterative
	resolver can re-query for missing glue.  The only time they
	can't do this at the momemnt is when you have a cross
	delegation.

	e.g.
	     all the servers for a.com in b.com and all the servers
	for b.com in a.com.

	Note delegating servers have to take care when answering
	queries for missing glue by ensuring that the glue appears
	in the additional section.  This should not be a problem
	unless the number of nameservers is excessive.

	For the cross delegation case the parent could still put the
	glue record in the additional section.  The iterative server
	just needs to accept it as there won't be a corresponding
	NS record for it.
	
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Pekka Savola <[email-masked]>
Date: Wed, 17 Dec 2003 23:51:36 +0200 (EET)

On Thu, 18 Dec 2003 [email-masked] wrote:
> 	data are iterative resolvers.  

.. which is a pretty big part of DNS..

> They can't work unless they

The main point I was trying to make is that when you get only 
*partial* additional data (e.g. only A records but not AAAA), how do 
you know that it's *partial*, not the whole truth (i.e., that you 
should go asking for AAAA records because you know you want them as 
well as the A records you got already).

.

---

From: Rob Austein <[email-masked]>
Date: Wed, 17 Dec 2003 17:27:16 -0500

<hat=just-another-bozo-on-this-bus>

Pekka,

The short answer is that additional section processing should not
break up RRsets (nothing ever should, except for weird cases like the
RRSIG which doesn't really form proper RRsets at all).

Eg, assuming zone data:

foo.example.	IN	MX	1 foo.example.
			MX	2 bar.example.
			A	192.0.2.1
			A	192.0.2.2
			AAAA	2001:0db8::f00
bar.example.		A	192.0.2.3
			AAAA	2001:0db8::baa
			AAAA	2001:0db8::baaa

and a query <QNAME=foo.example., QTYPE=MX, QCLASS=IN>,

- you should get back 192.0.2.1 as additional data if and only if you
  also get back 192.0.2.2;

- you should get back 2001::0db8::baa as additional data if and only
  if you also get back 2001::0db8::baaa;

- but pretty much all the other possible combinations of addresses as
  additional data, while perhaps suboptimal, would be legal.

Does this answer your question?

</hat>
.

---

From: [email-masked]
Date: Thu, 18 Dec 2003 11:05:23 +1100

> well as the A records you got already).

	You don't know if there are dropped records however this
	really isn't a problem.  You use what you get then look
	for missing glue when you exhaust the supplied glue.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 18 Dec 2003 09:57:23 +0900

Pekka Savola;

> you know that it's *partial*, not the whole truth

I think your concern is, for glue cases, valid and servers are
not allowed to omit "necessary" glue information, even if
inclusion causes message truncation.

"necessary" means that, if some (but not all) of the related
nameservers are down, you can't reach authoritative server of
glue information unless you have glue information.

A problem is that, because of possible complex delegation loop,
relays can not judge whether some glue is "necessary" or not.
Administators of authoritative nameservers can. So, relay
implementations must be careful to cache answers including glue
to be able to reproduce the original answers (there is additional
complexity w.r.t. TTL, of course).

In other cases, you can make other queries.

> (i.e., that you 

That's insufficient. Considering the possibility of "necessary"
glue, which can not be queried separately, you should resubmit
the original query with TCP.

If such requery is expected to occur to root servers, anycast
will be helpful to distribute load.

						Masataka Ohta

.

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 17 Dec 2003 21:49:34 -0600

> exists"), even though there was no space for all the records to be

The concern is valid. I asked the same question to namedroppers when I was
writing the draft (see <[email-masked]> attached).

A couple of critical points to keep in mind here. First is that RFC 1886
(the ADDR spec) already defined a just-include rule for additional data,
and draft-hall-qtype-addr-01 just tries to optimize the existing rule.
Second is that getting incomplete additional-data is going to be
unavoidable -- perhaps a legacy cache only returns the A RRs in subsequent
responses, one of which goes to your host. Given these considerations,
incomplete additional-data is just something that clients are going to
have to deal with regardless of what we do here. It's a fact of life.

There are ways to improve the clarity but the available mechanisms all
have costs and I'm not sure the costs are worth the benefits, especially
given the realities above. Setting TC just means a whole lot more TCP
requeries, but for very little gain in a very large number of cases (if
the world is 90% IPv4-only now, then 90% of the TC responses will be
unnecessary today; reverse this for whenever IPv6 goes to 51%). Or you
could use some other kind of flagging mechanism (add 128 to the code
value, perhaps, or whatever), but DNS is already too fragile for my liking
and I'm not keen on making it moreso.

There is a free fix to most problem cases, which is to use EDNS.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Subject: incorporating just-include; dealing with truncation
From: "Eric A. Hall" <[email-masked]>
To: [email-masked]
Date: Mon, 24 Nov 2003 14:22:54 -0600

Although I've argued against just-include-AAAA as a prima strategy (and
for good reasons), that approach does have significant merit in those
cases where A RRs would be included as additional data, but where AAAA RRs
would not. Thus, even though I'm not backing that approach for all
queries, I do plan on incorporating it into the updated qtype=addr draft
as a secondary mechanism for use whenever another query would produce A
RRs as additional data. This approach seems to recognize and incorporate
the strengths of both models, but without mandating that the weaknesses of
either model in isolation also be embraced as a cost of doing business.
Specifically, I'm specifying that qtype=addr be provided as a way for
dual-stack systems to request all of the addressing RRs defined for a
target domain name, and also specifying a just-include algorithm that
should be used with lookups that would produce A RRs as additional data.

One of the sticky points that I raised about just-include has to do with
message size, and what to do with truncated answer sets. What I'm going to
propose here is that if only one of the addressing RRsets can fit in the
message without causing truncation, favor the address type that matches
the protocol used by the query. For example, if the query arrived via
IPv4, then favor the A RRs in the answer and truncate the AAAA RRs if
necessary. Similarly, if a query arrived via IPv6, then favor the AAAA RRs
in the answer and truncate the A RRs if necessary. This rule would take
effect whenever a response would include A RRs as additional data, such as
responses to MX queries, glue data, and so forth.

The nice thing about this approach is that it's transitional; as hosts are
defined with single-stack addresses (either with IPv4 now, or IPv6 in the
distant future), the focus naturally moves along towards the single
addressing syntax in use, and the burden is (appropriately) at its highest
as hosts are defined with dual-stack addresses.

I've got a couple of relatively minor issues here. First of all, what
should be done about the TC flag? Since this rule would only apply to
additional data, the TC flag isn't mandatory (and has some associated
costs) but it would be useful (and its absence would also have costs). On
the one hand, if the TC flag is enabled for incomplete responses, then
single-stack hosts may end up burning costs on TCP requeries for no
meaningful data. On the other hand, if the TC is not enabled, then
dual-stack hosts won't be able to tell that the target supports multiple
address types. Since the planned algorithm favors the address family in
use, however, this may not be so bad (EG, who cares if a dual-stack host
doesn't learn about IPv4 addresses, if it wanted to use IPv6 addresses
anyway). Of course, just because a particular client uses IPv6 for DNS
lookups doesn't necessarily mean that all of the other applications on
that host are capable of supporting IPv6, so the absence of the
information can be critical. I can go either way on this, but I think that
in general it would be easiest to disable TC in these responses, and put
the onus on (the relatively newer) IPv6-aware resolvers to either issue
followup requests for the missing data, or to use EDNS, or whatever. That
seems to be easier than forcing legacy IPv4 resolvers to use TCP to get
meaningless data.

Secondary issue is procedural/administrative: since this algorithm will
affect all of those scenarios where IPv4 address RRs are returned as
additional data, does this document need to "update" all of those specs?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

--
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: Pekka Savola <[email-masked]>
Date: Thu, 18 Dec 2003 15:42:26 +0200 (EET)

> and draft-hall-qtype-addr-01 just tries to optimize the existing rule.

Whether this optimization is appropriate is a different subject..

> have to deal with regardless of what we do here. It's a fact of life.

I'm not sure if we have to resign to the fact of incomplete
additional-data.

In your example, wouldn't the legacy cache not be able to handle the
AAAA record query in the first place if it wouldn't return the AAAA
records from its cache -- I don't somehow this particular failure
mode.

.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Dec 2003 15:34:19 +0200 (EET)

> 	for missing glue when you exhaust the supplied glue.

Perhaps I should clarify what I was after from the v4/v6 transition
point of view:  this does not seem to be as straightforward in some
cases.

Consider a case where using IPv4 or IPv6 to reach a destination are
somehow inequal (e.g., IPv4 will have to go through a protocol
translator, IPv4 will have to get a dynamically allocated v4 address
using some mechanism, etc.) -- and the lack of glue might force one to
use v4 (for example) when it strictly speaking wouldn't be necessary.

When v4 and v6 are completely equal, this doesn't seem to matter as
much.  But in some scenarios at least some folks (I'm not sure whether
I subscribe to that or not :-) would prefer to avoid using particular
protocol if there are other options.  And that appears to be 
difficult if glue is not sufficiently consistent.

.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 18 Dec 2003 11:54:55 -0500

>complexity w.r.t. TTL, of course).

This is very true.

In the development of DNSSEC we have haggled over whether or not an 
authoritative server ought to emit data it thought cryptographically 
invalid based on either the mathematics or temporal restrictions.  In 
summary, we learned that we ought never allow a name server to edit a 
zone.  As far as mathematically invalid - the question ranged from a 
server not being able to access all of the keys on start (example.com 
doesn't find .com during load) and a server with a lot of data would 
waste a lot of time loading if it checked all signatures.  As far as 
temporal - a signature may be valid on load but expire before the 
zone is refreshed.

Another point to keep in mind is that the more DNS "internally" 
(meaning the servers, both authoritative and recursive) edits the 
data send, the more opaque it gets.  We lost the end-to-end-ness, 
which is bad for debugging and makes things like NAT not work.  (Like 
them or not, it should not be a goal to make them break.  Yes, NAT is 
a larger issue, my point is that DNS should stick to simplicity to 
not obviate unforseen future advances.

Getting back to Ohta-san's point, servers are not policy wonks. 
Policy is up to the administrators and the applications.  They are 
the end-to-end masters of the DNS, not the servers in between.

PS - I've been tracing the steps one implementation takes in chasing 
glue.  It asks for A and AAAA at each step (at one time A6 too), also 
using EDNS0.  The result is four queries to non-EDNS servers to get 
possibly one address record.  Wasteful - but, what's the alternative? 
If the implementation only chased A's until it found the name and 
then looked for AAAA, that hurts V6.  There's no way of telling if, 
at any moment, a query will be answered by data, negation, or a 
referral.  So, asking for all simultaneously is the only rational "in 
self-interest" strategy.

PPS - Glue is a stickier issue than we realize.  Watch a few packet 
traces just for fun.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

History repeats, therefore my life is a rerun.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: [email-masked]
Date: Fri, 19 Dec 2003 07:39:35 +1100

> difficult if glue is not sufficiently consistent.

	Glue is glue.  It doesn't matter whether it is A or AAAA.  You
	use what you can then request what is missing.

	None of the issues hear have changed with the introduction of IPv6.

	You have glue being dropped today because sites have excessive
	numbers of nameservers.  Try asking for a really long name from
	the root servers under com or net.  You may only have one glue
	record.

; <<>> DiG 9.2.3 <<>> 456789.12456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.vix.com @f.root-servers.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31348
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 1

;; QUESTION SECTION:
;456789.12456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.vix.com. IN A

;; AUTHORITY SECTION:
com.                    172800  IN      NS      L.GTLD-SERVERS.NET.
com.                    172800  IN      NS      M.GTLD-SERVERS.NET.
com.                    172800  IN      NS      A.GTLD-SERVERS.NET.
com.                    172800  IN      NS      B.GTLD-SERVERS.NET.
com.                    172800  IN      NS      C.GTLD-SERVERS.NET.
com.                    172800  IN      NS      D.GTLD-SERVERS.NET.
com.                    172800  IN      NS      E.GTLD-SERVERS.NET.
com.                    172800  IN      NS      F.GTLD-SERVERS.NET.
com.                    172800  IN      NS      G.GTLD-SERVERS.NET.
com.                    172800  IN      NS      H.GTLD-SERVERS.NET.
com.                    172800  IN      NS      I.GTLD-SERVERS.NET.
com.                    172800  IN      NS      J.GTLD-SERVERS.NET.
com.                    172800  IN      NS      K.GTLD-SERVERS.NET.

;; ADDITIONAL SECTION:
A.GTLD-SERVERS.NET.     172800  IN      A       192.5.6.30

;; Query time: 171 msec
;; SERVER: 192.5.5.241#53(f.root-servers.net)
;; WHEN: Fri Dec 19 07:05:52 2003
;; MSG SIZE  rcvd: 511

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 19 Dec 2003 06:28:31 +0900

Mark.Andrews;

> 	None of the issues hear have changed with the introduction of IPv6.

With IPv6, trancation is morelikely, which is the change.

> 	the root servers under com or net.  You may only have one glue

With your example of query for "com." all the name servers of which
are under "net." all the name servers of which are under "net.",
glues are not "necessary" that the behaviour is fine.

A problem is that the root server gives similar reply to similar
query for "vix.net".

Then, there is a subtlity whether glues are "necessary" or not.

In theory, it may be and the implementation is broken.

In practice, it may not be, if name servers do not gives up against
the obvious delegation loop (all the name servers are under zone cut)
and ask As of "?.gtld-servers.net", because query for
"?.gtld-servers.net" gives all the "necessary" glues without
truncation.

In practice with both A and AAAA, it is, because explicite query
for "?.gtld-servers.net" will also be truncated.

If the case is too difficult to understand, just consider a
case of "vix.net" with just a single AAAA and no A glue
returned. Then, IPv4 only host is at a loss.

							Masataka Ohta

.

---

From: [email-masked]
Date: Fri, 19 Dec 2003 09:06:30 +1100

> returned. Then, IPv4 only host is at a loss.

	No.  It just asks the parent the missing glue records
	individually.  In this case for ?.gtld-servers.net/A records
	from the root servers.

	The only time it will loose is when the NS RRset is too big
	to even allow the requested glue RRset to be added
	preferentially to the additional section.

	If the parent server is really smart it will reserve enough
	space for the requested glue RRset.  Attempt to add the NS
	RRset.  If that fails it will set TC and return the message.
	Otherwise it will then release the reserved space for the
	glue RRset.  Add the glue RRset then add any other additional
	records that will fit.
	
	The reserved space is 16 octets per A and 28 octets per AAAA.

	Older parent servers that promote glue to answer don't even
	have this problem.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 19 Dec 2003 09:42:44 +0900

Mark.Andrews;

> 	preferentially to the additional section.

No. In general, clients can not know which nameserver needs
glues and to which nameserver to ask. If a delegation loop
involves multiple zones, clients have no reason to ask, for
example, a "com." zone nameserver addresses of nameservers of
zones under "edu." 

> 	Older parent servers that promote glue to answer don't even

Glue is glue.

Glue information should be answered only as glue.

DNS works, if a child zone nameserver can be contacted at an
address of a nameserver, which means most of the glue
information can be incorrect.

On the other hand, DNS answers are expected to be authoritative
one or copy of it.

							Masataka Ohta

.

---

From: [email-masked]
Date: Fri, 19 Dec 2003 12:08:44 +1100

> example, a "com." zone nameserver addresses of nameservers of

	The fully general case doesn't work even if the parents
	return glue for out of scope servers because the caches
	will reject it.

	For the cross servers under the same parent the glue can
	still be returned in the additional section even if it is
	not a server for the zone it lives in.
 
> Glue information should be answered only as glue.

	I'm not suggesting otherwise.  I was just pointing out that
	the older servers did do this so lack of space would never
	prevent the glue being returned.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 19 Dec 2003 17:32:44 +0900

Mark.Andrews;

> 	return glue for out of scope servers because the caches

Wrong. Though some broken implementaion may reject caching of
glue, it merely means inefficiency and does not at all mean
broken relaying.

As you said, glue is glue.

Proper implementations should cache glue as glue to be used
in an additional section but never in an answer section.

> 	not a server for the zone it lives in.

That is an improper workaround.

> 	prevent the glue being returned.

I'm afraid you don't understand full implication of "glue is glue".

W.r.t. caching, "Glue information should be answered only as glue."
means glue information may be cached as long as the cached information
is used in answers only as glue in additional secitons.

							Masataka Ohta

.