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? ** 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) ** Section 8. For completeness, per “The test below use dig from BIND 9.11.0”, please provide a reference. ** Section 8 dig examples. It would be worth explaining $zone and $server. ** 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/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
