Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Author Topic: DNS server question  (Read 247 times)

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9824
  • Retd sw dev; A&A; 3 ◊ 7km ADSL2; IPv6; Firebrick
DNS server question
« on: April 21, 2021, 04:44:58 PM »

I just read this article 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.
« Last Edit: April 22, 2021, 01:28:33 AM by Weaver »
Logged

CarlT

  • Kitizen
  • ****
  • Posts: 1752
  • Random network numpty
Re: DNS server question
« Reply #1 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.
Logged
WiFi: Nighthawkģ AX12 RAX120
Routing: Mikrotik CCR2004-1G-12S+2XS
Switching: Mikrotik 2 * CRS305-1G-4S-IN, 2 * CRS309-1G-8S+; 1 * CSS326-24G-2S+RM
Exchange: Wakefield
ISP: BT Full Fibre 900. Zen Full Fibre 900. Faelix FTTP 300

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9824
  • Retd sw dev; A&A; 3 ◊ 7km ADSL2; IPv6; Firebrick
Re: DNS server question
« Reply #2 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 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.
« Last Edit: April 22, 2021, 05:58:15 AM by Weaver »
Logged