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
                   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 “DNS Zone File Time Value Recommendations”


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”

IT-Security-Links #33

  • Simon Mullis of FireEye now posted the last part of the three-part series we mentioned last week with the title “Thinking Outside the Sandbox“. It seems like Anti-Virus vendors are using uploaded files from VirusTotal and alike services to find new Command-and-Control (C&C) servers but do this only successfully for ZeuS based malware families.
  • A talk from Alex Stamos at the Black Hat conference last week made the point that RSA is broken in four to five years. The BREACH attack he showed abuses the fact that compression combined with encryption is problematic. Applied to HTTPS he was able to steal a secret in under 30 seconds.
  • Nice write-down of the Comfoo APT threat by SecureWorks. While it targeted mainly Japanese and Indian government ministries, other industries such as education were targeted as well. The article concludes with the very true statement that most businesses will never see a Comfoo infection. However, evaluating whether an organization is a potential target of cyber-espionage is important in any risk evaluation.
  • OpenX downloads were compromised. OpenX is an open source ad serving product used widely on the Internet. The binary distribution contained malicious files with a backdoor. The file was modified in November 2012. So, if you downloaded this software within the last 7 months, attackers have full access to your site.
  • Matt Johansen of WhiteHat Security writes about Two-Factor Authentication. What it is, why you should care and how it is used by Google, Facebook and Twitter. Read the article and then go and enable it for your accounts if you haven’t already.

IT-Security-Links #32

IT-Security-Links #31

IT-Security-Links #30

  • Geoff Huston (APNIC) published a long post on his DNSSEC validation measurements. Since March 2013 he has seen an rise in the number of DNSSEC validating resolvers from 3.3% to 8.1%. This increase is mainly because Googles public DNS has started to validate a few weeks ago. For Switzerland the number of validating DNSSEC resolvers is at 5.13%.
  • Mac OS X Malware: Malwarebytes.org reports that FBI ransomware is now targeting Apple’s Mac OS X users. The news received a lot of attention and so Malwarebytes.org posted a Q&A.
  • AndroRAT, is a free Trojan horse for Android devices that allows a remote attacker to gain control over the device and steal information from it. Cybercriminals have now created a tool called “binders” that easily allows users to repackage and Trojanize legitimate Android applications with AndroRAT. To date, Symantec has counted 23 cases of popular legitimate apps being Trojanized in the wild with AndroRAT.
  • You would think that server compromises have advanced a lot. This does not mean that old style attacks such as simple account brute-forcing still don’t work. According Sucuri SSH brute-force, an attack 10 years old still persists.
  • Harlan Carvey from the Windows Incident Response Blog posted the first part of the HowTo serie “Malware Detection”. An interesting read on how to easily detect malware on an infected computer.

Was kommt nach DNS Response Rate Limiting?

Werden autoritative DNS-Server über reflektierende DNS-Angriffe missbraucht, zum Beispiel um in einem Distributed Denial of Service (DDoS) Angriff ein Zielsystem zu überlasten, so ist eine der vorgeschlagenen Massnahmen DNS Response Rate Limiting (DNS RRL) zu aktivieren.

SWITCH hat auf diesem Blog bereits in früheren Posts über DNS Angriffe und Massnahmen berichtet. In diesem Artikel möchten wir unsere neusten Beobachtungen im Betrieb von DNS RRL teilen und zeigen, dass es Anzeichen gibt, dass die Angreifer die Schwächen von DNS RRL ausnutzen um weiterhin ihre Angriffe durchführen zu können.

Stärken und Schwächen von DNS RRL
Für viele autoritative DNS Serverbetreiber war DNS RRL eine ersehnte Lösung um die Serverlast und vor allem die ausgehende Serverbandbreite aufgrund von reflektierenden DNS-Angriffen einzuschränken. DNS RRL lässt für einen IP-Adressbereich nur eine bestimmte Anzahl identische DNS Antworten zu. Wird der konfigurierte Schwellwert überschritten, verwirft DNS RRL zum einen die DNS-Antwort. Für einen anderen Teil der Antworten wird das “Truncated”-Bit (TC) in der Antwort gesetzt, damit wird der DNS Resolver aufgefordert, die Anfrage noch einmal über TCP zu stellen. Da bei reflektierenden DNS-Angriffen die Quelladresse gefälscht wird, kommt nie eine Verbindung über TCP zu Stande. Im Gegensatz zu Firewall-Regeln hat der DNS RRL Ansatz den Vorteil, dass bei einem leicht geänderten Angriffs-Pattern (z.B. Query-Name ändert) die implementierten Firewall-Regeln nicht angepasst werden müssen. Kurz, DNS RRL ist sehr effektiv gegenüber Angriffen, bei denen DNS-Anfragen gesendet werden, welche in identischen Antworten resultierten.
Continue reading “Was kommt nach DNS Response Rate Limiting?”

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”

Analysing DNS traffic using PacketQ

Our authoritative only name-servers are every once in a while hit by strange DNS queries. To spot anomalies we use DSC (DNS Statistic Collector), which allows exploring many details of DNS requests and responses to and from our name-servers. Usually one can already get a good sense of what has happened with DSC. However often, deep packet inspection is needed to get the full picture.

DSC Statistic showing query-type MX and ANY traffic anomalies
DSC Statistic showing query-type MX and ANY traffic anomalies

DNS traffic heading towards our authoritative only name-servers is stored for a few days in PCAP. Should we have any need to analyse some of the data we can then easily do so. Analysing very large PCAP files may sound cumbersome but thanks to PacketQ this is actually very easy and fast. PacketQ was originally developed by IIS.SE and is open source. It is a command line tool to run sql queries directly on PCAP files. It exports some IP and UDP header fields and most importantly all DNS protocol fields.

Continue reading “Analysing DNS traffic using PacketQ”

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