Re: [DNSOP] Benoit Claise's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

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" <[e-mail]> wrote:

>"Benoit Claise" <[e-mail]> 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