Wes, Sorry for late reply, I was part-time on vacations and part-time too busy.
Regarding the EDNS0, it was more related to flow of the I-D where EDNS0 is introduced rather late in the document. But, I am fine with leaving the document as it is. Thanks for the modified pieces of text: they are good for me -éric On 08/07/16 16:21, "Wes Hardaker" <[email protected]> wrote: >"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
