Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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
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.
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.
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?
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.
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
(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.
(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.
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.
Class map generic configuration mode
Admin and user contexts
ACE Module Release
This command was introduced.
This command supports the "\xST" metacharacter.
ACE Appliance Release
This command was introduced.
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).
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 22.214.171.124, IN A to 126.96.36.199, IN CNAME to 188.8.131.52, IN PTR to 184.108.40.206, etc etc ??? that requires lots of cpu overhead for inspection and NAT'ing, likely to impact overall latency for heavy dns environment.
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 220.127.116.11, IN A to 18.104.22.168, IN CNAME to 22.214.171.124, IN PTR to 126.96.36.199, 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.)