In our company we have separate /24 subnets from one big class B (/16) address.

(refer to the picture)

I am working in domain1.company.com and from there I am able to resolve all hostnames in the same domain xx.domain1.company.com (an example is server1.doamin1.company.com).

I also can go out to the internet using the DNS server in domain3.company.com as a forwarder.

But when trying to resolve anything in another subdomain (ex: server3.domain2.company.com), it fails.

enter image description here

this is how my named.conf.options looks like.

acl "inner-net" {
    A.B.C.0/24;; //private mgmt network

acl "blocked-from-recursion" {

options {
    directory "/var/cache/bind";
    // recursion yes;
        allow-recursion { inner-net; };
    blackhole { blocked-from-recursion; };
        listen-on { any; };
        allow-transfer { none; };
    allow-query { inner-net; };
        forwarders {
                A.B.E.2; // ip address of the DNS fowarder
                x.x.x.x; //second forwarder
    dnssec-enable yes;
    dnssec-validation yes;

    auth-nxdomain no;    # conform to RFC1035
    // listen-on-v6 { any; };

what can i do to solve this, if i don't have access to other DNS servers in other subnets? (can't change their config)

Edit: adding default zones


// prime the server with knowledge of the root servers
zone "." {
    type hint;
    file "/etc/bind/db.root";

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
    type master;
    file "/etc/bind/db.local";

zone "127.in-addr.arpa" {
    type master;
    file "/etc/bind/db.127";

zone "0.in-addr.arpa" {
    type master;
    file "/etc/bind/db.0";

zone "255.in-addr.arpa" {
    type master;
    file "/etc/bind/db.255";


// Do any local configuration here

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

zone "domain1.company.com" {
    type master;
    file "/etc/bind/zones/db.domain1.company.com";
//    allow-transfer {; };

zone "A.B.C.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.A.B.C";
//    allow-transfer {; };

zone "10.11.200.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.10.11.200";
//    allow-transfer {; };

  • Do you not "have access to other DNS servers" because your company prohibits you from using them and/or firewalls them off to prevent you from accessing them? Or do you just not have access to them because your current DNS configuration is broken? Also, please edit your question to show your list of zonefiles so that we know what zones your BIND server thinks it is authoritative for, either as master or slave. – Jim L. Aug 9 '19 at 19:15
  • Hi @JimL.by not having access i mean i cannot ssh and change configs on their DNS. where can i find the zonefiles ? – Mheni Aug 9 '19 at 19:23
  • found the default zones file. added it at the end of the question. Thx – Mheni Aug 9 '19 at 19:33
  • sorry about that, there is a second zones file that defines the zones. the first one is just the default – Mheni Aug 9 '19 at 19:43
  • Thank you for adding the zone configuration info. So your server is authoritative for domain1.company.com, but not any other sub-domains, correct? – Jim L. Aug 9 '19 at 19:47

For the purposes of discussion, let's call your company's domain example.com which is fictitious, as opposed to company.com which really does exist.

TL;DR Debug DNS problems from the top down, until you find the level at which things break. Edit your post to include some basic dig results, such as:

dig @A.B.E.2 example.com ns
dig @A.B.E.2 domain2.example.com ns
dig @A.B.E.2 server3.domain2.example.com

Without more detail in your question, such as specific dig queries and their detailed results, it's difficult to definitively assess your problem.

If none of the below helps, edit your post to show the results of those commands.

DNS is hierarchical

If you will pardon a bit of review for those readers who are learning about DNS, DNS is essentially a hierarchical database, where top-level nameservers specify information for second-level nameservers, and so on down through what can be several levels of recursion. DNS can also be arranged in a "flat" topology (domains and sub-domains all mixed into the same zonefile), but at least at the highest levels, it is hierarchical.

Let's refer to your company's domain name generically as example.com.

At the top DNS level is the "." zone. This corresponds to your "hint" zone in your config. That hint zone lists several apex-level DNS servers:

.                        3600000      NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A
A.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:ba3e::2:30
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A
B.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:200::b

Each sub-level requires the level above to be correct

These "root-level" nameservers know how to get to any of the levels below that, the next "sub-domains" if you will. They know that "for com addresses, go here. For org addresses, go here." And so on. Since we're referring to example.com in this case, that means the the next level down is the com hierarchy. This same thing often happens at multiple levels as we recursively descend through the DNS hierarchy. If any level gives out invalid information, it is unlikely that any sub-levels below that will function properly. I suspect your company's top-level nameservers might have a configuration error, or perhaps an intentional access restriction between domains, for whatever reason.

Troubleshooting the tree

We can arbitrarily choose one of the ROOT-SERVERS nameservers and ask it where we should send inquiries for .com hostnames, using the stalwart DNS utility dig. Here we use dig to query a nameserver @ and ask for the domain com. what are the ns records -- that is, what are the nameservers for the com domain?

$ dig @ com. ns
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 2252
;; flags: qr rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 12 
;; com. IN      NS


com.    172800  IN      NS      e.gtld-servers.net.
com.    172800  IN      NS      b.gtld-servers.net.
com.    172800  IN      NS      j.gtld-servers.net.
com.    172800  IN      NS      m.gtld-servers.net.
com.    172800  IN      NS      i.gtld-servers.net.
com.    172800  IN      NS      f.gtld-servers.net.
com.    172800  IN      NS      a.gtld-servers.net.
com.    172800  IN      NS      g.gtld-servers.net.
com.    172800  IN      NS      h.gtld-servers.net.
com.    172800  IN      NS      l.gtld-servers.net.
com.    172800  IN      NS      k.gtld-servers.net.
com.    172800  IN      NS      c.gtld-servers.net.
com.    172800  IN      NS      d.gtld-servers.net.

e.gtld-servers.net.     172800  IN      A
e.gtld-servers.net.     172800  IN      AAAA    2001:502:1ca1::30
b.gtld-servers.net.     172800  IN      A
b.gtld-servers.net.     172800  IN      AAAA    2001:503:231d::2:30
j.gtld-servers.net.     172800  IN      A
j.gtld-servers.net.     172800  IN      AAAA    2001:502:7094::30
m.gtld-servers.net.     172800  IN      A
m.gtld-servers.net.     172800  IN      AAAA    2001:501:b1f9::30
i.gtld-servers.net.     172800  IN      A
i.gtld-servers.net.     172800  IN      AAAA    2001:503:39c1::30
f.gtld-servers.net.     172800  IN      A
f.gtld-servers.net.     172800  IN      AAAA    2001:503:d414::30

;; Query time: 23 msec
;; WHEN: Fri Aug  9 12:55:15 2019
;; MSG SIZE  rcvd: 509

That's a fair bit of output, so I'll break it down. The most important line for our immediate purpose is:

;; flags: qr rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 12 

This means the nameserver we queried at received 1 query, returned 0 answers, and 13 authoritative sources. We'll ignore the "additional" entries for now, but they're basically there for convenience and to speed further DNS queries that are likely to ensue.

The fact that we received 0 answers basically means the nameserver is telling us, "I don't know the answer ...", and the 13 authority entries mean, "... but I do know that these nameservers can answer that." This is called a delegated domain. The top-level ROOT-SERVERS don't have direct knowledge of the com domain (other than it exists), but they have specifically delegated authority for com domains to the 13 nameservers that appear in the list. Any one of them can be queried for details about domains in the com heirarchy. Let's do exactly that:

$ dig @ example.com ns
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 38217
;; flags: qr rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; example.com.       IN      NS


example.com.  172800  IN      NS      ns.example.com.
example.com.  172800  IN      NS      ns2.example.com.

ns.example.com.       172800  IN      A
ns2.example.com.      172800  IN      A

;; Query time: 4 msec
;; WHEN: Fri Aug  9 13:05:51 2019
;; MSG SIZE  rcvd: 98

Part of that information is fictionalized for the purpose of illustration. In particular, let's pretend that the 172.16.x.y addresses are real, public IP addresses, which they pretty much have to be for a real .com domain. Again we see the ANSWER: 0 so the nameserver is telling us "I don't have direct knowledge of example.com, but these nameservers do." ns.example.com and ns2.example.com are your company's highest-level domain servers. They may not be resolving servers (and best practice is that they wouldn't be), but they have to be authoritative. That is, they need to either a) have the answer to any DNS query regarding your company's example.com domain; or b) they need to know where to refer a DNS client who seeks any DNS record that is not directly available from them. It seems likely that this is the level at which your problem originates, at your company's top-level nameservers.

As I mentioned earlier, the hierarchical nature of DNS means that a high-level problem can block lower DNS levels from working correctly. Specifically, if it were the case that a configuration error at ns.example.com prevented you from getting information about the sub-domain domain1.example.com, that is one reason why you might be experiencing problems. Another reason could be that the top-level nameserver is giving out correct information, but internal company routing or firewalling policies are intentionally or inadvertently blocking your access.

This might help you figure out whether it's a config error, or a routing/firewall problem:

dig @ example.com ns

That should return something like the fictionalized information above, and tell you what the top-level nameservers are for your company name. Now we'll query them directly, and ask it for information about a sub-domain. Since we're skeptical, we'll ask it a question we already know the answer to. The nameserver for domain1.example.com is your BIND server, correct? Let's see if corporate nameservers agree:

dig @ domain1.example.com ns

Instead of, use the actual IP returned by the previous dig command. Generally, the information you then see should confirm the configuration of your existing BIND server (it's hostname and IP number), since it is authoritative for domain1.example.com.

Broken delegation?

By the same token, the top-level company nameservers should also know the correct nameservers to use for all valid sub-domains in your company. By definition an authoritative nameserver has to know the answer to any query in that domain, or at least be able to refer to another nameserver that knows the answer (or knows someone who knows, etc.). Since domain2.example.com is a specific problem case for you, let's look at that:

dig @ domain2.example.com ns

There are at least a couple cases that could arise here. As the first case, let's suppose that ns.example.com is misconfigured and doesn't know that domain2.example.com exists. You'd see an answer like:

;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 21457
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; domain2.example.com.       IN      NS


example.com.  3600    IN      SOA     ns.example.com. hostmaster.example.com. 201906260 7200 900 2592000 3600


;; Query time: 4 msec
;; WHEN: Fri Aug  9 14:03:16 2019
;; MSG SIZE  rcvd: 89

Again, note: ANSWER: 0; AUTHORITY: 1. "I don't know" but the second part is different. In the "referral" replies above, we were given additional NS records to consult, which means "I don't know, but ask one of them." Here the "authority" entry is the "Start Of Authority" record for the domain itself. In other words, it might mean "there is no one else to ask, because I am the definitive server for example.com." This style of result (answer:0, authority pointing to SOA for the domain) is a definitive "that record does not exist." The string rcode: NXDOMAIN is also diagnostic of a "does not exist" result.

Unreachable nameserver

A second case that could arise would be when the company nameserver does return a value, but you can't reach that host. Suppose you lookup the nameservers for domain2.example.com and get:

$ dig @ domain2.example.com ns
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 3098
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 5
;; domain2.example.com.        IN      NS

domain2.example.com.   3600    IN      NS      ns1.domain2.example.com.
domain2.example.com.   3600    IN      NS      ns2.domain2.example.com.


ns1.domain2.example.com.       3600    IN      A
ns2.domain2.example.com.       3600    IN      A

;; Query time: 0 msec
;; WHEN: Fri Aug  9 14:08:17 2019
;; MSG SIZE  rcvd: 200

That seems promising! Now we know who to ask to resolve hostnames in domain2. But if this happens:

$ dig @ host.domain2.example.com
Error: error sending query: Could not send or receive, because of network error

then you may have a firewall blocking you, or a router that doesn't know how to reach that subnet.

"Lame" nameserver

If a nameserver delegates a subdomain to another nameserver, but that second nameserver is unaware of that delegation (in other words, it isn't specifically configured to respond to queries for that zone), the downstream nameserver is said to be "lame." It ought to respond to queries, but it doesn't know that it should. Or sometimes it can happen the other way, that the downstream nameserver has been retired, but the upstream nameserver is still giving out the wrong referral records. I don't have an easily-crafted example of what that would look like, but given time, you'll experience this. The first nameserver will say, "I don't know, but ask this guy." The second nameserver will say, "How should I know? Why are you asking me?"


Because it is a hierarchical database that is searched recursively, DNS can fail if any one single level fails. The key to troubleshooting the inability to resolve DNS queries is to start at the top and work down until you find the last level that is resolving queries correctly. It is probably at the next level then, the referral records returned by the last known good nameserver, where the problem lies.

DNS queries can fail for a variety of reasons. Some of the most common are because an IP number in the zonefile is wrong; or because an IP is unreachable from your network (whether from a firewall or an unknown route, or any of several types of network faults); or because a low-level nameserver that is referenced by a high-level nameserver isn't correctly configured to answer the query.

  • Good to use RFC2606 for names but you should then as well use rfc5737 for ip addresses and avoid things like @A.B.E.2 and 172.16.x.y – Patrick Mevzek Aug 16 '19 at 16:03
  • dig +trace will show each step of the DNS resolution. See also dig +nssearch. – Patrick Mevzek Aug 16 '19 at 16:04
  • Another important point when troubleshooting DNS: always start by querying authoritative nameservers, and when they are all ok and working as expected then try to query recursive nameservers and check what happens. – Patrick Mevzek Aug 16 '19 at 16:08
  • @PatrickMevzek All good points. And to be clear, my example states that I am intending for 172.16.x.y to represent a public IP. Private IPs for internal nameservers or internal nameservers behind corporate firewalls can also cause problems, Including delegations, if the master AUTH NS are accessible, but a "minor" delegated NS is not. In the last case it can sometimes be better to have the AUTH NS slave the zone from the delegatee instead of actually delegating. That way the AUTH NS is universally accessible AND it has definitive answers, without relying on delegations. – Jim L. Aug 16 '19 at 16:31
  • "that I am intending for 172.16.x.y to represent a public IP" Then it is particularly important to switch to RFC5737 IP addresses instead, as block is clearly put aside for private needs, see RFC1918. (And I am not able to parse the rest of your comment and what it means) – Patrick Mevzek Aug 16 '19 at 16:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.