Peter van Dijk <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. 3) Requester (resolvers) _would_ retransmit same request after timeouts if none of response is received. 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. -- Daisuke Higashi
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
