Understanding DNS: Anatomy of a BIND zone file

&gt; <i>If you don&#x27;t update the zone file serial, your changes to the zone will not be picked up by DNS resolvers that have previously cached records from your zone!</i><p>This is incorrect. The serial number affects whether <i>slave servers</i> (in this case probably ns2.example.tld) will pick up changes. Resolvers do not see or care about the zone serial.<p>&gt; <i>This used to be a YYMMDDnn format in days gone by—but that format is no longer required, or in some cases even supported.</i><p>A serial number has <i>always</i> been an increasing integer with no technical meaning assigned. But it is <i>still</i> recommended that anyone editing zone files by hand to use the YYYYMMDDXX format; it has <i>not</i> been deprecated, nor is it unsupported by anyone.

&gt; <i>if your IP address changes and your DNS needs to change along with it, a five-minute TTL is a very, very fine thing to have.</i><p>This is discouraged by both RFC 1912 and RIPE-203 (relevant for Europeans). Use a TTL of at least a few days (or more) if you know that you won’t be changing a DNS record anytime soon. It’s fine to have, say, an hour’s TTL for records you might want to change with little or no warning, and even five minutes is OK as a preparation for a specific scheduled change. But please don’t use a five minute TTL for all your DNS records as a matter of course!

Sigh, it isn&#x27;t a BIND zone file, it&#x27;s a standard RFC 1035 zone file <a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc1035#section-5" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc1035#section-5</a> If you want to tie it to a particular piece of software then JEEVES would be more accurate :-) <a href="https:&#x2F;&#x2F;www.icann.org&#x2F;en&#x2F;system&#x2F;files&#x2F;files&#x2F;rssac-023-17jun20-en.pdf" rel="nofollow">https:&#x2F;&#x2F;www.icann.org&#x2F;en&#x2F;system&#x2F;files&#x2F;files&#x2F;rssac-023-17jun2...</a>

If you are using djbdns instead of bind, the zone file is documented at <a href="https:&#x2F;&#x2F;cr.yp.to&#x2F;djbdns&#x2F;tinydns-data.html" rel="nofollow">https:&#x2F;&#x2F;cr.yp.to&#x2F;djbdns&#x2F;tinydns-data.html</a><p>Note the neat djbdns feature where you can set the starting and ending time for every single record. &quot;<i>tinydns dynamically adjusts ttl so that the line&#x27;s DNS records are not cached for more than a few seconds past the ending time.</i>&quot; That makes planned IP address changes a lot less painful!

&gt; <i>if omitted, BIND will assume that the record being specified is of class IN</i><p>I thought that BIND defaults to the class of the previous record, which was why IN is usually specified on the SOA record, which, being the first record in a zone file, makes the IN class implicit for every following records.

&gt; <i>BIND9</i> […] <i>supports human-readable time sufffixes such as &quot;m&quot; for minutes, &quot;h&quot; for hours, and &quot;d&quot; for days.</i><p>In fact, the full supported list of suffixes – from the BIND 9 source code, <a href="https:&#x2F;&#x2F;gitlab.isc.org&#x2F;isc-projects&#x2F;bind9&#x2F;-&#x2F;blob&#x2F;main&#x2F;lib&#x2F;dns&#x2F;ttl.c#LC147" rel="nofollow">https:&#x2F;&#x2F;gitlab.isc.org&#x2F;isc-projects&#x2F;bind9&#x2F;-&#x2F;blob&#x2F;main&#x2F;lib&#x2F;dn...</a> – is:<p>• w = weeks<p>• d = days<p>• h = hours<p>• m = minutes<p>• s = seconds (optional)<p>Note also that the BIND code supports any number of stacked suffixes: “2D15M” means 2 days plus 15 minutes.

BIND zone files support TTL per record. Not sure why that isn&#x27;t shown.

&gt; <i>refresh — after this period of time, secondary nameservers should query the primary nameserver for this SOA record, to detect changes in serial number.</i><p>Firstly, the term is still “master server” and “slave server”, officially. [EDIT: I was wrong; it apparently changed again 7 months ago in RFC 8499, Jan 2019] Secondly, while this is true, nobody needs to care about the refresh time anymore, since the master servers usually sends DNS NOTIFY to all its slave servers when an update is needed.

&gt; <i>Using dig is as simple as specifying a server to query, the record type you want to look for, and the FQDN it should be associated with.</i><p>While this works, the canonical (documented) syntax is “dig &lt;name&gt; &lt;type&gt;”, i.e. “dig @127.0.0.1 example.tld NS”. Or, for safety when scripting, use the “-t &lt;type&gt;” and “-q &lt;name&gt;” options to avoid accidental ambiguity.

FWIW, &quot;nslint&quot; is probably available in your distribution&#x27;s package repositories.<p>Liberal usage of &quot;named-checkzone&quot; (and &quot;named-checkconf&quot;) is highly recommended as well.