DNS/1/EDNS/BINDについて、ここに記述してください。

Refinements to EDNS fallback behavior can cause different outcomes in Recursive Servers Updated on 04 Oct 2018

• https://www.isc.org/blogs/refinements-to-edns-fallback-behavior-can-cause-different-outcomes-in-recursive-servers/

For currently (and recently) supported versions of BIND up to and including BIND 9.9, the fallback algorithm for a ‘new’ authoritative server operates as follows:

    Query with EDNS, advertising size 4096, DO (DNSSEC OK) bit set
    If no response, retry with EDNS, size 512, DO bit set
    If no response, retry without EDNS (no DNSSEC, and buffer size maximum 512)
    If no response, retry the query over TCP

DNS/EDNS/DNS-flag-day

TCP may be used earlier, not just as the final attempt

BIND will resend a query over TCP immediately if it receives a response to that same query sent over UDP that has the TC (Truncated) bit set in the DNS response header.
This mechanism is designed so that a server can flag to a client that it was unable to fit all of the necessary records into the maximum packet size that it was able to use for that response, therefore the client is receiving an incomplete answer. 
Although this is optional (per DNS standards), most clients receiving a response that is flagged as truncated will re-send the query using TCP in order to obtain the full response.

A future change to BIND will reintroduce the query without EDNS as a last-ditch effort to obtain an answer to a query, so long as the resolver is not configured for DNSSEC validation.

Subsequent queries to the same authoritative server would always be tried first with EDNS.

1. This future change is not a bug fix

The proposed future change to BIND is being made purely to accommodate broken server environments in the short term - administrators are strongly urged to fix their configurations and infrastruture.

The process of retries adds delays into resolution of queries for clients. Where there are many servers authoritative for a domain, named will progress through all of them and in some situations may fail to complete its fallback to no-EDNS before the client query times out.

Recursive servers that do not support TCP are broken and will be having a negative impact on the experience of their clients.

Recursive servers that do not support EDNS are limiting their own performance.

Recursive servers that support limited EDNS sizes but which have not been appropriately configured are also limiting their own performance.