DNS Flag Day

There are quite a lot of broken DNS servers out there. I’m sure that’s no surprise to you, but some of them might be yours. And you might not notice that until your domains stop working early next year.

DNS is quite an old protocol, and when it was originally specified there wasn’t really a good way to extend the protocol to add new features. That was fixed about 19 years ago when Extension Mechanisms for DNS (EDNS0) was specified, and solidly standardized in RFC 6891 in 2013. It added a backwards compatible way for a DNS client to ask “Hey! Do you support new features?” and for servers to include as part of their response “Yes! Yes I do!”.

That’s incredibly useful, and critical for extending the DNS to support new features (such as DNSSEC, or support for larger replies). And yet some authoritative DNS servers not only don’t support it, they misbehave when they’re asked if they support it. It’s been the case forever that DNS servers should just ignore (some sorts of) fields in requests if they don’t understand them. So when you send a request that includes an EDNS0 “Do you support new features?” field to a DNS server that doesn’t understand EDNS0 it should return a regular DNS response. Some (broken) nameservers don’t do that – instead they drop the request on the floor and don’t respond (or, even worse, crash). Eventually the recursive resolver will give up on the request.

(DNS servers broken in this way aren’t that rare in 2018 – just last week I had to add code to a DNS library I use so that it didn’t crash when it saw EDNS0 requests.)

Right now most recursive resolvers will see a timeout for a request that included EDNS0 and decide “Maybe it only failed because the remote server has buggy EDNS0 handling”. They’ll retry the request without EDNS0 and get an answer. This workaround means that the DNS will resolve eventually, after five or ten seconds of delay. Not good, but the web page will open or the mail will be delivered eventually.

But it’s a horrible workaround, and the developers of the most widely used recursive resolvers are done with this silliness. As of February 1st next year they’re not going to do it any more. If your DNS server is broken with respect to EDNS0 your hostnames won’t resolve via a large fraction of recursive resolvers. Your webpages won’t load, mail you send won’t have any SPF, DKIM or DMARC information or even any reverse DNS. Lots of things will break in a very visible way.

You can check whether your DNS server is broken or not, and get a bunch more technical details at dnsflagday.net.

Related Posts

TXTing

txt
On Friday I talked a bit about the history behind TXT records, their uses and abuses.
But what’s in a TXT record? How is it used? When and where should you use them?
Here’s what you get if you query for the TXT records for exacttarget.com from a unix or OS X command line with dig exacttarget.com txt

Read More

SPF: The rule of ten

Some mechanisms and modifiers (collectively, “terms”) cause DNS queries at the time of evaluation, and some do not. The following terms cause DNS queries: the “include”, “a”, “mx”, “ptr”, and “exists” mechanisms, and the “redirect” modifier. SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return “permerror”.

Read More

December 2016: The Month in Email

Happy New Year! We’re looking forward to some interesting new projects this year, both for our clients and for Word to the Wise. Stay tuned!
December was a slow month for blogging, with everything going on. But we’re back on the horse now and ready to blog for 2017.
WalesCaernarfonCastle
List and subscription management continue to be hot topics, especially in the wake of the listbombing attacks earlier this year. Earlier this month, I presented a webinar on listbombing for the EEC and DMA to review the attacks and discuss best practices for companies to manage subscriptions. For Ask Laura, I wrote about the unsubscribe process and how senders can best manage those requests to keep their lists current and compliant.
With all the holiday mail flying around, Steve wrote up a good post about the challenges of DNS hosting and issues customers may have reaching your site. He also wrote about canonicalization, a process for comparing things to see if they are the same, which is useful for understanding how messages change during the delivery process. It’s important to understand how this works with DKIM, as that process specifically looks at changes to messages in delivery to validate them.
I wrote a post about how delivery at Gmail is a bit different from other mail providers, which can lead to intermittent delivery problems, and got some useful information in the comments about some upcoming process changes. And as always, unwanted email is SPAM. It doesn’t matter if you call it outreach or prospecting, or “here’s something you might find interesting!” Still SPAM.

Read More