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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 07 Apr 2020 18:25:28 -0700

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/

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Apr 2020 10:23:04 +1000

> On 8 Apr 2020, at 11:25, Roman Danyliw via Datatracker <[email-masked]> wrote:
> 

20 years of experience writing recursive servers.  We have given up trying to
work around so misbehaviour and just let the resolution fail.

> a new software load whose features were not understood, or a configuration

And if you have such scenarios you are not looking at Internet facing servers.

> please provide a reference.

Added.

> ** Section 8 dig examples.  It would be worth explaining $zone and $server.

added.

> -- Section 8. s/is know/is known/

done.

> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]