I have a suggestion to create the possibility for domain owners to configure how multi-VA should be treated for their domain.
And that is a TXT-record. This special TXT record is fetched from all network locations, and this TXT-record MUST be consistent. This TXT record then decides what happens next.
Note that since this TXT record is fetched from ALL locations, and this record must then be consistent in label and content across all 4 requests, its not possible for an attacker to in any way cheat with this record.
could be like:
_letsencrypt-config.domain.tld IN TXT “v=1; vs=(main, [NUMBER], random, all); vc=(single, all, majority); vr=(valid, consistent, strict, very-strict); onerror=(ignore, fail, fail-label, fail-all);”
Now to specification:
v = Version number. 1 for this time.
vs = Validation strategy. - Decides how LE will push out queries.
“main” means it will only validate from main server
[NUMBER] means that the DNS-server will receive [NUMBER] requests for each record from [NUMBER] random different locations. [NUMBER] cannot of course be higher than the number of server locations LE have.
“random” means that the DNS-server will receive a random number of requests from a random number of different locations, for each record.
“all” means that it will always receive 4 requests, one from each location, for each item.
vc = Validation count - Decides how results are intepreted.
“single” = Only a single validation attempt need to validate. This means a more insecure approach since a attacker only needs to compromise one of the 4 network paths to succeed. But this could be desirable for some domain owners which have buggy/weird DNS server setups which are inconsistent, and they want to succeed at first hit on a “good” response.
If different CAA policies are stumbled upon, the most “generous” policy will be applied.
“all” = All validation attempts must validate.
If different CAA policies are stumbled upon, then a policy that fulfills all CAA policies combined, will be applied.
“majority” = A majority of the validation attempts must validate. Rounded upwards, so a tie is considered a success if the success contains multiple records. If the tie consist of single records only, then fail.
if different CAA policies are stumbled upon, only policies that are present in a majority of the requests are used to build the “combined” policy.
vr = Validation requirement - Decides how strict it should be when comparing records
“valid” = They just need to be valid, basically be as valid as if a single server hitted. (the config TXT still needs to be consistent)
“consistent” = The content and label of the DNS record must match.
“strict” = More stricter consistency check - TTL must also match.
“very-strict” = strictest. This also means serial and SOA must also match completely, thus all requests must respond identically in all regards.
onerror = Decides what should happen on an error.
“ignore” = Ignore the error completely, as if the request never happened. Note that if all 4 requests result in a ignore, it would obviously fail, but otherwise, in configurations where for example all is specified, and a single authorative server is down or has DNSSEC sheniningans, then “all” would skip that server. This means that a attacker, by attacking a single authorative server (DDoS) or breaking one of the network links, could get one or more validation paths (but not all) ignored, but if that is the domain owner’s wish, respect him.
“fail” = Fail this request only, like if NXDOMAIN/404 was received for this challenge.
“fail-label” = Fail all requests associated with this label. (meaning a majority config will fail if a SERVERR is received instead of a single server returning a inconsistent or non-validating record)
“fail-all” = Fail all outstanding requests for this domain (all outstanding authorizations for this domain will fail)
default (today’s policy) would be “v=1; vs=all; vc=all; vr=consistent; onerror=fail-label;”
By adding such a configuration record possibility, the domain/account whitelist could be dropped, and those that have buggy/weird configs, needs to use a config record.