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!
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.
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.
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".
It’s a standardized format for serializing DNS data to ASCII text and back. There’s nothing wrong with that. This is like complaining that Lisp syntax is stupid since no Lisp implementation stores the Lisp syntax as ASCII, but stores it as the parsed AST. This does not make the Lisp syntax for humans any less useful. Would you prefer it if every DNS implementation had its own text syntax for DNS records?
DNS implementations do have their own syntax for DNS records! The implementation details of how DNS servers choose to represent records are not properly part of the DNS standard.
You saw this play out in the early days of tinydns/djbdns, when people on namedroppers accused djbdns of being noncompliant because it used a different format.
The whole point of the DNS protocol is that systems interoperate through the protocol, which exists exclusively for that purpose. Zone files aren't an interchange format.
Oh yes they are. It’s an everyday occurence to export a zone from one name server to standard “master zone file” format and then import that into another name server running some other software DNS implementation. Having a standardized file format for machine-readable DNS data is extremely useful.
It’s also used as an interchange format between people, so that people can talk about DNS data structure in technical detail without having to either send binary DNS data to each other or use some program-specific syntax, which might be misunderstood or be incomprehensible by users of some other program.
You might want to argue that it’s a bad format, and you should feel free to do that. However, to argue that the RFCs either are wrong and don’t exist, and the standard “master file” format somehow is some program-specific format, when the format is clearly and demonstrably used by most extant DNS servers (if only for import/export) and is useful for a number of things, is not productive discourse.
1035 is The DNS RFC. Using BIND's archaic zone file format is in no sense a requirement to interoperate with other DNS protocol servers.
You could argue that the IETF should have another RFC specifying the zone file format; what could be wrong with standardizing a file format? Standardize my iTunes Library database file while you're at it; that would help far more people.
But it has nothing to do with provisioning DNS service, and the claim that BIND zone files have any kind of special status is bogus, despite what 1035 mistakenly says.
There is a de facto standardized computer file format for playlists, called Moving Picture Experts Group Audio Layer 3 Uniform Resource Locator, and it is supported by iTunes together with basically every music player and device cable of playing music. It is one of the few file formats where you can take a file that is 20 years old and it still works to create a play list anywhere.
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.
You misunderstood my point that the zone file design was originally implemented in JEEVES, which was the first DNS server written by Paul Mockapetris; it did not come from BIND. Other servers such as NSD and Knot and PowerDNS support standard zone files, and many other DNS tools use the standard presentation format for printing and reading DNS records.
> 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.
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 :-)
> 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.
> 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.
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).
> 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.
> 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.
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.
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
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.
This must be a recent change, then. The latest DNS-related RFC I can find which mentions either term is RFC 8765 of June 2020, which has exactly one mention of “primary” and “secondary” each. The previous RFC which uses either term is RFC 8501 from 2018, which uses “master” and “slave” multiple times throughout. IIRC, this was changed from RFC 1035’s “primary” and “secondary” some years back into “master” and “slave”, and I think it was due to confusion with primary and secondary DNS resolvers.
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”.
The problem was that people overused "primary" and "secondary". They have meanings when it comes to database replication, but people then erroneously transferred that to the query resolution process, where they do not.
> 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!
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?
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.
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.
Both of the cited standards are ancient and written from the perspective of network admins trying to reduce the bandwidth used by DNS back in the 90's (DNS messages usually fit within a single packet).
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.
> 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.
43 comments
[ 3.0 ms ] story [ 102 ms ] threadNote 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...
You saw this play out in the early days of tinydns/djbdns, when people on namedroppers accused djbdns of being noncompliant because it used a different format.
The whole point of the DNS protocol is that systems interoperate through the protocol, which exists exclusively for that purpose. Zone files aren't an interchange format.
Oh yes they are. It’s an everyday occurence to export a zone from one name server to standard “master zone file” format and then import that into another name server running some other software DNS implementation. Having a standardized file format for machine-readable DNS data is extremely useful.
It’s also used as an interchange format between people, so that people can talk about DNS data structure in technical detail without having to either send binary DNS data to each other or use some program-specific syntax, which might be misunderstood or be incomprehensible by users of some other program.
You might want to argue that it’s a bad format, and you should feel free to do that. However, to argue that the RFCs either are wrong and don’t exist, and the standard “master file” format somehow is some program-specific format, when the format is clearly and demonstrably used by most extant DNS servers (if only for import/export) and is useful for a number of things, is not productive discourse.
You could argue that the IETF should have another RFC specifying the zone file format; what could be wrong with standardizing a file format? Standardize my iTunes Library database file while you're at it; that would help far more people.
But it has nothing to do with provisioning DNS service, and the claim that BIND zone files have any kind of special status is bogus, despite what 1035 mistakenly says.
If it does not, then RFC 1035 just happens to specify both the DNS protocol and a canonical ASCII serialization of DNS zone data.
There is a de facto standardized computer file format for playlists, called Moving Picture Experts Group Audio Layer 3 Uniform Resource Locator, and it is supported by iTunes together with basically every music player and device cable of playing music. It is one of the few file formats where you can take a file that is 20 years old and it still works to create a play list anywhere.
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.
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 :-)
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.
Related:
* https://en.wikipedia.org/wiki/Serial_number_arithmetic
---
[0]: https://tools.ietf.org/html/rfc1982
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):
* https://cr.yp.to/djbdns/tinydns-data.html
* http://jdebp.uk./Softwares/djbwares/guide/commands/tinydns-d...
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”.
* http://jdebp.uk./FGA/dns-database-replication.html
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...
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.
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.