Join Log in
Score:0
raj avatar Server

Internal DNS with BIND, how to resolve one IP address differently?

ye flag
raj

I have an internal DNS (it is completely internal, ie. the network is not connected to Internet) for a group of networks. They are set up as follows:

  • Each network has a different address range of 10.x.0.0/16 and its own domain domainx (it is a top-level domain) - for example network 10.1.0.0/16 has domain1 (all hosts in this network have DNS names somehost.domain1)

  • For each network/domain, host ns.domainx (10.x.1.1) is a DNS server that handles both forward zone domainx and reverse zone x.10.in-addr.arpa

  • These networks are not interconnected, except of a special multi-homed server that has connectivity to all these networks (and my question is about that server in fact) - but it does not route packets between those networks, it only can communicate with each of them. It is by design, each network is designed to be operated separately and standalone.

  • Therefore, the DNS server in each network knows only about its domain; it doesn't know (and should not know) anything about domains from other networks.

  • However, the multi-homed server I mentioned earlier needs to have working DNS resolution for addresses in all these networks. By requirement, I can't touch anything in any of the networks, in particular their DNS servers. I can only modify configuration of the multi-homed server.

  • So I set up BIND on the multi-homed server that just defines zone . as "master", and the zone file contains the following records:

    1.10.in-addr.arpa.    IN    NS    ns.domain1.
domain1.              IN    NS    ns.domain1.
ns.domain1.           IN    A     10.1.1.1

2.10.in-addr.arpa.    IN    NS    ns.domain2.
domain2.              IN    NS    ns.domain2.
ns.domain2.           IN    A     10.2.1.1

3.10.in-addr.arpa.    IN    NS    ns.domain3.
domain3.              IN    NS    ns.domain3.
ns.domain3.           IN    A     10.3.1.1

    and so on for all networks.

Everything works OK, but there is one small issue.

Sometimes the DNS server for a particular network is down. In these networks, the DNS server being down is not considered a failure - it is just a normal operating state that can happen. It is expected and normal that there will be no DNS resolution for that particular network at that time.

But there is one particular IP address in network 1 (say, 10.1.10.10) that I want always to resolve to a domain name - even when the DNS for network 1 is down. So it must be resolved by the local server, not delegated to the server for network 1. Actually, it is also acceptable that NXDOMAIN will be returned as a response to the query for this address (if this is easier to configure), but the response must be returned immediately, without trying to contact the DNS server for network 1 - the delay when that server is down is exactly what we want to avoid.

And I don't know how to do this.

Adding a PTR record for 10.10.1.10.in-addr.arpa. to the . zone file does not work - it seems to be simply ignored, and when the DNS for network 1 is not working, 10.1.10.10 is not resolved.

How to make this address resolve locally?

74
0 + 0
vidarlo avatar
ar flag
vidarlo
This sounds like a X-Y problem to me. The normal way to handle DNS server outage is to have multiple DNS-servers. There's furthermore no reason one server can't have multiple views, so that isolation can be upheld with only one DNS-server serving multiple nets.
1
Reply
raj avatar
ye flag
raj
@vidarlo I have simplified the setup for the sake of this question - in fact there are usually 3 DNS servers for each network. But it is **expected** that **all** of them may be down. This is the way the network operates. The single address I'm interested in is "special" (sorry, I can't disclose details) and therefore should be handled on the multi-homed server level even if all "subordinate" DNS servers are down.
0
Reply
raj avatar
ye flag
raj
@vidarlo Also, as I wrote, it is **by design** that each network is independent, so there can't be a single DNS server serving multiple nets. The networks **have to** not know anything about each other. The multi-homed server is an additional layer we added. It does not exist "in the field". You can imagine the entire networks (including their DNS servers) being 3rd party products that you have no control over and can't touch anything there. You control only the multi-homed server.
0
Reply
Score:0
raj avatar Server
ye flag
raj

I found a solution. It was actually simple. It was sufficient to add 10.10.1.10.in-addr.arpa as another "master" zone to my named.conf file, with the zone file being named.empty ie. the default file included in BIND configuration to serve zone 0.in-addr.arpa.

Now the query for 10.1.10.10 gives the answer that the address has no PTR record, regardless whether the DNS server for 10.1.0.0/16 is up or down. That eliminates the delay when resolving the address, which is sufficient for me. Of course I could define a separate zone file for this zone instead of named.empty and add in this zone file a PTR record for @ to make the IP address actually resolve to some domain name, but I have no need for this right now.

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.