SWITCH Security-Blog

SWITCH-CERT IT-Security Blog

1 Comment

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.

DNSSEC signed .ch domain names 1.4.2019

Continue reading

1 Comment

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.


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.

DNSSEC Signed Domain Names in .ch   DNSSEC Signed Domain Names in .li
Continue reading

DNSSEC signing your domain with BIND inline signing

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.


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


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

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

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
                   IN   AAAA  2001:DB8:BEEF:113::10
www                IN   CNAME example.com.
ftp                IN   CNAME example.com.

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

Please read the following sections for a more detailed explanation.

Continue reading


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