DNS autoritative reply with NOTIMP but renewal process detect SERVFAIL looking up CAA and not renew

My domain is LEADER.IT
All authoritative server reply with NOTIMP to this query:

(I have replaced @ with AT to bypass mail list erroneus application check e-mail limits)

dig __AT__77.72.193.200 leader.it -t type257
dig __AT__77.72.193.201 leader.it -t type257
==> ; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 59012

But “/opt/certbot/certbot-auto -n renew” reply with error: “DNS problem: SERVFAIL looking up CAA for leader.it

Probably a DNS intermediate server you use reply SERVFAIL instead NOTIMP.

For example Google DNS reply with SERVFAIL:

dig __AT__8.8.8.8 leader.it -t type257
==> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 40448

If you do not verify the authoritative servers, all websites served by DNS services that do not implement CAA will be excluded long before the deadline agreed in September 2017.

If an update is not available, replacing DNS software is not a matter of minutes :frowning:

You're right. The intermediate server in question is a recursive DNS server running Unbound operated by Let's Encrypt. A variety of issues (authoritative nameservers don't respond, do respond with NOTIMP, with REFUSED, DNSSEC is invalid, etc.) all get reduced to a simple "SERVFAIL" error code.

It's just the way of things with DNS. There are options in development or usable now, such as moving from dedicated DNS servers to an in-process DNS resolution implementation that exposes error messages to consumers, implementing a different protocol like Google's HTTP and JSON scheme, or a draft to add extended error information to the DNS standard, but for now Let's Encrypt is subject to typical environmental limitations.

The CAA standard was published in January 2013. By September, DNS software developers and operators will have had close to 5 years to fix and update their servers.

Beyond that, a reasonable DNS server should respond reasonably to queries for unrecognized types, even if they don't have explicit support for CAA. Let's Encrypt of course has no problem using authoritative DNS servers that are not badly broken. (To be clear, no one is required to have a CAA record. A valid negative response is absolutely fine.)

There should not have been, and should not still be, widespread problems with the deployment of CAA queries. That there were and are shows the sorry state of the DNS server community.

(I'm sympathetic to, but not wholly impressed by, DNS servers running slightly out-of-date software on circa-2014 long-term-support operating systems. But patches for security vulnerabilities and other serious bugs are routinely backported to such systems. It's not ideal, but this is a case where that needs to happen.)


I forgot to add, there's an ongoing discussion on debugging DNS issues, and https://unboundtest.com/ is now available to produce Unbound debug logs from a setup similar to Let's Encrypt's.


We were informed about the expiration of September 2017 (*) and we had planned the migration of the old DNS server in August (it is connected to a dynamic DNS service that will be rewritten to use a different DNS server with CAA support), but with this change we must anticipate migration with urgency.
Your kind response confirms to me that we don’t have alternatives.

My best regards! … and thanks for your work done to make Let’s Encrypt!!!
Guido Brugnara

(*) https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-cabrowser-forum

Well… Let’s Encrypt has maintained a shrinking whitelist of domains with problematic DNS servers. You may be able to ask the staff to continue to whitelist your domain until September.

I’m sorry you’re in this situation. :sweat:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.