The purpose of this article demonstrate how to get GSS-TSIG or secure dynamic updates working using ISC Bind DNS on a *NIX server. After several hours of trying to get this to work, perhaps this article would have been better named "GSS-TSIG on ISC Bind -- The Missing Manual".  I know in working with others, we experienced many trials and tribulations in getting it all to work.  GSS-TSIG DNS Updates or secure dynamic updates is an extension to TSIG based updates which implements secure key exchange. GSS API calls for the use of Kerberos for authentication, integrity and confidentiality by establishing a limited lifetime security context.  Once the security context is established, special TKEY resource records are used to securely exchange key material between the DNS Server and DNS Client. GSS-TSIG support has been present in the ISC Bind code since version 9.5.0, circa mid-summer of 2008. In this HOW-TO, we compiled ISC Bind 9.7.1-P2 on Fedora 13 (32-bit) and used a single Microsoft Windows 2008 Server running as an Active Directory Domain Controller for

Before we demonstrate secure dynamic updates, we must first address a "chicken-and-egg" issue.  We need our Active Directory Domain Controller up and running prior so we can configure our AD user and Kerberos Service Principal.  Prior to running dcpromo to promote our first AD Domain Controller or DC, we must have DNS up and running with dynamic DNS support.  So, It is recommended that ISC Bind is built and configured to be authoritative for the AD Domain and support dynamic DNS updates using the allow-update directive by supplying the IP address of the AD DC. 

Building ISC Bind on Fedora, CentOS, or Red Hat Linux

In this exercise, a minimal install of the Fedora 13 and/or CentOS 5.5 (32-bit) operating system was installed.  Ensure that the following RPM dependencies openssl-devel, gcc, make, perl, krb5-workstation, and krb5-devel.  This can be done using the yum pkg manager as follows:

yum install openssl-devel
yum install gcc make perl
yum install krb5-workstation krb5-devel 

You will note that we did not specify libgssapi* modules.  The reason for this is that the GSS-API code is present and embedded in the krb5-workstation and krb5-devel library and development package. In our test, we used the latest version of ISC Bind (9.7.1-P2 was the current version at the time of this article). Unpack this version of bind and build as follows:

./configure --with-openssl --with-gssapi
make && make install 

Some key assumptions:

  • Configure our DNS server, to be authoritative for the zone
  • Configure our DNS server, to be authoritative for the reverse zone
  • Configure the zone(s) and to be dynamically updatable via the allow-update directive using the IP address of the AD DC(s) so they can inject any/all AD-related DNS records. 

Once that is complete, our ISC Bind name server should accept insecure dynamic DNS updates from the Domain Controllers for the forward zone and the reverse zone At this point it is time to bring up the AD Domain Controller. 

Active Directory Domain Controller Promotion

With our Unix DNS server configured to support dynamic updates, we change our focus to the configuration of the AD Domain and DC itself.  At this point, we can now run dcpromo.exe on our Windows Server 2008 to promote it to a Domain Controller or DC for Follow the wizard and at the conclusion of dcpromo.exe, make sure that all the AD related records were properly "injected" into our ISC Bind Server. Our DC will populate the BIND DNS server with the records that are contained in the %systemroot%\system32\config\netlogon.dns file. You can verify and validate that this occurred by either querying the name server for specific SRV, A, and CNAME records or by displaying the contents of the file using the Bind-provided named-journalprint command.

Create AD user & Service Principal

Using the Microsoft Active Directory Users and Computers Microsoft Management Console or MMC, create an AD user called "dns1" in a zone such as as shown in Fig. 1 - New User below.

NOTE: we chose the name "dns1" because it will represent the "instance" or hostname of the DNS server we plan to run ISC Bind on, i.e.  You should plan to add an AD User for each DNS server that will perform GSS-TSIG secure dynamic updates.

Click Next, and set & confirm a strong password.  In this example, we chose to set a one-time fixed password so that we would not have to rebuild Kerberos keytab files with the new credentials. If you permit the password to change or require it to be rotated for security reasons, you will need to update the Kerberos keytab files that get configured on the remote DNS Servers. 

When done, click next to view the final user creation screen shown in Fig. 3. Click Finish to complete the task of creating our user. 

Next, we must create a Kerberos Service Principal Name or SPN, that is mapped to our Active Directory User dns1. This is accomplished using the ktpass.exe utility that is installed on modern Microsoft Windows 2008 Server Installations.  If you are operating on Microsoft Windows 2003, you will need to install the Microsoft "Support Tools".  You MUST make sure to install the same release of the Support Tools as the version of Windows Server you are operating.  Run the ktpass.exe utility with the following flags and/or options:

-princ DNS/This email address is being protected from spambots. You need JavaScript enabled to view it. This represents the Kerberos Service Principal Account for the <instance> in the realm EXAMPLE.COM
-mapuser This email address is being protected from spambots. You need JavaScript enabled to view it. The Kerberos SPN is mapped to this AD User Account that was created
-mapOp set Specifies how the mapping attribute is set
+DesOnly Sets the encryption type to Des only
-ptype KRB5_NT_PRINCIPAL This is the type of Kerberos Principal
-pass Pa$$w0rd The password of the AD user This email address is being protected from spambots. You need JavaScript enabled to view it. must be correctly passed as an argument.
-out dns1.keytab  This option names the output file for ktpass.exe.  The file that is outputted is a Kerberos Keytab File that can be imported or merged to an existing keytab file on the Unix Host. 
 gss-tsig1  gss-tsig2  gss-tsig3 gss-tsig4 
 Fig. 1 - New User  Fig. 2 - Password  Fig. 3 - Finish  Fig. 4 - ktpass.exe usage

The ktpass.exe command above should be executed for as many Bind DNS server instances you plan to operate.  In our testing, we generated two such SPN instances for two (2) different Linux hosts that were running ISC Bind 9.7.2-P2, and Copy each keytab file to a temporary directory on the corresponding instance or Linux host, e.g. dns1.keytab should be copied to /tmp on 

Configuring The Kerberos Client on Linux

The first step is to ensure that the krb5-workstation utilities are properly installed, and that the location of the utilities are in your current PATH environment variable.  In our case, we added /usr/kerberos/bin to our default path. Set up Kerberos with a config similar to that shown below:

 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

 default_realm = EXAMPLE.COM
 default_tkt_enctypes = des-cbc-md5
 default_tgs_enctypes = des-cbc-md5
 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 30d
 forwardable = yes
 default_keytab_name = FILE:/etc/krb5.keytab

  kdc =
  admin_server =
  default_domain =

[domain_realm] = EXAMPLE.COM = EXAMPLE.COM

 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false

Run the ktutil command to read in the freshly copied keytab file, and write out the full contents to our target keytab file as follows:

[root@dns1 ~]# ktutil
ktutil:  rkt /tmp/dns1.keytab
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    3         DNS/This email address is being protected from spambots. You need JavaScript enabled to view it.
ktutil:  wkt /etc/krb5.keytab
ktutil:  quit
[root@dns1 ~]# 

If you are running ISC Bind as a lesser privileged user than the root user, you MUST set new ownership on the /etc/krb5.keytab file to the user that is running Bind. In our testing, we set the owner to 'named'.

Now, that our keytab file is in place, and our krb5.conf file is set up, you can initiate Kerberos authentication in obtaining Kerberos Tickets from the AD Server. This is done via the following command:

/usr/kerberos/bin/kinit -k -t /etc/krb5.keytab DNS/

If there is no output and/or the return value $? is 0, then the command completed without any errors. You can now view the Kerberos tickets that have been granted by:

[root@dns1 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: DNS/This email address is being protected from spambots. You need JavaScript enabled to view it.

Valid starting     Expires            Service principal
10/02/10 11:12:58  10/02/10 21:12:54  krbtgt/This email address is being protected from spambots. You need JavaScript enabled to view it.
    renew until 10/09/10 11:12:58

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

At this point, you should now have a working Kerberos Workstation or client that can authenticate and obtain Kerberos Tickets via the AD Domain Controller. If you run kdestroy, this command will remove any cached tickets from the Kerberos Client. Remove these cached tickets so that you don't have any cached tickets that will expire. Once that is done, the named process should renew tickets as needed to remain authenticated and capable of performing secure dynamic updates.

Configuring ISC Bind to Perform GSS-TSIG Secure Dynamic Updates

Previously, we had configured our DNS server to support dynamic DNS updates in the clear (insecure) by using the allow-update directive.  Now that our server has been "Kerberized", you can change the configuration of the name server to accept only secure dynamic updates by tweaking the server's global and zone configuration(s).  In the global options block of the named.conf file, you will need to add the tkey-gssapi-credential and tkey-domain directives.  The following was used for the domain name server

tkey-gssapi-credential "DNS/This email address is being protected from spambots. You need JavaScript enabled to view it.";
tkey-domain "EXAMPLE.COM"; 

It was during the next part of the configuration, that we experienced difficulty in getting our configuration to work.  Since we are configuring secure dynamic updates on two zone(s),, and, we first needed to remove the allow-update { update_acl; }; because that directive is based upon IP access lists and is associated with insecure updates. The newer update-policy directive is what should be used to configure zones to support secure dynamic updates. We struggled with the documentation and exact syntax of this policy while trying to get GSS-TSIG working. The following syntax was used to get things working for our two (2) zones:

zone "" { 
    type master;
    file "";
    check-names ignore;
    allow-transfer { localhost;; };
    update-policy {
        grant * subdomain ANY;

zone "" {
    type master;
    file "";
    check-names ignore;
    allow-transfer { localhost;; };
    update-policy {
        grant * subdomain PTR TXT;

While the above configuration allowed our ISC Bind Server to handle GSS-TSIG secure dynamic updates, it is far less than optimal from a security perspective.  With all that said, how do we really know it's working? During testing, it's best to start named at a low debugging level so that log output shows details and evidence of the GSS-TSIG signed updates. Running ISC Bind in Debug level 6 will output logged messages as shown in gss-tsig.log. This is the first part of a two (2) article series on GSS-TSIG Updates using ISC Bind.  Part 2 - will cover some of the "gotchas", exceptions, and provide some additional recipes for a more secure update-policy usage.