As part of our stricter handling of SERVFAILs on CAA record lookups, I did an additional analysis of hostnames that have Let’s Encrypt certificates and currently return SERVFAIL for CAA, counting by nameserver. I found that the biggest group of nameservers that return SERVFAIL for CAA are the ones belonging to namebrightdns.com (see example). I’m having trouble parsing out the exact problem; can anyone else see what’s wrong with their responses? Also, does anyone have a technical contact at NameBright? Their whois data only shows supprt@namebrightdns.com.
I’ve just hit a new customer signup who are using this mob, and… it ain’t pretty.
Like you, @jsha, I can’t figure out exactly what the problem is with their service of CAA records. It might be that the responses are corrupted, although I’m surprised that unbound doesn’t shout a big warning about that.
It definitely seems their DNS servers are broken in many spectacular and varied ways. When I dig @ns2.namebrightdns.com nonexistentname.threadbanger.com I get a vaguely consistent NOERROR (not NXDOMAIN!) response that includes the warning “Message has 11 extra bytes at the end”. On the other hand, if I ask for a CAA record (for a name that does or doesn’t exist) I get a response that indicates it has one ADDITIONAL record, but none is printed. Worse, their servers are so screwed up that if I resolve a name that I know is a CNAME (forum.threadbanger.com) it only answers with the CNAME for A and AAAA requests – everything else gets an empty NOERROR (most with “11 extra bytes at the end”).
Essentially, I think these people are running maxtremely shonky software. I don’t know what, because the usual bind.version query doesn’t return anything, which leads me to think it’s probably home-grown. I’ve advised our customer to find a new DNS provider, because I can’t imagine all this crazy is going to be fixed real quick.
Good news: I think I’ve found the source of the bug. In response to DNS queries with unrecognized qtype (including both CAA / TYPE257, and a random undefined qtype, e.g. TYPE119), Namebright’s DNS servers send a response that has the Query/Response (QR) flag set to “Query (0)” when it should be “Response (1)”. The servers correctly set this flag when qtype = A.
The DNS RFCs specify that unrecognized qtypes should be handled transparently with NOERROR. I think if Namebright can get their nameservers to set QR to 1 for responses to all qtypes, this issue would be fixed.
I’ve attached an example pcap demonstrating the pattern. This is a subset of a resolution by Unbound, narrowed to just one of Namebright’s IPs. In practice Unbound receives the response packet and discards it due to the incorrect flag, treating it as a timeout and moving onto the next IP address to ask.
Update: I’ve emailed Namebright support with the details above and a request to forward to their Director of Software Development. The support staff said they’d forwarded it, but so far I haven’t gotten a reply.
In the meantime, @sahsanu has written a detailed guide for Namebright customers on how to change your authoritative DNS to Cloudflare. Following this guide for your domain will fix the CAA SERVFAIL for you and allow you to issue again: Guide to change DNS servers from NameBright to CloudFlare.
