On Oct 1, 2007, at 1:52 AM, Stephane Bortzmeyer wrote:
On Sun, Sep 30, 2007 at 10:32:39PM -0600,
Danny McPherson <danny@xxxxxxx> wrote
a message of 51 lines which said:
Section 4's reference to BCP 84, in part, creates a false sense of
useful action on part of the operator,
This could be said of all the parts of the I-D which mentions non-DNS
issues such as BCP 38. In that respect, I full agree with Stephen
Hanna's review
(http://www1.ietf.org/mail-archive/web/ietf/current/msg48117.html).
I read Stephen's comments before posting, and I agree
as well.
However, the BCP 84 bit is slightly different because it's
only useful for mitigating reflective attacks IF it's employed
in a particular way. If this document is going to reference it
then it should make a distinction here.
Any idea? The current draft mentions "Incoming Interface based
selection" and I do not see what to add?
Perhaps expanding in the "Problem Description" section
would be beneficial. Something mentioning that Many
SOHO and broadband access devices provide some flavor
of name resolution services (e.g., there are 4 flavors
outlined by JKT and others; Recursive, Forwarder, Caching-
only and Restricted).
Some other empirical bits might be useful as well, though
and although I'm not sure they need to be in the I-D, they
would be useful:
E.g., 16M recursive "type" servers, , with 800k or so being
the larger problem. Also, some references that provide usual
information on actual numbers, such as John's work here:
http://condor.depaul.edu/~jkristof/orns/
http://maps.measurement-factory.com/gallery/Openresolvers/
And this is particularly illustrative:
http://maps.measurement-factory.com/gallery/Openresolvers/20070429.png
As for the current text, you don't provide much in the way
of explaining that queries should probably not be accepted
from the Internet/untrusted interfaces, you just essentially
state that interface-based discrimination might be employed.
That was my initial concern. If your attempt is to progress as
BCP, then some actual specific guidelines on this front
for implementers and administrators alike might provide more
actionable information.
Sorry, but their messages are quite off the track. The problem is not
wether there is an use case for using a resolver different from the
one provided by the current access point. There are, indeed, many
reasons for *not* using the default resolver (ISP which violates RFC
4925, section 2.5.2 are a very good example). But ORNS are *not* the
proper solution for that use case. TSIG signatures, VPNs, local
caching resolvers are the good solutions.
I think you made my point. Where is this currently explained in the
document as such? Acknowledging existence and practical realities
is important, methinks.
-danny
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
