Zone Files DNS Courses - Revision Lecturer: Ron Aitchison

Zone Files DNS Courses - Revision Lecturer: Ron Aitchison

Copyright Zytrax, Inc. All rights reserved.
Module Objectives Understand the idea of a zone and how it relates to a Domain Name Understand zone file structure Understand the major Resource Record (RRs) used to create zone files Understand the RPZ Resource Record subset The specific topics are covered on the slide. This module is DNS software agnostic - it covers zone files which form part of the DNS RFC standards and therefore applies to all DNS software. Copyright Zytrax, Inc. All rights reserved.

DNS – Zone Files Domain Name = Zone Contains textual records that describe various properties of the Domain Name (zone) and all the domain names in the zone The Authoritative Name Server for the Domain Name (Zone) loads the zone file Forward mapping translates a name into an IP address or a secondary name Reverse Mapping translates an IP address into a name For all practical purposes the term zone is synonymous with Domain Name. In the DNS jargon and literature, in general, zone is used in a collective sense thus all the domain names at a particular Domain Name are collected together in a zone file (not a Domain Name file). A zone is transferred (all the names in the zone). However, like all technical terminology, it can be abused. Like almost all Internet standards the records in a zone file use a textual format, they can be created and edited with any text editor. The various records describe characteristics of the Domain Name or zone as well as all the visible hosts or services in the domain. The term visible indicates that records that appear in any zone file are visible within the network to which they are attached - if the Name Server is attached to the Internet they are hosts defined in it are visible globally. Two points need to be considered. First, there is no mandatory requirement to define any specific host in any zone file. Second, we will see in later modules that many users choose to maintain two or more zone files that describe their network, for example, a public zone file and a private zone file. Such files may have very different numbers of hosts or services. The zone file is loaded by the Authoritative Name Server for the Domain Name (or zone). The zone file is the data used by the Name Server to respond to queries. The term forward mapping is generically used to describe a zone file that defines the mapping of names to other resources, typically but no means only, to IP addresses. This is the zone file that we will meet first and the one used by the Authoritative Name Server. Reverse mapped zone files, which we will look at in this module, are used to map IP addresses to host names. An Authoritative Name Server for the Domain Name does not use the reverse map zone files, instead their will be an Authoritative Name which will load the reverse map zone but the Domain Name is very different because the delegation route through the DNS name hierarchy to the reverse map is very different.. Copyright Zytrax, Inc. All rights reserved.

DNS Zone File ; IPv4 zone file for example.com $TTL 2d ; default TTL for zone $ORIGIN example.com. ; base Domain (zone) Name ; Start of Authority record defining the key characteristics of the zone (domain) @ IN SOA ns1.example.com. hostmaster.example.com. ( ; se = serial number 12h ; ref = refresh 15m ; ret = update retry 3w ; ex = expiry 2h ; nxttl = nxdomain ttl ) ; name servers Resource Records for the domain IN NS ns1.example.com. ; the second name server is external to this zone (domain). IN NS ns2.example.net. ; mail server Resource Records for the zone (domain) 3w IN MX 10 mail.example.com. ; the second mail server has lower priority and is ; external to the zone (domain) IN MX 20 mail.example.net. ; domain hosts includes NS and MX records defined previously ; plus any others required ns IN A mail IN A joe IN A www IN A ; aliases ftp (ftp server) to an external location ftp IN CNAME ftp.example.net. This is a fairly standard zone file for a small zone (Domain Name) that we will use throughout this and other modules to illustrate the general principles of constructing zone files. It is not important at this stage to understand the contents of the file other than to note that this is a forward map zone file (maps names to IP Addresses) for the Domain Name of example.com, it is composed of ten Resource Records (RRs) of various types, for example the line beginning www is the Resource Record (RR) that defines the web site for the domain (wwww.example.com), contains zone file directives (lines beginning with a dollar ($) and, finally, that zone file comments start with a semi-colon (;). Copyright Zytrax, Inc. All rights reserved.

DNS - Forward Mapping RRs
SOA RR defines the Apex of the zone (the Domain Name) and general properties NS RRs define the Name Servers (DNS) which are authoritative MX RRs define the mail servers CNAME RRs define aliases A (IPv4) and AAAA (IPv6) RRs define IP addresses TXT RRs are general text records (overloaded for specific functions, such as, SPF) In building the forward map zone file for the Domain Name example.com we will look at a number of Resource Record types that together allow the construction of most zone files in use today. There are significantly more RRs available but most have specialized used and we will meet then in later modules. At this point we focus on the broad definitions of each type before looking at them in detail. The SOA RR description includes the term zone apex, which is frequently used in the literature to describe the base name of the domain or zone. Thus, Domain Name = zone name = zone apex. With the exception of the TXT and AAAA RRs these RRs all appear in the previous slide of the example.com forward map zone file. The TXT RR defines a general purpose unformatted text record. However, it is widely used (to the disgust of many DNS professionals it must be said) to have specific meaning by defining a textual format, thus creating what is, in essence, an RR within an RR. The TXT RR illustrates a general point about overloading (giving more than one meaning to an entity) which can make the DNS RRs even more powerful than they already are. The AAAA RR (colloquially referred to as a quad A RR) defines an IPv6 address and will be covered in a specialized IPv6 Module. Copyright Zytrax, Inc. All rights reserved.

RRs – Generic Format name ttl class type parameters www IN A name (owner-name) or label identifies the record externally, for instance, www ttl (Time-to-Live) defines how long, in seconds, the RR may be cached class = IN = Internet type of RR, for example, MX One or more type-specific parameters TTL and Class can be omitted All RRs have the same generic format which we need to understand thoroughly before moving to the specific RR types. name - The left most field is the name that will be associated with this record. In DNS jargon any name that appears between dots is generically called a label. We tend to use the term owner-name to differentiate it from names which can also appear in the parameter field. As always terminology can be a source of confusion. This field may take some unique values or may be left blank and will be explored in detail in alter slide. ttl - defines the amount of time that a Resolver (of whatever type, stub or full-service) may store the RR in its cache. As our understanding of DNS grows we will see that this is a very significant field which can have all kinds of unexpected effects. class - defines the class to which this RR applies. IN (or in - it is case insensitive) indicates this RR applies to Internet RRs. There are two other classes that you are unlikely to come across since both relate to MIT specific systems. They are CH for CHAOS (an MIT LAN protocol) and HS for HESIOD (an MIT information service). type - identifies the RR type, such as MX or NS or TXT parameters - are always type-specific and vary enormously in number and size. Both, or either, the ttl or class may be omitted from any RR definition. In the case of ttl only if the zone file directive $TTL is present. In the case of class IN (or in) is assumed. Copyright Zytrax, Inc. All rights reserved.

Zone Directives All start with $ $TTL time-in-seconds default Time-to-Live for the zone in seconds $ORIGIN FQDN. Base Domain (zone) Name $INCLUDE file-name Include another file here Comments start with ; Zone file directives control the detail behavior of how RRs are finally constructed from the zone file. They can be also the source of the much confusion. This slide briefly reviews the directives and their functionality before moving on to describe $TTL and $ORIGIN in detail. $INCLUDE - This directive is a operational convenience and allows a zone file to be constructed from multiple files by inserting it (them) at the appropriate place(s) in the zone file. It is especially used to protect confidential data, such as cryptographic keys, that DNS administrators without certain security privileges may not be allowed to view even though their normal duties may require them to access and maintain zone files. By placing these keys in separate files each such file may be protected by differing levels of security within the operating system. When the DNS software application is loaded it will assemble the entire zone file including the secure keys before parsing it and converting into its internal format. Copyright Zytrax, Inc. All rights reserved.

$TTL Zone Directive The default Time-to-Live in seconds if no TTL value on a specific RR. Optional. = 2 days (standard specifies seconds) Takes short forms in BIND (and most other DNS software) Short form = m, h, d, w (used on RRs also) = 2d or 48h $TTL 1d2h3m = 93780 Must appear before use (typically first in zone file) $TTL - Defines the default TTL for the zone - the value used if a TTL is omitted on any RR. Obviously, the $TTL directive must appear before it can be used and for this reason it is normally defined at the start of the zone file. A $TTL directive is not required if all RRs have explicit TTL values. Most DNS software will refuse to load a zone file if there is no $TTL directive and one or more TTL values are missing from RRs (no default is assumed). It is good practice to always include a $TTL directive even if TTLs are explicitly defined in all RRs simply because zone files change and future enhancers may not be as careful about adding TTLs to RRs. The value of the TTL is in seconds(unsigned 32 bit with a maximum value of or 67+ years). The DNS software BIND allows the short forms m (minutes), h (hours), d (days) and w (weeks) to simplify the definition. Thus the value $TTL can be written as $TTL 2d or $TTL 48h or $TTL 2880m. These short forms can also be used on individual TTLs in RRs. While most modern DNS software also supports these short forms, not all do, zone files that need to be portable should always use explicit seconds and keep a calculator handy. Copyright Zytrax, Inc. All rights reserved.

DNS - TTL Only used by caching Name Servers (Resolvers) Slave uses SOA parameters Determines the time the RR can be held in a cache Value in seconds (think in hours) 0 = never cache (dangerous) One element of DNS change propagation time Always a compromise between DNS load and change propagation In the previous module we briefly touched on the role of TTL in the DNS. TTLs are only used by resolvers either caching stub-resolvers or full-service resolvers. Slaves do not use the TTL values in a transferred zone file to expire the zone records instead they have a completely separate mechanism based on the SOA RR parameters (refresh, retry and expire). When a resolver places a record it is cache the TTL valued is stored and a countdown timer is started. When a query arrives for a record that exists in the resolvers cache it is returned immediately with the current (counted down) value of the TTL relative to this cache. Thus, if an RR with a TTL of 3600 (1 hour) is received from an Authoritative Name Server in response to a query then it is returned in the answer to the requesting client with a TTL of 3600 and placed in the resolver's cache. If a further query which results in the same RR is made by a client 59 minutes later, the RR will be returned in the answer but with a TTL of 60 (1 minute). When an RR expires from the cache it is not refreshed by the resolver automatically, it is simply discarded. The resolver waits until another client query causes it to read the same RR from the Authoritative Name Server after which it is again placed in the cache. The TTL value is specified in seconds (though when defined in the zone file it may use convenient short forms). The value 0 = don't cache. The modern tendency is to use increasingly short TTL values, including the value 0, in the mistaken belief that this will improve system resilience. As a simple example, assume a user wishes to provide a reliable web service and consequently uses a 0 TTL to allow it to swap to an alternative address should the web site fail. Unless the Authoritative Name Servers are as reliable as the web site this is entirely pointless. There are, depending on the implementation, significantly better DNS strategies that may be used (discussed shortly) than low TTLs. Finally, every external DNS access offers attackers the opportunity to poison or pollute a cache. The more frequent the external access the more frequent the attack possibilities. Use low TTLs with extreme caution. TTLs are one of the two major determining factors over the time taken to propagate network changes - the other being the method used for Slave zone transfer. Copyright Zytrax, Inc. All rights reserved.

$ORIGIN Directive Defines a label (name) that will be used to substitute all non-FQDN names Parameter must be an FQDN $ORIGIN example.com. terminates with a dot Optional - defaults to zone name Usage illustrated in later slides Single biggest problem in the early phase of working with zone files $ORIGIN - defines a base domain name that will be used in subsequent name substitutions when a non-FQDN name is encountered. The $ORIGIN parameter must be in the form of an FQDN (Fully qualified Domain Name ending with a dot). It is the single biggest cause of confusion when starting to work with zone files. The $ORIGIN directive is optional (all DNS software will synthesize an $ORIGIN from the zone name of the configuration). This course always uses an explicit $ORIGIN directive in every zone file to avoid confusion in line with what we regards as best DNS practice. Not defining an $ORIGIN directive can lead to all kinds of unexpected errors and strange behaviors. The $ORIGIN directive should appear before it is required in the zone file and for this reason normally appears at the start of the zone definitions. We will meet uses of the $ORIGIN directive in later modules where it can appear multiple times within a zone file. Copyright Zytrax, Inc. All rights reserved.

DNS Zone File ; IPv4 zone file for example.com $TTL 2d ; default TTL for zone $ORIGIN example.com. ; base Domain Name (zone apex) ; Start of Authority record defining the key characteristics of the zone (domain) @ IN SOA ns1.example.com. hostmaster.example.com. ( ; se = serial number 12h ; ref = refresh 15m ; ret = update retry 3w ; ex = expiry 2h ; nxttl = nxdomain ttl ) ; name servers Resource Records for the domain IN NS ns1.example.com. ; the second name server is external to this zone (domain). IN NS ns2.example.net. ; mail server Resource Records for the zone (domain) 3w IN MX 10 mail.example.com. ; the second mail server has lower priority and is external to the zone (domain) IN MX 20 mail.example.net. ; domain hosts includes NS and MX records defined previously plus any others required ns IN A mail IN A joe IN A www IN A ; aliases ftp (ftp server) to an external location ftp IN CNAME ftp.example.net. Lets return to the zone file for example.com with our new found knowledge. We can see the default TTL for this zone is 2 days ( seconds) which is defined by $TTL 2d (could have been $TTL ) on the second line. The $ORIGIN example.com. (with a terminating dot) on line 3 means we know, even if we did not read the prior comments, that this zone file is for example.com (there is nothing else in the file that confirms this and the comment could be wrong). We understand that lines (or part lines) beginning with ; are comments. We should be able to spot the RR types SOA, NS, MX and A even if we don't understand what all the parameters mean yet. We should also be able to spot those RRs that have included and those that have omitted an explicit TTL value. But what about the lines beginning with spaces or sign, and what is an owner-name (a left hand name) of www and how does it relate to Time to look at some zone file layout information before we start learning the detail of each RR type. Copyright Zytrax, Inc. All rights reserved.

File layout rules Comments begin with ; ; IPv4 zone file for example.com = $ORIGIN Blank or TAB = last label (owner-name) or $ORIGIN Parameters continued in parenthesis () @ IN SOA ns1.example.com. hostmaster.example.com. ( ; se = serial number 12h ; ref = refresh 15m ; ret = update retry 3w ; ex = expiry 2h ; nxttl = nxdomain ttl ) Zone files can use all kinds of tricks to keep then as short and small as possible. Some are genuine masterpieces. But they can be very confusing. If the appears as the first character in a line (in the name or owner-name position) then the current value of $ORIGIN is substituted (even if there is no explict $ORIGIN directive since one is always synthesized). Line 4 of the file starts @ IN SOA .... after this rule is applied it becomes: example.com. IN SOA .... If a line starts with a blank, TAB or spaces then either the last label or, in its absence, the value of $ORIGIN is applied. If we find the line starting IN NS After applying this rule it becomes: example.com. IN NS .... Finally, for convenience RRs with many parameters such as the SOA may have their parameters shown on separate lines enclosed within parenthesis. The opening parenthesis must appear on the first line of the RR definition. Copyright Zytrax, Inc. All rights reserved.

DNS – Substitution Rule
If any name (label) in a zone file is not an FQDN the last value of $ORIGIN will be appended to the end of the name (label). This rule is applied to all names (labels) in the zone file. Example: www IN A Becomes after the substitution IN A The most confusing rule, at least initially, when working with zone files is how names are expanded using what we call the $ORIGIN substitution rule. The rule itself is simple: Names that don't end with a dot (are non-FQDNs) will have the value of $ORIGIN (which always ends with a dot) appended to them. This rule is applied to every name in the zone file wheter they appear on the right-hand side or the left-hand side (or in the middle as we shall see with the SOA RR shortly). The confusion comes if we don't have an explicit $ORIGIN (its presence is a constant reminder of what happens) and from simply remembering when this feature is useful and when it is not. The example shown in the slide is one affecting only the left-hand side name (owner-name) we will see others later in this module. Finally, a word of caution. Once this feature is mastered there is a tendency to use it wherever possible. This can lead to very short, but very confusing, zone files which may cause problems in the future. We tend to use non-FQDNs only on the owner-name (left-hand side name) and always FQDNs when names appear on the right-hand side (in the parameters). Its a simple convention and we find it less confusing. Whatever convention you adopt use it consistently. Copyright Zytrax, Inc. All rights reserved.

DNS - SOA RR SOA pmns mail sn refresh retry expiry nxttl SOA defines the start of the zone and must be first non-directive entry pmns = Primary Master Name Server Normally one of the Authoritative Name Servers OR If DDNS is used it defines the NS which will be updated Specification term is MNAME. Finally, its time to start looking at our chosen RRs in some detail. We begin with the Start Of Authority (SOA) RR which is by far the most complex RR in the zone file taking a total of 7 parameters. The SOA RR defines the beginning of the zone, must be present and must be the first non-directive entry in the zone file. Its parameters are in a number of circumstances the one that we have met so far is the Slave Name Servers use 4 of the 7 parameters. The SOA RR is almost always written using the multi-line feature by enclosing some of the parameters within parenthesis. There is no need for this. It could all be written on a single line if that is more useful or less confusing (which it rarely is). The first SOA parameter we call pmns (its official specification name is MNAME) the Primary Master Name Server. In normal use this can be any Authoritative Name Server (Master or Slave) for the domain (defined using a NS RR type in this zone). If, however, you are using a feature called Dynamic DNS (DDNS - covered in a future module) then this defines the only Master Name Server that DDNS can update. Copyright Zytrax, Inc. All rights reserved.

DNS - SOA RR SOA pmns mail sn refresh retry expiry nxttl mail = mail address of DNS administrator or tech contact Format is all dot separated is used) hostmaster.example.com (recommended) = Can be very important Specification name is RNAME. The mail parameter (official specification name is RNAME) is the mail address of the administrator or technical contact for the domain or zone. Uniquely for a mail address it is written as separated by dots. This is because symbol used in RFC 822 format address already has a special meaning in the zone file. Thus even if this parameter is written as hostmaster.example.com (hostmaster is the official recommendation but it can be any valid address) mail should be sent to This can address can be very important. In many cases when a query fails, especially due to configuration errors, the Authoritative Name Server will return the SOA RR for its Domain Name. A remote DNS administrator can use the mail address to send to the contact specified. This may speed up rectification of potentially disastrous, or at the very least embarrassing, errors. Whatever address is defined make sure it is valid and operational. Copyright Zytrax, Inc. All rights reserved.

DNS - SOA RR SOA pmns mail sn refresh retry expiry nxttl sn = serial number of zone contents Arbitrary 10 digit number ( ) Usage typically YYYYMMDDSS YYYY = year, MM = month DD = day, SS = sequence number MUST increment every time zone contents change Slave reads SOA and compares serial number The sn parameter is used exclusively by a Slave Name Server to determine whether to initiate a zone transfer or not (even on receipt of NOTIFY). When using a Master Slave configuration it is essential to always update the serial number. The serial number is an arbitrary 10 digit value (unsigned 32 bit integer). By convention it is used in a date format as shown in the slide (others formats also exist). This is a convention, its format is not validated by any DNS software. The date convention is, however, useful for two reasons. First, it provides a reminder of when the last update to the zone file took place. Second, it forces an update to this field to reflect the current date whenever a change is made. Copyright Zytrax, Inc. All rights reserved.

DNS - SOA RR SOA pmns mail sn refresh retry expiry nxttl refresh = time after which Slave will try to refresh zone from Master (AXFR, IXFR) retry = time between failed attempts to refresh zone expiry = time after which Slave will not respond Authoritatively to zone queries if Master not accessed nxttl = time NXDOMAIN (no name) may be cached (max 3 hours) refresh, retry and expiry are used by a Slave Name Server to control how long it will continue to answer Authoritatively for its Domain Name if it fails to contact the Master. Let's remind ourselves how these vales are used. Immediately a Slave Name Server loads a zone file its starts two timers one with a value of refresh, the other with a value of expiry. When the refresh timer expires (or if a NOTIFY message arrives before this) the Slave sends a query to the master for its SOA RR and compares the sn (serial number). If the new sn is greater than the one it currently has it initiates a zone transfer. On completion of the zone transfer, or if the sn value is the same or lower that its current one, both the refresh and expiry timers are reset. If the Slave fails to read the Master's SOA (or the subsequent zone transfer fails) the retry timer is started. When this time expires the operation (read SOA or zone transfer) is retried. If successful then both the refresh and expiry times are reset. If the read of the SOA or the zone transfer fails again the operation is repeated every retry interval until either it is successful, in which case the refresh and expiry timers are reset, or until the expiry timer expires at which point the Slave will stop responding Authoritatively for the Domain Name (it stops setting the Authoritative (AA) bit). It becomes what is called a Lame Server in the jargon. nxto - This value (time in seconds with a maximum value of three hours) is used by resolvers to cache an NXDOMAIN response. If a query is sent to the Authoritative Name Server of a Domain Name (and the requested domain name is under its zone apex) but the name does not exist then it returns an error with a status of NXDOMAIN. (This field is frequently referred to as the min field and reflects a time - pre 2000'ish - when the parameter used to contain the minimum TTL time for the zone.) Copyright Zytrax, Inc. All rights reserved.

DNS – SOA Example @ IN SOA ns1.example.com. hostmaster.example.com. ( ; se = serial number 12h ; ref = refresh 15m ; ret = update retry 3w ; ex = expiry 2h ; nxttl = nxdomain ttl ) This slide shows the SOA RR used in our example zone file. It should now be perfectly understandable. Note especially the use of FQDNs for the pmns and mail fields. The value for refresh (12h), retry (5m) and expiry (3w) are fairly common. You may want to consider your own site/zone specific values. The expiry value (3w) may look remarkably long. However, consider that when this value expires your entire Domain Name may go off-the air (the zone goes dark in the colloquial DNS jargon) shorter values may be risky. Best to have something responding even if some values are out of date rather than a dark zone. Finally, the master may be off the air for a number of reasons. Perhaps the server is broken and needs to be replaced (a non-trivial job) or more likely perhaps you may have a mal-configured firewall somewhere which may take some to even recognize, let alone fix. Low expiry values have consequences. Note also that the will be replaced by the value of the $ORIGIN (or its synthesized one if missing). In the example file this will be example.com. Copyright Zytrax, Inc. All rights reserved.

DNS – SOA Example $ORIGIN example.com. @ IN SOA ns1 hostmaster ( ; se = serial number 12h ; ref = refresh 15m ; ret = update retry 3w ; ex = expiry 2h ; nxttl = nxdomain ttl ) This slide shows an alternative method of defining the same SOA RR as in the previous slide to make use of the $ORIGIN substitution rule. (The rule applies to any name in the zone file.) Neither the pmns field (ns1) or the mail field (hostmaster) terminates with a dot (they are non- FQDNs) and the value of $ORIGIN (example.com.) will be appended resulting in exactly the same RR definition as in the previous slide. Whether this is more or less understandable is for you to decide. Copyright Zytrax, Inc. All rights reserved.

DNS - NS RR NS name NS RRs defines all Name Servers for the zone (Domain Name) At zone apex (infrastructure RRs) Minimum of two - may be in-zone or out-of-zone In-zone servers will need A or AAAA RRs name = name of an in-zone or out-of-zone Name Server that is authoritative for this domain NS RRs appear in the zone (authoritative) and the parent (point of delegation – not authoritative) The Name Server (NS) RR defines Name Servers that will answer Authoritatively for the zone or Domain Name. That is, they will load the zone file for the Domain Name. There must be at least two of them. They may be, as we have seen, Master and Slave(s), all Masters, or all Slaves. The difference is not visible within the zone file (it is determined by the DNS Name Server configuration not the zone file). All NS RRs appear at the zone apex (they have a blank name in the example zone file and will therefore substitute example.com. in the name field of the RR). All the RRs that appear at the zone apex (SOA, NS and MX) are sometimes referred to as infrastructure RRs and they respond to queries with a name (or names) not an address. This has interesting implications for TTL values that we will examine later. The Name Servers may be in-zone as in the definition of ns1.example.com. or out-of-zone as in the definition of ns2.example.net. Name Servers may be configured in a variety of ways. they may be Masters for one or more zones (Domain Names), Masters for some zones and Slaves for others or Slaves for one or more zones. It is very common for resilience purposes for a Domain Name owner to subcontract to one or more third party/parties operation of one or more of their Name Servers. Smaller sites may equally peer with a site with similar traffic volumes and agree to be each others Slave Name Servers. If the Name Server is in-zone it must have either an A (or AAAA) RR, if out-of-zone it must not have an A (or AAAA) RR (in point of fact the zone would fail to load if you did try to define an A (or AAAA) RR for an out-of- zone server. as we have seen and the The NS RRs (and associated A or AAAA RRs) for any Domain Name appear in two zone files. This Domain Name zone file where the NS RRs are regarded as Authoritative and the parents zone file (.com in this case) - called the point of delegation - where they are not Authoritative. At the parent, these NS RRs (and associated A or AAAA RRs) form the referral response. Copyright Zytrax, Inc. All rights reserved.

DNS – NS RRs ; name servers Resource Records for the domain IN NS ns1.example.com. ; could have been ; IN NS ns1 ; the second name server is external to this zone. IN NS ns2.example.net. The NS RRs defined in our example zone file. The first is an in-zone Name Server and consequently the A (or AAAA) RR for ns1.example.com must be defined in this zone file. The alternative format shown makes use of the $ORIGIN substitution by omitting the terminating dot. It is functionally identical to the previous one. The second NS RR cannot make use of the $ORIGIN substitution rule for obvious reasons and must use an FQDN. Copyright Zytrax, Inc. All rights reserved.

DNS – NS RRs $ORIGIN example.com. ; name servers Resource Records for the domain IN NS ns1.example.com. ; missing dot IN NS ns1.example.com ; looks for ns1.example.com.example.com. This slide simply shows the effect of an erroneously missing dot on the end of a name. Not something that you want to do too often. It is made worse by the fact that debugging is quite difficult. The zone is perfectly legal even with the strange name of ns1.example.com.example.com and will load normally with no errors or warnings. However, the Authoritative Name Server will not respond to queries for ns1.example.com. You could look at this zone file for a long time before figuring out the problem. We have all done it. Copyright Zytrax, Inc. All rights reserved.

DNS - MX RR MX priority name MX RRs list all incoming mail servers for the domain Defined at zone apex for this zone One or more priority = relative priority of defined server (low is most important). Value = 0 – 65535 name = name of an internal or external mail server for this domain In-zone servers will have A or AAAA RRs Mail EXchanger (MX) RRs allow external parties to find the mail server for incoming mail for the Domain Name (or zone). Again this RR sits at the zone apex and forms part of the infrastructure records in that it results in a name that requires a further query for the IP address. There may be one or more MX RRs for domains that receive mail. Domains that do not receive or wish to receive mail do not need an MX RR. priority - Is a number in the range 0 to and defines the relative priority of this MX RR (lowest number has highest priority). The number 10 that you see on many MX RRs has no special significance other that it means you can add a higher priority MX RR without changing this RR (but only 10 times). name - The name of the mail server that will accept incoming mail for this Domain Name (of the form in our case). This may be an in-zone server (in which case it will need a A or AAAA RR) or an out-of-zone server in which case it must not have an A or AAAA RR. Any number of MX RRs may be defined. There are many forms of mail service organization, especially for larger operators, where mail filesystems may be shared between multiple mail servers. For smaller operations the normal method is to use a backup or forwarding mail server (possibly peered with an similar sized Domain Name each acting as backup for each other). In this case a second MX RR will have a higher priority priority number (meaning a lower priority). If the normal mail server is not available or busy then sending MTAs (Mail Transfer Agents) will attempt to send to the second highest priority mail server (the backup or forwarding mail server). On receipt of the mail, this mail server will immediately try to forward the mail to the normal mail server for the Domain Name. Copyright Zytrax, Inc. All rights reserved.

DNS – MX RRs ; mail server Resource Records for the zone (domain) 3w IN MX 10 mail.example.com. ; the second mail server has lower priority and is ; external to the zone (domain) - backup IN MX 20 mail.example.net. 3w = TTL Priority 10 simply means you can add a more important mail server with only one change The configuration is explained in the comments. The use of long TTL values on infrastructure RRs may be worth amplifying because it sheds light on the nature of zone files and RRs more generally. The MX RR like the NS RR will yield a name when queried. A further query is required to get the IP address of the server that supplies the service (mail or name server). While it is possible that the IP address of the host that supplies the service may change, even quite fequently, there is no need to change the name on the NS or MX RRs. DNS translates a name to an IP address as its basic service (as we have seen it does a lot more as well but always in support of this basic name to IP translation). All network access (HTTP, SMTP, LDAP etc.) is to a IP address not a name. Thus, suppose we have a mail service which on the MX record yields a name of mail.example.com. Suppose further that this service runs on a host that is called superfastmailserver.example.com (the name in its Windows properties or with which it responds to a unix hostname command) which has the IPv4 address As long as there is a record in the zone that will translate mail.example.com to the IPv4 address (an A RR which we will look at next) every thing will work. DNS does not know about host names. It simply takes the name allocated by the Domain Name owner and defined in the zone file and supplies the answer. So the MX RR can continue to use the name mail.example.com essentially forever, while the A RR for mail.example.com may change as frequently as you want. Consequentially, the MX RR (and NS RR) can have very long TTLs with no risk and a 50% DNS load reduction for mail accesses. Copyright Zytrax, Inc. All rights reserved.

DNS - A RR A IPv4-address A RRs list all visible hosts for the zone (domain). Must include the in-zone NS and MX RRs plus others IPv4-address = standard dotted quad address x.x.x.x (address not a name) The A RR defines the IPv4 address associated with a specific domain name (such as Its format is relatively trivial in comparison with the previous RRs we have examined. The parameter is simply the IPv4 address in the convention IPv4 dotted quad notation (x.x.x.x). This parameter is an address not a name and does not require a terminating dot (.). All the visible hosts or services in the zone should be defined with A RRs. If NS or MX RRs reference in-zone servers they must appear as A (or AAAA) RRs in the zone file. Multiple A RRs may reference the same IPv4 address, thus, if both a mail service, say, mail.example.com (referenced in an MX RR) and web service, normally run on the same hardware the following is a perfectly valid zone definition: mail IN A www IN A DNS does not know about or care about the relation between the actual name of the host and its DNS name, thus in the above both the services could run on a host called joe.example.com. If joe was also made visible in the zone file (it does not need to be) then the following definition achieves this: joe IN A Multiple A records may be used to reference the same name. Assume that for resilience purposes we will run a web service on two hosts, the following definition does this: www IN A IN A Technically these two RRs form an RRset - defined as having the same name and type but a different parameter (the NS RRs in the example zone file form an RRset). Copyright Zytrax, Inc. All rights reserved.

DNS - AAAA RR AAAA IPv6-address AAAA RRs list all visible IPv6 hosts for the zone (domain). Mixed with A RRs Both A and AAAA if dual stacked IPv6-address = standard colon separated address (address not a name) The AAAA RR (called a quad A RR) is used to define an IPv6 address we mention it here only so you are aware it exists but is covered in detail in an IPv6 specific module. AAAA RR can be mixed with A RRs in the same zone file. Where a host is dual stacked (it has both IPv4 and IPv6 stacks) a single name can be mapped to both an A and AAAA RRs as shown: www IN A Ipv4-address IN AAAA ipv6-address Copyright Zytrax, Inc. All rights reserved.

DNS - CNAME RR CNAME canonical-name CNAME RRs maps an alias name to a canonical (real) name (in A or AAAA RRs) May point to a host name in-zone or out-of-zone canonical-name = real name of host CNAME costs extra access Alternate is to use multiple A or AAAA RRs CNAME is a method of aliasing one name to another. The term used is to map from a name to its canonical (real) name. In the A RR description we used this definition to map multiple services to a single host: mail IN A www IN A joe IN A Many people prefer to define the same configuration as shown below: mail IN CNAME joe www IN CNAME joe joe IN A Functionally there is no difference between these configurations. The second makes some people more comfortable because it tells the 'truth' (these services run on joe). The first means that if joe changes to a host called bill at the same IPv4 address then only one changes, in the second case all three RRs change. It's ultimately a question of personal taste not technical correctness. The only case where a CNAME RR must be used (as opposed to may be used) is where the name is redirected to an out-of-zone name. The example zone file shows this being used for an ftp service: ftp IN CNAME ftp.example.net. Copyright Zytrax, Inc. All rights reserved.

DNS – CNAME RRs ; aliases ftp (ftp server) to an external location ftp IN CNAME ftp.example.net. ; very common use of CNAME mail IN A www IN CNAME mail ; alternate – functionally identical www IN A Copyright Zytrax, Inc. All rights reserved.

DNS - TXT RRs TXT text TXT RRs may be used to contain any text Externally visible Overloaded to define Sender Profile Framework (SPF) RRs Used to define DKIM and DMARC RRs text = enclosed in quotes The TXT RR was originally used to simply provide a text (human readable) description associated with a name. However, because its format is very flexible (simple ASCII text inside a quoted string) it can, by specifying a particular format for the generic text string, be used by applications that do not have an explicit RR type. The text field may be said to be overloaded with multiple definitions. A number of mail abuse prevention systems use this overloading feature extensively, specifically, Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) and now Domain-based Message, Reporting and Conformance (DMARC). There is much furious debate and gnashing of teeth in the DNS community over whether this overloading is good or bad. Copyright Zytrax, Inc. All rights reserved.

DNS – TXT RRs ; uses of TXT ftp IN CNAME ftp.example.net. IN TXT “Supports FTP and SFTP” ; SPF TXT RR IN MX mail.example.com. IN TXT “v=spf1 ip4: /27 –all” ; DKIM TXT RR mail._domainkey IN TXT "v=DKIM1;t=s;p=blah....blah;" ; ADSP TXT RR _adsp._domainkey IN TXT "dkim=discardable;" Copyright Zytrax, Inc. All rights reserved.

Zone File – Best Practice
Comment file – changes made Always include $ORIGIN $ORIGIN is optional defaulted to name of zone Bad practice – non-self documenting Use consistent style FQDN on right names, or left names or both Don't be too smart - someone else may have to maintain the zone files Use meaningful names - why have the example.com zone file in anything but a file called example.com This slide attempts to identify some best practices for writing zone files. Some are common sense, some reflect this author's prejudices, some reflect mistakes made over the years. They are certainly not intended to be hard-and-fast rules but perhaps cover ground that need to be considered. If anything goes wrong the chances are high it was caused by the last modification. The law of unintended consequences haunts us all. Documenting changes in the zone files is a pain, but it does make sense, especially if someone else has to debug the problem. Further, commenting specific items in the configuration that are non-intuitive also makes sense. Many zone file examples on the Internet do not use $ORIGIN statements (all DNS software will synthesize one silently). I consider this foolish for three reasons. First, in complex zone files such as reverse maps it is practically essential to include the $ORIGIN to avoid getting into a real mess. Second, if you are handed a zone file without an $ORIGIN it is practically impossible to figure out the Domain Name it is applicable to. You need two pieces of information, the zone file and the zone name, from two sources to figure out what you are looking at. I like self-documenting files. Everything in one place. Whatever style you use for the use of FQDN/non-FQDN - be consistent. I use non-FQDNs on the left, FQDNs on the right. Especially at the beginning a consistent style can avoid problems. DNS provides many ways to produce super-short zone files - mostly such files simply turn a 1 minute job for the next guy who looks at them into a 20 minute job. Big deal. But it can also be fun to push the limits! DNS has many things that have to be learned and remembered. Files names invented by some guy 25 years ago, for excellent reasons at the time no doubt, are not one of them. Make files work for you. Finally, one confusing thing about reverse maps is the reversal of the address components. We always name reverse files in their forward direction and append .rev thus the reverse map for in-addr.apa will be named rev. Copyright Zytrax, Inc. All rights reserved.

Required Zone Files Depends on name server function Authoritative - only Domain Name zone file Resolvers - depends on where Resolver - Forward and reverse map for localhost zone Forward domain = localhost ( ) Reverse map in-addr.arpa Resolver - Hints file – points to root-servers Reverse map private IPs ( x, 10.x.x, x) Depending on the function of the Name Server (Authoritative or Resolver) one or more zone files may be required. In the case of Authoritative Names Servers only the zone files for which the server is authoritative are required. Resolvers are a little more complicated. Most resolvers tend to provide zone files for the forward and reverse maps for localhost (we will look at these files in the next slides). It is a good idea since it will 'trap' any requests coming from local PCs (in the case of normal, well configured, PCs localhost is normally defined in the hosts file and does not even touch the DNS. However, as we all know, not all PCs are normal or well-configured. Area resolvers always need the so-called hints file (the zone file for the root-servers, which we pathologically rename to root.servers). (In practice this list is so stable that most DNS resolver software has a compiled-in list if the user forgets this zone file.) In case of a local full-service resolver (on-site) it is good practice to include a reverse map for local IP address blocks (10, , 192,168) address blocks. Partly, because it may be essential (local mail services) and partly, because it 'traps' them from the DNS hierarchy where they will simply consume resources and end with a failure. Above the local site level it also makes sense to include reverse map files for their ability to trap useless queries not because they will give useful results. The latest version of BIND include this feature automatically (without requiring zone files) to reduce unwanted traffic. Copyright Zytrax, Inc. All rights reserved.

Hints (root.servers) Zone file
; ; last update: Jan 29, 2004 ; related version of root zone: ; formerly NS.INTERNIC.NET IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET A … This is a snippet from a zone file covering the root-servers (and which we pathologically rename as root.servers). It is a normal zone - nothing special. The Domain Name of the root is dot(.). Hence all 13 root-servers live under this name as shown for the NS RR for a.root- servers.net above and has a corresponding IPv4 address for this server (most root-servers now have IPv6 addresses as well) Copyright Zytrax, Inc. All rights reserved.

Local Host Forward Map $TTL ; 24 hours could have been written as 24h or 1d $ORIGIN localhost. @ 1D IN hostmaster ( ; serial 12h; refresh 15m ; retry 1w ; expiry 3h ; nxttl ) @ 1D IN ; localhost is the name server 1D IN A ; always returns the loop-back address This is a commented version of the localhost forward map zone file that comes with most DNS software distributions. It uses almost every trick in the book to reduce the zone file size. Note: While the requirement for Domain Names delegation is that they need a two or more NS RRs the zone will load even if only one is present. Further, the $TTL format is in seconds meaning it can be loaded by any DNS software, while times used for refresh, retry, expiry and nxttl use a short form meaning they cannot. Copyright Zytrax, Inc. All rights reserved.

Alternate Format $TTL 1d ; $ORIGIN localhost. localhost. IN SOA localhost. hostmaster.localhost. ( ; serial 3H ; refresh 15M ; retry 1w ; expire 3h ; nxttl ) localhost. IN NS localhost. ; localhost is the name server localhost. IN A ; the loop-back address This is an alternative version of the localhost forward zone file that is functionally identical to the previous one showing how many options are available for writing zone files. This file is called localhost.zone with most distributions (we rename it master.localhost) Copyright Zytrax, Inc. All rights reserved.

Localhost Reverse Map $TTL ; 24 hours ; could use $ORIGIN IN-ADDR.ARPA. @ IN SOA localhost. hostmaster.localhost. ( ; Serial 3h ; Refresh ; Retry 1w ; Expire 3h ) ; nxttl IN NS localhost. IN PTR localhost. The localhost reverse map zone file. Less tricks are available for use with reverse map zone files. This file is typically called named.local in most distributions (we always rename it localhost.rev). Copyright Zytrax, Inc. All rights reserved.

RPZ RR Subset $TTL directive $ORIGIN directive SOA RR NS (only one required) CNAME - used by most RPZ Policy Triggers for redirection or Policy Action keywords A/AAAA - can be used for redirection Copyright Zytrax, Inc. All rights reserved.

Quick Quiz What is the first record in a zone file? What does the $ORIGIN directive do? How does the slave know to transfer zone? What value defines how long an RR can be cached? Copyright Zytrax, Inc. All rights reserved.

Zone Files DNS Courses - Revision Lecturer: Ron Aitchison

Similar presentations

Presentation on theme: "Zone Files DNS Courses - Revision Lecturer: Ron Aitchison"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Zone Files DNS Courses - Revision Lecturer: Ron Aitchison

Similar presentations

Presentation on theme: "Zone Files DNS Courses - Revision Lecturer: Ron Aitchison"— Presentation transcript:

Similar presentations

About project

Feedback