The Domain Name System (DNS) is a crucial component for the good functioning of the internet. It’s the system that makes it possible for visitors to find your websites and customers to exchange email with your organization.
DNS has been around for a very long time and a lot has changed since its original publications in RFC882 and RFC883 in the early 1980s. Over time, new features have been added, but unfortunately, the system still had to guarantee backward compliance with previous implementations — that is, until DNS Flag Day.
Extension Mechanisms for DNS
One of those new features was the extension mechanisms for DNS (EDNS), which extended the old system with additional information such as new flags and response codes. A major benefit of EDNS is that it allows a server to understand whether it is talking to another server that supports EDNS as well. If they both support EDNS, they can exchange the additional information, and if a server doesn’t support EDNS, it will just ignore this information. This is important because it’s not mandatory to implement EDNS.
EDNS itself relies on resource records (RR). RRs are, in essence, domain name server database entries and can include A or CNAME records — the pointers to your website — or MX records, which tell everyone which mail servers to use when they want to contact your organization.
One record type, the OPT “pseudo” RR type, was specifically foreseen for EDNS. Whereas “normal” record types, such as A or MX records, are included in zone files, OPT record types will never appear in a zone file. The OPT record only exists in the messages exchanged between a server and a client. For completeness, when referring to EDNS, based on the latest published standard (RFC 6891), you should refer to it as EDNS(0).
EDNS is also essential for the implementation of DNS Security Extensions (DNSSEC). More on that later.
Backward Compatibility and DNS Flag Day
In theory, the published specifications (and extension protocols) should result in a uniform implementation. Unfortunately, these specifications sometimes leave room for interpretation and certain coding decisions result in different implementations. Additionally, some implementations are just broken and are not at all compliant with these standards.
The end result is that developers continuously have to address interoperability between different existing implementations. This also means that a substantial amount of code (and effort) is spent on coping with these broken implementations. All this adds to the complexity of the solution and hogs up valuable resources that developers could otherwise spend on improving the software.
To resolve these problems, different DNS software and service providers agreed to coordinate removing accommodations for these noncompliant implementations so their developers could focus more on deploying new features. That switch, which was referred to as DNS Flag Day, happened on February 1, 2019.
Wait … Nothing Happened, My DNS Still Functions
This is not unusual, as the changes only affected noncompliant software. However, because of the potential impact of a nonfunctioning DNS infrastructure, it is important to raise awareness. Also, note that Feb. 1 was merely the day that open-source resolver vendors released their updates. It doesn’t necessarily mean that these updates are already applied everywhere. You might still have to face the consequences of this update at a later stage.
Inventory and Test Your Domains
The first thing you should do is review if your asset inventory contains sufficient information on your domains, as well as where the DNS service providers for these domains are located. This type of information is also essential to your incident response plans — for example, the plan to combat distributed denial-of-service (DDoS) attacks. Ideally, you should be able to answer each of the following questions:
- Is the service in-house or outsourced? If it’s in-house, which software do you use and what is the patch management policy?
- On which logical and physical networks are the servers located?
- What is the update process for domain and record information (via a web console, a master server on your network, etc.)?
- Which protection measures are put in place to access the management consoles?
- Is there an alert system if a change was committed? Do you monitor the changes in your domain records and registrations?
- Do you use Registrar-Lock code to protect your domains (e.g., RFC3632)?
- Are zone files versioned and can you easily roll back to older versions? This is not the same as the serial number in the Start of Authority (SOA) record.
When you have inventoried all your domains, you can test them on the DNS Flag Day homepage. The test results will tell you if the servers supporting your domain are in compliance with the new standards or not. You can do bulk testing of domains via the EDNS Compliance Scanner. Note that if you have multiple domains all hosted on the same server, then you only need to do the test once, for one domain. This is because the changes are tied to the server providing the service, not your actual domain configuration (zone file).
Uh Oh, the Test Failed
If the test fails, you shouldn’t immediately start to panic. It is important to rule out any intermediate problems that could have caused the test to fail. Analyze the results and check if the failure could be caused by timeout problems or problems with load balancers or firewalls. If you’re unsure, try the test again. A temporary network hiccup might have negatively affected the results.
If the test continues to fail, it’s time to upgrade your software. If you control your own servers then you can do this yourself and repeat the testing after upgrading. Make sure you also review your firewall setup and verify that they do not drop packets with EDNS extensions. Also, check that your software is configured to support requests via both Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).
If your services are hosted somewhere else, you’ll have to convince your host to upgrade. Be sure to rule out that the security protection measures put in place by your host are not the cause of the test failure. Some hosts implement rate limiting and the volume of test queries could potentially be seen as an attack. It’s best to conduct the tests on different occasions. You can then use the information provided by PowerDNS and cz.nic to convince them of the necessity to upgrade.
What DNS Security Features Can I Deploy?
There is an additional benefit to making your DNS software compliant with the new standards and applying the latest updates; it allows you to make use of some of the new security features.
DNS Cookies
One of these features is the so-called DNS cookies. This cookie is an EDNS option that, if supported by both the server and the client, can help you ignore spoofed responses. Cookies are one of the mechanisms that you can implement as a protection against DDoS attacks.
A server can use DNS cookies to rate limit the number of requests a client can send. Here, cookies are used to whitelist known clients for Response Rate Limiting (RRL). The queries coming from clients with valid cookies will not be rate limited.
This mechanism can also be used to prevent a server from replying to spoofed packets. By using cookies, a server can filter out the legitimate requests from spoofed queries — as long as the client also supports the cookie option. This effectively prevents your server from flooding a victim with responses if the source IP was spoofed to the address of the victim. There will still be a relatively low amount of traffic sent to the victim (the error messages), but the total volume will be low.
An additional benefit is that resolvers can also reject replies that do not contain the correct cookies, preventing cache poisoning and answer forgery attacks.
As with most features, there’s also a downside to DNS cookies. Just like traditional HTTP cookies, DNS cookies can be used to track users on the web. One difference is that DNS cookies can also be used outside a web browser.
It will probably take some time before cookies are supported by all servers. Does this mean you should wait? No! Servers that are properly compliant with regard to EDNS options but do not support cookies will have no issues, they will simply ignore the cookies.
DNS Security Extensions
DNSSEC is another feature that adds a layer of security to the lookup and exchange processes for domain name resolution. It requires the queries for a given domain to be digitally signed, and protects users (and systems) from going to unintended, possibly fraudulent, locations. Note that DNSSEC does not prevent perpetrators from listening in on traffic; it will not encrypt your traffic or queries. Also, to be successful, this feature needs to be implemented for both signing (the zones) and validation (the responses).
DNSSEC is a very effective solution for mitigating DNS spoofing or hijacking attacks. A spoofing attack is when an attacker is able to inject a change in data into the resolvers’ cache. A hijacking attack is when an attacker is able to force the victim into using a different nameserver (resolver) or is able to change the actual resource records that are configured for a domain. The net result is that, as a victim of such an attack, you get redirected to infrastructure under control of the attacker. These widespread attacks can also potentially lead to attackers gaining access to your sensitive data, including, for example, the authentication credentials for email.
Unfortunately, despite the fact that the core of DNSSEC specifications were already published in RFCs in 2005 and about 90 percent of top-level domains (TLDs) are now signed, it’s adoption rate is still fairly low. If you want to focus on further protecting your domain name infrastructure, then it’s absolutely worth investing some extra time and resources in deploying DNSSEC for your domains.
Have You Updated Yet?
Whether or not you plan on using DNS cookies or DNSSEC, foreseeing an upgrade plan for your software to the latest version made available as part of DNS Flag Day is highly advised. Not only will you experience a performance gain, but updating today allows you to make use of existing security features and those still to come.
The post Missed DNS Flag Day? It’s Not Too Late to Upgrade Your Domain Security appeared first on Security Intelligence.
