[Pdns-users] EDNS support + default buffer size

bert hubert bert.hubert at netherlabs.nl
Thu Mar 18 05:45:23 UTC 2010

On Thu, Mar 18, 2010 at 03:48:48PM +1300, Michael Fincham wrote:
> Looking at the source it seems in 3.2 an option "disable-edns=no" was
> added which turns EDNS support on. A cursory test here shows that adding
> this to the stock config does cause the dns-oarc reply size test to
> report a reply size of 1200 vs 512 when EDNS is off.


Thanks for the thorough investigation of our EDNS support in the source code

EDNS consists of two things: honoring EDNS when answering queries, and using
it for our own queries. Both the PowerDNS Authoritative Server and the
Recursor honor EDNS when answering queries.

After long thought and study, it was decided not to use EDNS on outgoing
queries by default. Other implementations have also come to this conclusion,
since in many cases it can cause duplicate queries to go out.

'disable-edns=no' is in fact not a documented setting, and I am surprised it
even works.  Interesting. This does indeed show that there is a full EDNS
outgoing implementation in PowerDNS.

> What is the status of EDNS support? Is it safe to rely on in production
> environments? What specifically does the "nothing but trouble" comment
> on the changeset refer to?

Yes, things are safe as they are. The only EDNS use case is retrieving >512
byte answers potentially faster than over TCP/IP, or when TCP/IP is not
available. This is exceedingly rare.

The 'nothing but trouble' refers to the surprisingly large number of servers
that when queried with EDNS on, either provide no answer, return a SERVFAIL
or a malformed answer. 

So within PowerDNS there is a whole EDNS 'state keeper', which stores the
level of EDNS support for each IP address, in one of 5 states.

In the end, it turned out that this was all too much work and packet
duplication ('retransmit without EDNS' etc) to save an incidental TCP/IP

> Also, the buffer size of "1200" appears to be hard coded. Is there any
> particular reason for this value? I'm guessing it has to do with
> avoiding fragmentation, but it'd be nice to know for sure.

Indeed, 1200 is a 'known safe value' that supposedly never fragments in a
way with spoofing implications. 

The true optimum for outgoing EDNS use is only to try it after receiving a
TC=1 (truncated) response from a remote.  This allows for least packet
duplication and the least EDNS-level probing.

I hope the above answers your questions.

Kind regards,

Bert Hubert

> Thanks,
> -- 
> -Michael Fincham
> System Administrator, Unleash
> www.unleash.co.nz
> Phone: 0800 750 250
> _______________________________________________
> Pdns-users mailing list
> Pdns-users at mailman.powerdns.com
> http://mailman.powerdns.com/mailman/listinfo/pdns-users

More information about the Pdns-users mailing list