<div dir="ltr">On Thu, Aug 28, 2014 at 6:09 AM, Iñigo Ortiz de Urbina Cazenave <span dir="ltr"><<a href="mailto:iortiz@ripe.net" target="_blank">iortiz@ripe.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 27/08/14 18:48, Wessels, Duane wrote:<br>
> Hello All,<br>
><br>
> The getdns API description says:<br>
><br>
>> getdns_return_t getdns_context_set_edns_maximum_udp_payload_size(<br>
>>     getdns_context *context,<br>
>>     uint16_t value<br>
>> );<br>
>><br>
>> The value is between 512 and 65535; the default is 512.<br>
><br>
> Can someone explain why 512 should be the default value?  It seems odd<br>
> that if the library is going to add an EDNS0 OPT record, that it should<br>
> use the smallest possible value for the buffer size.  Software with long<br>
> deployment history uses large values, such as 4096 and measurements from<br>
> root/TLD name servers also indicates that 4096 is a very common value.<br>
><br>
> It should at least be safe to have a default value close to ethernet MTU<br>
> sizes minus some for safety (1400-ish).<br>
<br>
</span>+1 to this pragmatic approach.<br>
<br>
An alternative, working default could also be around the magic number 1280.<br></blockquote><div><br></div><div>I strongly support this also. And we'd like to change the default in the NLNetLabs/Verisign implementation ( <a href="http://getdnsapi.net">http://getdnsapi.net</a> ), so if anyone has any strong objections, please voice them. Clearly, the API supports the ability to configure a specific value for the UDP payload, but we'd like to see a more reasonable default.<br><br></div><div>The 1280 magic number comes from the IPv6 minimum MTU. To avoid IPv6 fragmentation, we'd need to specify a number somewhat below 1280 to account for UDP header (8 bytes) and any likely encapsulation/extension headers. BIND appears to use a value of 1232 for this purpose. But I'm okay with starting at 4096 as long as implementations also do downward probing on failure. Note that the current <a href="http://getdnsapi.net">getdnsapi.net</a> implementation is actually using a value of 4096 (with downward probing) due to a bug that didn't match the spec. But we'd like to get the spec updated.<br><br></div><div>--Shumon. <br><br></div></div></div></div>