[DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-avoid-fragmentation-16: (with COMMENT)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-avoid-fragmentation-16: Yes

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


        At the time of writing, most DNS server software did not set
        the DF bit for IPv4, and many OS kernel constraints make it
        difficult to set the DF bit in all cases. Best Current Practice
        documents should not specify what is currently impossible, so R2,
        which is setting the DF bit, is "MAY" rather than "SHOULD".

If what you want is "we really really want this but it cannot be done on every OS",
then I think SHOULD instead of MUST is fine, but MAY seems too weak.

        R7. UDP requestors MAY drop fragmented DNS/UDP responses without
        IP reassembly to avoid cache poisoning attacks.

        R8. DNS responses may be dropped by IP fragmentation. Upon a
        timeout, to avoid resolution failures, UDP requestors MAY retry
        using TCP or UDP with a smaller EDNS requestor's maximum UDP
        payload size per local policy.

Same here. R7 and R8 are "recommendations" so I feel the MAY's should be SHOULDs.
Otherwise the recommendation becomes "do whatever you MAY please", in which case
why are these in the document?


        R9. Use a smaller number of name servers (13 may be too large)

I would say "name server names" instead of "name servers", to avoid any ambiguity
of anycast name servers operating under the same name. Eg the document is not
saying "use less than 13 name servers", but it is saying "use less than 13 name
server names"


        smaller than those usually used for RSA.

smaller than those of equivalent cryptographic strength using RSA