DNSSEC signing your domain with BIND 9.16

Update December 2022: added “inline-signing yes;” to the zone statement as BIND 9.16.33, 9.18.7 and newer requires an explicit statement for zones without a configured ‘allow-update’ or ‘update-policy’ (see KB).

BIND 9.16 has improved DNSSEC support to the point where it can (finally) be called simple to use. This is excellent news for DNS administrators because it means there are now several options (viable alternatives being Knot DNS or PowerDNS) which make DNSSEC simple to deploy.

Six years ago we wrote a blog post about BIND 9.9 and its new in-line signing support. This article got a lot of views but at some point we had to put a warning message on the blog post stating vaguely that we would not recommend the method described anymore. The main reason was that DNSSEC with BIND 9.9 still contained many manual steps which could not be configured in named.conf. Especially key roll-overs caused headaches for administrators. If you cannot upgrade to BIND 9.16 the old blog post might still be useful. But in this case, we recommend to omit key roll-overs altogether.

However, now that we have BIND 9.16, you can just make some configuration changes to named.conf and it’s all done. Now let’s take a closer look on how you can enable DNSSEC for your domain name.

OS Setup

We used Debian 10 (aka buster) which comes with BIND 9.11 at the time of writing. We used the BIND9 packages provided by ISC, who offer BIND 9.16 in the “BIND 9 Stable” repository. Please head over to ISC Packages for BIND 9 for instructions on how to use the ISC packages directly.

Once you have added the ISC BIND 9 Stable repository we install bind9, bind9 utils and the bind documentation:

apt-get install bind9 bind9-dnsutils bind9-doc

You have now a running bind9 instance. You can check its running state with systemctl:

systemctl status bind9

Continue reading “DNSSEC signing your domain with BIND 9.16”

Attacks on DNS continue, targets are also in Switzerland

Attacks on the domain name system continue

Talos, the intelligence group of CISCO reported in their blog that their monitoring shows that attacks on the domain name system (DNS) by “Sea Turtle” continue. The attack technique used is similar than before, the actors compromise name server records to take ownership of the domain. They then provide false information to selected parties (e.g certificate authorities, mail users) which leads to the disclosure of email credentials of the targeted organisations. These credentials give initial access to the victims E-mails accounts and other resources and are a starting point for further attacks.

Victims in Switzerland

For the first time, Talos also reported victims in Switzerland.

While Talos didn’t disclose the targeted organizations they identified these groups as primary targets:

Government organizations
Energy companies
Think tanks
International non-governmental organizations
At least one airport

Continue reading “Attacks on DNS continue, targets are also in Switzerland”

DNSSEC Usage in Switzerland is on the rise after widespread attacks on the Domain Name System

Attacks on the DNS System

Cyber attacks on the DNS system are not new. Cache poisoning, Domain Hijacking and BGP injections of routes to public DNS resolvers happen regularly, but they usually don’t get much attention as they target the Internet’s core infrastructure and are not directly visible to end users in most cases. This time it was different. The recent widespread DNS hijacking attacks on several Mid East, North African and European and North American governments and infrastructure providers, published by Ciscos Talos showed that DNS attacks are a real threat to cyber security. Netnod, one of the affected infrastructure providers issued a statement, that called, amongst other domain security mechanisms, for the implementation of the DNS Security Extensions (DNSSEC).

The analysis of these attacks also convinced the Internet Corporation for Assigned Names and Numbers (ICANN) that there is an ongoing and significant risk to key parts of the System (DNS) infrastructure. ICANN issued a call for “Full DNSSEC Deployment to Protect the Internet” across all unsecured domain names.

The question is if these attacks and the awareness that DNSSEC is an absolute essential base layer protection for domain names had some effects on the Implementation of DNSSEC Switzerland?

More DNSSEC signed domain names

As a ccTLD operator SWITCH publishes the number of DNSSEC signed .ch and .li domain names every month. While the number of signed domain names is still very low at around 3-4% we see a rise in the numbers of signed domain names for two years now.

Continue reading “DNSSEC Usage in Switzerland is on the rise after widespread attacks on the Domain Name System”

DNSSEC Signing for .ch and .li on the Rise

The share of DNSSEC signed domain names in .ch and .li reached 1% for the first time in June 2017. While this is still a very low number compared to other ccTLDs, the number of DNSSEC signed domain names is increasing at a high rate for the last two quarters.

DNSSEC

The Domain Name System Security Extensions (DNSSEC) is a set of technologies that secures the origin authentication and data integrity of the Domain Name System. It allows to detect DNS records that have been modified on the way from the authoritative name server to the client using a domain name. This helps to protect Internet users from going to bogus websites.

In addition from protecting Internet users from cybercriminals and state sponsored actors, DNSSEC is the base for important standards such as DNS-based Authentication of Named Entities (DANE).

DNSSEC in .ch and .li

DNSSEC was enabled for the .ch and .li zones in 2010 but unfortunately received a slow adaptation by domain holders. From 2013 there was a slow but steady growth of domain names signed with DNSSEC. In November 2016 we noticed a increased rate of DNSSEC signed domain names that accelerated in April 2017.

From now on SWITCH will publish statistics about the number of signed domain names for both ccTLDs .ch and .li on the nic.ch and nic.li website.

Continue reading “DNSSEC Signing for .ch and .li on the Rise”

DNSSEC signing your domain with BIND inline signing

Update Dez 2020: We made an update for users with BIND 9.16.

Update Nov 2017: DNSSEC zone signing as described here is outdated. We strongly recommend against the method described in this blog post. Newer BIND versions or other DNS software have greatly simplified DNSSEC signing.

With BIND 9.9, ISC introduced a new inline signing option for BIND 9. In earlier versions of BIND, you had to use the dnssec-signzone utility to sign your zone. With inline signing, however, BIND refreshes your signatures automatically, while you can still work on the unsigned zone file to make your changes.

This blog post explains how you can set up your zone with BIND inline signing. The zone we are using is called example.com. In addition, we look at how to roll over your keys. In our example, we do a Zone Signing Key (ZSK) rollover. We expect that you are already familiar with ISC BIND and have a basic understanding of DNSSEC. More specifically, you should be able to set up an authoritative-only name server and have read up on DNSSEC and maybe used some of its functions already.

Architecture

Before we set up inline signing with BIND, let us look at a typical network architecture. We will set up inline signing on a hidden master name server. This server is only reachable from the Internet via one or more publicly reachable secondary name servers. We will only cover the configuration of the hidden master as the secondary name server configuration will not differ for the signed zone (assuming you are using DNSSEC-capable name server software).
Continue reading “DNSSEC signing your domain with BIND inline signing”

Taking Advantage of DNSSEC

According to measurements by APNIC’s Geoff Huston currently 16 percent of Swiss Internet users use a DNSSEC validating DNS resolver. If you want to benefit from the added security with DNSSEC in your network then I suggest you enable DNSSEC validation in your network as well. SurfNet published a deployment guide recently that takes BIND 9.x, Unbound and Microsoft Windows Server 2012 into account.

Enabling DNSSEC validation on your DNS resolvers is one simple step and it protects you from DNS Cache Poisoning. However, if it were only for this, then the DNSSEC protocol complexity would come at a high cost for only providing this one benefit. In fact, DNSSEC is much more than only a protection from Cache Poisoning. It’s a new PKI in DNS and if you have signed your zone and are already validating then you can take advantage of that PKI. Some use cases are described below but there are many more ideas which are currently discussed.
Continue reading “Taking Advantage of DNSSEC”

Verbindungsprobleme bei der DNS Namensauflösung erkennen

Die ursprüngliche Spezifikation von DNS-Nachrichten (RFC 1035), welche über UDP gesendet werden, ist auf 512 Bytes begrenzt. Bereits Ende der Neunzigerjahre wurde mit dem “Extension Mechanisms for DNS (EDNS0)” (RFC 2671) eine Erweiterung für das DNS-Protokoll festgelegt, welche es u.a. dem Client erlaubt eine grössere Buffergrösse bekannt zu geben.

Die meisten DNS Resolver-Implementierungen kündigen eine Buffergrösse von 4096 Bytes an. Das heisst aber auch, dass bei einer maximalen Paketgrösse (Maximum Transmission Unit, MTU) von 1500 Bytes eine Fragmentierung der Datenpakete stattfindet. Die Vergangenheit hat gezeigt, dass viele Netzwerk- und Sicherheitsprodukte diese Protokolländerung noch nicht mitgekriegt haben und auf eine kleinere Paketgrösse bestehen. Für DNSSEC ist die EDNS0-Erweiterung eine Voraussetzung, da durch die Signierung der Daten die Paketgrösse ansteigt.

Die Unterstützung einer grossen Buffergrösse von Ihrem DNS-Resolver zur Aussenwelt ist aber auch relevant, wenn Sie keine DNSSEC-Validierung auf dem DNS-Resolver aktiviert haben. Aktuelle DNS-Resolver kennzeichnen die Unterstützung von DNSSEC (durch das DO-bit, Bezeichnung “DNSSEC OK”-bit, RFC 3225) und erhalten deshalb in der Antwort die DNSSEC-Signaturen, auch wenn der DNS-Resolver die Validierung nicht aktiviert hat.
Continue reading “Verbindungsprobleme bei der DNS Namensauflösung erkennen”

DNS Zone File Time Value Recommendations

When setting up a zone file for a domain name, the administrator can freely choose what time values he would like to set on the SOA record or regarding the Time To Live (TTL) value on the Resource Records (RR). There are already many useful documents describing recommendations for these time values but most lack the reference to signed zones using DNSSEC because at the time these documents were published, DNSSEC did either not exist or had no relevance. We tried to update the recommendations for these time values so that the none-experts can adapt their template or have a reference. Our recommendations work for both signed and unsigned zones and in the best case it helps improve the stability and resilience of the DNS.

Our recommended DNS example.com zone file in BIND format looks as follow:

$TTL 86400 ; (1 day)
$ORIGIN example.com.
@ IN SOA ns1.example.com. hostmaster.example.com. (
                2014012401 ; serial YYYYMMDDnn
                14400      ; refresh (4 hours)
                1800       ; retry   (30 minutes)
                1209600    ; expire  (2 weeks)
                3600       ; minimum (1 hour)
                )

         86400    IN   NS    ns1
         86400    IN   NS    ns2

                   IN   A     203.0.113.10
                   IN   AAAA  2001:DB8:BEEF:113::10
www                IN   CNAME example.com.
ftp                IN   CNAME example.com.

ns1      86400    IN   A     192.0.2.22
         86400    IN   AAAA  2001:DB8:BEEF:2::22
ns2      86400    IN   A     198.51.100.22
         86400    IN   AAAA  2001:DB8:BEEF:100::22
...

Please read the following sections for a more detailed explanation.

Continue reading “DNS Zone File Time Value Recommendations”

SWITCH DNS/DNSSEC Audit

SWITCH is regularly assessing parts of the registry infrastructure in technical audits. The goal of these audits is to find operational or software vulnerabilities before attackers do. For 2013 we wanted to audit the DNS/DNSSEC related aspects of the registry and DNS name server service operation. The introduction of DNSSEC for the ch. and li. zones in early 2010 brought a lot of changes to our DNS management software, the registry application and to the registrar interface. Naturally, most changes occurred in the DNS management software, which is responsible for properly signing the zones and rolling the keys.

In 2009, when we started the DNSSEC project internally, mature support for DNSSEC was close to inexistent, so we ended up writing our own scripts and tools around ISC BIND. In the mean time BIND added support for inline-signing and OpenDNSSEC matured a lot, just to name a few examples. If you are on the verge of signing your zone, I suggest you look at already existing solutions first. I don’t think that today there is still a need to develop your own script and tools. However, ours have been in production since then. So we felt, it was high time to get an independent view on our implementation.

Continue reading “SWITCH DNS/DNSSEC Audit”

DNS Hijacking nimmt zu

Internetbenutzer die den Domainnamen nytimes.com in der Navigationsleiste ihres Browsers eingegeben hatten, sahen gestern für sechs Stunden nicht etwa die Webseite der Zeitung, sondern eine Seite der “Syrian Electronic Army” oder eine Fehlermeldung. Wie die Los Angeles Times berichtet, wurden die Zugriffs-Credentials eines Resellers von Melbourne IT missbraucht um die DNS-Einträge für nytimes.com zu ändern und die Besucher so auf einen anderen Webserver zu leiten.

Angriffe über das Domain Name System (DNS) häufen sich in der letzten Zeit. Statt eine gut gesicherte Webseite zu hacken, versuchen Kriminelle den Domainnamen auf den eigenen Server umzuleiten. Der Web-Traffic ist viel wert, sei es für Propaganda, wie im Fall der Syrian Electronic Army, oder für kriminelle Zwecke, wie das Verteilen von Malware, Clickfraud oder zur Search Engine Optimierung.

Statt einzelne DNS-Server zu hacken, versuchen die Kriminellen verstärkt, Registries, Registrare und Reseller von Domainnamen anzugreifen. Gelingt es ihnen in die Systeme oder an Credentials zu gelangen, können so oft gleich tausende von Domainnamen auf den eigenen Server umgeleitet werden. Prominente Opfer sind vor allem viel besuchte Webseiten wie Suchmaschinen oder Nachrichtenportale.

Auch Schweizer Domainnamen waren in der vergangenen Woche von falschen DNS Antworten betroffen. Continue reading “DNS Hijacking nimmt zu”

DNSSEC Deployment in .CH

It has now been three years since SWITCH officially signed the .CH and .LI ccTLDs. Since then adoption of DNSSEC for the .CH domains has been very slow. During the last few weeks we have seen a small increase, but noticeable, including one registrar (OVH.de); who have started to sign a few hundert domain names. It may be the start to something bigger; however we trail other TLDs in the number of singed delegations (See https://xs.powerdns.com/dnssec-nl-graph/) by a large margin

Currently, SWITCH does not publish statistics about DNSSEC, as only 0.05% of all active domains use DNSSEC. Therefore publishing any DNSSEC statistics remain unjustified.

In this blog article we want to give you a look at the numbers nonetheless. Please keep in mind that: because the number of DNSSEC enabled domains is so low, the interpretation of the data and graphs should not be taken too seriously, the numbers can change very quickly.

Continue reading “DNSSEC Deployment in .CH”

DNSSEC Signierungs-Algorithmus wechseln

Eine DNS-Zone zu signieren ist mit heutiger Software nicht mehr schwierig oder kompliziert. Die Schwierigkeiten im Betrieb von signierten Zonen sind selten angewendete Prozeduren, wofür teilweise noch die Software-Unterstützung fehlt, sei dies in der Signierungssoftware oder in Monitoring- und Debugging-Tools. Eine solche selten angewendete Prozedur ist der Wechsel des DNSSEC Signierungs-Algorithmus.

Als SWITCH die DNSSEC-Signierung für die ccTLDs CH und LI im Jahr 2009 entwickelte und testete, entschied sie sich für den DNS Security-Algorithmus RSASHA1-NSEC3-SHA1 (RFC 5155). Aktuell ist der DNS Security-Algorithmus RSA/SHA-256 (RFC5702) einer der verbreitetsten Signierungs-Algorithmen unter TLDs (NANOG 56, E. Lewis), welcher auch von der Root-Zone verwendet wird. SWITCH hat in den letzten Wochen einen sogenannten Key Algorithm Rollover durchgeführt und auf den DNS Security-Algorithmus RSA/SHA-256 gewechselt.

Continue reading “DNSSEC Signierungs-Algorithmus wechseln”

CH-Zone Opfer eines DNS-Amplifikations-Angriffes

Erst ein paar Wochen ist es her, dass wir über DDoS-Angriffe durch Reflektierende DNS-Amplifikation gepostet haben. Heute Morgen um 4 Uhr wurde nun erstmals auch die CH-Zone für einen solchen DNS-Amplifikations-Angriff missbraucht.

NetFlow Daten: Ein- und Ausgehender Datenverkehr der SWITCH CH-Nameserver

Die DNS-Anfragen lauten auf ‘CH’. mit dem Query-Type ‘ANY’. Zusätzlich wird die EDNS-Erweiterung aktiviert, was es ermöglicht in einer UDP-Antwort mehr als 512 Bytes zu erhalten. Ohne EDNS würde der autoritative DNS-Server mit dem gesetzten Flag „TC“ (Truncated) antworten, womit der Client aufgefordert wird, die DNS-Anfrage nochmals über TCP zu schicken. Bei gespooften DNS-Anfragen will man das natürlich verhindern, deshalb ist hier EDNS aktiviert. Wir sehen die DNS-Anfragen von mehreren Quell-Adressen, jedoch ist eine IP-Adresse besonders benutzt. Diese IP-Adresse, welches das Opfer des DDoS-Angriffes ist, empfängt alle Antworten.

Warum wird gerade die CH-Zone missbraucht?

Continue reading “CH-Zone Opfer eines DNS-Amplifikations-Angriffes”

DDoS-Angriffe durch Reflektierende DNS-Amplifikation vermeiden

Das DNS (Domain Name System) Protokoll ist momentan das häufigst missbrauchte Protokoll für Distributed Denial of Service (DDoS) Angriffe. Wurden früher vor allem öffentlich erreichbare DNS-Resolver (Open Resolver) als Amplifikator verwendet, werden heute zunehmend autoritative DNS-Server benutzt.

Was sind reflektierende DNS-Amplifikation-DDoS-Angriffe?
Bei reflektierenden DNS-Amplifikation-DDoS-Angriffen versenden infizierte Clients (meistens aus einem Botnet) tausende von DNS-Anfragen an autoritative DNS-Server, welche als Amplifikator missbraucht werden. Die DNS-Anfragen werden mit der IP-Adresse des Opfers gefälscht. Die autoritativen DNS-Server beantworten die DNS-Anfragen, wobei die Antwort ein Mehrfaches der Anfragegrösse sein kann. Für DNSSEC-signierte Zonen kann schnell ein Amplifikationsfaktor von über 40 entstehen.

Continue reading “DDoS-Angriffe durch Reflektierende DNS-Amplifikation vermeiden”

DNSSEC – Einführung zu DNS Security Extensions

Das Domain Name System (DNS) ist ein wichtiger Bestandteil des Internets. Aus Endbenutzersicht erscheint das Internet oft zusammengebrochen, wenn die Namensauflösung nicht funktioniert. In den letzten Jahren wurden Schwachstellen im Protokoll aufgedeckt, welche es erlauben, DNS-Antworten für einen DNS-Resolver zu manipulieren. Um die Vertrauenswürdigkeit der Daten sicherzustellen, wurde die Erweiterung DNSSEC entwickelt.

Was ist DNSSEC?

DNSSEC ist eine Erweiterung des Domain Namen Systems (DNS), die dazu dient, die Echtheit (Authentizität) und die Vollständigkeit (Integrität) der Daten von DNS-Antworten sicherzustellen.

Continue reading “DNSSEC – Einführung zu DNS Security Extensions”