DNSSEC Validation and Deployment Planning for ISPs

In this article

Enabling DNSSEC validation on a resolver is usually the easy part. The real work is making sure it behaves correctly on the ISP network, and that support can tell a validation failure from an ordinary DNS problem.

I wrote this article to explain the steps and logic for a validating DNSSEC resolver. It covers the resolver itself, the network path, the rollout, and what needs to be in the logs when something breaks.

What Is the Resolver Checking?

For a signed zone, the resolver gets more than the address record. The RRSIG is the signature and the DNSKEY is the key used to check it. The parent zone publishes a DS record that points to the key it expects the child to use. The resolver works back through those records until it reaches a trust anchor it already has. For an ISP resolver, that is normally the root trust anchor.

An unsigned domain can still resolve normally. A domain that claims to be signed but has a broken chain is different. The resolver should return SERVFAIL rather than give the customer an answer it cannot validate. This is handy because not everyone is using DNSSEC.

A stale DS at the registrar is a common example. The parent points to one key, but the child serves another. The mismatch is usually easy to see when you follow the chain.

Start With dnssec-failed.org

I usually start with dnssec-failed.org. A validating resolver should return SERVFAIL. I check the resolver log to make sure it tells me why. Then I try a signed domain and an unsigned domain. Both should resolve normally.

If the resolver returns SERVFAIL, I want to know why. Was the signature expired, or did the resolver time out trying to reach the authoritative server? SERVFAIL alone does not give support much to work with when the customer calls.

Check the resolver clock too. DNSSEC signatures have start and expiration times. A bad clock can make a valid signature look expired or not valid yet. I check every resolver node, especially one that has been offline and is about to return to service.

Test UDP and TCP From the Resolver

The next thing to look for is whether the resolver can get a large DNS answer back. A small UDP reply may work while a fragmented reply gets dropped by a firewall. I test TCP port 53 from the same resolver path too. Some queries retry over TCP, and those domains fail if that path is blocked.

Run the tests from the resolver VLAN. A laptop on the management network may use a different source address, firewall, or upstream route and never reproduce the problem.

Does the ISP resolver recurse on its own, or does it forward the query somewhere else? With two resolvers in the path, the local log may show only the SERVFAIL it received from upstream. Find the resolver that actually performed validation. That is where the useful error should be.

Spin Up a New Resolver for Testing

I would not use the secondary DNS field for the tests. Clients do whatever they want with primary and secondary. Some stick to the first address, some use both, and some switch between them. You can see traffic on the validating resolver, but you do not have a clean group of test subscribers.

We can start with a resolver in your lab or a third one on your network. I like spinning up a new resolver because I can then use it and see what a customer would see. After that, move a known set of test devices or subscribers to an address you can identify in the logs. On an anycast network, verify which node receives those queries. A route change should not move the pilot to another site without anyone noticing.

A Broken Domain

At some point a domain operator will publish an expired signature, remove the wrong key, or leave an old DS at the parent. Customers behind a validating resolver will not reach the domain. Someone testing with a non-validating resolver may say it works fine.

Support needs to recognize that case. Query the domain through the ISP resolver, then look at the DS, DNSKEY, and RRSIG records. If the chain is broken, the ticket should say that. There is no reason to send a field technician to work on the customer’s access circuit.

If one domain has a bad DNSSEC chain, do not turn validation off for the whole resolver. If that name has to be allowed through, add a negative trust anchor and set an end date. I also want the ticket number in the note so somebody knows why it was added. Six months later, that exception may still be there with no record of why it was added.

Signing ISP Zones Is a Different Project

Turning on validation for subscriber queries does not sign the ISP’s authoritative zones. Treat those as separate changes with separate tests.

For a signed zone, query the DS from the parent and compare it with the key the child is serving. Then look at how signatures are refreshed and when old keys are removed. A rollover can look correct in the zone configuration while validating resolvers are already returning SERVFAIL.

Reverse zones need the same work if the ISP plans to sign them. I would start with one zone where the parent delegation is understood, check it from outside the ISP network, and then move to the next one.

How Justin Can Help

I can review your current resolver and help get validation into production. We can work through the configuration, the network path, and the subscriber rollout with the people who will operate it.

I also help ISPs sign zones they operate and prepare for key rollovers. Contact Justin Wilson at J2 to talk through where DNSSEC fits in your network.

j2networks family of sites
https://j2sw.com
https://startawisp.info
https://indycolo.net
#packetsdownrange #routethelight