Local DNS seems OK, but not working - configuration issue?

Rocky Linux General
1

Hi all. I run RL9 and have a local DNS server in my LAN. I am preparing a new server (“server.hartings.se”) to replace an 8 year old machine. I tried to follow the guidance on BIND given in the RockLinux on-line documentation. Sorry for a lengthy post, but I want to make sure, you hopefully get att required info on my set-up.

My domain is “hartings.se” (158.174.119.71) and the new local DNS server is called “server.hartings.se” (192.168.1.221). There are several machines connected to the LAN. The firewall is opened and active for DNS services and connected to the NCs
I tested the named setup with named-checkconf and named-checkzone (db and rev files) and both say all is OK. Systemctl status named also says all is up and running and OK.

[root@server ~]# systemctl status named
● named.service - Berkeley Internet Name Domain (DNS)
     Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor preset: disabled)
     Active: active (running) since Sun 2022-10-09 14:16:03 CEST; 43min ago
    Process: 175395 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z "$NAMEDCONF"; e>
    Process: 175398 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS (code=exited, status=0/SUCCESS)
   Main PID: 175400 (named)
      Tasks: 38 (limit: 98144)
     Memory: 93.2M
        CPU: 126ms
     CGroup: /system.slice/named.service
             └─175400 /usr/sbin/named -u named -c /etc/named.conf -4

Oct 09 14:16:03 server.hartings.se named[175400]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded >
Oct 09 14:16:03 server.hartings.se named[175400]: zone localhost/IN: loaded serial 0
Oct 09 14:16:03 server.hartings.se named[175400]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
Oct 09 14:16:03 server.hartings.se named[175400]: zone hartings.se/IN: loaded serial 2019061800
Oct 09 14:16:03 server.hartings.se named[175400]: zone localhost.localdomain/IN: loaded serial 0
Oct 09 14:16:03 server.hartings.se named[175400]: all zones loaded
Oct 09 14:16:03 server.hartings.se named[175400]: running
Oct 09 14:16:03 server.hartings.se systemd[1]: Started Berkeley Internet Name Domain (DNS).
Oct 09 14:16:03 server.hartings.se named[175400]: managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)
Oct 09 14:16:03 server.hartings.se named[175400]: resolver priming query complete
[root@server ~]#

In order to fully test the setup, I stopped the presently active old local DNS server. When running nslookup, it finds instead the router (192.168.1.254), not the new local DNS server :

[root@server ~]# nslookup hartings.se
Server:		192.168.1.254
Address:	192.168.1.254#53

Non-authoritative answer:
Name:	hartings.se
Address: 158.174.119.71

[root@server ~]#

When i remove the LAN cable from the new DNS server, I would certainly expect the new DNS server to reply (only machine available), being 127.0.0.1 or 192.168.1.221. But instead is doesn’t find any DNS server, though the only available machine is now the new DNS server (command given on new DNS server):

[root@server ~]# nslookup hartings.se
;; connection timed out; no servers could be reached

[root@server ~]#

When I go the the old (and for now again active!) DNS server (“server1”) and run nslookup, I get:

[root@server1 named]# nslookup hartings.se
Server:		213.80.98.2
Address:	213.80.98.2#53

Non-authoritative answer:
Name:	hartings.se
Address: 158.174.119.71

[root@server1 named]#

Funny, it now shows my ISP DNS server as the answering DNS server. Why doesn’t my new server see this one? But of course, I want the new server (“server”) to be acting local DNS server!

My named-settings on the new server (“server”) are pretty simple and clean, se below.

[root@server ~]# more /var/named/hartings.se.db
$TTL 86400
@ IN SOA server.hartings.se. ralf.hartings.se. (
    2019061800 ;Serial
    3600 ;Refresh
    1800 ;Retry
    604800 ;Expire
    86400 ;Minimum TTL
)

;Name Server Information
@ IN NS server.hartings.se.
;IP for Name Server.
server IN A 192.168.1.221

;A Record for IP address to Hostname 
ralf IN A 192.168.1.109
elly IN A 192.168.1.95
mediaserver     IN A 192.168.1.151
backupserver 	IN A 192.168.1.93

[root@server ~]#
[root@server ~]# more /var/named/hartings.se.rev
$TTL 86400
@ IN SOA server.hartings.se. ralf.hartings.se. (
    2019061800 ;Serial
    3600 ;Refresh
    1800 ;Retry
    604800 ;Expire
    86400 ;Minimum TTL
)
;Name Server Information
@ IN NS server.hartings.se.

;Reverse lookup for Name Server
221 IN PTR server.hartings.se.

;PTR Record IP address to HostName
93 IN PTR backupserver.hartings.se.
95 IN PTR elly.hartings.se.
109 IN PTR ralf.hartings.se.
151 IN PTR mediaserver.hartings.se.
[root@server ~]#

My named.conf file looks like this (just to give you all required info) on the new server (“server”):

[root@server ~]# more /etc/named.conf
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

options {
	listen-on port 53 { 127.0.0.1; };
#	listen-on-v6 port 53 { ::1; };
	directory 	"/var/named";
	dump-file 	"/var/named/data/cache_dump.db";
	statistics-file "/var/named/data/named_stats.txt";
	memstatistics-file "/var/named/data/named_mem_stats.txt";
	secroots-file	"/var/named/data/named.secroots";
	recursing-file	"/var/named/data/named.recursing";
	allow-query     { localhost; 192.168.1.0/24; };
#       filter-aaaa-on-v4 yes;

	/* 
	 - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
	 - If you are building a RECURSIVE (caching) DNS server, you need to enable 
	   recursion. 
	 - If your recursive DNS server has a public IP address, you MUST enable access 
	   control to limit queries to your legitimate users. Failing to do so will
	   cause your server to become part of large scale DNS amplification 
	   attacks. Implementing BCP38 within your network would greatly
	   reduce such attack surface 
	*/
	recursion yes;

#	dnssec-validation yes;

	managed-keys-directory "/var/named/dynamic";
	geoip-directory "/usr/share/GeoIP";

	pid-file "/run/named/named.pid";
	session-keyfile "/run/named/session.key";

	/* https://fedoraproject.org/wiki/Changes/CryptoPolicy */
	include "/etc/crypto-policies/back-ends/bind.config";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
	type hint;
	file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

# primary forwward and reverse zones
//forward zone
zone "hartings.se" IN {
     type master;
     file "hartings.se.db";
     allow-update { none; };
    allow-query {any; };
};
//reverse zone
zone "1.168.192.in-addr.arpa" IN {
     type master;
     file "hartings.se.rev";
     allow-update { none; };
    allow-query { any; };
};
[root@server ~]#

I note that the referred file /var/named/data/named.recursing in /etc/named.conf does not exist. Is this a problem?

Any ideas on why the new local DNS server is not working? I have tried several variants for the xxx.db and xxx.rev files, but I cannot get it to work. Any help is appreciated!

2

First, I have not used BIND since I found that dnsmasq is simpler, yet sufficient (for my needs).

You have LAN (192.168.1.0/24?) and then there is “outside”. If the intention of “local DNS” is that members of LAN can resolve names from it, then we should not care about the outside (at first).

When I’m in a client and run any command that has to resolve a name to IP (or IP to name), it will look from network configuration list of DNS servers and domain/search-string. On Linux those are in /etc/resolv.conf.

Your old DNS server (server1) seems to have servername 213.80.98.2 in there, while the new one (server) has servername 192.168.1.254 – the address of the router, which it probably got as part of network config from DHCP server, which I presume to be the router. Consumer routers tend to offer DHCP service and DNS service.

NetworkManager connection can be set to use DHCP, but ignore the DNS servername that DHCP offers and use one or more statically set servers. (See man nmcli and man nm-settings.)

I believe that commands, like nslookup, host, and dig will ignore the /etc/resolv.conf – at least if they are given address of DNS server as additional parameter.

The point is that if router is the DHCP server and if you don’t set it to send 192.168.1.221 as (one of) the DNS server or do not have 192.168.1.221 and/or IP-of_server1 manually configured in the clients (which is less recommended, since DHCP is really convenient) , then nobody will use those DNS servers.

Logically, if the clients connect to local DNS for all queries, then the local DNS has to somehow resolve the “outside” names too. For that the DNS server has to have config - “whom to ask from, if name is not in LAN”.

3

Thanks jlethone!

Some very valid comments and thoughts indeed! As the IP on my new (test)server is provided by DHCP, it would just take whatever the DHCP server supplies. Very likely.
So I changed the settings of the IP into manual settings with same IP number (102.168.1.221) and the address of the router as gateway. I did not gave an DNS address, but to search the domain “hartings.se”

FYI:

[root@server named]# more /etc/resolv.conf
# Generated by NetworkManager
search hartings.se
[root@server named]#

which is good, but is perhaps not used as you say?

So with the manual IP settings on the new “server” I now get:

[root@server named]# nslookup hartings.se
Server:		127.0.0.1
Address:	127.0.0.1#53

Name:	hartings.se
Address: 192.168.1.221

[root@server named]#

which is correct! So named is working as it should on the new server!
The old active DNS server still provides the same output: it points to the outside world, when named is not running in this machine:

[root@server1 data]# nslookup hartings.se
Server:		213.80.98.2
Address:	213.80.98.2#53

Non-authoritative answer:
Name:	hartings.se
Address: 158.174.119.71

[root@server1 data]#

Why is this server not pointing to the new local DNS server?. I checked /etc/resolv.conf:

[root@server1 data]# more /etc/resolv.conf
# Generated by NetworkManager
search hartings.se
nameserver 192.168.1.94
nameserver 213.80.98.2
nameserver 213.80.101.3
[root@server1 data]#

so this is pointing to the outside world, as 192.168.1.94 is not active (named not running on this machine just now).
If I would change the network settings, to get the lines with nameserver in the file /etc/resolv.conf removed and leave search in hartings.se there, it should find the new local DNS server? Is that correct?
I should probably use the settings from the old DNS server (as shown in /etc/resolv.conf) in the new one (and change 192.168.1.94 to 192.168.1.221), for instance using nmcli ? Correct?
Need to go now, but will test tomorrow!

Any other comments/thoughts?

Many thanks for putting me on the right track!

4

The search line on it’s own in /etc/resolv.conf normally wouldn’t be enough. The system though seemed to be OK finding DNS locally on 127.0.0.1/localhost probably because of this either being provided by resolvconf. The search line is used, so you can do something like:

ping www

which would then expand that as if you had written:

ping www.hartings.se

effectively if you don’t provide a full FQDN, whatever you put will expand to search under hartings.se. And it will either resolve or not resolve, depending on whether a DNS entry exists for it.

The reason why your external DNS didn’t resolve to your internal one is most likely because you need to configure your nameservers wherever you purchased and manage your domain to use the public IP that resolves to the server you are running internally. Also, you will need to ensure that your server runs as a split DNS server - this means that when you resolve queries on the internal IP it will reply with internal IP’s for your internal DNS entries. For DNS queries that come externally, it replies with external IP addresses. Effectively two zones, one for internal, one for external. Obviously if your external queries resolved to internal IP’s that is useless, since traffic will not be possible as they are non-routable across the internet.

A normal /etc/resolv.conf would have something like this:

search hastings.se
nameserver x.x.x.x

where x.x.x.x is the IP of your DNS server. If resolvconf is resolving your DNS then the resolv.conf would list localhost normally, and then in the resolvconf configuration you should find the IP of your DNS server configured.

5

Pretty simple: It most likely DOES work, but it listens only on localhost. If you want to have it accessible from your LAN, then you need ti change the listen-on statement in your /etc/named.conf
Either add explicit listen address(es) in order to listen on specific addresses or remove the whole brace part in order to listen on ANY interface.

As an example, here is the listen-on statement from my local server:

        listen-on {
                127.0.0.1;
                192.168.2.17;
                192.168.97.1;
                192.168.98.1;
                192.168.99.1;
                192.168.100.1;
                192.168.102.1;
        };

Oh and BTW:
For testing you don’t need to tweak any resolv.conf setup. Instead just tell nslokup which server to use on the cmdline (the second argument):

e.g. to ask google’s DNS directly without consulting resolv setup:

nslookup harting.se 8.8.8.8

6

Great comment felfert!
So I could/should add 192.168.1.0/24 to allow all units on this subnet? Does that work?

Thanks!

7

Thanks @iwalker for your valid input!

Yes, this works indeed! it expands automatically to the complete address!

My DNS server on the LAN is not directly exposed to the internet, only through the router with a locked (non-forwarded) port 53.

I had also put the ISP (internet) DNS addresses in the list of DNS servers, because, I thought, that in case my local DNS server cannot resolve outside/internet addresses, it should know which DNS servers do provide that info. Isn’t this required?

8

No, in your case, the correct entry would be:

listen-on { 127.0.0.1; 192.168.1.221; };

In other words: The IP of interface you want it to listen on.

BTW: There’s an online configuration reference here:
https://bind9.readthedocs.io/
Just make shure, you select the correct version in the combobox on the left.

9

If you are not going to allow your internal DNS server to accept queries from the internet, then you do not need to put your ISP public IP on the list of DNS servers. Since now, you’ll have a slight performance hit, because it will try to query that nameserver that doesn’t have the ports open, before it falls to the next one on the list.

Secondly, if it is going to respond to queries, it has to have two zones like I mentioned one for internal queries and one for external queries. Because there is no point resolving to an internal IP from the external zone. So if you have no intention of doing that, then there is no need to include your ISP IP on the list of nameservers.

You can maintain your own internal DNS server to utilise locally, and keep it separate from the two servers you use when external for resolving DNS. This means though that you need to maintain entries twice by adding on your internal server, and then creating on the external servers as well which you were doing anyway up until running your internal server. That way you don’t have to worry about internal/external zones, and also you do not need to open up firewall access to your internal server.

It would be good to read all about Bind DNS from the link that was posted by @felfert since you need to understand what you are wanting to achieve, and how to do it correctly without causing yourself more problems in the long run.

10

That is “boring”. I’d rather … see the output of nmcli -f ipv4 con show NAME_OF_CONNECTION
I’d have there:

ipv4.method:                            auto
ipv4.dns:                               127.0.0.1, 213.80.98.2
ipv4.dns-search:                        harting.se
ipv4.addresses:                         --
ipv4.gateway:                           --
ipv4.ignore-auto-dns:                   yes

That means that programs (other than BIND) that run on this machine will ask from BIND in this machine (127.0.0.1) and if it does not answer, they query 213.80.98.2.
Furthermore, the DNS offered by the router is ignored.

On other machines you would have

ipv4.dns 192.168.1.221, 213.80.98.2

and preferably not as static config, but set by DHCP (if you can change the router’s DHCP to give out such info).

1 Like
11

Many thanks @felfert !
Good comments and I will follow your recommendation regarding the documentation link for bind!

12

Thanks again @jlehtone!
That was exactly what I was looking for!
Problem solved!