Chapter 4. DNS services

Table of Contents

DNS
Architecture
Flows and feeds
Administration
Monitoring
Operations
Users
Security
BIND
From records to views
Deployment and uses
Using bind
Logging
Resources

DNS

So with the structure (and thus network/IP map) in place the first component up is DNS.

DNS, or Domain Name System, allows resources on the network to be reachable through a human-readable name rather than an obscure ID that is useful for computers and routers. To support human-readable names, a DNS service is positioned which helps in translating these domain names onto IP addresses and vice versa. But next to the name resolving, DNS infrastructure is also positioned for various other purposes.

Figure 4.1. DNS services

DNS services

For instance, a mail client can interact with the DNS server of a domain to find out where to send e-mails to that are meant for that domain. This information is stored in the MX records of that domain. Recently, standards are emerging to counter e-mail spoofing, like SPF (Sender Policy Framework) and DKIM (DomainKey Identified Mail). In case of SPF, a DNS record tells whoever asks it which (IP) addresses are allowed to be sending e-mail that seems to originate from its domain. Mail servers will then check this record to see if an incoming e-mail indeed comes from this location and if not, can reject the e-mail. DKIM on the other hand uses digital signatures in the mail itself, where the mail servers then check the signature based on the public key that is stored in a DNS record of the domain that the mail seems to originate from.

Another example of a service offered by DNS is documenting the SSH finger print of servers. SSH fingerprints are cryptographic hashes of the public key (and some additional information about it) used by the SSH service of a particular server. This fingerprint can then be added to the DNS server, and users that connect to an SSH server can verify if the fingerprint they receive is indeed the one expected to be from that server. If not, then they might be connecting to a malicious server.

Having a well performing DNS architecture is extremely important as many services will rely on DNS to know how to contact other resources: although it is perfectly possible to use IP-only configurations, this is a lot less flexible and less transparent - and with IPv6 this will become even more difficult. Because of that, DNS must definitely be high available. Depending on the size and use, DNS caching daemons can be positioned across the network.

Figure 4.2. Simple DNS architecture

Simple DNS architecture

In the above architecture, two DNS servers are positioned (most likely in the DMZ) set up in a high-available manner (where a slave system pulls in changes from a master), and two internally with a similar setup. The distinction between the DMZ and the internal ones is that the internal DNS servers will host a lot more information needed for the internal components, whereas the ones on the DMZ only contain information for the publicly available services.

In both cases (DMZ and internal), a configuration management database is responsible for providing the addresses and names.

Architecture

Many organizations will host their own domain name servers, and perhaps have a third one outside their premises as a fall-back. In this reference architecture, BIND is used as the DNS software of choice. Name servers such as BIND structure their contents in zones. A zone is a set of IP addresses, hostnames and affiliated information, most often for one domain. So genfic.com is one domain (one zone) whereas internal.genfic.com is another domain (zone).

Flows and feeds

Within the DNS server setup, the following flows are defined:

  • zone transfer flow

  • zone configuration

Figure 4.3. Flows and feeds

Flows and feeds

Zone transfer flow

The zone transfers are to update the slave(s).

Zone configuration

Updates on the zones themselves are triggered through the configuration management service, where new (or to be deleted) zones are created and then uploaded towards the name server.

Administration

Administration of the DNS server is done through the configuration management service (Puppet) and manual operations (SSH).

Figure 4.4. BIND administration

BIND administration

The configuration for the server (and BIND) is first pulled from the configuration management repository (through a git pull, most likely scheduled or triggered by the administrator) after which the (re)configuration of BIND is done. This results in updates on the named.conf file. The rndc command is used to interact with the named daemon itself.

Monitoring

The monitors for BIND should do at least the following checks:

  • See if the processes are running (and bound on a reachable interface)

  • See if there are any errors mentioned in the logs

  • See if the named server returns proper records (check on various types, DNSSEC info, etc.)

  • See if the serial of the master and slave is the same

Figure 4.5. BIND monitoring

BIND monitoring

Process running and bound to the right interface

Checking if processes are running is a primitive check, but quite important to troubleshoot potential failures. The check should also include validation that the processes are bound on reachable interfaces - a named daemon that only runs on localhost is not reachable through the network.

Errors in logs

Validate that there are no errors in the logs, and assign proper procedures when certain, well-known errors occur.

Record retrieval

On a remote system, dig can be used to retrieve a set of records and validate that the return value is correct (and perhaps also within the time boundaries).

Serial validation

The serial (which is the version of the zone files) should be the same on the master and slave. If this is not the case, the monitor should check with the previous state (master and slave are allowed to be not synchronized for a very short while) and if that previous state was also showing differences in serial version, then an alert should be raised that the zone transfer between master and slave is most likely not working.

Operations

When running, BIND is a fairly simple daemon from an architectural point of view.

Figure 4.6. Standard operation usage of BIND

Standard operation usage of BIND

Network-wise, it interacts with two other services: other BIND servers (for zone transfers) and with standard clients (for querying the DNS records).

On the system, the interaction is mainly with the system logger (over a socket). The resources that the named daemon uses are its configuration (and cryptographic keys if applicable) and its zone files.

Users

DNS services are, by default, anonymous services. Some access controls are often placed to restrict who can (from a network point of view) query the DNS service or send/receive data from (in case of pull requests/zone transfers), and more tight access controls (like shared keys) can be used to further authenticate such activities. However, real "users" are not known in the BIND setup.

That being said, the SELinux policy for BIND does provide an administrative interface, supporting the definition of roles that are allowed to administer a BIND environment without granting those users full administrative access on the system. The interface is called bind_admin and takes two arguments: the user domain allowed access and its role.

bind_admin(<userdomain>, <userrole>)

Security

DNS services are widely available and are a high-profile target for hackers and malicious persons or organizations. If someone could change the DNS records for a domain, then it can have users visit different sites (which are made to look like the official site) which might allow the perpetrator to get access to authentication credentials, confidential information and more. He only needs to modify the IP address replies that the DNS server would give and have them point to its own website. This is called DNS hijacking, and does not only introduce the risk of "spoofed websites", but also changes in e-mail flows (for instance, the malicious user changes the MX records to point to his own e-mail server so he can watch and even modify e-mail communication to the official domain).

To provide some level of protection against these threats, a number of security changes are recommended:

  • If the registrar supports DNSSEC, then enable DNSSEC on the zones as well. With DNSSEC, the resource records in the zone are digitally signed (by private keys) and that key is signed by the parent domain (hence the need for the registrar and higher-level domains to support it too).

    This provides some additional protection against DNS hijacking, although it is not perfect (end users must use DNSSEC for their lookups and should have a valid trusted keystore containing the root DNS server keys).

  • Enable SPF (Sender Policy Framework) so that mail servers who receive an e-mail that is supposed to be sent by the official locations (or someone within the environment), then the mail server can check the origin address against the SPF records in the DNS to validate if they match or not.

  • Enable DKIM (DomainKey Identified Mail) to sign outgoing e-mails and provide the DKIM public key in the DNS records so DKIM-supporting mail servers can validate the signatures.

  • Enable DMARC (Domain-based Message Authentication, Reporting and Conformance) to receive reports on how mails from that domain are treated, as well as identify which protective measures the domain takes

DNSSEC

The DNSSEC structure adds in a number of DNS records that help with the authentication of the DNS data, as well as verification of the integrity of this data. This protects the DNS records from both hijacking as well as tampering.

Figure 4.7. DNSSEC overview

DNSSEC overview

The idea is that a record (in the example the record for www.genfic.com) has its various types signed. In the example, two types are provided (A and AAAA), each of these has its own signature in an RRSIG (Resource Record Signature) field. The RRSIG fields are digital signatures made with a private key called the ZSK (Zone Signing Key) of which the public key part is available in the zone, in a DNSKEY (DNS public Key) field. This field is also signed by a private key called the KSK (Key Signing Key) also available in a DNSKEY field in the zone.

Now, to verify that the KSK public key is the proper key, it is also signed with the KSK private key, but also by the zone signing key of the parent domain (in our example, the .com zone). This domain has a DS (Delegation Signer) field in the genfic.com zone record, which contains a hash of the genfic.com KSK public key (the field itself), and this hash is signed through the parent zone RRSIG field.

In the drawing NSEC (Next Secure) fields are also shown. This "chains" multiple secure records with each other, providing a way for requestors to make sure a record really does not exist (upon retrieval of a nonexisting record, the DNS server replies with data pointing out that between records 1 and 2, there is no record for the requested one).

Next to NSEC, it is also possible to use NSEC3. NSEC3 covers one of the possible security holes that NSEC provides: malicious people can "walk" across all the NSECs to get a view of the entire zone. For fully public zones, this is not an issue, but many DNS servers want only to expose a few of the records in a zone, and NSEC requires that all records are public. With NSEC3 (DNSSEC Hashed Authenticated Denial of Existence) not the record name itself (like "www") but a hashed value of it is used. This prevents "walking" over the entire zone, while still providing validation that records do (or don't) exist.

SPF - Sender Policy Framework

In SMTP (Simple Mail Transfer Protocol) mail clients need to pass on information about the mail they are sending. It starts with the HELO (or EHLO) statements, telling the mail server who the client system is, followed by information whom the mail is from (MAIL FROM) and to who the mail should be sent (RCPT TO):

220 mail.internal.genfic.com
> HELO relay.internal.genfic.com
250 relay.internal.genfic.com Hello relay.internal.genfic.com [10.24.2.3], pleased to meet you
> MAIL FROM: <someone@genfic.com>
250 someone@genfic.com... Sendor ok
> RCPT TO: <otherone@genfic.com>
250 otherone@genfic.com... Recipient ok (will queue)
> DATA
354 Enter mail, end with "." on a line by itself
...

A first check that mail servers (should) do is validate that the fully qualified hostname provided through the HELO (or EHLO) commands really comes from that host. If it doesn't, then it is possibly a fake mail. But other than that, there are little checks done to see if the mail is truly sent from and to those mail boxes.

With SPF mail servers will do one or two more checks:

  • the mail server will first check if the host (as provided by the HELO/EHLO) is allowed to send mails, and

  • the mail server will then check if this host is allowed to send mail for the given domain (as provided by the MAIL FROM)

For this to happen, specific fields are added to the host record:

.genfic.com.  IN  SPF  "v=spf1 mx a -all"
.genfic.com.  MX  10   relay.internal.genfic.com

relay.internal.genfic.com   IN   SPF   "v=spf1  ip4:10.24.2.3 a -all"
relay.internal.genfic.com    A   10.24.2.3

The SPF records can be read as:

  • Mails sent for the genfic.com domain are allowed to be sent from any system that is defined as an MX record; all others are denied

  • The relay.internal.genfic.com system is allowed to send mail (as long as it is really this system, with IP 10.24.2.3).

DKIM

DKIM (DomainKeys Identified Mail) uses cryptographic signatures on the e-mail (and important headers of the e-mail) to provide authenticity on the mail. Mail servers that use DKIM will sign the outgoing e-mails with a private key (whose public component can be obtained through DNS, on the <hostname>._domainkey.<domain> TXT record). Receiving mail servers can then validate that the mail they receive, if it has a DKIM signature, has not been tampered with along the way.

A mail can have DKIM signatures of non-authorative domains though (domains that are not related to the mail). An extension on DKIM, called ADSP (Author Domain Signing Practices) provides a signature that is authenticated through the same domain as the mail says it is from. If ADSP is used, then an additional TXT record exists that informs recipients of this. Recipients should check this field to see if they should find a proper DKIM signature (from that domain) or not.

This TXT record is for _adsp._domainkey.<domain>.

DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) is used to inform other systems how to treat non-conformance (if mails are not according to the SPF requests, or DKIM signatures are missing, or...). This information is available through the _dmarc.<domain> record and uses tags (similar to SPF).

.genfic.com    TXT    "v=DMARC1 p=quarantine pct=20 rua=mailto:dmarc@genfic.com sp=r aspf=r"

The above record tells other parties that:

  • If mails fail the DKIM/SPF checks (generally called the DMARC checks), then 20% of those mails should be quarantined. Daily reports are sent to dmarc@genfic.com

  • The policy for subdomains (sp) is relaxed

  • The alignment mode for SPF (aspf) is related

BIND

On the Internet, Berkeleys Internet Name Domain (BIND) server is the most popular DNS server to date. It has been plagued by its set of security issues, but is still very well supported on Gentoo (and other) platforms. The software was originally developed at Berkeley in the early 80s in an open source model. Since 2010, the software is maintained by the Internet Systems Consortium.

Because it has such a large history, it has also seen quite a few updates and even rewrites. The current major version (BIND 9) is a rewrite that was tailored to answer the various secrity-related concerns that came from earlier versions. Sadly, even BIND 9 has seen its set of security vulnerabilities. Although a new major is in the making (BIND 10) it is not made generally available for production use yet.

From records to views

For DNS, the smallest set of information it returns is called a record. Records are grouped together in domains, and domains are grouped in zones. Within a record, there are 6 fields (including the name of the record and the type). In the next few sections, the syntax as used by BIND is described although the concepts are the same for other DNS servers.

Record structure

When an IP address for a host name is declared, this actually maps on a DNS record:

www    IN  A      192.168.0.2

This record states that, within the domain that this record is a part of, that 'www.<domain>' resolves to 192.168.0.2. Type type of the record here is A. An IPv6 address would result in a AAAA record.

mail   IN  AAAA  2001:db8:10::1

For the same host, there can be multiple records as long as they are of a different type (and don't make the definitions ambiguous).

www    IN  A     192.168.0.2
       IN  AAAA  2001:db8:10::1

There are many record types available (and more are being defined every few years). For instance:

  • CNAME which says that the given host name is an alias for another record

  • LOC provides location information for servers

  • SSHFP gives the SSH finger print information for a server

etc...

Domains

Multiple records are combined within a domain.

; Comments are prepended with a semi-colon
$TTL 24h ; If records do not hold TTL information themselves, use this as default
$ORIGIN internal.genfic.com.  ; Domain that is defined here
@  1D  IN  SOA ns1.internal.genfic.com. hostmaster.genfic.com. (
         2013020401 ; serial
         3H ; refresh
         15 ; retry
         1w ; expire
         3h ; minimum
       )
       IN  NS     ns1.internal.genfic.com. ; in the domain

In the above example, the @ sign is shorthand for the domain ($ORIGIN).

The first record in the domain declaration is the SOA record, and after this record there is an NS record.

Zone

One (or more) domains (and their affiliated records) are stored in a zone file. A zone is a specific space within the global Domain Name System that is managed (administered) by a single authority. Other DNS servers might also serve the same zone, but they will not be marked as the authoritative DNS service for that zone.

View

A view is not DNS specific, but a feature that many DNS servers offer. A view uses different zone files depending on the requestor. For instance, a DNS server might serve both Internet-originating requests as well as internal requests. Internet-originating requests thus need to receive the Internet-facing IP addresses as replies, but internal requests can use internal IP addresses.

public-host$ dig +short @ns1.genfic.com www.genfic.com A
123.45.67.89
intern-host$ dig +short @ns1.genfic.com www.genfic.com A
10.152.20.12

Deployment and uses

Configuring BIND on Gentoo Linux is fairly similar as configuring BIND on other platforms. There are plenty of good and elaborate resources on BIND configuration on the Internet, some of which are mentioned at the end of this chapter.

Installing bind

First, install net-dns/bind. An overview of the USE flags used here is shown as well as output of the equery command.

# equery u bind
[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for net-dns/bind-9.9.2_p1:
 U I
 - - berkdb      : Adds support for sys-libs/db (Berkeley DB for MySQL)
 + + caps        : Use Linux capabilities library to control privilege
 + + dlz         : Enables dynamic loaded zones, 3rd party extension
 - - doc         : Adds extra documentation (API, Javadoc, etc). It is recommended \
                   to enable per package instead of globally
 - - filter-aaaa : Enable filtering of AAAA records over IPv4
 - - geoip       : Add geoip support for country and city lookup based on IPs
 - - gost        : Enables gost OpenSSL engine support
 - - gssapi      : Enable gssapi support
 - - idn         : Enable support for Internationalized Domain Names
 + + ipv6        : Adds support for IP version 6
 - - ldap        : Adds LDAP support (Lightweight Directory Access Protocol)
 - - mysql       : Adds mySQL Database support
 - - odbc        : Adds ODBC Support (Open DataBase Connectivity)
 - - postgres    : Adds support for the postgresql database
 - - python      : Adds optional support/bindings for the Python language
 - - rpz         : Enable response policy rewriting (rpz)
 - - rrl         : Response Rate Limiting (RRL) - Experimental
 - - sdb-ldap    : Enables ldap-sdb backend
 + + ssl         : Adds support for Secure Socket Layer connections
 - - static-libs : Build static libraries
 + + threads     : Adds threads support for various packages. Usually pthreads
 + + urandom     : Use /dev/urandom instead of /dev/random
 + + xml         : Add support for XML files

# emerge net-dns/bind net-dns/bind-tools
# rc-update add named default

Initial configuration

The configuration below is meant for a master DNS server.

Start with /etc/bind/named.conf:

options {
  directory "/var/bind";
  pid-file "/var/run/named/named.pid";
  statistics-file "/var/run/named/named.stats";
  listen-on { 127.0.0.1; };
  listen-on-v6 { 2001:db8:81:21::ac:98ad:5fe1; };
  allow-query { any; };
  zone-statistics yes;
  allow-transfer { 2001:db8:81:22::ae:6b01:e3d8; };
  notify yes;
  recursion no;
  version "[nope]";
};

# Access to DNS for local addresses (i.e. genfic-owned)
view "local" {
  match-clients { 2001:db8:81::/48; };
  recursion yes;
  zone "genfic.com" { 
    type master;
    file "pri/com.genfic";
  };
  zone "1.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa" {
    type master;
    file "pri/1.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa";
  };
};

That's it. The configuration will have this installation work as the master DNS server and will (only) accept DNS requests from IPv6 addresses within the defined IP range. For these requests, the pri/com.genfic file is used (which is the "zone" file that will contain the DNS records) and pri/1.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa for the reverse lookups.

The name of the reverse lookup is fairly difficult to work with by people. For this reason, create a symbolic link that makes this a lot easier:

# ln -s 1.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa genfic.com.inv

This way, <domain>.inv is a symbolic link pointing to the reverse lookup zone definition.

For the slave server, the setup is fairly similar:

  • do not set the allow-transfer though. It is a slave server.

  • set the type of the zone's to "slave" instead and add in masters { 2001:db8:81:21::ac:98ad:5fe1; } to each zone. That will tell BIND what the master of this particular zone is.

  • on the slave, set the named_write_master_zones SELinux boolean to "on" so that the named_t domain can write to the cache location.

Finally, set the initial zone files for the organization.

# cat /var/bind/pri/com.genfic
$TTL 1h ;
$ORIGIN genfic.com.
@       IN      SOA     ns.genfic.com. ns.genfic.com. (
                        2012041101
                        1d      
                        2h
                        4w
                        1h )

        IN      NS      ns.genfic.com.
        IN      NS      ns2.genfic.com.
        IN      MX      10      mail.genfic.com.
        IN      MX      20      mail2.genfic.com.

genfic.com.     IN      AAAA    2001:db8:81:80::dd:13ed:c49e;
ns              IN      AAAA    2001:db8:81:21::ac:98ad:5fe1;
ns2             IN      AAAA    2001:db8:81:22::ae:6b01:e3d8;
www             IN      CNAME   genfic.com.;
mail            IN      AAAA    2001:db8:81:21::b0:0738:8ad5;
mail2           IN      AAAA    2001:db8:81:22::50:5e9f:e569;
; (...)
# cat /var/bind/pri/com.genfic.inv
$TTL 1h ;
@       IN      SOA     1.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.genfic.com. (
                        2012041101
                        1d
                        2h
                        4w
                        1h )

        IN      NS      ns.genfic.com.
        IN      NS      ns2.genfic.com.

$ORIGIN 1.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

1.e.f.5.d.a.8.9.c.a.0.0.0.0.0.0.1.2.0.0         IN      PTR     ns.genfic.com.
8.d.3.e.1.0.b.6.e.a.0.0.0.0.0.0.2.2.0.0         IN      PTR     ns2.genfic.com.
; (...)

With the configuration done, start the named daemon.

# run_init rc-service named start

Hardening zone transfers

The BIND system can get additional hardening by introducing transaction signatures (TSIG). To do so, create a shared secret (key) with dnssec-keygen. The generated key is then added to the named.conf file like so:

# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST secundary
# cat Ksecundary.*.key
secundary. IN KEY 512 3 157 d8fhe2frgY24WFedx348==
(... In named.conf ...)
key secundary { algorithm hmac-md5; secret "d8fhe2frgY24WFedx348=="; };

(... In named.conf's zone definition ...)
allow-update { key secundary; };

In the slave's configuration, add in an entry for the master and refer to this key as well.

(... In named.conf ...)
key secundary { algorithm hmac-md5; secret "d8fhe2frgY24WFedx348=="; };
server 2001:db8:81:21::ac:98ad:5fe1 { keys { secundary; }; };

It is not possible to use the TSIG together with an IP address list though, so either use the keys or use IP addresses (or use the keys and define local firewall rules).

Hardening DNS records (DNSSEC)

To use DNSSEC, first create two keypairs. One is the KSK (Key Signing Key) and is a long-term keypair. It will be used to sign the ZSKs (Zone Signing Keys) used for the zones. ZSKs are used to sign most DNS records, whereas the KSK is used to sign the ZSK. It is also the KSK which is signed by the "higher-level" domain.

# cd /var/named/chroot/etc/bind
# mkdir keys && cd keys
# dnssec-keygen -a RSASHA256 -b 2048 -3 genfic.com
# dnssec-keygen -a RSASHA256 -b 2048 -3 -fk genfic.com
# chown -R named:named .

Next, update the BIND configuration to use these keys. Below is an updated named.conf file with highlights where changes were made:

options {
  directory "/var/bind";
  pid-file "/var/run/named/named.pid";
  statistics-file "/var/run/named/named.stats";
  listen-on { 127.0.0.1; };
  listen-on-v6 { 2001:db8:81:21::ac:98ad:5fe1; };
  allow-query { any; };
  zone-statistics yes;
  allow-transfer { 2001:db8:81:22::ae:6b01:e3d8; };
  notify yes;
  recursion no;
  version "[nope]";
  dnssec-validation yes;
  dnssec-lookaside auto;
  dnssec-enable yes;
  key-directory "/etc/bind/keys";
  allow-new-zones yes;
};
view "local" {
  match-clients { 2001:db8:81::/48; };
  recursion yes;
  zone "genfic.com" {
        type master;
        file "pri/genfic.com";
        inline-signing yes;
        auto-dnssec maintain;
  };
  zone "1.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa" {
        type master;
        file "pri/genfic.com.inv";
        inline-signing yes;
        auto-dnssec maintain;
  };
};

include "/etc/bind/bind.keys";

Make sure that the named daemon has write access to the zone files (both through the SELinux named_write_masters_zone boolean as well as regular Linux permissions) as it will save the signed records next to the regular file.

With these changes made, restarting the named daemon enables DNSSEC support.

Using bind

The bind server is started and managed through its init script.

# run_init rc-service named start

Validating configurations

The installed utilities can help troubleshoot configuration issues.

The named-checkconf tool will verify the syntax of the named.conf file and report any issues it finds.

With named-checkzone, the syntax of the zone files can be validated.

Checking named results

A good tool to query name servers (to make sure they function correctly) is dig.

To see if the name server is up and running:

# ping6 -n -c 1 ns.genfic.com

If the host resolves (locally) and replies, then at least the local network is working. Now query the name server itself, asking for the IP address of mail.genfic.com:

# dig @ns.genfic.com mail.genfic.com AAAA

To get a reverse lookup, use -n -x:

# dig -x 2001:db8:81:22::ae:6b01:e3d8 @ns.genfic.com 

If the output of dig is not needed, but just the answer, add in "+short".

# dig mail.genfic.com AAAA @ns.genfic.com +short
2001:db8:81:21:0:b0:738:8ad5

Sending DNSSEC DS Records to the parent domain

When the DNS service provides DNSSEC, the Delegation Signer information should be uploaded to the parent domain service. This DS record will then be stored in the parent zone, and thus get its own digital signature so clients can check the validity of the key. To push the DS records, generate those using dnssec-dsfromkey against the KSK:

# grep key-signing *.key
K1.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.+008+41569.key:; This is a key-signing key, \
  keyid 41569, for 1.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
Kgenfic.com.+008+51397.key:; This is a key-signing key, keyid 51397, for \
  genfic.com
# dnssec-dsfromkey Kgenfic.com.+008+51397.key
genfic.com. IN DS 51397 8 1 B23D4D54B971A2A835A31B2B1AF24AB43E2C8EA2
genfic.com. IN DS 51397 8 2 323F009E2B952F3247DC78BA85AA38A9C798B5FE129A78935CCC4686 \
  C5F02A14

These records (the first is a SHA1 checksum of the DNSKEY and owner information, the second one a SHA256 checksum of the same data) can now be submitted to the registrar. Some support an automated way to handle this, others still require to send it manually. Just make sure it is sent securely - not that the information is private, but if the registrar doesn't take proper measures to make sure it is an authoritative figure handing over the DS records, then the entire idea of a secure DNS falls down.

Refreshing DNSSEC Zone Signing Keys

While creating the keys, dnssec-keygen supports timing information to allow for proper roll-over of the zone signing keys. This information includes a publication date (when will the new key be published in the DNS records, even if the key is not used yet), activation date (when will the new key be used to sign records), inactivation date and deletion date. When refreshing the zone keys, the DS records do not need to be resubmitted (as those are made against the key-signing key, not zone-signing key).

When made available, run rndc loadkeys genfic.com to reload the keys for the genfic.com domain.

What if the key signing keys are refreshed? In that case, send over the new DS records to the parent domain. It is better to do double-signing when refreshing KSK versus using roll-over periods for ZSK, as the KSK only signs one record (the DNSKEY one) whereas the ZSK signs many more records. Double-signing would increase the amount of records immensely in case of the ZSK.

Pushing changes

Changes to BIND can be pushed using the nsupdate application. Make sure the system from which it is run has the proper rights in BIND (through the allow-update directive). Once set up though, it can be used to create the feed from, for instance, a configuration management database.

$ cat changes.txt
server 2001:db8:81:21::ac:98ad:5fe1 53
update add mail2.internal.genfic.com 3600 AAAA 2001:db8:81:22::50:5e9f:e569
$ nsupdate ./changes.txt

Logging

In case of DNS services, the following events should probably be logged:

  • queries made against the DNS server (timestamp, source address, query itself) and the answers given

  • modifications made on the configuration (timestamp, source address, modification)

Whereas the logging of the queries can be done in local log files, modifications need to be sent to a remote location (and might be stored locally too) for audit purposes.

Configuring logging

BIND by default will log through the system logger. This allows to store the logging information where needed, perhaps even moving the data towards other systems.

However, BIND does not log queries immediately - it needs to be told to do so through the querylog command:

# rndc querylog

Once enabled, queries will appear in the system log like so:

Dec 17 09:15:30 ns named[3721]: client 2001:db8:81:21:0:ac:98ad:5fe1#48818 \
  (mail.genfic.com): view local: query: mail.genfic.com IN AAAA +ED \
  (2001:db8:81:21:0:ac:98ad:5fe1)
Dec 17 09:16:07 ns named[3721]: client 2001:db8:81:21:0:ac:98ad:5fe1#54273 \
  (ns2.genfic.com): view local: query: ns2.genfic.com IN AAAA +ED \
  (2001:db8:81:21:0:ac:98ad:5fe1)

In the above case, the queries came from the same client (one with IPv6 address ending in :5fe1) and the client wanted to know the IPv6 addresses of mail.genfic.com and ns2.genfic.com.

Resources

IP addresses, segmentation and IPv6:

On ISC BIND: