The original design of the DNS (Domain Name System) contained no security. The emphasis was on creating a scalable and distributed system. DNSSEC (Domain Name System Security Extensions) tries to add security while maintaining compatibility with the existing standard.
DNSSEC was designed to protect internet clients against forged DNS data. Such data may be the result of DNS cache poisoning attacks. All DNSSEC replies are signed digitally. By checking the digital signature, a DNS resolver may ensure that the information is identical (correct and complete) to the data on the corresponding authoritative DNS server.
Although securing the IP address is the primary goal for many users, DNSSEC may also protect all other kinds of information stored in a DNS server, including web certificates, DKIM keys for e-mail, and SSH keys.
- DNSSEC provides no confidentiality for data and does not protect against DoS attacks.
- DNS zone transfers between servers are not protected
DeiC is implementing DNSSEC on two new authoritative DNS servers. That will allow institutions to secure their own domains with DNSSEC, either by letting DeiC operate the domain, or by letting DeiC be a slave server for the domain of the institution.
Slave server for the domain of the institution
In order to get started with authoritative DNSSEC on your own DK domain you must follow these steps.
For this example, it is presumed that you use the latest BIND software for your DNS.
Vi forudsætter her, at man anvender den nyeste BIND 9.9.0 som DNS.
- Set the server to run DNSSEC (dnssec-enable yes; )
- The zone file is placed on the server in the noraml way.
- Two keys must be generated: ZSK og KSK, each having a public and a private part (dnssec-keygen)
- Adjust the configuration file for the zone (auto-dnssec maintain; inline-signing yes; }
- Extract a DS key (dnssec-dsfromkey) from the KSK and install it at DK-Hostmaster using their self service portal.
Start up BIND which automatically signs the domain/zone and transfers the signed zone to any slave servers, e.g. the forskningsnet DNSSEC server.
Signing a zone became very simple with BIND 9.9.0, as it implements "inline signing". However, you still must renew the ZSK (every three months) and the KSK (every 12 months) in a "rollover" process.
All authoritative slave servers must run DNSSEC for the domain in question.
The forskningsnet authoritative DNSSEC servers are named
- a.ns.fsknet.dk
- b.ns.fsknet.dk
These names must be used in the respective NS records.
If the servers are slave servers for an institution, the institution must allow zone transfers from the following addresses:
- 130.225.245.202
- 130.225.245.206
- 2001:878:0:e000:82:e1:f5:ca
- 2001:878:0:e000:82:e1:f5:ce
Please note that these IP addresses do not correspond to the domain names above. The reason is that the new DNS servers are based on two physical machines running two virtual DNS servers with identical IP addresses. Users will be directed to the server which from a routing point of view is the nearest.
DNSSEC cache
To get started with a cache DNSSEC server serving local uses, add the following lines to the server configuration file of your BIND 9.9 server:
dnssec-enable yes; dnssec-validation yes;
Normally, DNSSEC only controls DNS information between DNS root servers (.) and the local cache DNS servers at the institution. There is no control between a cache server and a client. Controlling the last step demands that every client runs as its own cache server. Firefox has a DNSSEC plugin that can show if DNS replies from a cache server are correctly signed.
Agreement
An institution must enter an agreement with DeiC in order to use the DeiC DNSSEC servers. Send your request to dns@deic.dk
