Hello dnsop,
Warren asked implementers to provide feedback on the current text, so
I'm doing just that.
I'm not an apt copywriter but hopefully following notes will provide
material for other people to formulate commentary to supplement the
recommendations.
On 01. 03. 24 3:54, internet-dra...@ietf.org wrote:
Internet-Draft draft-ietf-dnsop-avoid-fragmentation-17.txt is now available.
It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF.
Title: IP Fragmentation Avoidance in DNS over UDP
Authors: Kazunori Fujiwara
Paul Vixie
Name: draft-ietf-dnsop-avoid-fragmentation-17.txt
Pages: 14
Dates: 2024-02-29
3.1. Recommendations for UDP responders
R1. UDP responders SHOULD NOT use IPv6 fragmentation [RFC8200].
Operational impact of this recommendation is unclear.
Why? Because clients belong to several sets:
- One set clients cannot receive fragmented answers,
- another set of clients cannot use TCP to overcome unfragmented UDP
size limitations,
- yet another set of clients actually depend on large answers to
function (say because they DNSSEC validate, or need to follow huge NS
sets geneated by MS AD, or they need large RRs to deliver e-mail, or ...).
It's unclear what proportion of clients belong to intersection of these
three sets. Banning fragmentation on the **outgoing** side might break
these clients, and it's extremely hard to measure and debug from the
server side.
R2. Where supported, UDP responders SHOULD set IP "Don't Fragment flag (DF)
bit" [RFC0791] on IPv4. At the time of writing, most DNS server software did not set
the DF bit for IPv4, and many operating systems' kernels constraint make it difficult to
set the DF bit in all cases.
E.g. on Linux socket API does not expose DF bit directly. Application
can request DF bit to be turned on in outgoing packets but at the same
time this implicitly enables receipt and processing of unauthenticated
ICMP messages. These messages can be used to manipulate Path MTU records
in the kernel and mount attacks misusing this technique.
R3. UDP responders SHOULD compose response packets that fit in the minimum of
the offered requestor's maximum UDP payload size [RFC6891], the interface MTU,
the network MTU value configured by the knowledge of the network operators, and
the RECOMMENDED maximum DNS/UDP payload size 1400. (See Appendix A for more
information.)
In practice doing syscall to determine MTU _estimate_ for every single
peer address is impractical, and in most cases the value exposed by
kernel is just a garbage anyway. It's more practical to assume that
outgoing EDNS buffer size is configured to a reasonable lower bound by
system admin.
R4. If the UDP responder detects an immediate error indicating that the UDP
packet cannot be sent beyond the path MTU size, the UDP responder MAY recreate
response packets fit in the path MTU size, or with the TC bit set.
Same note about MTU determination applies here. TC=1 sounds reasonable
and does not require more guesswork or reconstructing and recompressing
the answer packet.
R5. UDP requestors SHOULD limit the requestor's maximum UDP payload size. It
SHOULD use a limit of 1400 bytes, but a smaller limit MAY be used. (See
Appendix A for more information.)
Some operators have better experience with 1400, others with other
values. We at ISC go with lower value of 1232 because it's easier to
have conservative value which is more likely to work. Debugging this in
production is total pain, and using a bit smaller value is in our
limited experience not causing new issues. That's why we went with lower
values.
R6. UDP requestors SHOULD drop fragmented DNS/UDP responses without IP
reassembly to avoid cache poisoning attacks.
AFAIK this is impossible to do using normal socket API. The application
has no access to information about UDP reassembly.
Having said that, even if it was implementable it's IMHO not the best
advice for requestor.
IF the requestor is able to detect that a fragment was received then it
would be MUCH better to trigger retry using different protocol right
away. Just dropping the packet:
a] causes timeouts
b] leaves a time window open for another attack attempt
R7. DNS responses may be dropped by IP fragmentation. Upon a timeout, to avoid
resolution failures, UDP requestors SHOULD retry using TCP or UDP with a
smaller EDNS requestor's maximum UDP payload size per local policy. UDP
requestors SHOULD observe [RFC8961] in setting their timeout.
Problem:
There is no indication if timeout was caused by fragmentation - it might
have been caused by other factors. The server might be simply dead.
Server selection algorithm in DNS is currently undefined and each
implementation has it's own retry strategy. TCP might or might not be
first choice. I don't see compelling reason why this should be prescribed.
Proposed change - replace current text with:
DNS responses may be dropped by IP fragmentation. Requestors are
RECOMMENDED to try alternative transport protocols eventually.
(Heh, and now someone need to rewrite this into a proper English.)
Hope it helps.
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
