Thanks for an easy-to-read and useful document.  I have just a few minor issues to raise here:

— Section 1 —

   TCP avoids fragmentation using its Maximum Segment Size (MSS)
   parameter, but each transmitted segment is header-size aware such
   that the size of the IP and TCP headers is known, as well as the far
   end's MSS parameter and the interface or path MTU, so that the
   segment size can be chosen so as to keep the each IP datagram below a
   target size.

This sentence seems too long and somewhat convoluted.  Perhaps split it into two sentences to make it easier on the reader?

— Section 3.1 —

   R2.  UDP responders MAY set IP "Don't Fragment flag (DF) bit"
   [RFC0791] on IPv4.

But Section 1 says, “This document proposes that implementations set the ‘Don't Fragment (DF) bit’ on IPv4 and not use the ‘Fragment header’ on IPv6….”  That (“proposes”) seems like it should be stronger than “MAY”, no?

Section 7.1 touches on this, but maybe either R2 or Section 7.1 should explain why it’s “MAY” (which arguably is saying nothing at all, because,well, of course they may), and what needs to happen before it becomes SHOULD.

— Section 4 —

   Large DNS responses are the result of zone configuration.

I understand what you’re saying here (you’re referring to retrieving A/AAAA records), but in many cases large responses come from retrieving TXT records, and this sort of thing could get worse as key lengths, signatures, and the like get larger (you hint at this last bit in R12).  Maybe “Large DNS responses are often the result…,” or otherwise clarify that you’re talking about queries for IP addresses in particular.

— Section 7.2 —

   If a UDP response packet is dropped (for any reason), it increases
   the attack window for poisoning the requestor's cache.

But Section 3.2 says this:

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

…which seems to be contradictory.  Can you clarify this apparent contradiction in one place or both?