[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-no-response-issue-20: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

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/