SWITCH Security-Blog

SWITCH-CERT IT-Security Blog


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.

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.

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.

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


2 Comments

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)
                )

         172800    IN   NS    ns1
         172800    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      172800    IN   A     192.0.2.22
         172800    IN   AAAA  2001:DB8:BEEF:2::22
ns2      172800    IN   A     198.51.100.22
         172800    IN   AAAA  2001:DB8:BEEF:100::22
...

Please read the following sections for a more detailed explanation.

Continue reading


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


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