djbdns split horizon problem

[skroo]

I'm having a problem getting a split-horizon djbdns (aka tinydns) server to play nicely on my internal network. Here's the scenario:

There are two dns servers, one external, one internal. The external (ext.ns.example.net) server holds host and alias records for several domains. The internal server (int.ns.example.net) is on the LAN here, and only holds records for hosts on the internal example.net networks. They do not replicate between each other because I would really rather not have my internal hosts' IP addresses out on the public Internet.

djbdns is running fine on ext.ns.example.org as a public-facing DNS server: lookups from the Internet run flawlessly for any domain it is authoritative for. To give a bit more background, it essentially serves a small farm of shared-hosting boxes.

On int.ns.example.org, djbdns is running as a caching server per the standard instructions for doing so. This is where the problem is arising.

Lookups are working fine for internal hosts - server.example.net resolves to 10.23.1.5, router.example.net resolves to 10.23.1.1, and so forth; this is also working for any network that the server has been made authoritative for - so testserver.example.net would successfully resolve to, say, 10.23.2.10. The problem arises if I try to resolve an external example.net hostname from inside the network - www.example.net would result in a failed lookup.

I've tried making int.ns.example.net authoritative for the range that www.example.net sits on, making host and alias entries for it, and so forth - but nothing seems to work. I'm really not quite sure where it's breaking here, since I'm realtively new to djbdns. If anyone has any ideas, I'd love to hear them.

[bascule]

I can't tell what IPs you have your internal tinydns and dnscache running on. But the solution is to run your internal tinydns on the loopback interface of the internal DNS server, and run dnscache on the IP of the internal network interface. Then, you need to instruct dnscache to route requests for your internal domain to the tinydns running on the loopback interface. If your domain is my.domain, you would create a file called "my.domain" in the root/servers subdirectory of your dnscache directory. Inside this file, put in 127.0.0.1, the IP address of the loopback interface where tinydns will be listening. For reverse lookups, you can create an appropriately named zone file with the address of your local tinydns (e.g. "D.B.C.A.in-addr.arpa").

[skroo]

I can't tell what IPs you have your internal tinydns and dnscache running on.

127.0.0.1 and 10.23.1.5, respectively.

But the solution is to run your internal tinydns on the loopback interface of the internal DNS server, and run dnscache on the IP of the internal network interface.

Right, understood. This is how I have it set up, and it seems to be working OK, apart from the issue I mentioned before.

Then, you need to instruct dnscache to route requests for your internal domain to the tinydns running on the loopback interface. If your domain is my.domain, you would create a file called "my.domain" in the root/servers subdirectory of your dnscache directory. Inside this file, put in 127.0.0.1, the IP address of the loopback interface where tinydns will be listening. For reverse lookups, you can create an appropriately named zone file with the address of your local tinydns (e.g. "D.B.C.A.in-addr.arpa").

Yep. Infuriatingly, this is exactly how it's set up. Let me summarise:

- Resolution works fine on the internal DNS server for any internal host.

- Resolution works fine on the internal DNS server for any host on the external server that does not share its domain with the internal domain.

- Resolution works fine on the external server for any host, provided that the request is coming from an external source.

Basically, the problem is purely on the inside: the internal and external domain are the same; if you're on the internal network requesting a lookup on an external host on the same domain as the internal network, it fails.

Sorry if I sound a bit short - I'm really not grumbling at you, I'm just out of ideas at this point. Which, I'm sure you understand, is extremely frustrating.

[bigezy]

Sometimes it is the simple things. You indicated that the external entries were only in the external servers. Do internal hosts secondary off the external server? Is there a host entry for www.example.net in your internal server?

[skroo]

Sometimes it is the simple things. You indicated that the external entries were only in the external servers. Do internal hosts secondary off the external server? Is there a host entry for www.example.net in your internal server?

Tried that. Regardless of whether or not the server was authoritative for the external range those hosts sit on, lookups still failed. Thanks, though.

[bigezy]

You could always punt, and look at sniffer traces. It would at least verify where the process breakdown is.

Tried that. Regardless of whether or not the server was authoritative for the external range those hosts sit on, lookups still failed. Thanks, though.

[bascule]

Well, I'm still having trouble figuring out exactly what the problem is...

You're unable to resolve adresses served by the external server on the internal network? If so, this is what should happen... you've instructed dnscache to pass resolution requests for your internal network to the tinydns running on the loopback interface.

I'm guessing you've already created two different configuration directories for two instances of tinydns, one for both the internal and external interfaces. I would think you would simply duplicate all records added to the configuration of the external interface's tinydns on the internal interface's tinydns's configuration...

[skroo]

You're unable to resolve adresses served by the external server on the internal network?

Yes, but only for the domain common to both the internal and external network. If the network is example.net, www.example.net (which is on the public side) won't resolve from inside. server.example.net, however, which is an internal host, resolves OK from the inside. Does this help to clarify it at all? I'm out of ways to explain it, unfortunately.

If so, this is what should happen... you've instructed dnscache to pass resolution requests for your internal network to the tinydns running on the loopback interface.

Correct. And this is what's happening. But what I can't figure out is why none of the external hosts will resolve internally.

I'm guessing you've already created two different configuration directories for two instances of tinydns, one for both the internal and external interfaces.

Actually, we're talking about two different DNS servers on two different boxes - the internal and external servers are entirely separate entities.

I would think you would simply duplicate all records added to the configuration of the external interface's tinydns on the internal interface's tinydns's configuration...

I tried this, and no dice. Same problem. I'm about ready to start tearing my hair out at this point.

[yankee]

I'm not very familiar with djbdns, so I can't be sure this is even relevant but... does int.ns.example.net think it's authoritative for the example.net domain? If so, I think it would fail rather than do a recursive search on ext.ns.example.net.

[bascule]

I tried this, and no dice. Same problem. I'm about ready to start tearing my hair out at this point.

Your internal tinydns has all the same records in its own database as whatever server is actually authoritative for that domain and it doesn't work? Something is seriously wrong then...

How did you generate these records, axfr-get? By hand? Can you generate a cdb of just the external records for us to look at? If the other host is running tinydns you should just be able to rsync to them, provided you have ssh access to the system.

[Mr. Peabody]

I'm having a problem getting a split-horizon djbdns (aka tinydns) server to play nicely on my internal network. Here's the scenario:

There are two dns servers, one external, one internal. The external (ext.ns.example.net) server holds host and alias records for several domains. The internal server (int.ns.example.net) is on the LAN here, and only holds records for hosts on the internal example.net networks. They do not replicate between each other because I would really rather not have my internal hosts' IP addresses out on the public Internet.

djbdns is running fine on ext.ns.example.org as a public-facing DNS server: lookups from the Internet run flawlessly for any domain it is authoritative for. To give a bit more background, it essentially serves a small farm of shared-hosting boxes.

On int.ns.example.org, djbdns is running as a caching server per the standard instructions for doing so. This is where the problem is arising.

Lookups are working fine for internal hosts - server.example.net resolves to 10.23.1.5, router.example.net resolves to 10.23.1.1, and so forth; this is also working for any network that the server has been made authoritative for - so testserver.example.net would successfully resolve to, say, 10.23.2.10. The problem arises if I try to resolve an external example.net hostname from inside the network - www.example.net would result in a failed lookup.

I've tried making int.ns.example.net authoritative for the range that www.example.net sits on, making host and alias entries for it, and so forth - but nothing seems to work. I'm really not quite sure where it's breaking here, since I'm realtively new to djbdns. If anyone has any ideas, I'd love to hear them.

This might sound like a stupid question and a gross statement of the obivious. Where does your internal dns server's forward failed lookup point to?

On a side note, you can still create slave zones on the internal server to replicate the external zones. Fortunately DNS replication is not bidirectional, but uni-directional and dictated per zone.

[skroo]

This might sound like a stupid question and a gross statement of the obivious. Where does your internal dns server's forward failed lookup point to?

The ISP's DNS servers (verified functional).

On a side note, you can still create slave zones on the internal server to replicate the external zones. Fortunately DNS replication is not bidirectional, but uni-directional and dictated per zone.

Actually, the problem was a lot simpler than that; I just hadn't remembered to post the fix. I'd made both servers authoritative for the same domain but in different ranges. Dumb oversight on my part, but some good suggestions did arise out of the the thread.