Subject: Re: I have a feeling that the rules for setting TC need tweaking

From: Edward Lewis <[email-masked]>
Date: Sun, 6 Feb 2005 23:57:37 -0500

At 11:01 +1100 2/7/05, Mark Andrews wrote:

>	I propose that nameservers be allowed to set TC in these
>	case.  For the glue case above it would only be if it will
>	not fit as the first glue RRset in the additional section
>	with or without space being reserved for TSIG and/or EDNS.

This sounds like a matter that will need some study...you know the 
rules - send in a personal draft. ;)  Sounds like there will be some 
sharp corner cases to consider.

Perhaps you mean to say that if a response will have TSIG/EDNS0 in 
it, then TC is set for some definition of incompleteness in the 
additional section.  For non-TSIG/EDNS0 servers you'd get FORMERR 
anyway, what happens to the current deployed base of 
TSIG/EDNS0-capable servers?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

--
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: "Eric A. Hall" <[email-masked]>
Date: Mon, 07 Feb 2005 14:32:16 -0500

On 2/6/2005 7:01 PM, Mark Andrews wrote:

> 	* RFC 2181 precludes sending glue as a answer.  This leads
> 	to cases where, with big enough RRsets, you can't return
> 	the requested glue even as the first additional RRset.

This isn't really needed if all the necessary prerequisites are met and
the resolver does what it's supposed to. It wouldn't save anything, other
than providing explicit pointer instead of having to rely on implicit
logics. I mean, if the NS RRs are present and the parent servers are
reachable, the resolver can go and fetch the glue data separately without
being told that the data would not fit in the answer (it would still have
to do that even if the TC flag were set so the only real shortcut here
would be in the resolver logic).

There are also a lot of really weird corner cases here... my QTYPE ADDR
draft had some gymnastics that could be difficult to work with in such a
case, for exammple, but there's also a huge installed base of RFCs and
implementations alike that have been hammered on when TC is appropriate.

There's probably another way to skin this cat that doesn't cause problems
for core/critical handling that's already out there.

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

---

From: Pekka Savola <[email-masked]>
Date: Mon, 7 Feb 2005 22:39:10 +0200 (EET)

> would be in the resolver logic).

FWIW, draft-ietf-dnsop-ipv6-issues-10.txt section 4.4 (with 
subsections) discuss some of these problems in a specific context.

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 08 Feb 2005 10:12:27 +1100

> would be in the resolver logic).

	You are missing the point.  The query that needs the TC set *is*
	the glue query to the parent.

	If you are querying the parent (NET) for NS.EXAMPLE.NET/A and the
	size of the RRsets for EXAMPLE.NET/NS and NS.EXAMPLE.NET/A exceed
	what can fit in the UDP response you have a case were you can't
	fetch the glue.

	Note we can't assume we can reach any other servers for EXAMPLE.NET
	as we may have tried all of them and are just missing the glue for
	NS.EXAMPLE.NET.

	Older servers returned the NS.EXAMPLE.NET/A record in the answer
	section so if it didn't fit you would get TC set and fall back
	to TCP.  RFC 2181 changes the section where the glue is returned.
 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 07 Feb 2005 20:56:11 -0500

> 	what can fit in the UDP response you have a case were you can't

Sure you can: ask the servers for the NS.EXAMPLE.NET/A discretely. That's
what they have to do anyway, so it's best to just bonk them and say as
much. My main point is that changing the meaning of TC is probably bad.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 08 Feb 2005 11:27:49 +0900

> much. My main point is that changing the meaning of TC is probably bad.

RFC1034

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.

							Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Tue, 08 Feb 2005 14:08:01 +1100

> much. My main point is that changing the meaning of TC is probably bad.

	F implement RFC 2181 rules.   Note it has the glue for
	A.GTLD-SERVERS.NET and it is NOT returned in the ANSWER
	section.  Now let the NS RRset for NET get bigger and / or
	the A RRset for A.GTLD-SERVERS.NET get bigger so that their
	combined sizes exceed 476 octets.

	Prior to RFC 2181 you would just set TC as you couldn't fit
	the response into the ANSWER and AUTHORITY sections.  With
	RFC 2181 we still need to get the same information returned
	with the same space constaints however the A RRset now appears
	in the ADDITIONAL section and the current rules say that you
	don't set TC so all you return is the NS RRset and any other
	additonal RRsets that still fit.  You don't get the glue you
	are requesting.  You don't get any indication that if you were
	to retry the query with TCP that you would be able to get the
	glue.

	I know people will say that this is contrived.  Add DNSSEC,
	with associate DS, RRSIG(DS) an OPT records, and a broken
	firewall forcing the client to use a 512 byte UDP size to the
	picture and it becomes a lot less contrived.

; <<>> DiG 8.3 <<>> a.gtld-servers.net @f.root-servers.net +norec 
; (2 servers found)
;; res options: init defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13343
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 15
;; QUERY SECTION:
;;	a.gtld-servers.net, type = A, class = IN

;; AUTHORITY SECTION:
net.			2D IN NS	B.gtld-servers.net.
net.			2D IN NS	C.gtld-servers.net.
net.			2D IN NS	D.gtld-servers.net.
net.			2D IN NS	E.gtld-servers.net.
net.			2D IN NS	F.gtld-servers.net.
net.			2D IN NS	G.gtld-servers.net.
net.			2D IN NS	H.gtld-servers.net.
net.			2D IN NS	I.gtld-servers.net.
net.			2D IN NS	J.gtld-servers.net.
net.			2D IN NS	K.gtld-servers.net.
net.			2D IN NS	L.gtld-servers.net.
net.			2D IN NS	M.gtld-servers.net.
net.			2D IN NS	a.gtld-servers.net.

;; ADDITIONAL SECTION:
a.gtld-servers.net.	2D IN A		192.5.6.30
a.gtld-servers.net.	2D IN AAAA	2001:503:a83e::2:30
B.gtld-servers.net.	2D IN A		192.33.14.30
B.gtld-servers.net.	2D IN AAAA	2001:503:231d::2:30
C.gtld-servers.net.	2D IN A		192.26.92.30
D.gtld-servers.net.	2D IN A		192.31.80.30
E.gtld-servers.net.	2D IN A		192.12.94.30
F.gtld-servers.net.	2D IN A		192.35.51.30
G.gtld-servers.net.	2D IN A		192.42.93.30
H.gtld-servers.net.	2D IN A		192.54.112.30
I.gtld-servers.net.	2D IN A		192.43.172.30
J.gtld-servers.net.	2D IN A		192.48.79.30
K.gtld-servers.net.	2D IN A		192.52.178.30
L.gtld-servers.net.	2D IN A		192.41.162.30
M.gtld-servers.net.	2D IN A		192.55.83.30

;; Total query time: 179 msec
;; FROM: drugs.dv.isc.org to SERVER: 2001:500::1035
;; WHEN: Tue Feb  8 13:41:02 2005
;; MSG SIZE  sent: 36  rcvd: 506

---

From: "D. J. Bernstein" <[email-masked]>
Date: 16 Feb 2005 01:49:38 -0000

The situation seems quite straightforward to me. Fundamental rules:

   (1) If the server's response doesn't fit into UDP, it has to be sent
       through TCP. (The server sets the TC bit; the client makes a TCP
       connection.)

   (2) If the server's response is a normal answer (or a CNAME), it must
       include the answer records (or the CNAME record).

   (3) If the server's response is a referral (in bailiwick), it must
       include the relevant IP addresses. See RFC 1034 section 4.2.1.
       Of course, by rule #1, this referral---with the IP addresses---
       must be sent through TCP if it doesn't fit into UDP.

The server might add other records (and often can improve performance by
doing so), but those other records are optional.

These fundamental rules are separate from the rules for assigning
records to sections. In particular, it's not true that records in the
answer section are the only required records; RFC 1123 section 6.1.3.2
third sentence is both inadequate and misleading.

Here's what my software does:

   * Client: If a packet shows up with the TC bit, I throw it away and
     retry through TCP.

   * Server: If I have a packet over 512 bytes to be sent through UDP, I
     try throwing away the additional section _if the packet is not a
     referral_; if it's still over 512 bytes, I try throwing away the
     authority section _if the packet is not a referral_; it it's still
     over 512 bytes, I throw away _all_ records and set the TC bit.

Each of these strategies has a perfect interoperability record.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago