Kitz Forum

Internet => General Internet => Topic started by: Weaver on April 21, 2021, 04:44:58 PM

Title: DNS server question
Post by: Weaver on April 21, 2021, 04:44:58 PM
I just read this article (https://serverfault.com/questions/698251/how-does-the-dns-protocol-switch-from-udp-to-tcp) about the use of TCP or UDP in DNS responses. My question: if the server cannot fit the DNS reply into x bytes, then is there any real reason to send one full packet of the first part of the response?

I’d like to discuss these questions in reverse order for some reason.

Another question: What is the value of x? If the response is say 1280 bytes long and you’re using IPv6 then you’re good to go, so if you’re using IPv4 then is it not ok to just assume that 1280 bytes is ok even with IPv4? No ancient systems exist any more that have a 512 byte IP payload limit (IP SDU limit) surely. If you send back >1400 bytes then it might get into trouble with some path MTU limit, so perhaps >1280 bytes is too risky and I would think there’s no point dealing with (response_len > 1280 && response_len <1400) as a special case.

Going back to my first question. If a server sends back a first-part of a reply, then can the client even use it? Will the client just throw it away anyway and retry the request using TCP. Is a truncated first part sometimes useful in certain cases? Apologies for being so ignorant. :(

If it turns out that the first part is never useful to a client, then why not send back 0 bytes with the TC flag set in order to reduce the network traffic, rather than sending back some x-byte long response.
Title: Re: DNS server question
Post by: niemand on April 22, 2021, 12:39:28 AM
DNS travelling over UDP gets fragmented during transit. There's a fallback to TCP if this fails.

The data has to get to the client sooner or later so makes zero difference whether it is the first or the second part of a response that's full. Very rare DNS is this size, though.

Fragmented UDP requests are fine. OSI model - fragmented responses are reassembled lower down in the network stack and presented to the client complete.

Outside of Spanning Tree not familiar with TC flags so can't comment on this one.
Title: Re: DNS server question
Post by: Weaver on April 22, 2021, 01:22:31 AM
Iirc TC flag is "truncated content" but I need to look it up again; it’s been an eternity ( > 24 years :-) ).

Yes, I had forgotten about the possibility of using IP fragmentation. IPv6 has no fragmentation in middle boxes, only in the source, so it may not help you if you are a server and you send back more than 1280 bytes. So do you get IPv4 and IPv6 responses back IP-fragmented if they are between 1281 and 1500 bytes long?

Anyone any thoughts about the first question? If you only get a part of a response that is > 1280 or even  >1500 bytes long, is a first-part any use to you, because you will be getting it again as the first part of a TCP connection, no? So why send that first part twice?



I read RFC 5966 (https://tools.ietf.org/html/rfc5966) and noted that it points out the unreliability of relying on IP fragmentation in middle boxes, because of dodgy middle boxes and evil firewalls that don’t like reassembling fragments or can’t be bothered to wait the time required or tie up the RAM necessary; indeed if you are a firewall, allocing 64k of RAM for each flow in order to handle reassembly over a long time would introduce huge delays and be a method for a DOS attack by exhausting server RAM.

It talks about an IP SDU or is it PDU (?) size limit of 512 bytes but I ignored this when I first started this thread as I can’t see that it’s realistic for today’s systems and would think that surely <= 1280 bytes PDU size is safe enough, no?

Just to check I have this correct you get 512 bytes - or maybe more, I don’t know - in a UDP packet and then when the TCP connection starts you get that same data repeated at the beginning.