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.
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.
If named doesn't get a response from a remote server at first and then goes through its retry logic, then 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) are in cache, then 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.
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 (anyway) 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.
© 2001-2017 Internet Systems ConsortiumFor assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.