207.2. Create and maintain DNS zones
207.2 Create and maintain DNS zones
Weight: 3
Description: Candidates should be able to create a zone file for a forward or reverse zone and hints for root level servers. This objective includes setting appropriate values for records, adding hosts in zones and adding zones to the DNS. A candidate should also be able to delegate zones to another DNS server.
Key Knowledge Areas:
BIND 9 configuration files, terms and utilities
Utilities to request information from the DNS server
Layout, content and file location of the BIND zone files
Various methods to add a new host in the zone files, including reverse zones
Terms and Utilities:
/var/named/
zone file syntax
resource record formats
named-checkzone
named-compilezone
masterfile-format
dig
nslookup
host
DNS Zones
Configuring BIND DNS server to work as a forwarder or caching DNS server was pretty easy but some times we need to map our host names to IP addresses in our own network. So we need information about zones which are not defined in any other DNS servers in the world, consequently Forwarding or Caching don't work in this scenario.
As we said We have two different types of DNS queries , forward queries and recursive queries, as a result , we need two types of zones for answering both types.
forward zone
reverse zone
A forward lookup zone will, when supplied with a domain name (for example google.com), return the IP address for the supplied domain. When we access Google, a DNS server is looking in its forward lookup zone for the IP address(es) of the site, and then returning them to us. This type of record is an A record, and is the most common. A forward lookup zone can contain other records, such as MX, C-Name etc. An Example of forward lookup zone:
A reverse lookup zone is used to lookup the domain name when supplied with an IP address. We normally supply the IP address backwards and append .in-addr.arpa .The reverse lookup zone contains PTR resource records. A PTR record allows doing a reverse lookup by pointing the IP address to a host/domain name. When doing reverse lookups, these PTR records are used to point to A resource records. An example of Reverse Zone file:
DNS Zone Syntax
Some syntax explanation:
One important thing to understand here is the $ORIGIN entry, which is used to make all other entires in the zone file a FQDN. FQDN stands for Fully Qualified Domain Name, and it always ends with a dot (.). FQDN stands for Fully Qualified Domain Name, and it always ends with a dot (.)
@ shown in the above line is the NAME value for this SOA record. Using @ at this place will replace it with example.com (as we have mentioned it in $ORIGIN ).
The ‘;’ character in the example above indicates that the rest of the line is a comment that should be ignored by the nameserver.
Also note the trailing dot (‘.’) after each record referring to a hostname. Without the dot, the nameserver appends the current zone after the record. For example, srv1.example.com would be interpreted as srv1.example.com.in-addr.arpa.
In previous lesson we had a short over view over different types of DNS records, lets explain more and see how syntax look like:
Start of Authority (SOA) record
Start Of Authority (SOA) Record: is the first record in a properly configured zone. It contains information about the zone in a string of fields. An SOA record tells the server to be authoritative for the zone. The SOA record takes the format:
Where:
domain.name:The name of the domain to which the SOA belongs. Instead of writing out the full domain, you can also use ‘@’ in the file to let the nameserver fill this out automatically. Example:
IN:The class of the DNS record. ‘IN’ is an abbreviated form of ‘Internet’.
SOA:The type of DNS record, which in this case is ‘Start of Authority’.
hostname.domain.name: Also known as the ‘hostmaster’ field. It contains the e-mail address of the person responsible for maintaining the zone. No ‘@’ is used in this field. use "." instead.
me@example.comwould beme.example.com.serial-number: The serial number of the current version of the DNS database for this domain. If a secondary server’s number is lower than the number of the primary server, it indicates that the secondary server’s records are out of date and that it requires a zone transfer from the primary server.
refresh : This tells a secondary server how often to poll the primary server and check for changes in the serial number field. Measured in seconds.
retry: If a refresh attempt fails, a secondary server will retry after the interval specified in the retry field. Measured in seconds.
expire: If the refresh and retry attempts fail, the secondary server will stop serving the zone after the period specified in the expire field. Measured in seconds.
minimum-ttl: The default TTL (Time To Live) for every record in the zone. The default is only used when a particular resource record does not have its own specified TTL value. When changes are being made to a zone, the default is often set at ten minutes or less.
Example:
Another Example for SOA record in reverse Zone:
Address Type (A) records
Defines a direct ' name to address' translation
Example:
server1 IN A 192.168.10.111
or it can be given relative to the current domin ( i.e: just 'server1')
server1 IN A 192.168.10.111
Canonical Name (CN) records
Allows us to define a host with more than one name (or role) in our doman
<alias-name> IN CNAME <real-name>
Example:
Nameserver (NS) records
Every domain can have one (or more) name servers.They are defined as a NS (name server) record. The NS record takes the format:
and the fileds are:
domain. name :The name of the domain to which the NS belongs. Instead of writing out the full domain, we can also use ‘@’ in the file to let the nameserver fill this out automatically.
IN : The class of the DNS record. ‘IN’ is an abbreviated form of ‘Internet’.
NS: The type of DNS record, which in this case is ‘Name Server’.
hostname.domain.name: The hostname of an authoritative server.
Although the master name server is also defined in the SOA record, that server must have a full entry in the NS record definition
Example:
Mail Exchange (MX) records
Sending E-Mail services (MTA- mail Transfer Agents) have to be able to figure out which host handles emails for the zone/domain, we do this by creating one or more MX records:
Example:
The two records define two mail servers, the number indicates the priority (order) they should be tried for mail delivery. They can be different numeric priorities for primary and backups OR they can be the same if intended to be used in a loas balanced configuration.
Pointer (PTR) records
This record type is used in reverse lookup zone files, so that the IP address can be translated to the name.Note not all records have to have or will have a reverse lookup PTR record necessarily. The following illustrates the layout of a PTR record:
For the address ‘192.168.10.155’, this would be:
155.10.168.192.in-addr.arpa. IN PTR svc00.apnic.net.
or if the SOA record for the zone already states the in-addr.arpa domain in full, we do not need to write this out again. Instead, we can only to write the last dotted quad from the address:
155 IN PTR svc00.apnic.net.
Other Records Types
There are other types, but these are the most common and are the specific types we should be aware of for the lpic2 exam.
Once we have created all the Zones and reverse Zones and relevant PTR records for our in-addr.arpa zone, the next step is to load them into our name servers. but How and where to do that ?
/var/named
Zone files contain information about a namespace and by default they are stored in the named working directory (/var/named/)
But it can be different based on our distro or configuration.
We use ubuntu and fresh BIND installation so Lets go back to /etc/bind to see zone files which were installed during BIND installation:
in named.conf.default-zones all root DNS Servers have been defined here.
all files which are started with db are zone files.
named.conf.options contains all the configuration options for the DNS server
named.conf.local is defining our local host zones
how ever these files and their names might be differentin different distroes, But generally name.conf and other related files if exist are consist of some sections and statements which must be defined to work:
Options statement
Zones statement
1.Options statement
in named.conf.options file we can define system wide options:
There are many options which can be defined here some of them are:
allow-query : Specifies which hosts are allowed to query this nameserver. By default, all hosts are allowed to query. An access control list, or collection of IP addresses or networks, may be used here to allow only particular hosts to query the nameserver.
allow-recursion: Similar to allow-query, this option applies to recursive queries. By default, all hosts are allowed to perform recursive queries on the nameserver.
blackhole :Specifies which hosts are not allowed to query the server.
directory: Specifies the named working directory if different from the default value, /var/named/.
forwarders: Specifies a list of valid IP addresses for nameservers where requests should be forwarded for resolution.
forward: Specifies the forwarding behavior of a forwarders directive. The following options are accepted:
first — Specifies that the nameservers listed in the forwarders directive be queried before named attempts to resolve the name itself.
only — Specifies that named does not attempt name resolution itself in the event that queries to nameservers specified in the forwarders directive fail.
listen-on :Specifies the network interface on which named listens for queries. By default, all interfaces are used.Using this directive on a DNS server which also acts a gateway, BIND can be configured to only answer queries that originate from one of the networks.The following is an example of a listen-on directive:
So , only requests that arrive from the network interface serving the private network (10.0.1.1) are accepted.
notify :Controls whether named notifies the slave servers when a zone is updated. It accepts the following options:
yes — Notifies slave servers.
no — Does not notify slave servers.
explicit — Only notifies slave servers specified in an also-notify list within a zone statement.
and many many more sophisticated options.
2.Zones statement
usually zone ifnormation are defined in named.conf.local file, lets vim named.conf.local :
As it says we need to define our local zones here, but unfortunately there is no predefined configuration! How is the syntax?
A zone statement defines the characteristics of a zone, such as the location of its configuration file and zone-specific options. This statement can be used to override the global options statements. A zone statement takes the following form:
In this statement, <zone-name> is the name of the zone, <zone-class> is the optional class of the zone, and <zone-options> is a list of options characterizing the zone.
The <zone-name> attribute for the zone statement is particularly important. It is the default value assigned for the $ORIGIN . The named daemon appends the name of the zone to any non-fully qualified domain name listed in the zone file.
The most common zone statement options include the following:
allow-query :Specifies the clients that are allowed to request information about this zone. The default is to allow all query requests.
allow-transfer :Specifies the slave servers that are allowed to request a transfer of the zone's information. The default is to allow all transfer requests.
DNS Dynamic updates
While the records could be manually entered as static DNS records, it would be ideal if the process were more "dynamic". When thinking of the security, it will be very, very stupid to allow anybody to update records.Most servers simply don't allow dynamic updates and those who do, don't allow it for all zones, or allow updating a zone from specific subnet or specific IP-addresses.
For the most part, dynamic update functionality is used by programs like DHCP servers that assign IP addresses automatically to computers and then need to register the resulting name-to-address and address-to-name mappings.
It's also possible to create updates manually with the command-line program nsupdate, which is part of the standard BIND distribution.
allow-update :Specifies the hosts that are allowed to dynamically update information in their zone. The default is to deny all dynamic update requests.Be careful when allowing hosts to update information about their zone. Do not enable this option unless the host specified is completely trusted. In general, it is better to have an administrator manually update the records for a zone and reload the named service.
file :Specifies the name of the file in the named working directory that contains the zone's configuration data.
masters :Specifies the IP addresses from which to request authoritative zone information and is used only if the zone is defined as type slave.
notify :Specifies whether or not named notifies the slave servers when a zone is updated. This directive accepts the following options:
yes — Notifies slave servers.
no — Does not notify slave servers.
explicit — Only notifies slave servers specified in an also-notify list within a zone statement.
type:Defines the type of zone.Below is a list of valid options:
delegation-only — Enforces the delegation status of infrastructure zones such as COM, NET, or ORG. Any answer that is received without an explicit or implicit delegation is treated as NXDOMAIN. This option is only applicable in TLDs or root zone files used in recursive or caching implementations.
forward — Forwards all requests for information about this zone to other nameservers.
hint — A special type of zone used to point to the root nameservers which resolve queries when a zone is not otherwise known. No configuration beyond the default is necessary with a hint zone.
master — Designates the nameserver as authoritative for this zone. A zone should be set as the master if the zone's configuration files reside on the system.
slave — Designates the nameserver as a slave server for this zone. Also specifies the IP address of the master nameserver for the zone.
zone-statistics :Configures named to keep statistics concerning this zone, writing them to either the default location (/var/named/named.stats) or the file listed in the statistics-file option in the server statement
Implementing Basic BIND DNS Server
With that, Lets create forward and reverse zones for imaginary zone, named "myzone":
as you see we also declared where BIND daemon can find zone db files.To create zone db files we use existing samples:
and now we need to edit these two useful samples, lets start with db.myzone:
to verify zone file:
and next db.10.168.192 .Please note that there is not a one by one relationship between Forward Lookup zone and Reverse Lookup zone, so usually CNAME records are not defined in reverse zone:
to check the reverse zone:
also we cloud have used named-checkconf to check the configurations:
and finally we use rndc to reload configurations without losing cache:
Finally to check the results:
and
and to check reverse lookup:
Implementing Master / Slave BIND DNS servers
In previous Lesson we talked about master / slave DNS server and zone transfer, Let implement that with two ubuntu servers.
We have server1(192.168.10.129) as a master DNS server and server2(192.168.10.151) as a slave
Lets start modifying name.conf.local to allow zone transfer in master server by adding allow-transfer :
To check bind configuration for errors:
also we need to define both Name servers in Zone cofiguration file:
Okey lets go to the slave side:
and check for bind service if its not running :
But hey stop! bind can tranfer zones just if required ports are opened in the firewall.
BIND9 Ports
UDP 53 and TCP 53 ports need to be open for the Domain Name Service (DNS BIND server) to function properly:
UDP port 53 – This is primarily used by clients to make dns queries which are less than or equal to 512 byes. If the DNS server response data exceeds 512 bytes, the UDP query will fail and client will retry using TCP port 53.
TCP port 53 – This is used to get when response data exceeds 512 bytes. The zone trasfer between master and slave is also done using TCP port 53.
to open tcp and udp port 53 on both side:
and on slave server:
to check weather port 53 is open and ready, telnet each side from other side:
and the other side:
let cat /var/log/syslog to see what has happened:
To verify if our slave is working properly or not:
and we are done. Now we can dig slave server even if the master goes off.
we still can query slave server:
lets see where slave server has made our zone file:
As we said slave server information is some how read only, let check if we can edit zone file or not:
Well. That is impossibel, the slave zone files are now saved in a default raw binary format. This was done to improve performance, but at the sacrifice of being able to easily view the contents of the files. it can make debugging more difficult. In order to view the raw binary content, it must be converted to text first.There is command named-compilezone which help us to convert raw bind zone data to text and visa versa.(Its useful if we have challenge between different BIND servers versions also ) :
Saving salve zone files in default raw binary format is an added layer of complexity, but if we need the microscopic performance boost, that’s the way to go. If we want BIND to use the text file format, we simply update the named.conf files for ourslave zones to include the line masterfile-format text; and done! for example:
okey go back and forget these tricks, lets start master server and let them work:
now we can edit zone file in master and consequently slave server will be updated, but do not forget to increase serial number. (We have edited host2 to host3 with ip address 153) :
and dig slave for changes:
also we can use dig AXFR @masterdnsserver yourdomain.com to complete zone transfer if its allowed . That is all we are done!
Last updated