I've read draft-ietf-dnsop-cookies-00.txt and I think it is a good
idea, it would improve seriously the security <icann>and
stability</icann> of the DNS, for a very small cost, so it should be
pursued.
My main concern with the current draft is in section 5.2. I simply do
not understand why the two cases:
* the client sends an OPT RR but no COOKIE option,
* the client sends a malformed COOKIE option,
are treated together. They are completely different, the first case is
the normal behaviour of today's resolvers, the second case is a
programming error (or mangling in transit) and it deserves a FORMERR
(not a REFUSED).
I therefore suggest to rewrite the paragraph starting with "When DNS
Cookies are implemented and enabled" as:
When DNS Cookies are implemented and enabled, there are five
possibilities: (1) there is no OPT RR at all in the request; (2) the
COOKIE OPT option in absent from the request 3) one Client Cookie is
present in the request but does not have a legal length; (4) there is
a valid length cookie option in the request with no Server Cookie or
an incorrect Server Cookie; or (5) there is a cookie option in the
request with a correct Server Cookie. The five possibilities are
discussed in the subsections below.
And then:
5.2.1 [NO CHANGE]
5.2.2 No Cookie option
A request with an OPT RR but no COOKIE OPT option is from a
client that does not implement DNS cookies. A server on which DNS cookies
are enabled has the
following three choices in responding to such a request:
(1) Silently discard the request.
(2) Not process the request other than returning a minimal length
error response. Because of the absence of a
COOKIE OPT option in the request, it cannot be assumed that the
client would understand any new RCODE values. An RCODE of
Refused
is returned and the Error Field of the returned COOKIE OPT option
is set to NOCOOKIE.
(3) Process the request normally and provide a normal response except
that a COOKIE OPT option with a non-zero Error Field is included
as in point 2 above. The RCODE in the DNS Header is zero unless
some non-cookie error occurs in processing the request.
Since all current resolvers are in this case (they do not send
cookies), choosing (1) today is NOT RECOMMENDED. Server policy determines
how often the server selects each of the
above response choices; however, if the request was received over
TCP, the server may wish to take the weak authentication provided by
the use of TCP into account, increasing the probability of choice
3.
For both response choices 2 and 3, the server
should consider setting TC=1 in the response so that future requests
from the client are more likely to be received with the weak
authentication that can be provided by TCP.
5.2.3 Invalid cookie option
A request with an OPT RR and with a COOKIE
that is not a valid length (10 or 18 through 42) means some form of
abuse or a broken client
implementation. A server on which DNS cookies are enabled has the
following three choices in responding to such a request:
(1) Silently discard the request.
(2) Not process the request other than returning a minimal length
error response. Because of the absence of a validly formatted
COOKIE OPT option in the request, it cannot be assumed that the
client would understand any new RCODE values. An RCODE of FormErr
is returned and the Error Field of the returned COOKIE OPT option
is set to MFCOOKIE.
(3) Process the request normally and provide a normal response except
that a COOKIE OPT option with a non-zero Error Field is included
as in point 2 above. The RCODE in the DNS Header is zero unless
some non-cookie error occurs in processing the request.
Server policy determines how often the server selects each of the
above response choices; however, if the request was received over
TCP, the server may wish to take the weak authentication provided by
the use of TCP into account, increasing the probability of choice 3
and decreasing the probability of choice 1 perhaps to the extent of
never choosing 1. For both response choices 2 and 3, the server
should consider setting TC=1 in the response so that future requests
from the client are more likely to be received with the weak
authentication that can be provided by TCP.
5.2.3 Renumbered 5.2.4, otherwise unchanged
5.2.4 Renumbered 5.2.5, otherwise unchanged
Editorial:
* I had trouble understand section 6 so I suggest to add, after "There
is no problem with DNS transactions between clients and servers behind
a NAT box using local IP addresses", the terms ", because the server
uses only, to check the cookie, the source IP address it sees,
whatever the translations that happened before."
* Also in section 6, after "it is RECOMMENDED that the same server
secret be used by each DNS server in a set of anycast servers", I
suggest to specify ", and kept synchronised, by an external mean -
which is off-topic for this document".
Typos:
* In 5.3, RCODE is spelled RCDOE
* In 6, server is spelled sever
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
