6 ms·

Understanding DNS: Anatomy of a BIND zone file

138 points by surbas 6y ago

Tepix 6y ago
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 6y ago
  And some day, it might even support AAAA records.
  - JdeBP 6y ago
    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-data.xml http://jdebp.uk./Softwares/djbwares/guide/commands/tinydns-d...
  - hal9000-tng 6y ago
    sadly, djbdns will probably support AAAA records long before the majority of the Internet.
tyingq 6y ago
BIND zone files support TTL per record. Not sure why that isn't shown.
- Tepix 6y ago
  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 6y ago
    Do you mind me asking, what is your use case for scheduling creation of DNS entries?
    - Tepix 6y ago
      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).
fanf2 6y ago
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-17jun20-en.pdf https://www.icann.org/en/system/files/files/rssac-023-17jun2...
- tptacek 6y ago
  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".
  - teddyh 6y ago
    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?
    - tptacek 6y ago
      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.
      - teddyh 6y ago
teddyh 6y ago
> 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 6y ago
  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 6y ago
> 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.
- throw0101a 6y ago
  > A serial number has always been a increasing integer Related: * https://en.wikipedia.org/wiki/Serial_number_arithmetic https://en.wikipedia.org/wiki/Serial_number_arithmetic
  - jlgaddis 6y ago
    RFC 1982: Serial Number Arithmetic [0] --- [0]: https://tools.ietf.org/html/rfc1982 https://tools.ietf.org/html/rfc1982
- jlgaddis 6y ago
  > 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 6y ago
    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-data.xml http://jdebp.uk./Softwares/djbwares/guide/commands/tinydns-d...
teddyh 6y ago
> 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 6y ago
  > 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.
  - JdeBP 6y ago
    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. * http://jdebp.uk./FGA/dns-database-replication.html http://jdebp.uk./FGA/dns-database-replication.html
  - canadian_tired 6y ago
    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 6y ago
      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 6y ago
> 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 6y ago
  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 6y ago
    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 6y ago
      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.
- indolering 6y ago
  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. I really should submit a new RFC for TTL values. 0: https://ieeexplore.ieee.org/abstract/document/1041066 https://ieeexplore.ieee.org/abstract/document/1041066 1: http://cs.uccs.edu/~cchow/pub/master/ycai/doc/multipath/nissc/DNS%20performance%20and%20the%20effectiveness%20of%20caching.pdf http://cs.uccs.edu/~cchow/pub/master/ycai/doc/multipath/niss...
teddyh 6y ago
> 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 6y ago
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 6y ago
  I suggest Zonemaster as well, available as a web service and source code here: https://zonemaster.net/ https://zonemaster.net/
teddyh 6y ago
> 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/dns/ttl.c#LC147 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.

138 points by surbas 6y ago

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 6y ago
And some day, it might even support AAAA records.
- JdeBP 6y ago
  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-data.xml http://jdebp.uk./Softwares/djbwares/guide/commands/tinydns-d...
- hal9000-tng 6y ago
  sadly, djbdns will probably support AAAA records long before the majority of the Internet.

tyingq 6y ago

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

Tepix 6y ago
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 6y ago
  Do you mind me asking, what is your use case for scheduling creation of DNS entries?
  - Tepix 6y ago
    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).

fanf2 6y ago

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-17jun20-en.pdf https://www.icann.org/en/system/files/files/rssac-023-17jun2...

tptacek 6y ago
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".
- teddyh 6y ago
  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?
  - tptacek 6y ago
    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.
    - teddyh 6y ago

teddyh 6y ago

> 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 6y ago
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 6y ago

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

throw0101a 6y ago
> A serial number has always been a increasing integer Related: * https://en.wikipedia.org/wiki/Serial_number_arithmetic https://en.wikipedia.org/wiki/Serial_number_arithmetic
- jlgaddis 6y ago
  RFC 1982: Serial Number Arithmetic [0] --- [0]: https://tools.ietf.org/html/rfc1982 https://tools.ietf.org/html/rfc1982
jlgaddis 6y ago
> 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 6y ago
  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-data.xml http://jdebp.uk./Softwares/djbwares/guide/commands/tinydns-d...

teddyh 6y ago

> 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 6y ago
> 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.
- JdeBP 6y ago
  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. * http://jdebp.uk./FGA/dns-database-replication.html http://jdebp.uk./FGA/dns-database-replication.html
- canadian_tired 6y ago
  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 6y ago
    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 6y ago

> 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 6y ago
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 6y ago
  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 6y ago
    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.
indolering 6y ago
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. I really should submit a new RFC for TTL values. 0: https://ieeexplore.ieee.org/abstract/document/1041066 https://ieeexplore.ieee.org/abstract/document/1041066 1: http://cs.uccs.edu/~cchow/pub/master/ycai/doc/multipath/nissc/DNS%20performance%20and%20the%20effectiveness%20of%20caching.pdf http://cs.uccs.edu/~cchow/pub/master/ycai/doc/multipath/niss...

teddyh 6y ago

> 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 6y ago

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 6y ago
I suggest Zonemaster as well, available as a web service and source code here: https://zonemaster.net/ https://zonemaster.net/

teddyh 6y ago

> 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/dns/ttl.c#LC147 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.