I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. Document editors and WG chairs should treat these comments just
like any other last call comments.
The summary of the review is Ready with Issues.
I debated with myself as to whether the things that were bothering me
about this draft were small issues or big nits. I ended up deciding
that they were issues, although it might just be me.
The goal of this Best Current Practice draft is to, as the title says,
avoid fragmentation. This is for better security over UDP and better
efficiency over TCP for DNS.
Security
--------
I don't understand why R2 is not a SHOULD now.
Please consider moving Appendix A into the Security Considerations
Section. I think Appendix A is almost all Security Considerations.
Other Issues
------------
My first problem is with the first sentence in the abstract. The mere
existence of EDNS0 doesn't "enable" large responses. There seems to be
a lot missing in this sentence. I suggest something like "The widely
deployed EDNS0 feature in the DNS enables a DNS receiver to indicate
its received UDP message size capacity which supports the sending of
large UDP responses by a DNS server." Similar problem in the first
paragraph of the Introduction although split over multiple sentences.
A Best Current Practice document should specify things, not propose
them. The first two occurrences of "propose" in this document should
be changed to "specify" and the Section 3 title should be changed to
"How to avoid IP fragmentation in DNS". Other occurrences of
"propose", which are all in Appendices, are OK.
In Section 3, why are R2 and R4 only "MAY"? What not "SHOULD"?
In Section 3, R3, for clarity, suggest inserting "minimum of" so it
would start with "UDP responders SHOULD compose response packets that
fit in the minimum of the ..."
Section 4: Not all large responses are the result of zone
configuration. For example, queries may use the TYPE * (ALL).
Wording should be something like "Large DNS responses are typically
the result of zone configuration."
Appendix D: It is unusual to have lots of details of particular
implementations in a BCP. This information will become out of
date. Should there be an RFC Editor comment to remove this appendix
before publication?
Nits
----
According to the nits checker:
the RFC 2119 boilerplate has an error, and
draft-ietf-dnsop-glue-is-not-optional has been published as RFC
9471 so the reference should be updated.
Suggest eliminating the Section 5.1 header and changing the Section
5. title to "Protocol compliance considerations".
Suggest changing Section 6 to be "This document requests no IANA
actions."
Thanks,
Donald
===============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e3e3@xxxxxxxxx
ongoing effort to review all IETF documents being processed by the
IESG. Document editors and WG chairs should treat these comments just
like any other last call comments.
The summary of the review is Ready with Issues.
I debated with myself as to whether the things that were bothering me
about this draft were small issues or big nits. I ended up deciding
that they were issues, although it might just be me.
The goal of this Best Current Practice draft is to, as the title says,
avoid fragmentation. This is for better security over UDP and better
efficiency over TCP for DNS.
Security
--------
I don't understand why R2 is not a SHOULD now.
Please consider moving Appendix A into the Security Considerations
Section. I think Appendix A is almost all Security Considerations.
Other Issues
------------
My first problem is with the first sentence in the abstract. The mere
existence of EDNS0 doesn't "enable" large responses. There seems to be
a lot missing in this sentence. I suggest something like "The widely
deployed EDNS0 feature in the DNS enables a DNS receiver to indicate
its received UDP message size capacity which supports the sending of
large UDP responses by a DNS server." Similar problem in the first
paragraph of the Introduction although split over multiple sentences.
A Best Current Practice document should specify things, not propose
them. The first two occurrences of "propose" in this document should
be changed to "specify" and the Section 3 title should be changed to
"How to avoid IP fragmentation in DNS". Other occurrences of
"propose", which are all in Appendices, are OK.
In Section 3, why are R2 and R4 only "MAY"? What not "SHOULD"?
In Section 3, R3, for clarity, suggest inserting "minimum of" so it
would start with "UDP responders SHOULD compose response packets that
fit in the minimum of the ..."
Section 4: Not all large responses are the result of zone
configuration. For example, queries may use the TYPE * (ALL).
Wording should be something like "Large DNS responses are typically
the result of zone configuration."
Appendix D: It is unusual to have lots of details of particular
implementations in a BCP. This information will become out of
date. Should there be an RFC Editor comment to remove this appendix
before publication?
Nits
----
According to the nits checker:
the RFC 2119 boilerplate has an error, and
draft-ietf-dnsop-glue-is-not-optional has been published as RFC
9471 so the reference should be updated.
Suggest eliminating the Section 5.1 header and changing the Section
5. title to "Protocol compliance considerations".
Suggest changing Section 6 to be "This document requests no IANA
actions."
Thanks,
Donald
===============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e3e3@xxxxxxxxx
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
