1

Topic: The DNS-server

Help to understand logic of operation of the DNS-server. Application (and it is is specific dns.js in composition node.js) sends UDP-inquiry on  IPv6 on a domain name. The server returns a pack of IPv6-addresses. But at the answer there is flag Truncated. Probably, on this base application switches to TCP protocol and tries  a name through it. The DNS-server at all does not answer TCP-inquiries. I made such pattern on the basis of the analysis of the traffic with the help tcpdump. But further my knowledge ended. And very much there is no council of the knowing person "and in an ideal should be so". Explain, please: 1. I correctly understood, what exactly flag Truncated leads to switching on TCP? And so should be. 2. On what to pay attention to understand, the reason of appearance of flag Truncated in the answer? If the same request to send the utility dig the flag misses. All it happens in a network of one specific provider. To their administrators I will address next week. For now a rage I save

2

Re: The DNS-server

Hello, Mihas, you wrote: M> Explain, please: M> 1. I correctly understood, what exactly flag Truncated leads to switching on TCP? And so should be. Yes, it is strict under the standard. M> 2. On what to pay attention to understand, the reason of appearance of flag Truncated in the answer? If the same request to send the utility dig the flag misses. Answer volume. Truncated should appear at excess by the answer of 512 byte. Though it is norm old (those times when it was promised MTU> = 576 for the majority of normal networks; now for IPv6 it is mandatory 1280 and it is recommended 1500), it could in separate implementations and change. Than the request from dig differs - compare, but explicitly there is any difference in flags.

3

Re: The DNS-server

Hello, netch80, you wrote: M>> 2. On what to pay attention to understand, the reason of appearance of flag Truncated in the answer? If the same request to send the utility dig the flag misses. N> answer Volume. Truncated should appear at excess by the answer of 512 byte. Though it is norm old (those times when it was promised MTU> = 576 for the majority of normal networks; now for IPv6 it is mandatory 1280 and it is recommended 1500), it could in separate implementations and change. The answer does not exceed 512 byte. Probably, it is cut off somewhere at the sender with flag exhibiting. I.e. it is not obviously possible to check up. N> Than the request from dig differs - compare, but explicitly there is any difference in flags. In request from dig flag Don't fragment == 0. In my request == 1. In request from dig flag AD bit == 1. In my request == 0. At request from dig there is a section additional information type OPT. Its contents are important?

4

Re: The DNS-server

Hello, Mihas, you wrote: M> Hello, netch80, you wrote: M>>> 2. On what to pay attention to understand, the reason of appearance of flag Truncated in the answer? If the same request to send the utility dig the flag misses. N>> answer Volume. Truncated should appear at excess by the answer of 512 byte. Though it is norm old (those times when it was promised MTU> = 576 for the majority of normal networks; now for IPv6 it is mandatory 1280 and it is recommended 1500), it could in separate implementations and change. M> the answer does not exceed 512 byte. Probably, it is cut off somewhere at the sender with flag exhibiting. I.e. it is not obviously possible to check up. Restriction in 512 byte on a packet "is given from above" (for DNS over UDP), and on  it is necessary to consider a fragmentation: https://tools.ietf.org/html/draft-muks- … agments-00 As a result, a practical DNS payload size limitation is necessary. [RFC1035] limited DNS message UDP datagram lengths to a maximum of 512 bytes. Although EDNS (0) [RFC6891] allows an initiator to advertize the capability of receiving lager packets (up to 4096 bytes), it leads to fragmentation because practically most packets are limited to 1500 byte size due to host Ethernet interfaces, or 1280 byte size due to minimum IPv6 MTU in the IPv6 stack [RFC3542]. According to DNS specifications [RFC1035], if the DNS response message can not fit within the packet's size limit, the response is truncated and the initiator will have to use TCP as a fallback to RE - query to receive large response.

5

Re: The DNS-server

Hello, Mihas, you wrote: M> Hello, netch80, you wrote: M>>> 2. On what to pay attention to understand, the reason of appearance of flag Truncated in the answer? If the same request to send the utility dig the flag misses. N>> answer Volume. Truncated should appear at excess by the answer of 512 byte. Though it is norm old (those times when it was promised MTU> = 576 for the majority of normal networks; now for IPv6 it is mandatory 1280 and it is recommended 1500), it could in separate implementations and change. M> the answer does not exceed 512 byte. Probably, it is cut off somewhere at the sender with flag exhibiting. I.e. it is not obviously possible to check up. Well, it in this case is cut already down. N>> than the request from dig differs - compare, but explicitly there is any difference in flags. M> in request from dig flag Don't fragment == 0. In my request == 1. M> In request from dig flag AD bit == 1. In my request == 0. I in DNSSEC do not understand, but, on idea, at AD should even ask thicker answer... M> At request from dig there is a section additional information type OPT. Its contents are important? Similarly.