Subject: [dnsext] single-ton AXFRs, was Re: -10

From: Edward Lewis <[email-masked]>
Date: Thu, 12 Feb 2009 16:11:24 -0500

In going through some noted from Alfred...

>>  What is done about old servers that put one RR per message into AXFR
>>  responses?  How does this play with the words about complete RR sets?

At 11:40 +1100 12/31/08, Mark Andrews wrote:

>
>	The answer is the set of messages which make up the AXFR
>	response.  As long as the set of messages contains the
>	complete RRset there is no problem.

The question is how do we patch up this inconsistency?:

[RFC 2181]
9. The TC (truncated) header bit

    The TC bit should be set in responses only when an RRSet is required
    as a part of the response, but could not be included in its entirety.
    The TC bit should not be set merely because some extra information
    could have been included, but there was insufficient room.  This
    includes the results of additional section processing.  In such cases
    the entire RRSet that will not fit in the response should be omitted,
    and the reply sent as is, with the TC bit clear.  If the recipient of
    the reply needs the omitted data, it can construct a query for that
    data and send that separately.

    Where TC is set, the partial RRSet that would not completely fit may
    be left in the response.  When a DNS client receives a reply with TC
    set, it should ignore that response, and query again, using a
    mechanism, such as a TCP connection, that will permit larger replies.

This says an incomplete RRSet triggers a TC bit.  Should AXFR clarify 
say that DNS clarify's words on TC setting to not apply to AXFR?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Never confuse activity with progress.  Activity pays more.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 Feb 2009 11:14:02 +1100

The DNS is missing the ability to return a QUERY response
	with arbitrary number of records.  AXFR is a reponse to
	that.  Note we don't define what you do when you have to
	set TC in a TCP response.

In message <a06240804c5ba3ffbc72e@[0.0.0.0]>, Edward Lewis writes:
> --============_-977649409==_ma============
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
> 
> --============_-977649409==_ma============
> Content-Type: text/html; charset="us-ascii"
> 
> <!doctype html public "-//W3C//DTD W3 HTML//EN">
> <html><head><style type="text/css"><!--
> blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
>  --></style><title>single-ton AXFRs, was Re: -10</title></head><body>
> <div>In going through some noted from Alfred...</div>
> <div><br></div>
> <div>&gt;&gt; What is done about old servers that put one RR per
> message into AXFR<br>
> &gt;&gt; responses?&nbsp; How does this play with the words about
> complete RR sets?<br>
> </div>
> <div>At 11:40 +1100 12/31/08, Mark Andrews wrote:</div>
> <div><br></div>
> <div>&gt;<br>
> &gt;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>The answer is the
> set of messages which make up the AXFR<br>
> &gt;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>response.&nbsp;
> As long as the set of messages contains the</div>
> <div>&gt;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>complete
> RRset there is no problem.</div>
> <div><br></div>
> <div>The question is how do we patch up this inconsistency?:</div>
> <div><br></div>
> <div>[RFC 2181]</div>
> <div>9. The TC (truncated) header bit<br>
> <br>
> &nbsp;&nbsp; The TC bit should be set in responses only when an RRSet
> is required<br>
> &nbsp;&nbsp; as a part of the response, but could not be included in
> its entirety.<br>
> &nbsp;&nbsp; The TC bit should not be set merely because some extra
> information<br>
> &nbsp;&nbsp; could have been included, but there was insufficient
> room.&nbsp; This<br>
> &nbsp;&nbsp; includes the results of additional section processing.&nbsp;
> In such cases<br>
> &nbsp;&nbsp; the entire RRSet that will not fit in the response should
> be omitted,<br>
> &nbsp;&nbsp; and the reply sent as is, with the TC bit clear.&nbsp; If
> the recipient of<br>
> &nbsp;&nbsp; the reply needs the omitted data, it can construct a
> query for that<br>
> &nbsp;&nbsp; data and send that separately.<br>
> <br>
> &nbsp;&nbsp; Where TC is set, the partial RRSet that would not
> completely fit may<br>
> &nbsp;&nbsp; be left in the response.&nbsp; When a DNS client receives
> a reply with TC<br>
> &nbsp;&nbsp; set, it should ignore that response, and query again,
> using a<br>
> &nbsp;&nbsp; mechanism, such as a TCP connection, that will permit
> larger replies.<br>
> </div>
> <div>This says an incomplete RRSet triggers a TC bit.&nbsp; Should
> AXFR clarify say that DNS clarify's words on TC setting to not apply
> to AXFR?</div>
> <x-sigsep><pre>-- 
> </pre></x-sigsep>
> <div
> >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<span
> ></span>-=-=-=-</div>
> <div>Edward
> Lewis&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
> ></span>&nbsp;&nbsp;&nbsp;<br>
> NeuStar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
> ></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; You can
> leave a voice message at +1-571-434-5468</div>
> <div><br></div>
> <div>Never confuse activity with progress.&nbsp; Activity pays
> more.</div>
> </body>
> </html>
> --============_-977649409==_ma============--
> 
> --
> 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/>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: Edward Lewis <[email-masked]>
Date: Thu, 12 Feb 2009 19:25:26 -0500

>	set TC in a TCP response.

I get the meaning of the last sentence but not the first two.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 Feb 2009 12:10:37 +1100

> I get the meaning of the last sentence but not the first two.

	If foo.example has 4096 A records the DNS, as currently
	specified, provides no mechanism to return that RRset to
	the caller other than issuing a AXFR query and extracting
	the records.  I believe this is a gap in the protocol
	specification.

	I have seen PTR query responses set TC because the entire
	RRset could not fit into a 64K messsage.

	If the DNS had a mechanism to return those 4096 A records,
	then there would not have been a need to specify a special
	transport method for AXFR as it would have just been treated
	like any other big query response.

	Note: Now that DNSSEC is being deployed the response to ANY
	queries at zone apex are starting to exceed the capabilities
	of the DNS protocol.

	Mark

---

From: Edward Lewis <[email-masked]>
Date: Tue, 17 Feb 2009 15:15:30 -0500

Digesting this now - I forget what this has to do with AXFR.

Maybe that the TC bit is never set or needed in AXFR.