I'd like to direct a question to the chairs - would you summarize the
open IESG discuss issues with the current document? In this mail
I'll allude to some of what I guess are the open discuss items.
Looking at the tracker there are discusses against -04 and a note
that a new version is needed. We have a -05 now, I suppose that
qualifies as the new version.
Even though I am not an enthusiast of the notion that the attacks
reported in spring 2006 incriminate open recursive resolvers, I think
the draft should be published as it is and that we free this mailing
list of any more arguments on the topic.
The document only recommends that name server code should be shipped
with the open recursive configuration in the "off" position. It does
not say that operating an open recursive resolver is evil, despite
the the file name.
Recommending that an operator attempt to scope the source of requests
is harmless to those that want a wide open scope. A recommendation
of a scooping based on source IP address is not a client
authentication vulnerability (as in it is trivial to spoof the source
field of UDP) but is a reflection or a widely followed practice in
operations. Regardless of the IETF's notion of security, operators
have their own rules of thumb and source IP address ACLs are part of
that.
I can live with the details of the attacks, perhaps some find the
prose confusing and I am sympathetic to calls to shore it up. But I
think that it really isn't crucial as the recommendations section is
quite distinct from it.
There is one line in the -05 which I find to be the "meat."
"By default, nameservers SHOULD NOT offer recursive service to
external networks."
Note the "by default." If that were not present, I would object to
the document. To me, the statement is safe because there is no
penalty to operating in any manner that is not the "default" way. No
justification is needed to diverge from "default." So saying that
the default is to not be an open recursive server is acceptable to me.
PS - The other comment in the discuss items - removing the
possibility of amplification. That can be done, but the cure is
worse than the disease. We can expand all queries to be the maximum
acceptable response size (512 or to the size indicated via EDNS0)
with padding of the queries. That removes the incentive to use the
recursive server as a reflector because you can then just have the
botnet directly target the victim, probably with more aggregate
bandwidth. (Botnets could do that now, hit a victim with overstuffed
DNS queries or falsified answers for that matter, thanks to UDP's
fire and forget paradigm.) For legitimate DNS, it would be a
bandwidth waste.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Think glocally. Act confused.
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
