0

Edit: This was a generally awful question, as in not well documented. It wasn't generally awful in that I truly didn't know what was going wrong, and had been searching and researching. I finally turned to ServerFault with a "BBBBLLLLaaarrggghhh" type question. The title still stands, but the body should have been:

My DNS server appears to be resolving my queries with different answers depending on what network I'm attached to. Examples are:

# DiG command
  resulting output from first zone

# DiG command
  resulting output from second zone

I'll gladly provide more supporting detail. Please explain how I should get the supporting detail, though.

Now back to my awful question:

I've read a lot of other ServerFault BIND9 DNS not forwarding questions and answers. Queries (using DiG) for FQDNs I expect to be forwarded respond as if the public internet has the authoritative answer. Beyond DiG, what tools can I use to trace through my BIND9 configuration? It appears the zone I'm trying to forward is not forwarding.

Specifically, I am at home with a VPN to my work. I want to access my home zone (myhome.com., with DNS server at 10.71.73.10) and also my work zone (mywork.com., with DNS server at 10.10.1.33).

Using DiG to query hostname.mywork.com, DiG reports the AUTHORITY to be the public nameserver. The local resolver seems to ignore the BIND forwarding zone (db.mywork.com).

In /etc/bind/zones/db.mywork.com
// forwards mywork queries to the mywork DNS servers
zone "mywork.com" {
        type forward;
        forwarders { 10.10.1.33; };
};

bind.conf: include "/etc/bind/named.conf.options"; include "/etc/bind/named.conf.local"; include "/etc/bind/named.conf.default-zones"; include "/etc/bind/rndc.key"; include "/etc/bind/named.conf.logging";

controls {
  inet 127.0.0.1 port 953
  allow { 127.0.0.1; } keys { "rndc-key"; };
};

named.conf.options

acl goodclients {
        10.71.73.0/24;
        localhost;
        localnets;
};

options {
        directory "/var/cache/bind";
        forwarders {
                8.8.8.8;        # Google DNS #1
                8.8.4.4;        # Google DNS #2
        };
        recursion yes;
        allow-query { goodclients; };

        dnssec-enable no;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
        listen-on port 53 { localhost; };
};

and named.conf.local

# Forward zone
zone "myhome.com." {
        type master;
        file "/etc/bind/zones/db.myhome.com";
};

# Reverse zone
zone "73.71.10.in-addr.arpa" IN {
        type master;
        notify no;
        file "/etc/bind/zones/db.10";
};
ndemarco
  • 173
  • 1
  • 10
  • 1
    What you have quoted is configuration (which goes in `named.conf` or a file it references with `include`) but the filename you mention sounds like something I would expect to be a zone file (holding data). I think it would be good if you clarified exactly if/how the `db.mywork.com` file is used, if that is indeed where the configuration for the type forward zone is located. – Håkan Lindqvist May 09 '15 at 23:44
  • Have you considered using `unbound` instead ? it's much lighter and more suitable for cases when only the resolver is needed. – b0fh May 10 '15 at 01:20
  • I chose to stay with `BIND` as the DNS server because it is the common solution. My work requires me to be familiar with common solutions. – ndemarco Dec 29 '15 at 14:31
  • It would be nice if you could show us how you use the **dig** program and what its exact output is. – Tommiie Oct 03 '18 at 08:24
  • @Tommiie Yes, I should have documented this question much better. Hopefully my edits make this content more useful on StackExchange. – ndemarco Mar 04 '20 at 16:06

1 Answers1

1

Edit: I now have a lot more experience with domain name servers and resolvers. The root of this problem is having multiple authoritative name servers for a zone. This means two different name servers claim to be the authoritative source to resolve a DNS query for a particular zone (like 'example.com'). A nameserver claims authority via a SOA (start of authority) record, saying "Come to me for any lookups in the example.com zone."

I had used a public domain name (in this explanation, 'example.com') to refer to publicly available URLs (like www.example.com = 183.34.22.82, which gets redirected and translated to some private address like 192.168.1.2) AND for private URLs (private-server-1.example.com = 192.168.1.1). I had directed two different name servers to have authority over the same domain. The first would be a public DNS (in my case, Cloudflare). The second is my private DNS - the BIND server running on an internal, private URL (private-dns-server-1.example.com). This server would not be accessible to a computer outside my local network (the ubiquitous 192.168.x.x addresses).

This dual SOA works, but kind of. When you're at some public computer, you easily get to www.example.com because your public computer must use the public DNS as the authoritative answer to "What is the IP address of www.example.com?" The public computer can't reach the other authority (private-dns-server-1.example.com). The public computer has no knowledge of names or IP addresses within the private network. When you're at work, on the private network (you have an IP address like 192.168.1.32, and some other ranges also work), your computer will likely get the answer to "IP for www.example.com" from the internal private-dns-server-1.example.com. This will send you directly to 192.168.1.1, instead of sending you to the example public address I used above (183.34.22.82) then redirecting and translating to the private 192.168.1.1 address.

Sounds good, until you consider DNS caching. The DNS resolvers (these are 'clients' in DNS terminology) store prior answers for reuse. This speeds up your browsing, and reduces the load on servers overall. Let's re-run the example above.

While connected to the airport public wifi, you browsed to www.example.com. Your DNS resolver asked Cloudflare, and got back 183.34.22.82. The translation and redirection worked, and you saw your web page.

After returning to the office, you connected to the office wifi. You refreshed your browser, but the DNS query still directed you to 183.34.22.82, which may or may not work the same as if you went directly to 192.168.1.1. In many cases, you'll get the same web page. In some cases, you won't get the same behavior. This is the issue. Troubleshooting something that seems to behave one way at one time and another way at a different time is perhaps the most difficult task.

It's best to avoid multiple authoritative nameservers for a single zone. DNS servers like BIND9 have some clever constructs to solve this problem. An alternative is to pick an internal zone that is separate from your external zone. This doesn't mean you have to be 'example.com' to everyone, and 'awful324.int' inside your organization. You can carve out a zone within 'example.com' like 'int.example.com' as your internal addresses. Whatever you do choose, make sure you own it publicly (i.e. you've registered the domain name 'awful324.com') so nobody else registers it and creates a start of authority (SOA) record for that domain name/zone.

What I wrote a few years ago, while still flopping around with Linux and internet protocols generally:

In this case, I used tail to monitor the log file at /var/log/syslog by using $ tail -f /var/log/syslog. My configuration had multiple issues:

  • I had put my forwarding directive within a zone definition. I moved it to /etc/bind/named.conf.options.
  • As a separate problem, some public DNS queries were not resolving. By monitoring the syslog file, I found the server's time was not synchronized. I configured ntp on the server to resolve this issue.
ndemarco
  • 173
  • 1
  • 10