Subject: [dnsext] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-01.txt

From: Ray Bellis <[email-masked]>
Date: Tue, 27 Mar 2012 08:29:36 +0000

A new version of I-D, draft-bellis-dnsext-multi-qtypes-01.txt has been successfully submitted by Ray Bellis and posted to the IETF repository.

Filename: draft-bellis-dnsext-multi-qtypes
Revision: 01
Title: Title
Creation date: 2012-03-27
WG ID: Individual Submission
Number of pages: 7

Abstract:
  This document specifies a method for a DNS client to request
  additional DNS record types to be delivered alongside the primary
  record type specified in the question section of a DNS query.

Following discussions on this topic on the DNSOP list a couple of weeks ago I decided I ought to post this previously unsubmitted draft for the record.

https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/

There was (very briefly) a -00 of this posted this morning but I realised I had an incorrect reference in it.

Ray

_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Dick Franks <[email-masked]>
Date: Tue, 27 Mar 2012 12:29:06 +0100

Ray,

IMHO data format is horribly overcomplicated.

[3.1] redundant OPTION-DATA content

 OPTION-DATA: Option specific, as below:

                    +0 (MSB)                            +1 (LSB)
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    0: |QTD|   reserved    |  QTCOUNT  |           QT1 (MSB)           |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    2: |           QT1 (LSB)           |              ...              |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |              ...             ///          QTn (MSB)           |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |           QTn (LSB)           |
       +---+---+---+---+---+---+---+---+

   QTD: this bit indicates the direction of the packet.  It MUST be
   clear (0) in a query and set (1) in a response.

Redundant: packet direction determined by QR flag in packet header.

   QTCOUNT: a 3 bit field with range 0 .. 7 specifying the number of QT
   fields to follow.

Redundant: easily calculated from OPTION-LENGTH.

OPTION-DATA then becomes:

 OPTION-DATA: Option specific, as below:

                    +0 (MSB)                            +1 (LSB)
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    0: |                             QTYPE1                            |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |                              ...
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |                             QTYPEn                            |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   QTYPEn: a 2 octet field specifying a DNS RR type.  The RR type MUST
   be for a real resource record, and MUST NOT refer to a pseudo RR type
   such as "OPT", "IXFR", "TSIG", etc.

--Dick

On 27 March 2012 09:29, Ray Bellis <[email-masked]> wrote:

>
> A new version of I-D, draft-bellis-dnsext-multi-qtypes-01.txt has been
> successfully submitted by Ray Bellis and posted to the IETF repository.
>
> Following discussions on this topic on the DNSOP list a couple of weeks
> ago I decided I ought to post this previously unsubmitted draft for the
> record.
>

---

From: Ray Bellis <[email-masked]>
Date: Tue, 27 Mar 2012 11:51:47 +0000

> Redundant: packet direction determined by QR flag in packet header.

Not at all, per the text the intention of the QTD bit is to distinguish between a server which correctly parsed the option, and one that simply echoed it.
 
> Redundant: easily calculated from OPTION-LENGTH.

That may be fair - it's a year since I wrote the draft so I need to recall what the rationale was for not relying on the OPTION LENGTH.

kind regards,

Ray

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 27 Mar 2012 04:58:38 -0700

I think this is a bad idea:  

There are two kinds of secondary resource records: ones that can be asked in parallel (e.g. A and AAAA records associated with the same name), and ones that are sequentialized (e.g. the A and AAAA records corresponding to MX entries).

As far as I can tell, this draft only addresses the former, not the latter, as for the latter the client doesn't know yet which question to ASK, so it can't construct a multiple question query.

And in the former case, the efficiency savings are actually negative:  It imposes a needless sequentialization on what was previously a parallel activity of asking both questions separately.  

If the server has one record in the cache but not the other, it will have to wait until it has the other record.  This slows "happy eyeballs" approaches where A and AAAA records are looked up simultaneously, and then the contacts also proceed in parallel.

So this approach can NEVER be faster for the server to compute, only equal time or slower, thus the only speedups can occur if this made communication substantially smaller.

But it doesn't.  You only save the packet framing one one question and one response per additional RTYPE queried, which is, in practice, roughly 200B of traffic when one includes ALL overhead (including interframe gaps, ethernet framing and minimum packet sizes).  On a slow 1 Mbps home connection, this still represents ONLY a 1.6 ms savings.

The only case where this would have more than a 10ms savings is on a <200 Kbps link, and such a link is so slow that nobody will care about the savings because everything else is so glacial, and such links are likely to not be querying for AAAA records anyway (the most common case)

Thus I think this proposal is a bad idea:  It adds a substantial amount of complexity for something that can substantially slow things down by removing parallelization, and even when everything works right, is only 1.6ms of savings on a 1 Mbps link (and .16ms savings on a 10 Mbps link).

---

From: Dick Franks <[email-masked]>
Date: Thu, 29 Mar 2012 16:32:35 +0100

On 27 March 2012 12:51, Ray Bellis <[email-masked]> wrote:

> Not at all, per the text the intention of the QTD bit is to distinguish
> between a server which correctly parsed the option, and one that simply
> echoed it.
>

 I neglected to say that separate inbound/outbound option codes would be a
more convincing solution to the echo problem.

--Dick