DNSSEC in practice at the domain registrar
In this article, Webnames.Ru , one of the largest domain name registrars in Russia, will talk about how to put into practice the DNSSEC security protocol, a technology that protects vulnerabilities in the domain name system, which is based on the digital signature method of responses to DNS queries.
History reference
')
The Domain Name System (DNS) is one of the most important components of the Internet, but at the time of its development, security was not enough attention. With the development of the Internet, vulnerabilities have been discovered in the DNS system. The reliability of the DNS server response is not checked, which allows you to spoof the server response by redirecting the user's request to an arbitrary IP address. Caching DNS servers of Internet providers turned out to be vulnerable due to the possibility of filling the DNS server cache with data not coming from an authoritative DNS source (Kaminsky attack).
However, it cannot be said that DNS security has not been thought of at all until now. Serious shortcomings in the security of this system were identified as early as 1990 by Steve Bellovin. Research in this area began since the publication of the report in 1995, and in 1997 the IETF (Internet Engineering Task Force) published the first specifications on this topic (RFC 2065). The first attempts to implement this specification led to the emergence of a new specification (RFC 2535) in 1999. It was according to the IETF RFC 2535 specification that the implementation of DNSSEC was planned, but it had very serious problems spreading to the entire Internet. By 2001, it became clear that this specification is not suitable for large networks. This, in turn, led to the emergence of new specifications (RFC 4033, 4034 4035) with fundamental changes to DNSSEC (DNSSEC-bis), the new version of which eliminates the main problem of the previous implementation and, although in the new specification, customers need to take additional steps to verify the keys It is quite suitable for practical use.
Unfortunately, as it usually happens, the disadvantages of DNSSEC are a continuation of its strengths. Signing and validating DNS data creates additional costs, which negatively affects network and server performance. For example, on average, a DNSSEC zone is 7-10 times the size of the DNS system itself. Signature generation and verification takes considerable CPU time. Signatures and keys take up an order of magnitude more disk space and in RAM than the data itself.
Although work on DNSSEC has not yet been completed, any organization actively using the Internet should already consider DNSSEC as an essential component of its security infrastructure. The DNS protocol is still vulnerable to cyber attacks.
Our days
It is worth noting the unpopularity of this technology in runet. Recall that the zone .SU DNSSEC was introduced in October 2011, in the zone. RF - in November 2012, and in the zone .RU - in December 2012.
Now try to remember at least one domain signed by DNSSEC. You can not? This is expected. At the time of this writing, of the three registrars who have announced the implementation of DNSSEC, only one (and this is Webnames.Ru) has signed its main domain. To this we can add that for all the existence of DNSSEC the number of questions from users about the implementation of this technology can be counted on the fingers of one person.
Then the logical question arises: Why implement? The fact is that Webnames.Ru has always been and remains a pioneer and pioneer in many DNS issues. The introduction of DNSSEC is our next step forward. And not only for domestic domain zones, but also for many others.
At this I propose to finish with the theory and philosophy. Now consider the practical use of DNSSEC on our own name-servers.
Practical work
In order for DNSSEC to work as intended by its authors, the following components are needed:
- Signed zone of the first level (we have domestic .RU. SU i. RF)
- domain in this zone (we have webnames.ru)
- authoritarian DNS servers for our domain (available)
- resolver (caching DNS server)
The current stable version of Debian is Squeeze 6.0.7. We will use it as a base. As a DNS server, we have bind9.
Omit the details of the installation and configuration of the bind9 itself. It is put simply:
Components for working with DNSSEC:
All configs are in / etc / bind / by default.
Here we are interested in the options in named.conf.options. They need to add:
After that, you need to re-read configs or reload bind. There are two options: rndc reconfig or /etc/init.d/bind9 restart
For ease of implementation we will use zonesigner. This is a comprehensive utility that signs a zone in a single pass. There is a more difficult way, but why is it needed?
Looking ahead, I will say that in the course of their work, zonesigner creates a dozen files and it is more rational to add them separately, and not into a common directory with zones. And it is better not to add zones into one directory. This is not a problem. You have only a few domains. But if we have more than 150 thousand zones on each server, then we need to somehow optimize their storage, otherwise there will be huge overhead costs.
In the process of evolution, we obtained the following hierarchy of zones: auto / ru / w / e / b / n / webnames.ru. For zonesigner, a similar parallel branch was created: dnssec / ru / w / e / b / n / webnames.ru /
The initial generation of the signed zone looks like this:
At the output we get something like:
And now make sure that there are a lot of files created:
And the second file webnames.ru.signed appeared next to the file of the usual zone, and it is 20 times larger than the original - 32,669 bytes versus 1369. And another 7,520 bytes for the service files indicated above. Those. we received 30 times more information. True, the webnames.ru zone is quite small, and this increase is not very hard.
Just in case, check the new zone file for errors:
“—Level” is the level of error output. When there are no errors, then there is no special meaning in it. By the way, there is a very simple way to run into these errors. For example, adding an NS record with a third-party DNS server.
Add the bad NS record ns1.gde-to-tam-daleko.ru to the zone and update it:
Please note that you should always edit the regular zone, and the signed DNSSEC should be updated this way.
Now check for errors:
Like this. This complication of the structure should be taken into account in its practice. If you read thoughtfully, it becomes clear what you need to do. First, add the second NS record, and second, add the DS record for the subdomain.
But where do we get these DS from? Above we have shown the file dsset-webnames.ru. Its contents are:
These records need to be transferred to the domain registrar so that he sends them to the zone registry. And they are also needed in order for donuts to stop issuing errors for NS records.
The transfer procedure is different for different recorders. On Webnames.Ru , for example, in the “Domain Management” section in your personal account there is a special item “DNSSEC” where you can enable and disable the actual DNSSEC support, see the existing DS records and, if necessary, add new ones.
Now, remember that all cryptographic keys have an expiration date. It would be nice to automate and replace them ... For this there is a special rollerd daemon. But the fact that there is no init-script for this daemon complicates the situation. Therefore, you have to write it yourself. It is possible, of course, not to write, but to get by with the “collective farm” methods, but this is something everyone decides for himself. Another problem is that rollerd keeps track of the keys and replaces them, but cannot replace them in the registry.
First, decide what we will follow. For these purposes, there is a rollinit. He is preparing for rollerd a list of zones for which we are going to follow the keys. Assume that we will keep this list in dnssec /. Accordingly, we will add our signed zone there:
If someone, while reading this, has already done the signed zones, then you need to add them all to the same list, or follow the keys manually.
After that, you need to start rollerd. Here is the promised init script: /etc/init.d/rollerd
We prepare it for launch, autorun and launch.
Using the mail daemon, you can automate and complete rotation of keys. We use sendmail for this. Therefore, using smrsh, you can do almost anything. This is done quite simply. Add the following lines to /etc/mail/sendmail.mc before the first MAILER:
Add to / etc / mail / virtusertable:
dnssec @ localhost dnssec
Thus, we created a virtual mailbox dnssec @ localhost and sent all incoming mail to the system user dnssec.
Add to / etc / aliases:
dnssec: "| / etc / mail / smrsh / dnssec"
So we sent all incoming mail to dnssec user via pipe (i.e. in his STDIN) to the script / etc / mail / smrsh / dnssec
And in the script / etc / mail / smrsh / dnssec we can do whatever we want.
It is worth noting that the script is called conditionally. This may be a binary.
Now restart sendmail, and all changes will take effect:
/etc/init.d/sendmail restart
At the same time, do not forget that when using smrsh, you need to re-initiate / var / named / dnssec / rollrec with the address dnssec @ localhost. Those. like that:
The script itself / etc / mail / smrsh / dnssec does not make sense, therefore we restrict ourselves to wrapping bash without functionality.
The letter itself looks like this:
You can parse it, for example, like this:
Those. after parsing the Subject field by words, we end up with the domain name (in the W variable) for which we need to send the updated DS entries to the registry.
Now let's configure the last DNSSEC component - the resolver, which is also the caching DNS server. And here everything is also very simple. If you take the same bind9, then in the same file /etc/bind/named.conf.options you need to add the same options and reload the bind:
/etc/init.d/bind9 restart
Now you need to register our resolver as a DNS server on your work computer and enjoy DNSSEC.
That's all.
History reference
')
The Domain Name System (DNS) is one of the most important components of the Internet, but at the time of its development, security was not enough attention. With the development of the Internet, vulnerabilities have been discovered in the DNS system. The reliability of the DNS server response is not checked, which allows you to spoof the server response by redirecting the user's request to an arbitrary IP address. Caching DNS servers of Internet providers turned out to be vulnerable due to the possibility of filling the DNS server cache with data not coming from an authoritative DNS source (Kaminsky attack).
However, it cannot be said that DNS security has not been thought of at all until now. Serious shortcomings in the security of this system were identified as early as 1990 by Steve Bellovin. Research in this area began since the publication of the report in 1995, and in 1997 the IETF (Internet Engineering Task Force) published the first specifications on this topic (RFC 2065). The first attempts to implement this specification led to the emergence of a new specification (RFC 2535) in 1999. It was according to the IETF RFC 2535 specification that the implementation of DNSSEC was planned, but it had very serious problems spreading to the entire Internet. By 2001, it became clear that this specification is not suitable for large networks. This, in turn, led to the emergence of new specifications (RFC 4033, 4034 4035) with fundamental changes to DNSSEC (DNSSEC-bis), the new version of which eliminates the main problem of the previous implementation and, although in the new specification, customers need to take additional steps to verify the keys It is quite suitable for practical use.
Unfortunately, as it usually happens, the disadvantages of DNSSEC are a continuation of its strengths. Signing and validating DNS data creates additional costs, which negatively affects network and server performance. For example, on average, a DNSSEC zone is 7-10 times the size of the DNS system itself. Signature generation and verification takes considerable CPU time. Signatures and keys take up an order of magnitude more disk space and in RAM than the data itself.
Although work on DNSSEC has not yet been completed, any organization actively using the Internet should already consider DNSSEC as an essential component of its security infrastructure. The DNS protocol is still vulnerable to cyber attacks.
Our days
It is worth noting the unpopularity of this technology in runet. Recall that the zone .SU DNSSEC was introduced in October 2011, in the zone. RF - in November 2012, and in the zone .RU - in December 2012.
Now try to remember at least one domain signed by DNSSEC. You can not? This is expected. At the time of this writing, of the three registrars who have announced the implementation of DNSSEC, only one (and this is Webnames.Ru) has signed its main domain. To this we can add that for all the existence of DNSSEC the number of questions from users about the implementation of this technology can be counted on the fingers of one person.
Then the logical question arises: Why implement? The fact is that Webnames.Ru has always been and remains a pioneer and pioneer in many DNS issues. The introduction of DNSSEC is our next step forward. And not only for domestic domain zones, but also for many others.
At this I propose to finish with the theory and philosophy. Now consider the practical use of DNSSEC on our own name-servers.
Practical work
In order for DNSSEC to work as intended by its authors, the following components are needed:
- Signed zone of the first level (we have domestic .RU. SU i. RF)
- domain in this zone (we have webnames.ru)
- authoritarian DNS servers for our domain (available)
- resolver (caching DNS server)
The current stable version of Debian is Squeeze 6.0.7. We will use it as a base. As a DNS server, we have bind9.
Omit the details of the installation and configuration of the bind9 itself. It is put simply:
aptitude install bind9 Components for working with DNSSEC:
aptitude install dnssec-tools libcrypt-openssl-random-perl All configs are in / etc / bind / by default.
Here we are interested in the options in named.conf.options. They need to add:
dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; After that, you need to re-read configs or reload bind. There are two options: rndc reconfig or /etc/init.d/bind9 restart
For ease of implementation we will use zonesigner. This is a comprehensive utility that signs a zone in a single pass. There is a more difficult way, but why is it needed?
Looking ahead, I will say that in the course of their work, zonesigner creates a dozen files and it is more rational to add them separately, and not into a common directory with zones. And it is better not to add zones into one directory. This is not a problem. You have only a few domains. But if we have more than 150 thousand zones on each server, then we need to somehow optimize their storage, otherwise there will be huge overhead costs.
In the process of evolution, we obtained the following hierarchy of zones: auto / ru / w / e / b / n / webnames.ru. For zonesigner, a similar parallel branch was created: dnssec / ru / w / e / b / n / webnames.ru /
The initial generation of the signed zone looks like this:
mkdir -p /var/named/dnssec/ru/w/e/b/n/webnames.ru/ cd /var/named/dnssec/ru/w/e/b/n/webnames.ru/ zonesigner -genkeys -usensec3 -zone webnames.ru /var/named/auto/ru/w/e/b/n/webnames.ru At the output we get something like:
if zonesigner appears hung, strike keys until the program completes (see the "Entropy" section in the man page for details) Generating key pair.....++++++ .........................................................................++++++ Generating key pair..++++++ ...++++++ Generating key pair....+++ .........+++ Verifying the zone using the following algorithms: RSASHA256. Zone signing complete: Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 1 active, 1 stand-by, 0 revoked zone signed successfully webnames.ru: KSK (cur) 02110 -b 2048 02/22/13 (webnames.ru-signset-00003) ZSK (cur) 21834 -b 1024 02/22/13 (webnames.ru-signset-00001) ZSK (pub) 51069 -b 1024 02/22/13 (webnames.ru-signset-00002) zone will expire in 4 weeks, 2 days, 0 seconds DO NOT delete the keys until this time has passed. And now make sure that there are a lot of files created:
$ls -1 dsset-webnames.ru. Kwebnames.ru.+008+02110.key Kwebnames.ru.+008+02110.private Kwebnames.ru.+008+21834.key Kwebnames.ru.+008+21834.private Kwebnames.ru.+008+51069.key Kwebnames.ru.+008+51069.private webnames.ru.krf And the second file webnames.ru.signed appeared next to the file of the usual zone, and it is 20 times larger than the original - 32,669 bytes versus 1369. And another 7,520 bytes for the service files indicated above. Those. we received 30 times more information. True, the webnames.ru zone is quite small, and this increase is not very hard.
Just in case, check the new zone file for errors:
$ donuts --level 8 webnames.ru.signed webnames.ru 0 errors found in webnames.ru.signed “—Level” is the level of error output. When there are no errors, then there is no special meaning in it. By the way, there is a very simple way to run into these errors. For example, adding an NS record with a third-party DNS server.
Add the bad NS record ns1.gde-to-tam-daleko.ru to the zone and update it:
zonesigner -zone webnames.ru /var/named/auto/ru/w/e/b/n/webnames.ru Please note that you should always edit the regular zone, and the signed DNSSEC should be updated this way.
Now check for errors:
$ donuts --level 8 webnames.ru.signed webnames.ru bad.webnames.ru: Warning: Only 1 NS record(s) for bad.webnames.ru found, but at least 2 are suggested/required bad.webnames.ru: Error: sub-domain bad.webnames.ru is not securely delegated. It is missing a DS record. 2 errors found in webnames.ru.signed Like this. This complication of the structure should be taken into account in its practice. If you read thoughtfully, it becomes clear what you need to do. First, add the second NS record, and second, add the DS record for the subdomain.
But where do we get these DS from? Above we have shown the file dsset-webnames.ru. Its contents are:
webnames.ru. IN DS 2110 8 1 4F38DB26A26DDFFB0A84052472D1AF70DAA595D7 webnames.ru. IN DS 2110 8 2 0CC3937FE64FD4BF3B8282748F93C566870F4FCD254BCF0D91DBCF50 23D6D28C These records need to be transferred to the domain registrar so that he sends them to the zone registry. And they are also needed in order for donuts to stop issuing errors for NS records.
The transfer procedure is different for different recorders. On Webnames.Ru , for example, in the “Domain Management” section in your personal account there is a special item “DNSSEC” where you can enable and disable the actual DNSSEC support, see the existing DS records and, if necessary, add new ones.
Now, remember that all cryptographic keys have an expiration date. It would be nice to automate and replace them ... For this there is a special rollerd daemon. But the fact that there is no init-script for this daemon complicates the situation. Therefore, you have to write it yourself. It is possible, of course, not to write, but to get by with the “collective farm” methods, but this is something everyone decides for himself. Another problem is that rollerd keeps track of the keys and replaces them, but cannot replace them in the registry.
First, decide what we will follow. For these purposes, there is a rollinit. He is preparing for rollerd a list of zones for which we are going to follow the keys. Assume that we will keep this list in dnssec /. Accordingly, we will add our signed zone there:
rollinit -zonefile /var/named/auto/ru/w/e/b/n/webnames.ru.signed -keyrec /var/named/dnssec/ru/w/e/b/n/webnames.ru/webnames.ru.krf-admin support@webnames.ru webnames.ru >> /var/named/dnssec/rollrec If someone, while reading this, has already done the signed zones, then you need to add them all to the same list, or follow the keys manually.
After that, you need to start rollerd. Here is the promised init script: /etc/init.d/rollerd
#!/bin/bash ### BEGIN INIT INFO # Provides: rollerd # Required-Start: $remote_fs $network $syslog # Required-Stop: $remote_fs $network $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 ### END INIT INFO PATH=/bin:/usr/bin:/sbin:/usr/sbin DESC="DNSSEC-Tools daemon to manage DNSSEC key rollover" NAME=rollerd DAEMON=/usr/sbin/$NAME SCRIPTNAME=/etc/init.d/$NAME CONF=/var/named/dnssec/rollrec PIDFILE=/var/run/rollerd.pid [ -x "$DAEMON" ] || exit 0 . /lib/init/vars.sh . /lib/lsb/init-functions [ -f $CONF ] || exit 0 start_rollerd () { [ -f $PIDFILE ] && return 1 $DAEMON -rrfile $CONF -directory /etc/bind -pidfile $PIDFILE } stop_rollerd () { if [ -s $PIDFILE ]; then PID=`cat $PIDFILE` kill $PID && rm -f $PIDFILE sleep 3 [ -d "/proc/$PID" ] && return 1 return 0 fi PID=`ps xa | grep -v grep | grep $DAEMON | awk '{print $1}'` [ -z "$PID" ] && return 0 kill $PID sleep 3 [ -d "/proc/$PID" ] && return 1 return 0 } case "$1" in start) log_daemon_msg "Starting $DESC" "$NAME"; start_rollerd; log_end_msg $?; ;; stop|force-stop) log_daemon_msg "Stopping $DESC" "$NAME"; stop_rollerd; log_end_msg $?; ;; restart) log_daemon_msg "Restarting $DESC" "$NAME"; stop_rollerd; start_rollerd; log_end_msg $?; ;; *) echo "Usage: $0 "; exit 1; ;; esac; exit 0; We prepare it for launch, autorun and launch.
chmod 755 /etc/init.d/rollerd update-rc.d rollerd defaults /etc/init.d/rollerd start Using the mail daemon, you can automate and complete rotation of keys. We use sendmail for this. Therefore, using smrsh, you can do almost anything. This is done quite simply. Add the following lines to /etc/mail/sendmail.mc before the first MAILER:
FEATURE(`virtusertable', `hash /etc/mail/virtusertable')dnl VIRTUSER_DOMAIN_FILE(`/etc/mail/local-host-names')dnl Add to / etc / mail / virtusertable:
dnssec @ localhost dnssec
Thus, we created a virtual mailbox dnssec @ localhost and sent all incoming mail to the system user dnssec.
Add to / etc / aliases:
dnssec: "| / etc / mail / smrsh / dnssec"
So we sent all incoming mail to dnssec user via pipe (i.e. in his STDIN) to the script / etc / mail / smrsh / dnssec
And in the script / etc / mail / smrsh / dnssec we can do whatever we want.
It is worth noting that the script is called conditionally. This may be a binary.
Now restart sendmail, and all changes will take effect:
/etc/init.d/sendmail restart
At the same time, do not forget that when using smrsh, you need to re-initiate / var / named / dnssec / rollrec with the address dnssec @ localhost. Those. like that:
rollinit -zonefile /var/named/auto/ru/w/e/b/n/webnames.ru.signed -keyrec /var/named/dnssec/ru/w/e/b/n/webnames.ru/webnames.ru.krf -admin dnssec@localhost webnames.ru >> /var/named/dnssec/rollrec The script itself / etc / mail / smrsh / dnssec does not make sense, therefore we restrict ourselves to wrapping bash without functionality.
The letter itself looks like this:
From: root To: dnssec@localhost Subject: assistance needed with KSK rollover of zone webnames.ru The zone "webnames.ru" is in the middle of KSK rollover. In order for rollover to continue, its keyset must be transferred to its parent. You can parse it, for example, like this:
#!/bin/bash while read L; do if [ "${L:0:9}" == "Subject: " ]; then for W in $L ; do echo -n '' ; done echo "Domain $W" fi done Those. after parsing the Subject field by words, we end up with the domain name (in the W variable) for which we need to send the updated DS entries to the registry.
Now let's configure the last DNSSEC component - the resolver, which is also the caching DNS server. And here everything is also very simple. If you take the same bind9, then in the same file /etc/bind/named.conf.options you need to add the same options and reload the bind:
dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; /etc/init.d/bind9 restart
Now you need to register our resolver as a DNS server on your work computer and enjoy DNSSEC.
That's all.
Source: https://habr.com/ru/post/171177/
All Articles