> On 8 Apr 2020, at 11:25, Roman Danyliw via Datatracker <nore...@ietf.org> > wrote: > > Roman Danyliw has entered the following ballot position for > draft-ietf-dnsop-no-response-issue-20: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this document – it is allows for a very approachable way to verify > conformance. > > ** Section 2. Per “Working around issues due to non-compliance with RFCs is > not > sustainable”, this seems like a bold statement. What is the basis for it?
20 years of experience writing recursive servers. We have given up trying to work around so misbehaviour and just let the resolution fail. > ** Section 4. This section repeats several times that firewall should not > drop > DNS traffic with unknown parameters and such traffic should not be construed > as > an attack. In the general case with “normal clients”, this is good advice. > However, for certain highly controlled enclaves where a white-list-style > approach to traffic is taken, this is not realistic. The presence of > unexpected classes of new DNS traffic would be a bad sign (e.g., of > compromise, > a new software load whose features were not understood, or a configuration > which was not validated) And if you have such scenarios you are not looking at Internet facing servers. > ** Section 8. For completeness, per “The test below use dig from BIND > 9.11.0”, > please provide a reference. Added. > ** Section 8 dig examples. It would be worth explaining $zone and $server. added. > ** Section 10. Per “Testing protocol compliance can potentially result in > false reports of attempts to break services from Intrusion Detection Services > and firewalls.”, thanks for calling this out. I would recommend tuning this > language: > > -- s/break services/attack services/ > > -- to acknowledge that uncommon DNS protocol fields or traffic (from this test > regime) might trigger anomaly-detection/profile-based IDS alerts too > > ** Editorial Nits: > > -- Section 8. s/is know/is known/ done. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
