Linux - Software This 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. |
| Notices |
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.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
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.
 |
GNU/Linux Basic Guide
This 255-page guide will provide you with the keys to understand the philosophy of free software, teach you how to use and handle it, and give you the tools required to move easily in the world of GNU/Linux. Many users and administrators will be taking their first steps with this GNU/Linux Basic guide and it will show you how to approach and solve the problems you encounter.
Click Here to receive this Complete Guide absolutely free. |
|
 |
12-01-2011, 02:28 PM
|
#1
|
|
LQ Newbie
Registered: Nov 2010
Location: South Florida
Posts: 20
Rep:
|
DNS router
Has anyone heard of any software to route DNS packets based on DNS request types?
Example:
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
|
|
|
|
12-01-2011, 03:49 PM
|
#2
|
|
Senior Member
Registered: Aug 2009
Posts: 3,497
|
I haven't ... what's the goal? .. you can just have a layer of caching nameservers to accelerate queries/distribute the load.
|
|
|
|
12-01-2011, 04:12 PM
|
#3
|
|
LQ Newbie
Registered: Nov 2010
Location: South Florida
Posts: 20
Original Poster
Rep:
|
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.
|
|
|
|
12-01-2011, 05:15 PM
|
#4
|
|
Senior Member
Registered: Aug 2009
Posts: 3,497
|
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.
|
|
|
|
12-26-2011, 02:39 AM
|
#5
|
|
Member
Registered: Dec 2011
Posts: 32
Rep:
|
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"
|
|
|
|
12-26-2011, 02:56 AM
|
#6
|
|
LQ Newbie
Registered: Nov 2010
Location: South Florida
Posts: 20
Original Poster
Rep:
|
"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:
1.1.1.1 IN A "ONE"
* IN TXT "OTHERS"
dig 1.1.1.2 TXT yields "OTHERS", but,
dig 1.1.1.1 TXT yields SOA record (since * cant overlap existing entries - even when they are of different types A/TXT/MX/CNAME/etc.)
|
|
|
|
12-26-2011, 01:44 PM
|
#7
|
|
Member
Registered: Dec 2011
Posts: 32
Rep:
|
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.
|
|
|
|
12-29-2011, 11:20 AM
|
#8
|
|
Member
Registered: Dec 2011
Posts: 32
Rep:
|
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.
Code:
(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
line_number
(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
Modification
A2(1.0)
This command was introduced.
A2(2.1)
This command supports the "\xST" metacharacter.
ACE Appliance Release
Modification
A3(1.0)
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:
http://www.cisco.com/en/US/docs/inte...html#wp1217552
|
|
|
|
12-29-2011, 01:17 PM
|
#9
|
|
Member
Registered: Jan 2006
Location: USA
Posts: 462
Rep:
|
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 1.1.1.1, IN A to 2.2.2.2, IN CNAME to 3.3.3.3, IN PTR to 4.4.4.4, etc etc ??? that requires lots of cpu overhead for inspection and NAT'ing, likely to impact overall latency for heavy dns environment.
|
|
|
|
12-29-2011, 11:01 PM
|
#10
|
|
LQ Newbie
Registered: Nov 2010
Location: South Florida
Posts: 20
Original Poster
Rep:
|
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 1.1.1.1, IN A to 2.2.2.2, IN CNAME to 3.3.3.3, IN PTR to 4.4.4.4, 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.)
|
|
|
|
12-30-2011, 04:43 AM
|
#11
|
|
Member
Registered: Jan 2006
Location: USA
Posts: 462
Rep:
|
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.
|
|
|
|
| Thread Tools |
Search this Thread |
|
|
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -5. The time now is 05:13 PM.
|
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|