Idea/discussion: Permit CA to validate by NS if the CA manages the customers domain.

[Sebastian Robin Nielsen]

 

Currently, the CAB/F rules does not allow a CA to validate a domain ownership solely by NS records.

 

I propose a new validation method that allows this, that may ONLY be used if:

 

1: A DNS service or cloud service involving a customer delegating DNS control by NS records, where this service is owned by the same entity as the CA.

2: Where requiring any other validation method, would create a ”loop of trust” anyways, where the CA simply trusts itself as source of DCV validation.

If both of these prerequistes is fulfilled, the CA should be permitted to validate DCV by verifying that the NS records of said domain point to the NS servers of the CA in question.

Another requirement is that the CA must also validate that **ALL** NS records points to NS servers that is in control of the CA, so this validation method would not be permitted to use if the CA only operates a ”secondary DNS service”.

 

We could take an example by mentioning ”Amazon Trust Services” along with ”Amazon Route 53”.

Or lets say ”Google Trust Services” along with ”Google Cloud DNS”.

 

In this way, a very weird situation appears:

 

The CA itself is in control of the customer’s DNS. Requriring the CA to publish a DCV record in the customer’s DNS, and then ”ask itself” if the DCV record is there – becomes kind of weird in itself.

Thats why I suggest that the ”loop of trust into itself” is simply cut by using a wire snipper. instead of ”looping the trust around itself”, you cut this section by letting the NS delegation to the CA become the trust.

 

Lets take the two examples again:

In this case, ”Amazon Trust Services” would only need to verify that ALL customers NS records point to ”Amazon Route 53”. Thus ”Amazon Trust Services” have validated that ”Amazon Trust Services” are in control of the customer’s domain by total delegation, thus they can skip DCV checking and shortcut it using NS records.

In this case, ”Google Trust Services” would only need to verify that ALL customers NS records point to ”Google Cloud DNS”. Thus ”Google Trust Services” have validated that ”Google Trust Services” are in control of the customer’s domain by total delegation, thus they can skip DCV checking and shortcut it using NS records.

This would then apply to any CA operating a DNS service to customers to delegate their domains to.


What do you guys think about this?
It would certainly simplfy the provisioning of certificates for where the CA is in control of customer’s DNS by total delegation.

It WOULD give cloud providers that are CA’s a competitive advantage of not needing to do DCV validation (if they are in control of the customer’s domain by delegation) but on the other hand it gives incentive for large cloud providers to also become CA’s.

 

 

Best regards, Sebastian Robin Nielsen

 

[Andrew Ayer]

This idea has been tried before - CAs used to be allowed to skip CAA checking if they operated the domain's DNS. It did not go well - https://groups.google.com/g/mozilla.dev.security.policy/c/0TfT9BziQVc

Your proposal partly addresses the problem because it requires checking NS records. However, determining a domain's NS records is not straightforward. A domain's NS record set exists in two places - at the apex of the domain, and in the parent zone. Only the parent zone contains the true name servers - i.e. the name servers that would handle DCV queries. However, if you ask a DNS resolver what the NS records for a domain are, it might return the NS records from the domain apex instead, which might be different from the parent. If a CA relied on that, they could be misled into thinking they were the DNS operator when they really weren't.

For example, mismatched-ns.test.dnsaide.com's true name server is test-ns.dnsaide.com. But if you ask Unbound or use Google's dig tool <https://toolbox.googleapps.com/apps/dig/#NS/mismatched-ns.test.dnsaide.com.> what the NS record for mismatched-ns.test.dnsaide.com is, they will say its.always.dns instead.

The CA could implement a mini recursive lookup algorithm to find the right record set, but CAs are generally not DNS experts and I do not have faith CAs would implement this correctly. The risk doesn't seem worth it when instead the CA could just publish the necessary DNS record in the subscriber's domain and then do DCV normally using an off-the-shelf resolver.

Regards,
Andrew


On Sat, 09 May 2026 00:09:43 +0200
"'Sebastian Robin Nielsen' via Server Certificate WG (CA/B Forum)"

<server...@groups.cabforum.org> wrote:

>
>
> Currently, the CAB/F rules does not allow a CA to validate a domain
> ownership solely by NS records.
>
>
>
> I propose a new validation method that allows this, that may ONLY be
> used if:
>
>
>
> 1: A DNS service or cloud service involving a customer delegating DNS
> control by NS records, where this service is owned by the same entity
> as the CA.
>
> 2: Where requiring any other validation method, would create a "loop
> of trust" anyways, where the CA simply trusts itself as source of DCV
> validation.
>
>
> If both of these prerequistes is fulfilled, the CA should be
> permitted to validate DCV by verifying that the NS records of said
> domain point to the NS servers of the CA in question.
>
> Another requirement is that the CA must also validate that **ALL** NS
> records points to NS servers that is in control of the CA, so this
> validation method would not be permitted to use if the CA only
> operates a "secondary DNS service".
>
>
>
> We could take an example by mentioning "Amazon Trust Services" along
> with "Amazon Route 53".
>
> Or lets say "Google Trust Services" along with "Google Cloud DNS".
>
>
>
> In this way, a very weird situation appears:
>
>
>
> The CA itself is in control of the customer's DNS. Requriring the CA
> to publish a DCV record in the customer's DNS, and then "ask itself"

> if the DCV record is there - becomes kind of weird in itself.

> --
> You received this message because you are subscribed to the Google
> Groups "Server Certificate WG (CA/B Forum)" group. To unsubscribe
> from this group and stop receiving emails from it, send an email to
> servercert-w...@groups.cabforum.org. To view this
> discussion visit
> https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/006101dcdf37%245f9dba80%241ed92f80%24%40sebbe.eu.

[Henry Birge-Lee]

Hi all,

I also have some concerns about this. The parent zone/child zone versions of the NS records is a really good point. For this to be meaningful the check would have to be standardized to be the NS record at the parent zone and that would expose a good amount of DNS-specific language to the TLS BRs. NS is also just a potentially problematic record in general as it exists in two zones which few other records do.

I would also point out that often these types of cloud providers run distributed and multi-tenant systems so actually the value of the NS record is sometimes used to determine how responses are routed. I am aware of an attack where the adversary used NS records to hijack traffic from one Cloudflare account to another. The victim was given Cloudflare nameservers

a.ns.cloudflare.com and b.ns.cloudflare.com

the adversary made a new cloudflare account and was told to upload the nameservers

c.ns.cloudflare.com and d.ns.cloudflare.com

The adversary was able to compromise the victim's DNS registrar and changed the servers from a.ns.cloudflare.com and b.ns.cloudflare.com to c.ns.cloudflare.com and d.ns.cloudflare.com. When Cloudflare's backend engine saw this it updated the backend routing for the domain within Cloudflare from the victim's account to the adversary's because the ongoing nameserver check showed that the victim no longer had the proper config in place and the adversary account now showed the proper nameservers. This behavior may seem strange at first but imagine if a domain is sold and moved from one cloudflare account to another. I know cloudflare is not a CA, but if NS record checks for validation were in place and this example came from a CA with DNS hosting infrastructure, I worry a naive ballot could have permitted issuance to the adversary even without the NS hijack just because there were already same-org NS records in place. Obviously a good CDN/hosting provider should not let this happen, but putting this in as a general rule lets the responsibility of enforcing this security division between accounts on the hosting provider. I think these types of account dynamics could be complex to articulate in a ballot.

I am of the opinion it's always best to just run low-caching best-practices DNS in a stand alone module and check that the answer is correct even if the CA only expects to be checking itself. Also, I would argue that "Google Trust Services" may not be the same entity or infrastructure as "Google Cloud DNS." These could be separate LLCs running within the Google org that have firewalls between operations. If the DNS hosting provider and the CA are separate orgs, to me this practice gets even more questionable.

I also think dns-persist significantly reduces the friction this is made to solve. Google Cloud DNS and Amazon Route 53 could just put in a dns-persist record with the accounturi of the customer in customer zones by default essentially allowing a similar behavior but using well-established standards and records designed for account compartmentalization.

Best,

Henry

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/20260510204351.9c3b358425e95e1101b89871%40andrewayer.name.

[Sebastian Robin Nielsen]

Exactly, thats why my proposal is very clear that the customer should have delegated DNS control to the CA in question.

 

Note however, that the "apex" NS records should of course be ignored.

 

Technically, a CA would implement this validation method by having a recursive resolver configured to blacklist or ignore CA's own servers.

 

So it would not query the CA's own DNS servers for a potentially mismatched NS apex record, but instead always query the parent (that necessarly doesn't need to be a registry - after all, a customer might own "customer27.webhotel.com" which is delegated from him from webhotel.com).

 

Its also obvious that the CA should *NOT* do CAA validation for this type of DCV checking since its obvious that if the validated domain is delegated to the CA, the CA also "owns" the CAA records.

 

The risk of ingesting incorrect apes NS records exist also when the "the CA could just publish the necessary DNS record in the subscriber's domain and then do DCV normally using an off-the-shelf resolver" aswell, in some circumstances. This risk always exist if two different domains, under two different publix suffixes, share the same DNS infrastructure.

The risk can be mitigated by ignoring such DNS servers (in this case, ignoring own DNS servers) so a recursive resolver never potentially ingests and caches incorrect apex NS records.

 

 

The risk Henry raise about cross-account hijacks, would exist even today – if you can somehow fool a DNS operator that you own a domain delegated to them, then the whole security model of DNS fails.

Then no amount of DCV checking would correctly validate ownership of the domain.

So obvious its important that operators that allow you to delegate DNS to them, correctly implement boundaries between accounts, and for when a domain changes owner, require them to be unconfigured (or point to special ”parking servers”) to release the domain from the ”old account”, and then configure them again to ”gain ownership”.

 

 

So the rules would be something like this:

If a CA controls a specific subdomain by delegation, as defined as all NS-records for a specific FQDN point to a DNS server in control of the CA, the CA may skip DCV and CAA checking, after having verified, by using a recursive resolver, that all NS records, as traversed from the top root domain (.) to the FQDN being validated point to servers in control by the CA, and that, if any glue records exists, as defined as A or AAAA records that exist at the validated FQDN that point to a IP adress for the purpose of bootstrapping a DNS resolver, that these also point to IPs in control of the CA.

 

it is RECOMMENDED that any CA that implements this type of DCV and CAA skipping, that the CA blacklist their own authorative servers in their validation resolver, to prevent the CA from ingesting potentially incorrect, stale or mismatched apex NS records that may exist in the CA’s own infrastructure.

 

 

Of course, it would mean a CA that have lets say customerdomain.com delegated, could issue to ”server.somewhere.customerdomain.com” even if ”server.somewhere.customerdomain.com” doesn’t technically exist, but if ”customerdomain.com” is delegated to the CA, it should assumed that anything below customerdomain.com exist – which it technically could – the ”server.somewhere.customerdomain.com could exist for a millisecond.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAGxVKU6viua8nu4WTSSK9yp3_4YhsmE2UUK2QF1sPSo0AFgBhQ%40mail.gmail.com.