Member Avatar for dddexter

Hello everybody,

I'm trying to configure a couple of OpenBSD servers in a local network which is connected to the internet via an extrernal gateway (which is not part of my network). All servers should belong to an internal zone "domain.swi". I set up BIND 9.4.2 master and slave servers on machines A and B for the domain and set them as nameservers on every computer in the network. Up to now, everything works perfect, I was able to resolve all hostnames.

Now I'm trying to set up a forwarding nameserver on machine D which would forward all requests concerning the internal "domain.swi" to the nameservers on machines A and B and all other request to a nameserver running on external gateway which connects the network to the internet. I want to all servers in the network to use this forwarding nameserver. The problem is that after I start it I can resolve both internal and external hostnames on the machine D where it's running, but when I try to use it as a nameserver for machine A, I can't resolve any hostname either inside or outside the network. Log on machine D indicates that named daemon denies all requests made by machine A, even though I've set allow-query option to any.

This is how configuration files look like,
machine A (master nameserver) has address
machine B (slave nameserver) has address
machine D (forwarding nameserver) has address
external gateway (external nameserver) to the internet has address 192.168.56.2:

named.conf file on machine D ( i tried to put A and B to forwarders list in options as well, but it didn't help):

...

options {
...

   allow-query { any; };

   forward only;
   forwarders { 192.168.56.2; };
};

...

zone "swi" {
   type forward;
   forwarders { 192.168.56.67; 192.168.26.32; };
};

internal request on machine D:

ping a.domain.swi
PING a.domain.swi (192.168.56.67): 56 data bytes
...

external request on machine D:

ping www.google.com
PING www.l.google.com (74.125.87.103): 56 data bytes
...

internal request on machine A:

ping d.domain.swi
ping: unknown host: d.domain.swi

external request on machine A:

ping www.google.com
ping: unknown host: www.google.com

/var/log/daemon file on machine D:

d named[15789]: client 192.168.56.67#43919: query (cache) 'd.domain.swi/A/IN' denied
d named[15789]: client 192.168.56.67#32746: query (cache) 'www.google.com/A/IN' denied

I'm not sure about forwarding configuration in named.conf, but I can't see why should be queries denied. I would appreciate any help, comments or hints very much! Thanks!

  • 2 Contributors
  • 3 Replies
  • 961 Views
  • 17 Hours Discussion Span
  • Latest Post Latest Post by sknake

Dani AI

Generated

Short summary and recommended fix (follow-up to and )

The kernel of the problem is the log messages showing DNS answers from the cache being refused — that means named is blocking recursion/cached responses for that client, not authoritative answers. BIND treats access to cached/recursive answers separately from ordinary zone queries; since BIND 9.4.1 the default for recursion/cache access is restricted to localhost and localnets, so an explicit allow for your internal nets is needed to let machine A use D as a forwarder. (kb.isc.org)

Practical, safe configuration approach

Create an ACL for your internal networks and restrict recursion to it (do not use any on an Internet-facing box). Keep recursion enabled only for trusted hosts and leave allow-query permissive for authoritative queries if you must. Example pattern (adapt addresses to your setup):

acl "internal" {
  192.168.56.0/24;
  192.168.26.0/24;
  localhost;
  localnets;
};

options {
  recursion yes;
  allow-recursion { internal; };
  listen-on { any; };
}

Opening recursion to everyone exposes the server to DNS amplification abuse — use an ACL instead. (kb.isc.org)

Troubleshooting checklist

  1. From A, test directly with dig pointing at D (e.g. dig @<D-ip> d.domain.swi A) to reproduce.
  2. On D, confirm named is listening on the expected interfaces (netstat -na | grep :53) and check listen-on settings.
  3. Verify host firewall/pf allows UDP/TCP 53 from the internal nets. Use tcpdump -n -i any port 53 while testing to see packets.
  4. If you still see denied messages, the logs and the ACL names (newer BIND prints them) will show which access list blocked the request. (bind9.readthedocs.io)

This explains why 's advice to allow recursion for the internal network fixed the problem, and why allow-query { any; } alone did not.

Recommended Answers

All 3 Replies

Member Avatar for sknake

You probably need to specify the allowed hosts for recursion.

allow-recursion { 192.168.56.0/24; }

You should be able to do this globally in the bind configuration, or you can set it per specific zone.

Member Avatar for dddexter

Thanks Kevin, you're right of course.

Member Avatar for sknake

Thanks Kevin, you're right of course.

Who is Kevin?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.