Why does BIND log messages about disabling EDNS or reducing the advertised packet size?
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
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.
The usual reasons for problems communicating using EDNS0 and larger UDP packet sizes are mis-configured or broken firewalls and load balancers.
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.