Checking the validity of Resource Records in DNS Zones

Question

I am using perl to do some DNS manipulation tasks.

I am using NSD as my DNS server.

I want to figure out what the best way is to check whether the names of all Resource Records in a DNS zone file are valid.

There seem to be a couple of possibilities (that I can think of) to do the checking:

1. nsd-checkzone
2. An already made Perl module https://metacpan.org/pod/Data::Validate::Domain
3. Do the checking manually in perl by knowing all the RFCs describing what is a valid name and what is not.

The main problem, in my opinion, arises when special names of Resource Records come into question.

For example: I have seen online that there is a possibility to use a * as a name of a Resource Record:

*                IN A      192.168.150.144

This supposedly means return this record if no other record matches.

I have also seen some "special" names of Resource Records (in reverse DNS zones) like in this RFC:

   192/26          NS      ns.C.domain.
   192/26          NS      some.other.third.name.server.
   0/25            NS      ns.A.domain.
   0/25            NS      some.other.name.server.

I also have an additional question:

• Where can I see all these special names of Resource Records allowed in Forward and Reverse DNS zones and their meaning? (because I want to know them all :) )

Answer 1

IMHO zone files are a PITA to manipulate as text files...

For starters:

each RR should look like name ttl record_class record_type record_data BUT :

• name can be omitted, and then the record inherits the field from the previous record.
• ttl can be omitted and will become the value of $TTL
• record_class is often also omitted because hardly anyone uses anything but the default IN

And that is only the start of your problems.

---

Especially if your zones were maintained by hand it can be difficult to distinguish shorthand from typo's and really crafty tricks of the trade, which can make entries (even more) context dependant. Your parsing difficulties can be aggravated even more when for instance $-directives come into play.

Then there is of course also the difference between a zone file with a valid syntax as confirmed with the nsd-checkzone or named-checkzone and resource records that are semantically valid and work as intended.

A fairly typical example is a CNAME record in the example.com zone

www IN CNAME www.example.net

which is valid, but since there is no trailing dot on www.example.net that is not a FQDN and zone file shorthand. The value of $ORIGIN will be appended and by default that becomes:

www IN CNAME www.example.net.example.com.

That is not always the case though.
Rather than using an implicit value of $ORIGIN, or following convention and explicitly setting $ORIGIN to the name of the zone, people sometimes explicitly define $ORIGIN to only a . dot.

Again the example of a CNAME record in the example.com zone

$ORIGIN .

www IN CNAME www.example.net

Then when value of $ORIGIN will be appended that becomes:

www IN CNAME www.example.net.

This Q&A is an example of where the location of the MX record resulted in valid syntax but broken e-mail.

This answer of mine is an example of a bad idea, but valid syntax where the context of a Resource Record depends on the exact position within a zone file and the effect of shorthand will change due to repeated use/abuse of the $ORIGIN $-directive.