SC-86: Sunset the Inclusion of IP Reverse Address Domain Names

[CBonnell]

Resolves #153.

[dzacharo]

The language is clear but perhaps the example makes the reader believe we are trying to block only non-routable IP addresses. If this is not a big concern by others, you may ignore this comment :)

[CBonnell]

That's a good point. Maybe we can switch to an IP address from one of these blocks: https://datatracker.ietf.org/doc/html/rfc5737#section-3

[dzacharo]

Shall we also add an example for ip6.arpa?

[CBonnell]

Sure, what's a good example?

[dzacharo]

6.4.0.0.1.0.0.0.7.0.2.0.5.5.1.0.1.0.0.0.0.0.8.2.8.4.6.0.1.0.0.2.ip6.arpa. :-)

[CBonnell]

Added :)

[kidmin]

It would be better to use a prefix for documentation like as IPv4 (192.0.2.1). The prefix is 2001:db8::/32 (RFC 3849).
Example: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.e.e.f.8.b.d.0.1.0.0.2.ip6.arpa.

[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.