Subject: [dnsext] draft-barwood-dnsext-dns-transport-04 technical comments

From: Alfred Hönes <[email-masked]>
Date: Thu, 17 Sep 2009 16:55:02 +0200 (MESZ)

George,
I took the time to take a closer look at your DNS transport proposal in
        draft-barwood-dnsext-dns-transport-04 .

Here are a few technical and procedural considerations,
whereby I'd like to help make the proposal more technically
sound, independent of its potential political acceptability.

(1)  Sections 3.2 & 3.3

With respect to RFCs 5507 and 5395, I regard this as an abuse
of the TXT record.
I suggest that a new RR type should be allocated for this purpose
from the 128-255 range (cf. RFC 5395, bottom of page 7)

This would also ensure that existing debugging tools (hopefully
based on RFC 3597) are able to display the RRDATA in a readable
format, and not cause trouble due to binary content of a TXT RR.

(2)  Section 3.3

The SERVERTOKEN needs more discussion to make sure that Anycast
DNS servers operate consistently and can take over a dialogue
per  request - response(s)  transaction.

(3)  Section 3.5, 1st paragraph

   The server checks SERVERTOKEN, and divides the DNS payload into equal
   size pages, so that the size of each IP packet is not greater than
|  MTU.  Servers should use a smaller MTU if the path MTU is less than
   the MTU supplied by the client.
                                                          ^^

How does a particular DNS server know what the MTU *is* on the
path to an arbitrary client ?
In general, it doesnt; it only has local knowledge (interface MTU).
Thus, the server in general does not know the PMTU, but only an
upper limit to it.

So perhaps it would be better to state:

   The server checks SERVERTOKEN, and divides the DNS payload into equal
   size pages, so that the size of each IP packet is not greater than
|  MTU.  Servers should use a smaller MTU if the path MTU known to be
   less than the MTU supplied by the client.
                                                          ^^^^^^^^^^^

(4)  Section 3.6

With respect to Section 3.7, PAGE should be specified more precisely
as "the 0-based number of this page".  This is assumed below.

The proposed packet layout is unnecessarily wasteful:

We have     0 <= PAGE < COUNT,
COUNT is 8 bits (and might reasonably be restricted even more),
so 8 bits should suffice for PAGE as well, and

Since
        TOTAL <= COUNT * PAGESIZE ,

COUNT is 8-bit and PAGESIZE is 16-bit (unsigned? -- please
add precision!), 24 bits are sufficient for TOTAL.

Thus, the DNS Transport packet header can be shortened by 4 octets,
reducing MTU consumption:

Draft:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       3       |    COUNT      |           PAGESIZE            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             PAGE                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             TOTAL                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            COOKIE                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            QUERYID                            |
    ...

more compact:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       3       |     COUNT     |           PAGESIZE            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     PAGE      |                     TOTAL                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            COOKIE                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            QUERYID                            |
    ...

If you dislike 24-bit numbers, you can even quench out 8 reserved
bits for future expandability or flags, since the specification
requires all non-last 'pages' to be of equal size, a 16-bit
LASTPAGESIZE would, together with COUNT and PAGESIZE, carry
the same information as TOTAL:
   TOTAL = (COUNT - 1) * PAGESIZE + LASTPAGESIZE

This way, it would be possible to arrive at:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       3       |     COUNT     |           PAGESIZE            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     PAGE      |   RESERVED    |         LASTPAGESIZE          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            COOKIE                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            QUERYID                            |
    ...

NOTE: The encoding in Section 3.5 might be disliked due to the
non-alignment to 16-bit boundaries.  If the latter proposal for
multi-page responses is adopted with a specific future use of
the RESERVED field (as FLAGS ?) in mind, a similar octet might
be inserted in the single-page response breakdown after the
leading typecode (2) octet, restoring 16-bit alignment.

Additionally, in 3.6 DATA might better (and more precisely)
be specified as:

    "is the <PAGE>th part (fragment) of the DNS payload"

(5)  Section 3.7

Based on the elaborations in Section 3.9, it seems reasonable
to make more efficient use of the MTU by again containing the
PAGE field to 8 bits.  Packet loss tends to happen randomly,
and not in contiguous blocks.
Inspired by the TCP SACK option, I therefore propose another
encoding for the follow-up request.

Draft:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       4       |    COUNT      |           PAGESIZE            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             PAGE                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            COOKIE                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ...

Alternative:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       4       |     COUNT     |           PAGESIZE            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    PAGE_1     |    PAGE_2     |    PAGE_3     |    PAGE_4     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            COOKIE                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ...

where:
COUNT only has 4 valid values: 1..4, specifying the number of
PAGE_n fields containing valid page numbers requested;
PAGE_i is RESERVED for i > COUNT (i=2,3,4).

If the original semantics are deemed indispensable, this can optionally
be overlayed by using negative values for COUNT (i.e. COUNT=-{number of
contiguous pages requested}), using PAGE_1 as the starting page number;
PAGE_2, ..., PAGE_4 are RESERVED fields if COUNT<0.

Unless the latter option is adopted, the elaborations in Section 3.9
can be simplified under theis alternative.

If the number of pages per response is limited to 128, the protocol
and implementations could be simplified even more by also using
this packet format for the initial request, because -- if the eventual
necessity of follow-up requests is assumed, the DNS request and hence
the DATA need be restricted in size to what would be possible in the
latter case anyway, a slight reduction by 4 octets not being a real
restiction in practical use.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+