Join Log in
Score:0
Liam Chaney avatar Server

DNS Zone File returns Error about my A records. Bind9 Ubuntu 22.04

cv flag
Liam Chaney

I am trying to setup a guest ubuntu 22.04 DNS/DHCP server on a ProxMox Host. My error message when running

I have my domain registered via cloudfare ("Not shown in the file", and the domain can return a positive dig result when cloudfare is one of my nameservers") So this is supposed to be a local domain, until I can configure my internet facing router (weird situation).

sudo named-checkzone example.local /etc/bind/db.example.local

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

My forward zone file is:

;
; BIND data file for local loopback interface
;
$TTL    604800
@   IN  SOA ns.example.local. root.example.local. (
                  7     ; Serial
             604800     ; Refresh
              86400     ; Retry
            2419200     ; Expire
             604800 )   ; Negative Cache TTL
;Name Server Information
@   IN  NS  ns.example.local.
ns.example.local    IN  A   192.168.4.100
clientlongname.example.local    IN  A   192.168.4.97
client2.example.local   IN  A   192.168.4.98
client3.example.local   IN  A   192.168.4.99
client4.example.local   IN  A   192.168.4.96

My reverse lookup zone file returns a positive return when using named-checkzone on it.

In case it is needed below is my named.conf.local file

//
// 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 "example.local" IN {
    type master;
    file "/etc/bind/db.example.local";
    allow-update { none; };
};
zone "4.168.192.in-addr.arpa" IN {
    type master;
    file "/etc/bind/db.r.example.local";
    allow-update { none; };
};

I've tried taking out the @ before my NS record, I've added the FQDN to the client's hostnames. Not sure what else I could try, these dang records "Seem" pretty straight forward.

Any Suggestions would be helpful.

Thank you.

62
1 + 0
Score:5
Nikita Kipriyanov avatar Server
za flag
Nikita Kipriyanov

Yes, there's a mistake. The record you you are thinking of,

ns.example.local    IN  A   192.168.4.100

is interpreted as ns.example.local.example.local instead. To fix, either add the dot, making the identifier fully qualified:

ns.example.local.    IN  A   192.168.4.100
clientlongname.example.local.    IN  A   192.168.4.97
client2.example.local.   IN  A   192.168.4.98
client3.example.local.   IN  A   192.168.4.99
client4.example.local.   IN  A   192.168.4.96

or remove suffix, leveraging the set origin:

ns    IN  A   192.168.4.100
clientlongname    IN  A   192.168.4.97
client2   IN  A   192.168.4.98
client3   IN  A   192.168.4.99
client4   IN  A   192.168.4.96

or, fix all the record simultaneously by setting the origin to DNS root at the beginning of the zone or at least, before first non-qualified record:

$ORIGIN .

I prefer to remove extra suffices and usually choose second way: to leverage the origin.

In DNS there is a distinction between records written with dot at the end, which are considered fully qualified identifiers, and those where there is no dot at the end.

Fully qualified are read and interpreted immediately as is. For example, a dot alone . (the DNS root), and example.com..

Non-qualified identifiers are resolved with respect to current origin. At the start of zone origin is set to the zone name in BIND, in your case, example.local for the first zone and 4.168.192.in-addr.arpa for a second zone. Then, when each record is parsed, if there are non-qualified names, origin is appended. This happens both with record names (as it was with your case with ns.example.local) and with record data, for example, with target names inside CNAME, PTR, SOA, NS, MX, SRV and other records. For example, if you don't change the origin before SOA, the record

@ IN SOA ns root 7 604800 86400 2419200 604800

will be interpreted exactly the same as current SOA record in your zone — both ns and root will have the origin appended. This is also the reason why almost always PTR records in reverse zones are spelled with the dot at the end — we don't normally want them to be interpreted into names like foo.bar.x.y.z.in-addr.arpa., but to foo.bar.. You can change the origin anytime within the zone file, and new value will be used for all subsequent records, until changed again.

+ 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.