
Understanding DNS: Anatomy of a BIND zone file - surbas
https://arstechnica.com/gadgets/2020/08/understanding-dns-anatomy-of-a-bind-zone-file/
======
teddyh
> _If you don '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!_

This is incorrect. The serial number affects whether _slave servers_ (in this
case probably ns2.example.tld) will pick up changes. Resolvers do not see or
care about the zone serial.

> _This used to be a YYMMDDnn format in days gone by—but that format is no
> longer required, or in some cases even supported._

A serial number has _always_ been an increasing integer with no technical
meaning assigned. But it is _still_ recommended that anyone editing zone files
by hand to use the YYYYMMDDXX format; it has _not_ been deprecated, nor is it
unsupported by anyone.

~~~
jlgaddis
> A serial number has always been an increasing integer ...

An unsigned 32-bit integer, to be specific.

While I've always preferred and used the _YYYYMMDDnn_ format for the serial,
I've noticed more and more zones using UNIX time for the serial in the last
several years. I'm not sure where that "started" but my first guess would be
some DNS server that uses something other than "BIND" zone files -- a MySQL
database, perhaps? -- as its backend.

> ... with no technical meaning assigned.

To underscore this key point, consider the following statement from RFC 1982
(in the case where the serial is a 2-bit integer):

    
    
      It is undefined whether 2 > 0 or 0 > 2, and whether 1 > 3 or 3 > 1.

~~~
JdeBP
Possibly the tinydns-data compiler, which uses the last modification timestamp
of the input file when processing Z and . records (unless the Z record has an
explicit serial number, of course).

* [https://cr.yp.to/djbdns/tinydns-data.html](https://cr.yp.to/djbdns/tinydns-data.html)

* [http://jdebp.uk./Softwares/djbwares/guide/commands/tinydns-d...](http://jdebp.uk./Softwares/djbwares/guide/commands/tinydns-data.xml)

------
teddyh
> _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._

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!

~~~
tombrossman
I have heard that setting a very long MX TTL can be helpful if your domain
registration is ever hijacked. The idea is that enough resolvers will have the
original cached records so you can still receive email (and prove ownership).
Anyone have any experience with this?

~~~
jlgaddis
I've not heard that specific reasoning before but I can believe it -- I've
seen MTAs continue to (attempt to) send mail to the "old" MX for several days
or even _weeks_ (in a few cases) after the RR (with my "standard" 2d TTL) was
updated.

~~~
toast0
Microsoft Exchange used to cache MX lookups for the life of the process. Which
is pretty frustrating, but I think that may have coincided with the ~ 45 day
uptime cap, so it wasn't completely awful.

------
fanf2
Sigh, it isn't a BIND zone file, it's a standard RFC 1035 zone file
[https://tools.ietf.org/html/rfc1035#section-5](https://tools.ietf.org/html/rfc1035#section-5)
If you want to tie it to a particular piece of software then JEEVES would be
more accurate :-)
[https://www.icann.org/en/system/files/files/rssac-023-17jun2...](https://www.icann.org/en/system/files/files/rssac-023-17jun20-en.pdf)

~~~
tptacek
It's a BIND zone file, and the elevation of an implementation detail to a
standard is an artifact of a time --- a bad time --- where BIND was the only
mainstream option for authority servers. That the file itself originates in an
earlier piece of software doesn't change that. The DNS doesn't interoperate
through "zone files", but through the DNS protocol itself. Modern zones don't
even have "files".

~~~
1vuio0pswjnm7
To defend your point, section 5 only says a "master file is most often used".
It does not require the use of a master file to load a zone. Further, in
section 5.2, it says "when a master file is used to load a zone". This
suggests there could be occasions when a master file is not used to load a
zone, e.g., a zone transfer.

Correct me if I am wrong but I think one difference between tinydns and, say,
nsd is that tinydns reads a zone file from disk to answer queries while nsd
loads the entire file into memory. The whole "on-disk" concept seems a bit
dated when one considers tinydns zone files are stored on mfs/tmpfs.

I still use tinydns (and cdb) heavily. I think it is well-suited for the home
user. BIND OTOH is an ever-changing, relatively large amount of code to
compile, a hybrid authoritative server/cache, and it comes with a sizeable
amount of complexity. BSD developers have long been trying to replace it with
something else like unbound. djb used to refer to "the BIND company" and I
think that is a reasonably accurate description of its developers. Thankfully,
djbdns is non-commercial. Its author does not try to earn a living by
monitoring/manipulating other people's DNS use.

~~~
tptacek
Presumably, Route53 isn't serving DNS out of zone files either.

------
Tepix
If you are using djbdns instead of bind, the zone file is documented at
[https://cr.yp.to/djbdns/tinydns-data.html](https://cr.yp.to/djbdns/tinydns-
data.html)

Note the neat djbdns feature where you can set the starting and ending time
for every single record. " _tinydns dynamically adjusts ttl so that the line
's DNS records are not cached for more than a few seconds past the ending
time._" That makes planned IP address changes a lot less painful!

~~~
jldugger
And some day, it might even support AAAA records.

~~~
JdeBP
That day was back in 2013.

* [http://jdebp.uk./Softwares/djbwares/](http://jdebp.uk./Softwares/djbwares/)

Felix von Leitner added support in a different way some years even earlier
than that, requiring new record types. The 2013 mechanism simply extended the
existing + record type (and indeed all of the other record types that have an
"ip" field) so that one could give it IPv4 addresses or IPv6 addresses.

* [http://jdebp.uk./Softwares/djbwares/guide/commands/tinydns-d...](http://jdebp.uk./Softwares/djbwares/guide/commands/tinydns-data.xml)

------
teddyh
> _if omitted, BIND will assume that the record being specified is of class
> IN_

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.

~~~
fanf2
The class is a property of the zone as a whole, and it's usually known up
front before the zone is loaded. So it's completely redundant in zone files.

You're right that the class is copied from the previous record if it isn't
mentioned. (This behavious is required by the standard, it isn't specific to
BIND.) But the catch is that it's an error if you use a different class :-)

------
teddyh
> _BIND9_ […] _supports human-readable time sufffixes such as "m" for minutes,
> "h" for hours, and "d" for days._

In fact, the full supported list of suffixes – from the BIND 9 source code,
[https://gitlab.isc.org/isc-
projects/bind9/-/blob/main/lib/dn...](https://gitlab.isc.org/isc-
projects/bind9/-/blob/main/lib/dns/ttl.c#LC147) – is:

• w = weeks

• d = days

• h = hours

• m = minutes

• s = seconds (optional)

Note also that the BIND code supports any number of stacked suffixes: “2D15M”
means 2 days plus 15 minutes.

------
tyingq
BIND zone files support TTL per record. Not sure why that isn't shown.

~~~
Tepix
Yes, you only can specify the TTL in seconds, however and also not the
starting time of the record, i.e. no way to bring online a new record at a
certain point in time.

~~~
stedaniels
Do you mind me asking, what is your use case for scheduling creation of DNS
entries?

~~~
Tepix
Changing an IP address to a new address at a certain point in time (without
having to load a new zone into bind at that exact time).

------
teddyh
> _refresh — after this period of time, secondary nameservers should query the
> primary nameserver for this SOA record, to detect changes in serial number._

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.

~~~
darrenf
> _the term is still "master server" and "slaver server", officially_

Can you provide a source for this? I was using "primary" and "secondary" back
when I administered DNS in the mid-to-late 90s, and my recollection is that
primary and secondary were always the terms in use (including in some of the
originating RFCs e.g. 1033, 1035).

In fact I checked RFC1035 myself, and it specifically says:

 _The DNS requires that all zones be redundantly supported by more than one
name server. Designated secondary servers can acquire zones and check for
updates from the primary server using the zone transfer protocol of the DNS._

~~~
canadian_tired
FWIW, I used primary/secondary for years too. Once BIND 8 showed up, I think
they switched to master/slave as it better described the process... to the
uninitiated, "secondary" was probably viewed as a "backup" in the sensse of
DR/HA.

~~~
darrenf
Interesting. I haven't touched BIND for years and am out of the loop, plus
memory is fallible anyway. Just looked at it and have ended up at RFC 8499
from January 2019:
[https://tools.ietf.org/html/rfc8499](https://tools.ietf.org/html/rfc8499)

    
    
       Master server:  See "Primary server".
    
       Primary server:  "Any authoritative server configured to be the
          source of zone transfer for one or more [secondary] servers."
          (Quoted from [RFC1996], Section 2.1) Or, more specifically,
          [RFC2136] calls it "an authoritative server configured to be the
          source of AXFR or IXFR data for one or more [secondary] servers".
          Primary servers are also discussed in [RFC1034].  Although early
          DNS RFCs such as [RFC1996] referred to this as a "master", the
          current common usage has shifted to "primary".
    

So it seems `primary` is essentially the official term in DNS, but `master`
may well be the preferred term by BIND itself.

------
teddyh
> _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._

While this works, the canonical (documented) syntax is “dig <name> <type>”,
i.e. “dig @127.0.0.1 example.tld NS”. Or, for safety when scripting, use the
“-t <type>” and “-q <name>” options to avoid accidental ambiguity.

------
jlgaddis
FWIW, "nslint" is probably available in your distribution's package
repositories.

Liberal usage of "named-checkzone" (and "named-checkconf") is highly
recommended as well.

~~~
teddyh
I suggest Zonemaster as well, available as a web service and source code here:
[https://zonemaster.net/](https://zonemaster.net/)

