1

I have an application on a Linux box that uses reverse lookup to resolve hostnames. The problem is, I have two sets of DNS servers in my resolve.conf (4 servers total), with each set corresponding to a different range of IP's. It works fine for one range of IP's, whichever one happens to be in the first server listed, but if I try to nslookup the other range, it reports not found: 3(NXDOMAIN). If it would just try the next server in the list, it would succeed....is there a way to make it do this? The DNS servers are only authoritative for their respective ranges.

1
  • My fault, apparently didn't set up emails for new responses. Yea, basically we have Server1 with reverse lookup entries for IP's in, say, range 192.168.0.0/24 and Server2 with reverse lookup entries for range 10.0.0.0/8. Let's say I have Server1 is the first server listed in resolv.conf, when I try to do a reverse lookup on IP 10.0.0.1, it fails instead of trying to look it up on Server2. This has nothing to do with host name resolution, that works fine recursively. Jan 17, 2013 at 21:31

3 Answers 3

3

I would install dnsmasq, make it (127.0.0.1) the only nameserver, and configure it to query this or that server for this or that domain using the "server" dnsmasq.conf directive.

If there's a way to try a different server upon a NXDOMAIN from a DNS server, that would be using a local DNS server with that functionality. The Linux resolver doesn't allow it. PowerDNS can be configured to run commands for every query, so as a last resort, you could always do that.

1
  • I think this will actually take care of my issue. I'll try this out and report back. Thanks for the answer and sorry for the 5 month delay. Jan 17, 2013 at 22:06
1

A response to @cstamas, just to clarify how to address the VPN issue with dnsmasq.

Let's say, your machine is on the homenetwork.test domain with IP addresses 10.1.0.0/16 and the DNS server is 10.1.0.1. That DNS server can only query the "external" domain names for the worknetwork.test domain. It is authoritative (internally) for homenetwork.test and 1.10.in-addr.arp.

Now, you connect a VPN to join the worknetwork, and you now have a new route to 10.2.0.0/16 via that interface and a new DNS server 10.2.0.1 which is authoritative for worknetwork.test and 2.10.in-addr.arpa. If you use one or the other of those name servers, you'll only be able to resolve one or the other of the worknetwork.test and homenetwork.test domains.

If you use both dns servers (and RES_ROTATE), it's not better as you'll be able sometimes to resolve one or the other.

Now, if you use

dnsmasq --no-resolv --no-negcache --no-host --conf-file= \
   --server=/worknetwork.test/10.2.0.1 \
   --server=/2.10.in-addr.arpa/10.2.0.1 \
   --server=10.1.0.1

And have "nameserver 127.0.0.1" in resolv.conf, you'll use 10.2.0.1 to resolve the worknetwork.test and the 10.2.x.x IP addresses and your home DNS server for the rest.

0

You tell little information so it is hard to begin, but I will try...

First of all the servers you are talking about are authoritative dns servers (that provides information about zones you set up), right? If so you should set up a server in your resolv.conf that is recursive only (only resolving dns name for you, not providing information). You can install it to listen on localhost as sch said.

On the other hand if a server returns an nxdomain that means: "I know this name, I am an authoritative server for it and this name does not exists." The standard dns resolving algorithm stops here. So that is it, there is no way around this. You should set your authoritative dns servers to not to be authoritative for that name.

2
  • A typical example is VPN or anything that merges two private networks with their corresponding DNS server. Each server is authoritative for their own domain (and inaddr.arpa).
    – sch
    Aug 29, 2012 at 7:50
  • @sch Ok, I understand. Still think there is no adequate solution for this.
    – cstamas
    Aug 29, 2012 at 9:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .