Subject: [dnsext] Feedback on draft-ietf-dnsext-rfc2671bis-edns0

From: Matthew Dempsky <[email-masked]>
Date: Fri, 14 May 2010 17:59:56 -0700

Section 3:
> EDNS support is mandatory in a modern world.

Is this informative or normative text?  Assuming informative, I
suggest rephrasing as something like "Many modern uses of DNS
necessitate support for EDNS."

>                                 In order to support this, DNS
> servers, middleware, and stub resolvers MUST support larger packet
> sizes advertised via EDNS0.

Is this intended to be all DNS servers, middleware, and stub
resolvers, or just EDNS-supporting software?  I suggest explicitly
specifying that "DNS servers, middleware, and stub resolvers implement
EDNS MUST support ...".

It's unclear to me exactly what it means to "support larger packet
sizes advertised by EDNS" means.  Is it okay to just just support
513-byte packets?  If a server wants to send a 2000 byte response, and
the client has advertised the ability to do so, is it a violation of
the draft to send a truncated response?

Also, this seems like an odd place for this requirement text.  Why not
closer to where the packet size advertisement is actually defined?

Section 4.1:
> The DNS Message Header's second full 16-bit word is divided into a
> 4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see ,
> section 4.1.1 [RFC1035]).

Looks like a typo in the citations.  I'm guessing it meant to be
something like "see [RFC1035], section 4.1.1"?

Section 4.3:
>                         Today, many organizations wish to return many
> records in a single reply, and special tricks are needed to make the
> responses fit in this 512-byte limit.

I don't think it's so much that organizations want to return many
records per se, but more generally that a number of DNS use cases are
burdened by the 512-byte limit.  I think rewording it as such would be
appropriate; e.g., "Today, many DNS uses cases could benefit from
using more or larger resource records, but are unduly burdened by this
512-byte limit."

Section 6.1:
> An OPT record does not carry any DNS data.  It is used only to
> contain control information pertaining to the question and answer
> sequence of a specific transaction.  OPT RRs MUST NOT be cached,
> forwarded, or stored in or loaded from master files.

Strictly speaking, this wording seems to rule out the possibility of
EDNS options that might want to carry DNS records for some reason.  As
I can imagine worthwhile uses for that, I'd suggest rewording this to
something like:

    As OPT records are not actual DNS records, in most cases they
    SHOULD NOT treated as such by DNS software.  In particular, DNS
    software MUST ensure that OPT records are not cached, forwarded,
    or stored in or loaded from master zone files as though they were
    generic DNS records.

However, the requirement that DNS software cannot forward OPT records
stands in contrast with section 6.8 which requires that they forward
it.

Section 6.2:
> The order of appearance of option tuples is not guaranteed.  If one
> option modifies the behavior of another or multiple options are
> related to one another in some way, they have the same effect
> regardless of ordering in the RDATA wire encoding.

This disclaimer was not in RFC 2671.  Is there a reason to add it
rather than allow EDNS options to define the significance (if any) of
their relative ordering?  If not, I suggest removing this paragraph.

Section 6.3:
> The OPT record must not be cached.

This section seems redundant with section 6.1, so I suggest removing
it.

Section 6.5:
> Choosing a very large value will guarantee fragmentation at the IP
> layer, and may prevent answers from being received due to a single
> fragment loss or misconfigured firewalls.

I think "guarantee" is the wrong word here, and "very large" is
misleading: in the range of possible values for the payload size
advertisement, most values could result in fragmentation.  I suggest
rewording as:

    Choosing a larger value risks fragmentation, which may prevent
    answers from being received due to a single fragment loss or
    misconfigured firewalls.

> The requestor's maximum payload size can change over time.  It MUST
> not be cached for use beyond the transaction in which it is
> advertised.

I don't generally think of holding onto data still necessary to
complete a transaction as "caching" it, so reading "X MUST NOT be
cached for Y" makes me inherently think there might be cases other
than Y where it's acceptable to cache X.  However, I think the intent
is that the maximum payload size value should never be used outside of
the actual transaction it was part of.

Also, it's worth pointing out that there might be multiple DNS clients
running on the same host (or behind the same NAT), so it would
additionally be incorrect to assume capabilities of one client apply
to other clients on the same host.

Section 6.8:
> Middleware boxes MUST NOT limit DNS messages over UDP to 512 bytes.

What should they do instead?  Is it acceptable to limit to 513?
Should they support any arbitrary sized UDP packet?  (This seems
outside of the scope of RFC2671bis though.)

> Middleware boxes which simply forward requests to a recursive
> resolver MUST NOT modify the OPT record contents in either direction.

I think it's acceptable for middleware boxes to modify OPT records
(e.g., adding or removing options, clamping payload size), but then
perhaps tautologically that does not qualify as "simply forward[ing]
requests" (i.e., the "intelligent forwarder" from the next section)?

> Middleware boxes which have additional functionality, such as
> answering certain queries or acting like an intelligent forwarder,
> MUST understand the OPT record.  These boxes MUST consider the
> incoming request and any outgoing requests as separate transactions
> if the characteristics of the messages are different.

One thing that I think is worth defining is how a box can tell whether
or not it's safe to forward an unknown option field.  E.g., extensions
like edns-ping and edns-client-ip are safe to forward.  Are future
extensions required to be similarly safe to blindly copy, or can some
extensions alter the transaction structure or message format?

Section 7:
> Responders who do not implement these protocol extensions MUST
> respond with FORMERR messages without any OPT record.

This seems to stand in contrast against existing practice.  Many DNS
servers that don't support EDNS will just ignore the OPT record and
respond as normal.  (Heck, I understood this was the driving
motivation for adding EDNS features in such an awkward fashion.)

Finally, for Section 9, I'm still in support of having a range of
option codes reserved for private use.  I'd suggest adding text
requesting IANA to reserve 65280--65534 for private use.