ietf
[Top] [All Lists]

Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP

2007-09-27 19:44:10
--On Thursday, 27 September, 2007 18:45 -0700 Paul Hoffman
<paul(_dot_)hoffman(_at_)vpnc(_dot_)org> wrote:

The Security Considerations section for this document is much
too narrow. It ignores one of the main reasons that many
organizations purposely choose to provide recursive lookup to
the public, namely for their own roaming users. Without an
open, known-good nameserver at a fixed address, roaming users
need to trust whatever is given to them by their ISP at the
moment, and it is reasonable for organizations to consider
...

Hi.

I want to express general agreement with Paul's comment, but
also to stress the importance of one of the points he has made...

Even if one ignores attacks of the usual sorts (i.e., bad acts
conducted out of malice or juvenile behavior) the ISP who plays
alternate root, DNS query interception and diversion, and
similar games is too large for comfort and probably growing.
Paul's explanation of this: 

- Some ISPs use DNS servers that purposely do not follow the
same good practices that the organization uses. In particular,
some ISPs have used bogus TLDs and name-lookup services to
generate revenue.

covers most of the problem, but it is perhaps also useful to
point out that some of these ISPs try to block DNS traffic that
is not directed to their preferred servers.  For many users and
enterprises, the warning implicit in not being able to reach
their own servers under those circumstances is an important, and
security-enhancing, source of information.   Of course, some of
those ISPs take the next step and divert all DNS traffic,
regardless of specified destination, to their own servers, but
the fact that simply making recursive nameservers available
doesn't solve it (at least absent well-deployed DNSSEC) doesn't
mean that the often-useful "use your own server" approach is
useless or should be avoided.

  
The Security Considerations section needs to deal with these
issues, even if they do not change the advice given in section
4.

Yeah.

    john



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf