Recommended idle timeout setting for DNS (UDP)?

Hi Jeremiah,

 

The typical settings isa around 300s.

 

 

Bhattman

 

 

Hi Jeremiah,

 

 

I have heard of a few major (some root) DNS servers being load balanced through LTM. So hopefully you'll get some experienced suggestions here.

 

 

Isn't the zone transfer done over TCP? If so, and you've configured a UDP only VIP, you should be able to use a very low idle timeout without failures on the UDP VIP and a slightly longer timeout for the TCP VIP. As Jesse pointed out in the thread linked below, any UDP packet would add a new entry in the connection table. So you shouldn't need to worry about removing the connection table entries too early.

 

 

 

http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&postid=814020&ptarget=814306

 

 

If this is a UDP-only DNS server you wouldn't need to change the "loose initiaition" setting at all because any UDP packet will generate a new connection table entry.

 

 

 

 

Aaron

I'm using a fastL4 all protocols (tcp/udp) vip currently with a custom fastL4-dns profile set at 120s. TCP is indeed needed for the zone xfer. Are you suggesting that I split it into 2 vip's... one UDP with 10s or less timeout and one TCP with 120s or 300s default? I suppose that might work well... I will test at earliest convenience.

 

 

Open to any other suggestions as well.

 

 

Thanks,

 

 

-Jeremiah

I don't have any experience testing DNS-specific VIPs, so I'd rather wait for someone else to provide their thoughts before you try something in production.

 

 

That said...

 

 

I would suggest using separate VIPs for TCP and UDP. I would think you could potentially set the UDP VIP idle timeout to 0 and the TCP VIP idle timeout to 15 seconds (or however long you expect the longest reasonable zone transfer to take). I'd expect the number of UDP requests would be a much greater proportion of the total entries anyhow. So the TCP idle timeout probably wouldn't make as big a difference as the UDP configuration.

 

 

Aaron

I've heard about a very powerful design pattern for DNS called the 'stateless UDP' pattern. It can be useful for fairly high volume DNS environments that fill up our connection tables quickly (which can certainly happenwith a massive number of UDP requests and default timeout settings).

 

 

**Note: I've not had the opportunity to set this up myself, so please test this well and be sure it behaves the way you want. If it doesn't behave the way you expect, you should explore other options or simply stick with very small timeout values.

 

 

**Also note: IMO this is a very advanced configuration, so again, please test it carefully before you go into production!! Hammer it with load, etc...

 

 

With all that said, here goes:

 

 

Inbound traffic

 

1) Create a custom fast l4 profile with a timeout of immediate. This essentially bypasses the connection table.

 

2) Create your DNS server pool

 

3) Create your DNS Virtual Server bound to the external VLAN. Disable port translation. Assign your new fast l4 profile and pool.

 

 

Outbound traffic

 

To handle response traffic for the DNS requests:

 

 

1) Create a SNAT pool with your Virtual Server address in it.

 

2) Create a wildcard (0.0.0.0:0) virtual server with a UDP profile. Confirm port/address translation are disabled, then assign your SNAT pool and fast L4 profile to this virtual, so it'll source the traffic from your virtual server address and have the same connection characteristics.

 

 

This type of setup should allow you to handle high volumes and still be in-line. Please report back on any findings you've got - I hope this makes sense.

 

 

-Matt

 

Thanks Aaron and Matt.

 

 

Matt, I'm basically doing what you suggest as far as outbound traffic except that I'm using a wildcard VS with * protocols and my 120s custom fastL4 profile. As Aaron had suggested, are you saying I use a custom fastL4 profile with timeout set to immediate for a UDP VS and then additionally create a TCP VS with default fastL4 profile (no reason to change from 300s)? Would you suggest splitting my wildcard VIP so I can have separate UDP and TCP timeout settings much like was discussed for incoming VIP's?

 

 

Also, I'm curious why you say I should disable port translation for the incoming VS? I already have address/port translation disabled on outgoing wildcard VS.

 

 

Thanks,

 

 

-Jeremiah

I used to run DNS frontended by LTM for a pretty big organisation with a major web presence. IIRC we used 10seconds timeout on the UDP, and normal 300s on the tcp (Since it's only zone transfers and querys/responses that are too big to fit in a single 512B UDP datagram that use TCP - That's about 13 RR's depending on data).

 

 

H

This thread was timely as a couple of us are exploring the various options for a high-volume deployment. Really, it pretty much boils down to these, each with its own advantages and disadvantages:

 

 

1) In-line, 'stateful' UDP. This is the normal way many folks setup DNS LB, taking defaults on the fast l4 profiles. The downside is that if you get hammered with traffic (valid or otherwise) it may not play nice with the connection table. This deployment is probably the most common. You can create custom profiles to lower the timeout values, but it's essentially normal 'ol BigIP.

 

2) "Stateless" UDP, discussed above. Better characteristics with the connection table, fairly well suited for mid-high volume deployments.

 

3) 'Stateless' npath. Probably best for ultra, ultra high volumes.

 

4) Datagram LB (stateful - uses the connection table). The LTM will send multiple queries from the same IP:src port combo to different systems per datagram. Helps distribute DNS load across a farm in a sane way.

 

5) Advanced iRule switching, protection, etc. Doing a quick search of the iRules Wiki for "DNS" is enough to keep many of us busy for a while!

 

 

If anyone else out there has variations or additions to this list please point them out.

 

 

One other note: the 'stateful' designs can also run you up against ephemeral port exhaustion so keep an eye on that if you decide to use this deployment option. Obviously the problem is really easy to fix via a snat pool with multiple addresses, but it's better to know about it up front than run into dropped queries in production...I've run into this issue two times now with large-ish DNS setups that are using SNAT automap. As a best practice, I'd go straight in with a pool of SNAT addresses.

 

 

Jeremiah: please update us when you arrive at some resting place with this deployment. It'll be really useful for all of us to see how you set it up to meet your requirements.

 

 

-Matt

I had a chance to test this configuration, but the stateless setup didn't work for me. I tried stateless udp profile on incoming fastL4/UDP vip as well as a wildcard/UDP vip for outbound. When using stateless profile on inbound and attempting a dig, I get errors about responding packet coming from different IP than expected. When stateless is set on wildcard, the dns slaves can't make UDP connections outbound.

 

 

My setup is slightly more complicated in that I'm using an iRule on my wildcard VS to SNAT out each of my dns slaves via individual IP's and then directing them towards a pool containing an external gateway. This is a legacy configuration from before my time, which I'd probably replace with a snat pool and a custom route if I was positive DNS was going to stay on my LTM. Thoughts on whether this configuration would cause stateless UDP to not work as intended?

 

 

For the time being, I've left the wildcard vs in a fastL4, all protocols configuration and split my dns_53_vs (fastl4, all protocols) vip into two separate virtual servers: fastl4/TCP with default fastL4 profile and fastL4/UDP with custom 10s timeout profile. This at least drastically decreases the amount of connections in the connection table.

 

 

Thanks for any insight.

 

 

-Jeremiah

Thanks for the update. Did you confirm that you're SNAT-ing correctly on the egress (response) VIP, and double checked your port translation settings? A client-side tcpdump/wireshark capture of a failed transaction would be really interesting to see. Either way, it seems like you've gotten a fairly solid solution for your needs in place, so thanks for sharing your setup.

 

 

-Matt