Why does BIND log messages about disabling EDNS or reducing the advertised packet size?

  • Updated on Oct 30, 2018
  • Published on Feb 5, 2014
  • 2 minute(s) read
  • Suzanne Goldlust
  • Cathy Almond

Question:

What do these messages mean, and is there any problem that might be caused as a result?

success resolving ... (query etc) ... after reducing the advertised EDNS UDP packet size to 512 octets

success resolving ... (another query etc.) ... after disabling EDNS

Answer:

By default, all currently-supported versions of BIND will send queries with EDNS options enabled (and with size 4096 bytes). There are some configuration options that alter this behavior - details can be found in the Administrator Reference Manual. But in particular:

  • edns-udp-size  - sets the default advertised packet size; it is telling remote servers what the maximum packet size is that the server can receive.
  • max-udp-size - sets the maximum packet size that the server will send.
  • server ip_address edns no; - this can be used to disable sending packets with EDNS enabled to a server that you know doesn't support EDNS0. The main reason for doing this is to avoid delays in communicating with the server while named tries first with EDNS before eventually falling back to sending with EDNS disabled. It's also possible to specify a maximum EDNS packet size on a per-server basis.

The messages that are logged are seen when named has retried its communication with a remote server, first with a reduced advertised EDNS packet size, and then with EDNS disabled altogether. If the communication succeeds (that is, named receives a valid response from the remote server), then a message will be logged. If communication fails entirely, then nothing is logged while named retries.

See also What happens when a remote server doesn't understand EDNS0?

The usual reasons for problems communicating using EDNS0 and larger UDP packet sizes are mis-configured or broken firewalls and load balancers.

Is the problem local or remote?
There is a helpful testing tool available (provided by DNS-OARC) that you can use to verify resolver behavior regarding EDNS: https://www.dns-oarc.net/oarc/services/replysizetest/.

If named doesn't get a response from a remote server at first and then goes through its retry logic, there may be some impact on the speed at which clients querying for names in zones served by that server receive their responses. Once the answer record(s) is/are in cache, clients will be answered promptly. The impact will be more significant for popular queries whose answer records have short TTLs, and therefore are frequently needing to be re-fetched from the authoritative servers.

Unless EDNS is used, BIND will not request DNSSEC records (DO set on the query) from an authoritative server, which means that DNSSEC validation may fail.

Intermittent connectivity or responsiveness problems from DNSSEC-signed zones can cause DNSSEC validation failures
BIND will temporarily 'remember' that a server failed to respond with EDNS enabled, so to reduce the impact of the delays caused by retrying with EDNS every time, it will, for a period, only send packets with EDNS disabled. This means that the zones served by that domain may fail DNSSEC validation when that happens. However, for any zone, BIND will try all the servers with EDNS before retrying them without. Administrators of signed zones should (in any event) be ensuring that they have multiple servers with good geographic and network diversity, so that a connectivity problem to one or more servers doesn't impact the DNSSEC-validity of their zone data.