"Benoit Claise" <[email protected]> writes:
> Here is Eric Vyncke's (pretty knowledgeable security expert) OPS DIR
> review (you'll see that it's in line with Terry's DISCUSS point):
> Based on my operational experience, I have seen multiple DNSSEC packets
> dropped by firewalls because they try to use EDNS0 rather than
> fragmenting. Does your I-D also address this issue?
Section 3.1.3 defines a test to determine if EDNS0 is an issue and
whether a resolver can make of it within the network its deployed in.
So, yes, the draft talks about it. I don't believe from the above
comment we're missing anything unless you think I've missed your point.
> I am a little puzzled by the hand waving "we also assume that the path is
> clear of "DNS interfering" crap-ware/middle-boxes, like stupid firewalls,
> proxies, forwarders." (I would avoid the use of "stupid") This
> restriction does not appear as realistic to me in the current
> deployment.
I think this new paragraph should fix these problems (along with the
usage of the words that shouldn't belong in an IETF document).
NOTE: when performing these tests we also assume that the
path is clear of "DNS interfering" middle-boxes, like firewalls,
proxies, forwarders. Presence of such infrastructure can easily
make a recursive resolver appear to be improperly performing. It
is beyond the scope of the document as how to work around such
interference, although the tests defined in this document may
indicate which such misbehaving middle-ware is causing interference.
> In the wave of IPv6 deployment and IPv4 sunset, I would suggest that
> examples (such as in 3.1.1) uses AAAA RR and not A.
I see your point, but at the same time we're not trying to test for
compliance of IPv6, and thus we are using A to avoid any other test
failure that may have been as a result of an IPv6 record being fetched.
Though, I admit, that if I resolver can't handle AAAA records there is
pretty much zero chance it can handle DNSSEC. However, I'd rather tests
be super-narrow in what may break when they issue queries.
> It is a little unclear to me WHEN the host should run those test? At boot
> time? At every network attach? When it resumes operation after a sleep
> period? Or a periodic test (such as hourly) ? This could cause a
> scalability problem in vast WiFi deployment.
How does this paragraph sound to address this:
These tests should be performed when a resolver determines its
network infrastructure has changed. Certainly a resolver should
perform these tests when first starting, but MAY also perform
these tests when they've detected network changes (e.g. address
changes, or network reattachment, etc).
> I am also a little puzzled by another hand waving "The goal of this
> document is to tie the above tests and aggregations to avoidance
> practices; however the document does not specify exactly how to do that."
> and later "Else return an useful error code" which will make
> interoperation (API portability) complex.
I need to speak to the author of that sentence to determine his
attention and will get back to it.
> I hope the above will help to improve a very useful document
Thanks so much for your comments!
--
Wes Hardaker
Parsons
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
