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.
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.* https://cr.yp.to/djbdns/tinydns-data.html
* http://jdebp.uk./Softwares/djbwares/guide/commands/tinydns-d...
Related:
---
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.
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.
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.
EDIT: I did not look far back enough to find RFC 8499 from January 2019 (7 months ago), found by darrenf in a sibling comment. This RFC apparently changes the terms again to “primary” and “secondary”.
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!
An actual study came out in 2002 [0, 1] showing that DNS cache hit rates follow a power-law curve, with the bend starting at ~5 minutes and leveling off ~15 minutes. You will get very marginal gains with a TTL above 1 hour. IMHO, anything past an hour is a footgun for most people.
I have to talk around an NDA here, but only big players like Google use a TTL past 24 hours. Google might care about shaving a few tens of milliseconds off of load times for a single user once a day, but you should worry more about customers not being able to load your website for a day because you screwed your DNS config.
I really should submit a new RFC for TTL values.
0: https://ieeexplore.ieee.org/abstract/document/1041066
1: http://cs.uccs.edu/~cchow/pub/master/ycai/doc/multipath/niss...
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!
* 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...
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.
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 :-)
Liberal usage of "named-checkzone" (and "named-checkconf") is highly recommended as well.
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... – 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.
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.