-   Linux - Software (
-   -   DNS router (

RudyGomez 12-01-2011 03:28 PM

DNS router
Has anyone heard of any software to route DNS packets based on DNS request types?
DNS request type A => Server A
DNS request type MX => Server B
DNS request type SOA => Server C
DNS request type TXT => Server D
ALL other DNS request => Server E

kbp 12-01-2011 04:49 PM

I haven't ... what's the goal? .. you can just have a layer of caching nameservers to accelerate queries/distribute the load.

RudyGomez 12-01-2011 05:12 PM

The goal is to separate DNS databases by record type.
In this particular case, this could save half of the entries space, as half of the entries are of one type and all of those return the same exact value.

In small systems this would not matter but this is for a very large DNS system; and half less would make a huge difference.

kbp 12-01-2011 06:15 PM

Would be interesting to see what your solution looks like at the end .. you might want something like a sql reverse proxy but I haven't come across anything like this. If you can't find a boxed product you may be able to modify pgbouncer or another connection pooler to do what you need.

RobertEachus 12-26-2011 03:39 AM

I think you would have to use a hardware accelerated load balancer with deep packet inspection and a little (3-7 lines?) of custom code to do what you are suggesting. I've never heard of anything off the self that could do this.

Would wild carding that record type solve your problem?

* IN TXT "These records are all the same"

RudyGomez 12-26-2011 03:56 AM

"Would wild carding that record type solve your problem?"
* IN TXT "These records are all the same"

You would think, but the net effect is that the wildcard only fills in any missing entries and doesn't overlap (to all entries.)

That is, using: IN A "ONE"

dig TXT yields "OTHERS", but,
dig TXT yields SOA record (since * cant overlap existing entries - even when they are of different types A/TXT/MX/CNAME/etc.)

RobertEachus 12-26-2011 02:44 PM

How very right you are... RFC 4592. This is not a problem I've run into before. Looks like you need deep packet inspection on a load balancer. This will enable you to route packets based on whats in the packet rather than based on the IP headers.

RobertEachus 12-29-2011 12:20 PM

Ok, took me forever to find this, looks like a lot of firewalls are using deep packet inspection to enforce that only valid DNS packets get through the firewall, and that is making it very hard to find information about load balancing based on deep packet inspection. However a Cisco LB w/ ACE can use the following command to build the criteria for routing to different server pools based on information inside the pay load of the packet. I think A10Networks load balancers can also do this with aFlex rules and I am sure other vendors as well.

I also looked at ways to do deep packet inspection in Linux, there are a few solutions but the problem seems to be taking meaningful action after a filter is matched. For most of the software I saw the options were drop or accept, and that won't let you do what you need. If anyone does know of some open source routing/LB software for Linux that does support deep packet inspection based on REGEX it would be great to hear from them.


(config-cmap-generic) match layer4-payload

To define match criteria for Layer 4 payloads, use the match layer4-payload command in class map generic configuration mode. Use the no form of this command to remove the Layer 4 payload match criteria from the class map.

[line_number] match layer4-payload [offset number] regex expression

no [line_number] match layer4-payload [offset number] regex expression

Syntax Description


(Optional) Line number that allows you to edit or delete individual match commands.

•For the ACE module, enter an integer from 1 to 1024 as the line number.

•For the ACE appliance, enter an integer from 2 to 1024 as the line number.

You can enter no line_number to delete long match commands instead of entering the entire line. The line numbers do not indicate any priority for the match statements.

offset number

(Optional) Specifies an absolute offset in the data where the Layer 4 payload expression search string starts. The offset starts at the first byte of the TCP or UDP body. Enter an integer from 0 to 999. The default is 0.

regex expression

Specifies the Layer 4 payload expression that is contained within the TCP or UDP entity body. The range is from 1 to 255 alphanumeric characters. For a list of the supported characters that you can use in regular expression strings, see Table 2-9.

Command Modes

Class map generic configuration mode

Admin and user contexts

Command History

ACE Module Release

This command was introduced.


This command supports the "\xST" metacharacter.

ACE Appliance Release

This command was introduced.

Usage Guidelines

You cannot configure more than one match layer4-payload command in the same match-all class map.

Generic data parsing begins at Layer 4 with the TCP or UDP payload, which allows you the flexibility to match Layer 5 data (in the case of LDAP or DNS) or any Layer 7 header or payload (for example, HTTP).

Found the information here:

Linux_Kidd 12-29-2011 02:17 PM

i presume this is for internal routing only...

so in the grand scheme of things, how does this affect the edge router(s) that are the paths for all DNS to/from the internet?

i dont quite follow how all of the same type of RR all have the same value. thats certainly not true. there can be infinite # of RR's of type IN TXT

is the goal to route all IN TXT to, IN A to, IN CNAME to, IN PTR to, etc etc ??? that requires lots of cpu overhead for inspection and NAT'ing, likely to impact overall latency for heavy dns environment.

RudyGomez 12-30-2011 12:01 AM

True, typical DNS have almost one-to-one forward and RR entries. But, this is not for a typical setup, it is for a very specific DNS setup.
Yes, the goal is very much like "route all IN TXT to, IN A to, IN CNAME to, IN PTR to, etc"
NAT'ing would be taking place regardless so that is a non-issue.
Now, CPU overheard for inspection, could be an issue... but not one that can't be overcome with sufficient spare CPU cycles (which most DNS servers already have.)
As for the overall latency, I would expect that this should not add more than a few milliseconds delay (which should not break the overall DNS functionality.)

Linux_Kidd 12-30-2011 05:43 AM

you mentioned "large" dns. i can only suggest some sort of modeling and testing before going full scale. as for "RR", that just means Resource Record. ok, let us know what you come up with.

All times are GMT -5. The time now is 11:22 AM.