SC-86: Sunset the Inclusion of Domain Names with an IP Reverse Zone Suffix

[CBonnell]

Resolves #153.

[peterthomassen]

I've been following this discussion for a while. It appears to have originated in #153 (via zmap/zlint#343) where the problem of wildcard certificates under RIR-controlled rDNS names appeared.

In that thread, it seemed like prohibiting certificates with a wildcard SAN covering an rDNS name would be a good thing to do. It could be easily implemented by looking whether there is a wildcard at any of the labels that is supposed to represent an IPv4 address octet / an IPv6 address nibble.

For some reason, the proposal has shifted to prohibiting certificates under .arpa altogether. I seem to have missed how we went from wildcard to general prohibition!

While the thread linked above only talks explicitly about wildcards, the pre-ballot discussion only talks explicitly about the general prohibition.

It would be nice to learn what triggered that shift, especially considering the following points:

1. The pre-ballot discussion's "Purpose of Ballot" says that .arpa "is not intended to include hostnames".

   • This is in contradiction to RFC 3596 which states (in Section 2.5):

     The intent of this domain is to provide a way of mapping an IPv6 address to a host name, although it may be used for other purposes as well.

     Note that this both declares those names hostnames, and also endorses other purposes.

   • It is also in contradiction to the fact that there are official hostnames under .arpa, such as blackhole.as112.arpa (see RFC 7535) or {a,b,c,...}.ns.arpa (RFC 9120, as recent as 2021).

   • Even the nameservers of the rDNS subtrees are hostnames under .arpa, such as a.in-addr-servers.arpa and b.ip6-servers.arpa etc. (see RFC 5855).

   • It's possible that in the future, those hostnames may need certificates for DoH/DoT/DoQ.

It's not clear why the (valid) concern for wildcard certificates covering subnet rDNS would need to be addressed in a way that shuts that door unnecessarily.

(Of course, in theory, the rules could be changed again. In practice, people would think "DoX can't be done under .arpa because you can't have a certificate", and drop the idea.)

2. In Clarify validation requirements for .arpa #153 (comment), @enygren noted

   that RFC 8738 overloads .arpa as a way to validate IP address certificates, including sending an {in-addr,in6}.arpa name as the SNI value.

   • While that is correct, it would be sufficiently addressed by outlawing certificate issuance for valid IP address rDNS FQDNs.
   • It is certainly not necessary to rule out certificates under other names, such as 37.41.45.in-addr.arpa (which corresponds to a /24 network, not an IP address -- and actually exists). Why disallow IP block owners to run an info page there, for example?
   • Other harmless scenarios are possible, e.g., turning an IP address into a hostname like mail.0.237.26.194.in-addr.arpa (note the subdomain), which can then be used in an MX record (which requires a hostname) for TLS-secured SMTP without purchasing a domain. Again, why disallow?

These use cases do not collide with the IP address validation SNI ambiguity, and they also have nothing to do with the wildcard problem that this discussion originally started with.

---

All in all, it seems that a general prohibition of certificate issuance under .arpa would be overly broad, and in particular not motivated by any technical or security reasons. Arbitrary carve-outs add needless complexity (e.g., for the nameservers under .arpa), and should be avoided where possible.

The concerns of wildcard certificates and RFC 8738 SNI overloading are addressed by making only the following two changes:

1. CAs SHALL NOT issue Certificates containing names which correspond to the reverse DNS name of an IPv4 address (i.e., exactly 4 labels followed by in-addr.arpa) or of an IPv6 address (i.e., exactly 32 labels followed by ip6.arpa).
2. CAs SHALL NOT issue Certificates containing names which correspond to the wildcard reverse DNS name of an IPv4 address (i.e., the wildcard label, followed by at most 3 labels and by in-addr.arpa) or of an IPv6 address (i.e., the wildcard label followed by at most 31 labels and by ip6.arpa).

I'd like to encourage an exchange about whether the proposal could be narrowed down this way, and if it cannot, what the reaons would be.

(Note that (1) breaks sites like https://160.176.40.77.in-addr.arpa/ (which actually exists), and could alternatively be addressed by deprecating validation methods 3.2.2.5.3 and 3.2.2.5.7, or by amending RFC 6066 Section 3 to allow literal IP addresses in the SNI HostName. -- In any case, though, it is not necessary to rule out certificates for subnames of rDNS FQDNs, or for nameservers under .arpa.)

---

Disclosure: I've shared these concerns with the ICANN Security and Stability Advisory Committee of which I am a member, but am not speaking for the committee, nor has the committee developed a consensus position. I am also not speaking for the IETF DNSOP group (of which I am a Secretary).

[CBonnell]

Hi @peterthomassen, thank you for your insights and feedback.

For some reason, the proposal has shifted to prohibiting certificates under .arpa altogether. I seem to have missed how we went from wildcard to general prohibition!

In the course of discussion several years ago, we discussed this particular passage from RFC 3172:

This domain is termed an "infrastructure domain", as its role is to support the operating infrastructure of the Internet. In particular, the "arpa" domain is not to be used in the same manner (e.g., for naming hosts) as other generic Top Level Domains are commonly used.

and this passage:

More generally, this domain name undertakes a role as a limited use domain for Internet infrastructure applications, by providing a name root for the mapping of particular protocol values to names of service entities.

Given these statements, it was determined that issuance for any hostname under .arpa would run counter to this guidance, so it was agreed at the time to sunset this issuance.

This is in contradiction to RFC 3596 which states (in Section 2.5)

The referenced section says:

The intent of this domain is to provide a way of mapping an IPv6 address to a host name, although it may be used for other purposes as well.

This section is speaking to PTR records, not to naming hosts under ip6.arpa. As for "other purposes", naming hosts would conflict with the guidance in RFC 3172.

It is also in contradiction to the fact that there are official hostnames under .arpa, such as blackhole.as112.arpa (see RFC 7535) or {a,b,c,...}.ns.arpa (RFC 9120, as recent as 2021).

It is unfortunate that RFC 3172 was not updated to clarify that .arpa can be used for naming hosts rather than solely mapping protocol values to service names at the time these specifications established these hostnames.

I'd like to encourage an exchange about whether the proposal could be narrowed down this way, and if it cannot, what the reaons would be.

I discussed your concerns with the endorsers of the ballot and we will not move forward with this ballot as-is, as there is value in allowing issuance for DoH/DoT nameservers under .arpa and do not want to hamper those efforts. Our current thinking is that ballot will be scaled down to prohibiting wildcards under .arpa, but we can certainly discuss.

As I hinted at above, I think it would very helpful that RFC 3172 be updated to explicitly permit the naming of hosts such as the previously mentioned nameservers. Doing so would eliminate confusion on the intended purpose of .arpa.

[peterthomassen]

Hi @peterthomassen, thank you for your insights and feedback.

Thank you for getting back, @CBonnell! :-)

For some reason, the proposal has shifted to prohibiting certificates under .arpa altogether. I seem to have missed how we went from wildcard to general prohibition!

In the course of discussion several years ago, we discussed this particular passage from RFC 3172:

This domain is termed an "infrastructure domain", as its role is to support the operating infrastructure of the Internet. In particular, the "arpa" domain is not to be used in the same manner (e.g., for naming hosts) as other generic Top Level Domains are commonly used.

and this passage:

More generally, this domain name undertakes a role as a limited use domain for Internet infrastructure applications, by providing a name root for the mapping of particular protocol values to names of service entities.

Given these statements, it was determined that issuance for any hostname under .arpa would run counter to this guidance, so it was agreed at the time to sunset this issuance.

While this limitation is indeed stated in RFC 3172, that doesn't mean that "you" (CA/B Forum) has to enforce it :-)

That's particularly true if a certain "lapse" causes no issues, and may actually be useful to some. In fact, not even the IETF sees itself as the "protocol police", except on specific days (see the publication date of RFC 8962). :) (... true, RFC 3172 is from the IAB, not the IETF.)

The intent of this domain is to provide a way of mapping an IPv6 address to a host name, although it may be used for other purposes as well.

This section is speaking to PTR records, not to naming hosts under ip6.arpa. As for "other purposes", naming hosts would conflict with the guidance in RFC 3172.

Fair.

I discussed your concerns with the endorsers of the ballot and we will not move forward with this ballot as-is, as there is value in allowing issuance for DoH/DoT nameservers under .arpa and do not want to hamper those efforts. Our current thinking is that ballot will be scaled down to prohibiting wildcards under .arpa, but we can certainly discuss.

Great! Thank you for considering the feedback with the others.

As I hinted at above, I think it would very helpful that RFC 3172 be updated to explicitly permit the naming of hosts such as the previously mentioned nameservers. Doing so would eliminate confusion on the intended purpose of .arpa.

I agree with you, yes!

[dzacharo]

Updates based on SCWG Teleconference of 2025-08-28.

@CBonnell please review and share with external reviewers as needed.

[CBonnell]

Silly git, it's just a branch rename. I restored the previous branch name even though it's not quite an accurate representation of the ballot content.

[clintwilson]

This looks clean and straight-forward to me.

[tobij]

I am not sure we really have to explain which is which; it does not seem relevant to begin with in this definition and the BRs are not Wikipedia, but maybe I would have formed a different opinion if I looked at this from the perspective of SC-91 instead?

In any case, I do not think it is a problem to leave it in, but it stood out, so I thought I would mention it.

[caramelpony]

@CBonnell

Given these statements, it was determined that issuance for any hostname under .arpa would run counter to this guidance, so it was agreed at the time to sunset this issuance.

In letsencrypt/boulder/pull/2279 the same assertion is made in confidence: RFC 3172 is being violated when rDNS is used for traditional naming, based on the statement in RFC 3172 that .arpa is “not to be used in the same manner (e.g., for naming hosts) as other generic top‑level domains are commonly used.”

That requirement is already satisfied because records in in‑addr.arpa, ip6.arpa, and e164.arpa (along with the rest of .arpa) are not available for registration outside the registries that administer the resources tied to each. The delegation of those names is inherently tied to the lifespan of the registration of those resources, so they cannot be used for conventional host naming (i.e., the way someone might purchase a domain from a registrar).

The ability to operate webpages on those in‑addr.arpa records and use them for naming hosts is a by‑product of DNS. While some may object to the unconventional nature of these webpages, it is pointless and foolish to reinterpret an RFC drafted 24 years ago to stop a practice that, over the last two and a half decades, has caused no technical strain or operational concerns.

It is to be expected that owners of these records may use them as they wish, such as for backend panels, informational pages, or any other services requiring a hostname. As with any other pages on the Internet, these pages may require a certificate from a publicly trusted CA to securely interconnect, and therefore should fall under the serviceable clientele of the CA/B Forum’s member CAs.

In most BCPs, the language defined in RFC 2112 provides unambiguous intent through keywords such as MUST NOT or SHOULD NOT. RFC 3172 lacks those keywords, simply stating that the intent behind the existence of the .arpa TLD is not for naming hosts, which is already satisfied by how the TLD operates.

The very next paragraph in the same RFC states:

The operational administration of this domain, in accordance with the provisions described in this document, shall be performed by the IANA under the terms of the MoU between the IAB and ICANN concerning the IANA.

I see no mention of IANA considerations, IAB discussions, or public comment from IP resource holders in your Google‑group discussions or on GitHub. Has the CA/B Forum conducted an impact assessment for such a decision among the audiences it would affect? Without doing so, your claims are merely baseless and broad assertions.

While this limitation is indeed stated in RFC 3172, that doesn’t mean that you (CA/B Forum) have to enforce it :-)

Trust anchors must provide certificates without baseless discrimination against a subset of records that has zero consequence or strain on operations. Without supplemental and proper justification for this discrimination, most IP resource holders will likely view the action as overreach that erodes trust in your member CAs.

Ultimately, the RFC you cited dictates that enforcement responsibility lies with the operators of the .arpa TLD, the IANA and the IAB.

At minimum, the CA/B Forum should not proceed without consulting those two bodies, and in my opinion, it should not move forward with such a measure at all.