Ok so it sounds like this is intentional.
Can you please make it possible for the admin to set the expiry for when EDNS size data expires, as I consider the situation that once a server is determined to be compatible, it’s very likely to stay compatible which means I would want to set a expiry really high such as a week, as it makes little sense in reverting back to 512 byte packets quite quickly, I dont know what the hardcoded expiry is but it seems to be under an hour which I consider very short.
Unbound has a tunable value for this, I think they call it infra-ttl or something.
On the existing system if I am making one lookup an hour to a EDNS server (dnssec so large data), then it would never use full sized packets as the single lookup will always be a compatibility lookup.
Thanks
Chris
From: Mark Andrews via RT [mailto:bind9-confidential@isc.org]
Sent: 20 August 2017 01:20
To: chrysalis@chrysalisnet.org
Subject: Re: [ISC-Bugs #45814] possible EDNS bug
Named starts out with EDNS queries with a UDP buffer size of 512
because that allows named to determine if the remote server supports
EDNS without also having to determine if the path supports larger
responses. There are still servers that do not respond to EDNS
queries. There are still firewalls that think DNS over UDP is
limited to 512 bytes. There are still firewalls that think dropping
fragments is a good thing.
If you start talking to a new nameserver with EDNS using a buffer
size of 4096 named cannot determine which of the above or packet
loss is causing lack of answers. By advertising a 512 byte buffer
you eliminate two sources of error and increase the probability
that you can accurately determine if a server supports EDNS or not.
If you start with 4096 byte packets you and the server gets no
response you have to try multiple recovery strategies simultaneously.
Unfortunately you can't just treat non response as packet loss.
Mark
In message <rt-4.4.1-370-1503183919-1928.45814-3-0@isc.org>, "Chris via RT" wri
tes:
> I dont know if this is intentional or a bug, but to me seems buggy behaviour.
>
> I am diagnosing EDNS by using the following command. Which makes a test
> server send responses to show the EDNS size used.
>
> ‘dig +short rs.dns-oarc.net txt’
>
> on unbound and bind 9.9 This will result in large packets of over 4000 bytes.
> It also reports a EDNS buffer size of 4096.
>
> On bind 9.10 the first request has packets below 512 bytes and reports and
> EDNS buffer size of 512. However if U run another query shortly after it
> then reports larger sizes of over 4000 bytes. So it seems it needs multiple
> requests to use large EDNS packets. I have confirmed this behaviour on 3
> different servers all of which run FreeBSD. The EDNS size seems to be
> stored in some kind of cache that expires because eventually a request
> will then drop back t o a 512 byte limit again.
>
> Result of first query using bind 9.10
>
> rst.x487.rs.dns-oarc.net.
> rst.x499.x487.rs.dns-oarc.net.
> rst.x457.x499.x487.rs.dns-oarc.net.
> "2001:41d0:1:a16c::10:1 DNS reply size limit is at least 499"
> "2001:41d0:1:a16c::10:1 sent EDNS buffer size 512"
>
> Result of second query using bind 9.10
>
> rst.x4090.rs.dns-oarc.net.
> rst.x4060.x4090.rs.dns-oarc.net.
> rst.x4066.x4060.x4090.rs.dns-oarc.net.
> "2001:41d0:1:a16c::10:1 sent EDNS buffer size 4096"
> "Tested at 2017-08-19 22:56:40 UTC"
> "2001:41d0:1:a16c::10:1 DNS reply size limit is at least 4090"
>
> Result of any query made on unbound or bind 9.9
>
> rst.x4090.rs.dns-oarc.net.
> rst.x4060.x4090.rs.dns-oarc.net.
> rst.x4066.x4060.x4090.rs.dns-oarc.net.
> "2a01:4f8:201:5465::2 DNS reply size limit is at least 4090"
> "2a01:4f8:201:5465::2 sent EDNS buffer size 4096"
> "Tested at 2017-08-19 23:03:20 UTC"
>
> Please let me know if you need more information.
>
> regards
>
> Chris
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
__________ Information from ESET NOD32 Antivirus, version of detection engine 15943P (20170819) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com