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
