0

I am currently trying to build my own home lab for the first time, and as a newbie it’s been a bit confusing. For the past few days, I have been working on configuring an internal DNS server, and after setting it up I run the following tests:

First I try to check if my DNS will resolve, and direct me to the IP address of my web server (as root):

nslookup www.wallynet.local

Output:

Server: 192.168.1.3
Address: 192.168.1.3#53

Name: www.wallynet.local
Address: 192.168.1.2

Next, I tried to see if my DNS will resolve in reverse, and also direct me to my web server (as root):

nslookup -x www.wallynet.local

Output:

*** Invalid option: x
Server: 192.168.1.3
Address: 192.168.1.3#53

Name: www.wallynet.local
Address: 192.168.1.2

I am getting the right IP addresses as far as I know.

However, according to a source I have been following as I am setting up my DNS, I should check my zone files by running the following zone check command on my forward zone file (which I get the result I should), as root:

named-checkzone wallynet.local /var/named/fwd.wallynet.local

Output:

zone wallynet.local/IN: loaded serial 2011071001
OK

However if I run the same command for my reverse zone file (which I get errors):

named-checkzone wallynet.local /var/named/reverse.wallynet.local

Output:

zone wallynet.local/IN: NS 'primary.wallynet.local' has no address records (A or AAAA)
zone wallynet.local/IN: not loaded due to errors.

This is my reverse zone file as it currently stands (please disregard the many commented out lines. I just pasted it from the source I am referring to for this task):

$TTL 86400
@ IN SOA primary.wallynet.local. root.wallynet.local. (
             2011071001  ;Serial
             3600        ;Refresh
             1800        ;Retry
             604800      ;Expire
             86400       ;Minimum TTL
)

;NAME SERVER INFORMATION
@ IN NS primary.wallynet.local.

;RECORD IP ADDRESS TO HOSTNAME
3 IN PTR primary.wallynet.local.

;WHAT IS BELOW IS COMMENTED OUT FOR NOW (CAME FROM A RESOURCE ONLINE)
;@ IN NS masterdns.unixmen.local.
;@ IN NS secondarydns.unixmen.local.
;@ IN A 192.168.1.101
;@ IN A 192.168.1.102
;@ IN A 192.168.1.103
;masterdns IN A 192.168.1.101
;secondarydns IN A 192.168.1.102
;client IN A 192.168.1.103

Why am I not getting an error for this command if supposedly my nslookup command is giving me the right results?

Update: this is my current forward file:

$TTL 86400
@      IN  SOA     primary.wallynet.local. root.wallynet.local. (
        2011071001  ;Serial
        3600        ;Refresh
        1800        ;Retry
        604800      ;Expire
        86400       ;Minimum TTL
)

;NAME SERVER INFORMATION
@       IN  NS          primary.wallynet.local.

;RECORD HOSTNAME TO IP ADDRESS
primary     IN  A  192.168.1.3
@       IN A    192.168.1.3

;WHAT IS BELOW IS COMMENTED OUT FOR NOW (CAME FROM A RESOURCE ONLINE)
;@       IN  NS          masterdns.unixmen.local.
;@       IN  NS          secondarydns.unixmen.local.
;@       IN  A           192.168.1.101
;@       IN  A           192.168.1.102
;@       IN  A           192.168.1.103
;masterdns       IN  A   192.168.1.101
;secondarydns    IN  A   192.168.1.102
;client          IN  A   192.168.1.103


;HERE I AM DEFINING A CNAME
www     IN A    192.168.1.2

Update: this is my zone configurations in my named.conf that i have added:

zone "wallynet.local" IN {
        type master;
        file "/var/named/fwd.wallynet.local";
        allow-update { none; };
};

zone "1.168.192.in-addr.arpa" IN {
        type master;
        file "/var/named/reverse.wallynet.local";
        allow-update { none; };
};
  • Can you please also show the "forward" zone, and also show how both "forward" and "reverse" zones are configured in the DNS server (e.g. the part of the BIND config that defines a zone)? Also, don't you see your second `nslookup -x` invocation throws an error `*** Invalid option: x`, and it interprets its only argument exactly in the same way as first one, so you have exactly same result as in the first invocation; this is *not* an attempt to do a reverse lookup! – Nikita Kipriyanov Jul 21 '23 at 08:47
  • Welcome to Server Fault! Please use copy-paste when posting console output / settings. Format that text as "`code`" using [Markdown](https://serverfault.com/editing-help) and/or the formatting options in the edit menu to properly type-set your posts and maintain original line-breaks and (meaningful) spaces. That improves readability and attracts better answers. – HBruijn Jul 21 '23 at 10:17

2 Answers2

2

It doesn't know what is primary.wallynet.local. Probably, the forward zone doesn't contain such name at all? Unfortunately, we never saw your forward zone so can't check. I am only convinced there exists www A 192.168.1.2 record. Also, it seems the primary zone name server is set to some other name; else it wouldn't load too. Or, maybe, the DNS resolution on the DNS server machine itself is crippled. We don't know either.

Update

It turned out all your "reverse" checks are wrong. nslookup -x shows nothing new because it doesn't know what is "x", so it is not indication that it is "giving you the right results"; named-checkzone was second time invoked with wrong zone name. Please, do as I asked in the comment: don't (only) show your interpretation, but raw evidence — zones and configuration snippets!

P.S.

By the way, avoid using there networks in the production: 192.168.0.0/24, 192.168.1.0/24, 192.168.88.0/24, because these serve as a defaults in many devices (last one in Mikrotik's); you'll thank me later when you start building VPNs. Get a habit to change them from the very beginning, and the lab is the perfect opportunity to get this habit.

Nikita Kipriyanov
  • 10,947
  • 2
  • 24
  • 45
  • Thank you for your response. I added my zone file to the question, if that helps. – DiamondFeather Jul 21 '23 at 14:26
  • Then it's correct. Try `nslookup 192.168.1.3` for the reverse lookup, and `named-checkzone 1.168.192.in-addr.arpa /var/named/reverse.wallynet.local`, as suggested by @HBruijn. It seems you ran the wrong command. – Nikita Kipriyanov Jul 21 '23 at 16:36
  • Command: ```nslookup 192.168.1.3 ``` Response:```** server can't find 3.1.168.192.in-addr.arpa.: NXDOMAIN ``` – DiamondFeather Jul 21 '23 at 16:55
  • Command: ```named-checkzone 1.168.192.in-addr.arpa /var/named/reverse.wallynet.local ``` Response: ```zone 1.168.192.in-addr.arpa/IN: loaded serial 2011071001 OK ``` – DiamondFeather Jul 21 '23 at 16:59
  • I think "master" and "primary" are synonyms in this context; consult your version's manual for that. And, this is unreadable; update question instead of putting such things in comments. Finally, show how is the DNS resolution on both server and other machine set up. – Nikita Kipriyanov Jul 22 '23 at 05:00
  • I added my zone file to the question (sorry i'm still kind of new to these forums). Also i'm not sure what you mean by "show how is the DNS resolution on both server and other machine setup" do you mean see the output of nslookup on different machines, or contents of my resolv.conf? – DiamondFeather Jul 22 '23 at 14:10
  • No, I wanted to understand how it's configured: which DNS servers, suffix, search domain, and so on. This is what nslookup uses to know who to ask to resolve. – Nikita Kipriyanov Jul 22 '23 at 16:55
2

For starters: there is a line-break missing:

 $TTL 86400 @ IN SOA primary.wallynet.local. root.wallynet.local. (
         2011071001  ;Serial

should be:

 $TTL 86400 
 @ IN SOA primary.wallynet.local. root.wallynet.local. (
         2011071001  ;Serial

Second: reverse DNS records and zones are created for IP-addresses (and not for domain names) and use IN-ADDR.ARPA
For the 192.168.1.0/24 range your named.conf zone definition entry would look like:

zone "1.168.192.in-addr.arpa" {
  type primary;
  file "/var/named/reverse.wallynet.local";
  };

and the correct command-line to validate the syntax of your reverse zone would be:

 named-checkzone 1.168.192.in-addr.arpa /var/named/reverse.wallynet.local

Your command nslookup -x www.wallynet.local generates an error because -x is AFAIK simply not a valid option.

You may be confused with the other/better DNS testing tool dig which uses the -x option for reverse lookups. But reverse lookups are done on IP-addresses, not hostnames so you'd use:

 dig -x 192.168.1.102 

which is also the case with nslookup:

 nslookup 192.168.1.102 
HBruijn
  • 77,029
  • 24
  • 135
  • 201
  • 1
    The missing line break is the artifact of how the OP created the question. I fixed most of it (it was all on a single line and that was clearly the wrong formatting in the SF; see the revision history). About the `named-checkzone` use with a reverse zone, however, is a good catch! – Nikita Kipriyanov Jul 21 '23 at 10:06
  • Thank you for your response, however I tried adding type "primary", however when i tried restarting the named service I get an error, and journalctl -xe gives me this as the reason: ```Jul 21 22:03:56 wallynet-dns bash[1251]: /etc/named.conf:67: 'primary' unexpected ``` – DiamondFeather Jul 22 '23 at 02:06