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”

The .ch zone file will be published as open data

The Swiss Federal council adopted the lower laws to the telecommunicaiton act today. Amongst it is the Ordinance on Internet Domains that also regulates the ccTLD .ch. SWITCH-CERT welcomes the new ordinance and the smart regulation by the Federal Office of Communications (OFCOM). The Ordinance on Internet Domains will come to power on 1.1.2021 and has some important changes.

The most obvious ist that the personal data of domain holders will no longer be published in the public whois, following other European countries and the GDPR. This is an important change to protect the privacy of Domain holders. There will be a regulated and monitored access for Swiss Authorities and others that require that data for fighting cybercrime or have other legitimate reasons to get access to the identity of a domain holder. You can find more information on the SWITCH website.

Not so obvious, but from the CERT and security persepective as important is that the .ch zone file will be published as a whole. While the data about (active) .ch domains itself has been published in the distributed Domain Name System ever since, the file containing all domain names – the .ch “zone” – was never public. This will change as of January 2021, details on how to access the .ch zone file will be published at the SWITCH open data page soon.

100’000 .ch domain names are secured with DNSSEC!

Imagine you want to visit your online banking website «www.example-bank.ch». Now, instead of getting the correct IP address your computer gets manipulated information and connects you to a website that is owned by a criminal. You wouldn’t notice but disclose your online banking credentials to the attacker.

Luckily, DNSSEC is here to help. The extension of DNS protects you from being misled and helps you reach exactly the address you typed into your browser. A complex cryptographic process makes sure, that you’re always at the right place.

100’000 .ch domain names are signed with DNSSEC

In late December 2019 the .ch zone achieved a milestone with 100’000 DNSSEC secured domains. DNSSEC adds digital signatures to DNS answers and helps to mitigate attacks on DNS name resolution.

The percentage of .ch domain names that are signed is still below 5%, but is rising thanks to a few registrars like Infomaniak, OVH, Firestorm and netzone that sign domain names for their customers by default. The number of DNSSEC signed .ch domain names rose 54% from 1.1.2019 to 1.1.2020.

By January 1st 2020 the .ch zone contained 100’065 domain names that are secured with DNSSEC

Top .ch domain names are just average regarding domain name security

Continue reading “100’000 .ch domain names are secured with DNSSEC!”

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”

Breaking security controls using subdomain hijacking

Users obtain a domain name to establish a unique identity on the Internet. Domain names are not only used to serve names and addresses of computers and services but also to store security controls, such as SPF or CAA records. Many of the Internet protocols were designed at a time where built-in security was not a requirement. The IETF continues to standardize protocol extensions to address today’s security needs.

For some protocols security is added with controls stored in your domain names zone file. In order to have the desired effect, the pre-condition is of course that your domain name is secure. In other words, the security of your application that makes use of controls in DNS is only as secure as the security of your domain name.

Hijacking a domain name because of weak credentials at the registrar may get the job done but this is far from stealthy and will likely not last long. In many cases it is sufficient to hijack an abandoned subdomain. Taking over abandoned subdomains may be unnoticed by the owner for a very long period of time making it also very useful for targeted attacks.

Picture 1: update.ft.com has been hijacked and the content from the ft.com front page is mirrored with a fake article about subdomain hijacking. Note: the website is not online anymore, Financial Times has been notified to remove the abandoned record from their zone file. A Certificate Transparency (CT) log proves that a TLS certificate has been issued for this demo site.

Continue reading “Breaking security controls using subdomain hijacking”

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”

Why the most successful Retefe spam campaign never paid off

Switzerland is one of the main targets of the Retefe banking trojan since its first appearance in November 2013. At that time, it changed the local DNS resolver on the computer (See also blog post “Retefe Bankentrojaner” in German only). Almost a year went by until they changed to the still current approach of setting a proxy auto-config (PAC) URL (See also blog post “The Retefe banking Trojan has targeted Switzerland“). To understand the story of this blog post, it helps to understand the modus operandi of the Retefe malware. We recommend you read up on it on our blog links posted above if you are not familiar with it.

While the Retefe actors are constantly changing tactics, for example their newest campaigns also target Mac OS X users, their malware still works the same. One of notable changes was the introduction of Tor in 2016. At first, they started using Tor gateway domain names such as onion.to, onion.link within the proxy auto-config URLs, later on they switched to Tor completely. The advantage of using Tor is of course, anonymity and the difficulty to block or take down the infrastructure.

Onion domain names don’t use DNS or do they?
The Tor network can use .onion domain names but these names are not resolved over DNS but instead work only in the Tor network. RFC 7686 (The “.onion” Special-Use Domain Name) goes into more details on the special case of .onion domain names. However, the fact is that .onion domain names do leak into the DNS system. For potential reasons and more information on this subject we recommend the paper by Versign Labs “Measuring the Leakage of Onion at the Root” (PDF).
Continue reading “Why the most successful Retefe spam campaign never paid off”

SWITCH DNS recursive name service improvements with dnsdist

SWITCH operates recursive name servers for any user within the Swiss NREN. While larger universities typically run their own recursive name server, many smaller organisations rely on our resolvers for domain name resolution. During the consolidation of our name server nodes into two data centres, we looked for opportunities to improve our setup. Dnsdist is a DNS, DoS and abuse-aware load balancer from the makers of PowerDNS and plays a big part in our new setup. While the first stable release of dnsdist (version 1.0.0) is only a few days old (21 April 2016), it feels like everyone is already using it. We are happy users as well and want to share with you some of the features we especially like about dnsdist.

Our old setup consisted of several name server nodes which all shared the same IP address provided by anycast routing. Our recursive name server of choice was and still is BIND, and we have been providing DNSSEC validation and malicious domain lookup protection through our DNSfirewall service for some time. While this setup worked very well, it had the disadvantage that some badly behaved or excessive clients could degrade the performance of a single name server node and as such affect all users routed to this node. Another disadvantage was that each name server node got its share of the whole traffic. While this may sound good, it has the disadvantage that we have several smaller caches, one on each node. My favorite quote from Bert Hubert, founder of PowerDNS, is: “A busy name server is a happy name server“. What it means is that it is actually faster to route all your queries to a single name server node because this will improve the cache-hit rate.

Dnsdist provides a rich set of DNS-specific features
Our new setup still makes use of anycast routing. However, it is now the dnsdist load balancer nodes that announce this IP address, and they forward the queries to the back-end recursive name servers for domain name resolution.

The server nodes are located in two data centres, and both load-balancers announce the same IP address to make use of anycast routing. Query load is typically sent to resolvers within the same data centre but is distributed to the other site as well in the event of a higher load or server loss.

Optimizing Negative Caching Time in DNS

A recent presentation by SIDN (.nl) at the Spring 2016 DNS-OARC workshop reminded me of the importance of Time-To-Live (TTL) values in TLD zones. Specifically, it got me thinking about lowering the negative caching time in .ch/.li from currently 1 hour to 15 minutes.

What is negative caching?
When a resolver receives a response to a query, it caches it for the duration of the TTL specified by the record. For positive responses, the record contains the TTL, but for negative responses (response code NXDOMAIN), there is no answer to the query question. For this case, the response contains the SOA record of the zone in the authority section. Negative caching is specified in RFC 2308 as the minimum of the SOA record’s TTL and the SOA minimum field. For example, the original SOA record of the .ch zone looked as follows:

dig +nocmd +noall +answer @a.nic.ch ch. soa ch. 3600 IN SOA a.nic.ch. helpdesk.nic.ch. 2016041421 900 600 1123200 3600

The SOA TTL is 3600, and the SOA minimum time is also set to 3600. The minimum of these two values is of course 3600 too. That means the negative caching time for any .ch domain lookup is one hour.

A lower negative caching time is more user-friendly
People who are about to register a new domain name may also look up the name over DNS. However, this means that they just cached the non-existence of the name in the resolver they are using. A domain can be registered in a matter of minutes, and this can prevent them from using the domain name on their network for the duration of the negative caching time.
Continue reading “Optimizing Negative Caching Time in DNS”

A Yeti in the DNS

written by Yves Bovard

Most of the time, the Internet works without any problem; we can just power on our computer and start surfing… ok, most of the time. Many things have to be reliable to make this possible: power, cables, routers, computers, software and, last but not least, the DNS. This last point is one of the most critical parts of the Internet. Each time we read our favorite online newspapers, each time we check our e-mails, write and reply to them, or more generally, each time we use the Internet, many queries are sent to DNS servers to convert (more or less) meaningful Web addresses to IP addresses. And this is only the tip of the iceberg.

In the early days of the Internet, this task was handled by a single file. During the 1980s, however, it became clear that such a method was not scalable enough. The DNS was thus born. Three parts were designed. First, the stub resolver is located on your computer. It receives your question: what is the IP of www.switch.ch? This question is transformed to a standard DNS message and sent over the network to the second part, the resolvers. These are able to find an answer almost instantly, either because somebody has already looked for it or by querying the third part, the authoritative servers, located somewhere on the Internet. They are structured in a hierarchical tree, with root servers at the top. Some of them know the answer to the question you asked.

Nowadays, the authoritative root of the tree is made up of 13 servers named alphabetically from a.root-servers.net to m.root-servers.net. In reality, a technique named anycast allows a much larger number of servers around the world to listen out for (and answer with) the same address. For example, k.root-server.net actually comprises 33 nodes spread all across the globe. To analyse the workload of the DNS, DNS OARC (DNS Operations Analysis and Research Center) computes yearly statistics (Day in The Life of the Internet, DITL). In 2015, it used a time window of three days and found that 10 of the 13 root servers answered about 60 billion queries in this period.

The current state of this infrastructure is robust. A single server failing to respond does not affect the availability. When a server is overloaded, we can just add more servers to spread the traffic. The size and complexity of this infrastructure make it hard to analyse. The new Yeti DNS Project (www.yeti-dns.org) aims to study it by asking the following questions and more:
Continue reading “A Yeti in the DNS”

So Long, and Thanks for All the Domains

While Trojans like Dyre and Dridex are dominating malware-related news, we take the time to have a closer look at Tinba (Tiny Banker, Zusy, Illi), yet another Trojan which targets Windows users. In the first part of this post, we give a short historical review, followed by hints about how to detect (and remove) this threat on an infected system. In the second part, we have a look at a portion of the Trojan’s code which enhances its communication resilience, and how we can leverage these properties for defensive purposes.

Tinba is a fine piece of work, initially purely written in assembly. CSIS discovered it back in May 2012, and it contained WebInject capability and rootkit functionality in a binary of just 20 KB. The source code of Tinba leaked in July 2014, helping bad guys to create their own, extended versions.

Tinba Rootkit ZwQueryDirectoryFile — The source code of Tinba leaked in July 2014. Shown are some preparations to hook ZwQueryDirectoryFile.

Tinba on steroids was discovered in September 2014. Two main features are worth noting: First, each binary comes with a public key to check incoming control messages for authenticity and integrity. Second, there is a domain generation algorithm (DGA), which we will discuss later. In October 2014, Tinba entered Switzerland, mainly to phish for credit card information.

Tinba Inject — Tinba tried to phish credit card information.

Like other commodity Trojans, Tinba checks whether it is running in a virtual machine/sandboxed environment by checking the hard-disk size or looking for user interaction. According to abuse.ch, there was an intense distribution of Tinba in Switzerland early this year. Such spam campaigns can happen again at any time, so it is of use to know how to detect Tinba on an infected system and remove it.

Even though Tinba has the ability to hide directories and files (rootkit functionality), cybercriminals were wondering why they should bother using it. Why not simply hide directories and files with the “hidden” flag, which works for most users? Thus, it is relatively simple for a computer-savvy user to remove this version of Tinba from an infected (see instructions below).

Tinba Directory Hidden — A randomly named directory, which contains the Trojan itself, can be hidden by setting its attributes to “hidden”.

Continue reading “So Long, and Thanks for All the Domains”

Protect your network with DNS Firewall

If you run your own mail server, you will quickly find out that 90% of the e-mails you receive are spam. The solution to this problem is e-mail filtering, which rejects or deletes unwanted spam. This solution is generally well accepted, and most users would not want the old days back when your inbox was filled with scams. Those people who want spam can also work around it by disabling spam filtering for their e-mail address or opting to run their own mail server.

Spam, scammers and other malicious abuse are not unique to e-mail. One possible approach is to invent a filtering technology for every protocol or service and allow the service owners to block misuse according to their policy. On the other hand, most services on the Internet make use of the Domain Name System (DNS). If you control DNS name resolution for your organisation, you can filter out the bad stuff the same way you filter out spam on e-mail. The difference and the advantage of DNS is that DNS filtering is independent of the service you use.

Back in 2010, ISC and Paul Vixie invented a technology called Response Policy Zones (RPZ) (See CircleID Post Taking back the DNS). While it has always been possible to block certain domain names from being resolved on your DNS resolver, adding host names manually as an authoritative zone does not scale.

Continue reading “Protect your network with DNS Firewall”

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”

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”