On 17. 08. 22 17:09, Daisuke HIGASHI wrote:
Peter van Dijk <peter.van.d...@powerdns.com <mailto:peter.van.d...@powerdns.com>>:


Thank you for reviewing my implementation.

    Note that the function called "probe_pmtu" does not really probe. At
    best, it finds some data the kernel cached recently. At worst (i.e.
    usually), it tells you the MTU of your local networking interface.


That's correct.


     > - A first response (to requester with small PMTU) can be lost because
     > nobody knows PMTU for destination that a large packet was never sent.
     > It slows down name resolution - Fortunately this is not a big problem
     > because 1) will be recovered by retransmission by the requestor

    (a) why would a requestor retransmit? (b) why would the retransmit help?


1) Responder receives first request and makes response (DF=1) that size is exceeding PMTU and it was not received by requester.
2) Responder should receive ICMP NEEDFRAG and knows PMTU.

And at this step we opened the attack window to ICMP-based fragmentation attacks again.

3) Requester (resolvers) _would_ retransmit same request after timeouts if none of response is received.

Possibly. Or it can retransmit to another address, or possibly routed to another node in anycast cloud. Or via another path. Or just fallback to TCP and don't bother with UDP anymore.

4) Responder composes DNS message fitting in PMTU or TC=1 (if does not fits in).


I admit that my current implementation (responder's behavior which the I-D describes, in my understanding) relies on requester's timeout / retransmission strategy and when PMTU cache information expires same timeout event would occurs again.

This is completely unreliable, I'm afraid.

--
Petr Špaček

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to