We use cookies to improve your experience. Please read our cookies policy here.

×

Instructions for use

To use the DNSSEC signing Service, registrars must first enable the service and agree to the terms of use. This is done in your registrar online service account.

There are two ways that you can configure the DNSSEC Signing Service (DSS) to sign your zones:

Web domain manager

  • sign up using online services
  • set up your unsigned master/signed slave nameservers
  • set up the zone in WDM, providing the IP/TSIG configuration for your nameservers
  • check that Nominet's DNSSEC Signing Service is pulling the zone from your unsigned master, and publishing the signed zone to your signed slave, and that you are publishing this as public DNS
  • the DS record for the zone should now be available; you can either tell the DSS to add this to the Nominet domain registry or retrieve the DS record and submit it to your parent zone.

EPP

  • trial your EPP client using the EPP testbed
  • use EPP instead of WDM
  • EPP schemas and detailed EPP instructions and templates are available

Server configuration

You will have to set up your unsigned master and signed slave nameservers to transfer your zones to/from the DNSSEC Signing Service.

Your unsigned master must be configured to send the zone to the DSS front-end.  DSS will check for changes at the appropriate refresh interval as specified in the zone SOA (within limits), but we also recommend that you configure your master to send DNS notifies.

Similarly, your signed slave must be configured to slave the zone from DSS.

The DSS front-end IP addresses are:

  • 213.248.242.87 (IPv4)
  • 2A01:618:8009:0:988:B84B:769D:7D96 (IPv6)

If you have a firewall, this also may require changes to make these transfers possible (port 53, TCP & UDP).

At this stage in the pilot, we have only set up DSS at a single site.  This already includes some redundancy to improve system reliability, and in the future we will increase this by adding additional sites, for which we will then need to add further IP addresses. (We intend to notify existing users when this happens).

 

 

The following configuration clauses should be added to, or altered in your master nameserver configuration. The parts in bold should be replaced with your own values:

# The name and secret key used to communicate with the Nominet DSS

 key secret-tsig-key {

    algorithm hmac-md5;

    secret "something/difficult/to/guess";

    };

# the server statement ensures that all messages between the

# Nominet DSS and this server is signed and validated with the secret

server 213.248.242.87  { keys secret-tsig-key; };

zone "ukdnssectest.co.uk" IN {

    type master;

    file "/etc/ukdnssectest.co.uk";

# the notify explicit and also-notify statements ensure that only

# the nominet DSS receive a notify

    notify explicit;

    also-notify {213.248.242.87};

    };

 

The following configuration clauses should be added to, or altered in your slave nameserver configuration. The parts in bold should be replaced with your own values:

# The name and secret key used to communicate with the Nominet DSS

key secret-tsig-key {

    algorithm hmac-md5;

    secret "something/difficult/to/guess";

    };

 

# the server statement ensures that all messages between the

# Nominet DSS and this server is signed and validated with the secret

server 213.248.242.87  { keys secret-tsig-key; };

zone "ukdnssectest.co.uk" IN {

   type slave;

# The masters clause ensures that this slave trusts the incoming

# notifies and sees the Nominet DSS as master

   masters {213.248.242.87};

   };

 

TSIG keys and security

The transfer of zone data is protected by limiting the IP addresses, and using TSIG.

You must specify (via EPP/WDM) the IP addresses of your unsigned master & signed slave nameservers, and we will only transfer to/from those IP addresses.  Similarly, you should configure your nameservers only to transfer to/from the DSS IPs.

You must also specify a TSIG key for each nameserver – you may share a TSIG key between servers and between zones.  Each TSIG key (see RFC 4635) has:

  • a name

this should have the same format as a fully-qualified domain name (i.e. foo123.some-domain.com.) but this is just a unique string and doesn't have to represent any real domain

  • a hash algorithm

hmac-md5 / hmac-sha1 / hmac-sha256 (recommended)

  • a secret, base-64 encoded

(you can generate an appropriate secret for hmac-256 with the following command)

    $ cat /dev/urandom | head -c32 | base64

 

The same TSIG name/hash/secret must of course be configured for your nameservers as you have provided in your DSS config.

 

Troubleshooting

  • DSS only supports AXFR to slaves (and incidentally only uses AXFR from masters); it would require extra complexity and storage to allow IXFRs.
    If you find that your slave does a successful AXFR, but then you get TSIG errors when subsequent IXFRs get retried as AXFRs (as happens with BIND 9.3.4) then try configuring it specifically not to try IXFRs, for example:
    request-ixfr no;

    in the server clause, e.g.

    server 213.248.242.87  { keys secret-tsig-key; request-ixfr no; };
  • You can use "dig" to help debug slave nameserver connection issues, e.g.
    $ dig @213.248.242.87 -b <slave IP as configured> -y [TSIG alg:]<TSIG name>:<TSIG secret> <zone name> SOA
    $ dig @213.248.242.87 -b <slave IP as configured> -y [TSIG alg:]<TSIG name>:<TSIG secret> <zone name> AXFR

    (you can also use the "-k" option to use a keyfile instead of "-y", which does not expose the TSIG secret to other users on your machine via the "ps" listing, or record it in your shell history)

Minerva House, Edmund Halley Road, Oxford Science Park, OX4 4DQ, United Kingdom