Hi,







 





I have reviewed draft-ietf-dnsop-dnssec-roadblock-avoidance-04 as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects
 of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.







 




From the abstract: 

This document describes problems
 that a DNSSEC aware resolver/

application might run into within a non-compliant infrastructure.  It

 outline
 (SIC) potential detection and mitigation techniques. It provides a way for DNSSEC validator to check whether DNSSEC is not blocked on the path.










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?










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.










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.










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.










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.










With a little improvement for some unclear (to me) text, this document could be useful. Especially if either the mitigation part is improved or removed completely.










I hope the above will help to improve a very useful document
















-éric