Voting period begins: Ballot SC-91: Sunset 3.2.2.5.3 Reverse Address Lookup Validation, proposal of new DNS-based validation using Persistent DCV TXT Record for IP addresses Inbox
Gurleen Grewal
Note: Please disregard the previous email as it had incorrect dates for the voting period. If you have already voted, please vote again by responding to this email.
Purpose of Ballot SC-91
This ballot sunsets 3.2.2.5.3 (“Reverse Address Lookup”) and introduces 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”) as its replacement.
Background
The “Reverse Address Lookup” method (3.2.2.5.3) has been recognized as insecure due to its reliance on PTR records and indirect validation of domains instead of IP addresses. However, DNS-based validation of IP addresses is useful for many specific client use cases (e.g., ssh frontends, DoH servers) where HTTP- or TLS-based validation is infeasible due to security concerns with opening associated ports or difficulty with serving challenges from anycasted addresses. For the replacement of “Reverse Address Lookup,” we offer another validation method, “DNS TXT Record with Persistent Value in the Reverse Namespace.” The new method is a more secure replacement of 3.2.2.5.3, allowing subscribers to validate IP addresses by DNS while mitigating the risk of “crossover” attacks.
The new method addresses two primary security concerns of the “Reverse Address Lookup” method: (1) staleness of PTR records (by requiring a TXT record placed at a validation-specific prefix in the .arpa zone) (2) lack of authentication and crossover risk (by requiring an account-bound credential to be placed in the TXT record).
Justification
For sunsetting the “Reverse Address Lookup” method for IP addresses (3.2.2.5.3):
The method proves a “weak binding” between the IP address listed in the Certificate and the domain name that ultimately completes DV for the certificate to be issued.
“Reverse Address Lookup” involves querying PTR records for an IP address’s associated reverse DNS name, and then validating the returned domain name using a DV method listed in 3.2.2.4. Successfully validating the PTR’s domain name proves control over that domain, but does not necessarily prove control of the IP address itself or its reverse zone.
Stale PTR records represent a critical security risk for this validation method.
PTR records are often stale, especially due to dynamic IP reassignment in cloud-based environments. “DNS scavenging” (removal of PTR records for decommissioned domain names) is not enabled by default on DNS server implementations. Additionally, there is no mechanism to sync updates in a FQDN’s A or AAAA records to PTR records in the corresponding reverse zone.
If an IP address’s PTR record(s) point to a domain that is no longer in use, an attacker can gain control of the free domain name, and complete validation for an IP address that they do not actually control or have administrative access to. Thus, the method may allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
The current reverse name validation method does not require any indication of request to issue in the reverse zone itself; there is no validation-related prefix appended to the reverse name associated with the IP address.
Reverse Address Lookup allows any DV method for domains in 3.2.2.4 to be applied for validation of the domain listed in the IP address’s PTR records. Thus, it inherits the attack surface of the superset of all domain DV methods; its effective security is tied to the weakest domain validation method still permitted.
The previous method allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
This included (previously) weaker WHOIS, email, and phone contact-based methods (scheduled to be sunset as proposed by SC-90). This represents a broader attack surface compared to 3.2.2.5.22, which consists purely of DNS. Compromise of any of the 3.2.2.4 methods could allow an attacker to gain a misissued certificate for an IP address.
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
Offers a secure replacement for a DNS-based validation method for IP addresses
The new method limits the validation challenge to direct DNS TXT queries in the .arpa zone associated with an IP address. This focuses proof of control on the authoritative namespace for that IP, rather than relying on a generic PTR record that may be stale or repurposed for uses unrelated to validation.
By contrast, “Reverse Address Lookup” allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
The newly created “DNS TXT Record with Persistent Value” method (SC-088v2, to be 3.2.2.4.22) for validation of domains offers several benefits to subscribers in terms of operational ease, flexibility, and ease of automated certificate issuance. These same benefits can be brought to validation of IP addresses by placement of an Persistent DCV TXT Record within the reverse zone associated with an IP address.
The method provides a more direct proof of certificate issuance through IP address-associated reverse zones.
The method minimizes the need to make live record updates in reverse zones to complete validation of an IP address, which may be especially challenging due to the fact that IP address holders may not have direct access to the .arpa zone associated with their IP address.
We confirm the feasibility of placement of non-PTR records in reverse zones, through consultation with several in-house DNS experts at Google and directly placing test records in an Unbound zonefile.
Benefits of adoption
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
Improves validation processes by extending an existing DV method, 3.2.2.4.22 “DNS TXT Record with Persistent Value,” to the validation of IP addresses.
This ensures that CAs and subscribers can adopt uniform process and tooling for both domain and IP address validation via the Persistent DCV TXT value method, reducing complexity and the risk of inconsistent implementation.
Promotes stronger validation integrity by ensuring that DV demonstrates a stronger binding to actual administrative control over an IP address, increasing the consistency of trustworthiness of issued certificates.
Reverse DNS zones (in-addr.arpa and ip6.arpa) are delegated by RIRs and LIRs in accordance with IP address block allocations. This makes the reverse namespace the authoritative DNS context for demonstrating control of IP addresses.
Direct DNS assertion through IP address-associated reverse zones is a stronger proof of control.
Publishing a TXT record at a validation specific-prefix directly demonstrates administrative control of the IP resource AS WELL AS request to issue.
Removes reliance on the correctness/freshness of PTR records and eliminates DV indirection through potentially unrelated domains.
Improves security posture and reduces risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
The new method replaces the current allowance in 3.2.2.5.3 to use any domain validation method in 3.2.2.4 with a single, narrowly defined DNS-based method. This strengthens security by eliminating the "weakest link" problem, as the security of 3.2.2.5.3 was inherently bound to the security of the weakest validation method in 3.2.2.4.
Removes the possibility of “crossover” attacks introduced by tying validation of an IP address to validation of an unrelated domain in a stale PTR record.
Limits the validation challenge to direct DNS TXT queries in the .arpa zone, minimizing the attack surface to only DNS.
Facilitates innovation by allowing automation without live DNS updates, supporting shortened certificate lifetimes and more agile re-issuance for IP address certificate subscribers. This is especially helpful because of the administrative burden often inherent in updating .arpa zones.
Creates opportunities for faster, more efficient certificate lifestyle management and simplification of maintenance of reverse zones.
Brings the improvements of 3.2.2.4.22 to validation of IP addresses.
Promote stronger validation integrity by ensuring that DCV proves a stronger, more direct binding to actual administrative control over the reverse namespace associated with an IP address.
Proposed Key Dates
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
Effective immediately:
Implementation of 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”)
Effective March 15, 2027:
Sunset of Method 3.2.2.5.3 (“Reverse Address Lookup”)
Motion
The following motion has been proposed by Gurleen Grewal of Google (Google Trust Services) and endorsed by Michael Slaughter (Amazon Trust Services) and Dimitris Zacharopoulos (HARICA).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.7.1.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 7 days)
Start: 2025-10-23 16:00:00 UTC
End time: 2025-11-04 16:00:00 UTC
Vote for approval (7 days)
Start: 2025-11-05 17:40:00 UTC
End: 2025-11-12 17:40:00 UTC
Ryan Dickson
--
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/CAHidiLEC7aTqSoHX6w1nEWy5xvH6tuVggY6_HHHcL9iFLYxOeg%40mail.gmail.com.
Backman, Antti
Lähetetty: keskiviikkona, marraskuuta 5, 2025 7:40 ip.
Vastaanottaja: server...@groups.cabforum.org <server...@groups.cabforum.org>
Aihe: [Servercert-wg] Voting period begins: Ballot SC-91: Sunset 3.2.2.5.3 Reverse Address Lookup Validation, proposal of new DNS-based validation using Persistent DCV TXT Record for IP addresses Inbox
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/CAHidiLEC7aTqSoHX6w1nEWy5xvH6tuVggY6_HHHcL9iFLYxOeg%40mail.gmail.com.
This email may contain information which is privileged or protected against unauthorized disclosure or communication. If you are not the intended recipient, please notify the sender and delete this message and any attachments from your system without producing, distributing or retaining copies thereof or disclosing its contents to any other person.
Telia Company processes emails and other files that may contain personal data in accordance with Telia Company’s Privacy Policy.
Ben Wilson
--
大野 文彰
SECOM Trust Systems votes YES on Ballot SC-91.
Best regards,
ONO Fumiaki / 大野 文彰
(Japanese name order: family name first, in uppercase)
SECOM Trust Systems CO., LTD.
From: 'Gurleen Grewal' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Thursday, November 6, 2025 2:40 AM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting period begins: Ballot SC-91: Sunset 3.2.2.5.3 Reverse Address Lookup Validation, proposal of new DNS-based validation using Persistent DCV TXT Record for IP addresses Inbox
Note: Please disregard the previous email as it had incorrect dates for the voting period. If you have already voted, please vote again by responding to this email.
Purpose of Ballot SC-91
This ballot sunsets 3.2.2.5.3 (“Reverse Address Lookup”) and introduces 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”) as its replacement.
Background
The “Reverse Address Lookup” method (3.2.2.5.3) has been recognized as insecure due to its reliance on PTR records and indirect validation of domains instead of IP addresses. However, DNS-based validation of IP addresses is useful for many specific client use cases (e.g., ssh frontends, DoH servers) where HTTP- or TLS-based validation is infeasible due to security concerns with opening associated ports or difficulty with serving challenges from anycasted addresses. For the replacement of “Reverse Address Lookup,” we offer another validation method, “DNS TXT Record with Persistent Value in the Reverse Namespace.” The new method is a more secure replacement of 3.2.2.5.3, allowing subscribers to validate IP addresses by DNS while mitigating the risk of “crossover” attacks.
The new method addresses two primary security concerns of the “Reverse Address Lookup” method: (1) staleness of PTR records (by requiring a TXT record placed at a validation-specific prefix in the .arpa zone) (2) lack of authentication and crossover risk (by requiring an account-bound credential to be placed in the TXT record).
Justification
For sunsetting the “Reverse Address Lookup” method for IP addresses (3.2.2.5.3):
· The method proves a “weak binding” between the IP address listed in the Certificate and the domain name that ultimately completes DV for the certificate to be issued.
o “Reverse Address Lookup” involves querying PTR records for an IP address’s associated reverse DNS name, and then validating the returned domain name using a DV method listed in 3.2.2.4. Successfully validating the PTR’s domain name proves control over that domain, but does not necessarily prove control of the IP address itself or its reverse zone.
· Stale PTR records represent a critical security risk for this validation method.
o PTR records are often stale, especially due to dynamic IP reassignment in cloud-based environments. “DNS scavenging” (removal of PTR records for decommissioned domain names) is not enabled by default on DNS server implementations. Additionally, there is no mechanism to sync updates in a FQDN’s A or AAAA records to PTR records in the corresponding reverse zone.
o If an IP address’s PTR record(s) point to a domain that is no longer in use, an attacker can gain control of the free domain name, and complete validation for an IP address that they do not actually control or have administrative access to. Thus, the method may allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
o The current reverse name validation method does not require any indication of request to issue in the reverse zone itself; there is no validation-related prefix appended to the reverse name associated with the IP address.
· Reverse Address Lookup allows any DV method for domains in 3.2.2.4 to be applied for validation of the domain listed in the IP address’s PTR records. Thus, it inherits the attack surface of the superset of all domain DV methods; its effective security is tied to the weakest domain validation method still permitted.
o The previous method allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
o This included (previously) weaker WHOIS, email, and phone contact-based methods (scheduled to be sunset as proposed by SC-90). This represents a broader attack surface compared to 3.2.2.5.22, which consists purely of DNS. Compromise of any of the 3.2.2.4 methods could allow an attacker to gain a misissued certificate for an IP address.
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Offers a secure replacement for a DNS-based validation method for IP addresses
o The new method limits the validation challenge to direct DNS TXT queries in the .arpa zone associated with an IP address. This focuses proof of control on the authoritative namespace for that IP, rather than relying on a generic PTR record that may be stale or repurposed for uses unrelated to validation.
o By contrast, “Reverse Address Lookup” allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
· The newly created “DNS TXT Record with Persistent Value” method (SC-088v2, to be 3.2.2.4.22) for validation of domains offers several benefits to subscribers in terms of operational ease, flexibility, and ease of automated certificate issuance. These same benefits can be brought to validation of IP addresses by placement of an Persistent DCV TXT Record within the reverse zone associated with an IP address.
o The method provides a more direct proof of certificate issuance through IP address-associated reverse zones.
o The method minimizes the need to make live record updates in reverse zones to complete validation of an IP address, which may be especially challenging due to the fact that IP address holders may not have direct access to the .arpa zone associated with their IP address.
o We confirm the feasibility of placement of non-PTR records in reverse zones, through consultation with several in-house DNS experts at Google and directly placing test records in an Unbound zonefile.
Benefits of adoption
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Improves validation processes by extending an existing DV method, 3.2.2.4.22 “DNS TXT Record with Persistent Value,” to the validation of IP addresses.
o This ensures that CAs and subscribers can adopt uniform process and tooling for both domain and IP address validation via the Persistent DCV TXT value method, reducing complexity and the risk of inconsistent implementation.
· Promotes stronger validation integrity by ensuring that DV demonstrates a stronger binding to actual administrative control over an IP address, increasing the consistency of trustworthiness of issued certificates.
o Reverse DNS zones (in-addr.arpa and ip6.arpa) are delegated by RIRs and LIRs in accordance with IP address block allocations. This makes the reverse namespace the authoritative DNS context for demonstrating control of IP addresses.
o Direct DNS assertion through IP address-associated reverse zones is a stronger proof of control.
o Publishing a TXT record at a validation specific-prefix directly demonstrates administrative control of the IP resource AS WELL AS request to issue.
o Removes reliance on the correctness/freshness of PTR records and eliminates DV indirection through potentially unrelated domains.
· Improves security posture and reduces risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
o The new method replaces the current allowance in 3.2.2.5.3 to use any domain validation method in 3.2.2.4 with a single, narrowly defined DNS-based method. This strengthens security by eliminating the "weakest link" problem, as the security of 3.2.2.5.3 was inherently bound to the security of the weakest validation method in 3.2.2.4.
o Removes the possibility of “crossover” attacks introduced by tying validation of an IP address to validation of an unrelated domain in a stale PTR record.
o Limits the validation challenge to direct DNS TXT queries in the .arpa zone, minimizing the attack surface to only DNS.
· Facilitates innovation by allowing automation without live DNS updates, supporting shortened certificate lifetimes and more agile re-issuance for IP address certificate subscribers. This is especially helpful because of the administrative burden often inherent in updating .arpa zones.
o Creates opportunities for faster, more efficient certificate lifestyle management and simplification of maintenance of reverse zones.
o Brings the improvements of 3.2.2.4.22 to validation of IP addresses.
· Promote stronger validation integrity by ensuring that DCV proves a stronger, more direct binding to actual administrative control over the reverse namespace associated with an IP address.
Proposed Key Dates
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective immediately:
o Implementation of 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”)
· Effective March 15, 2027:
o Sunset of Method 3.2.2.5.3 (“Reverse Address Lookup”)
Motion
The following motion has been proposed by Gurleen Grewal of Google (Google Trust Services) and endorsed by Michael Slaughter (Amazon Trust Services) and Dimitris Zacharopoulos (HARICA).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.7.1.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 7 days)
· Start: 2025-10-23 16:00:00 UTC
· End time: 2025-11-04 16:00:00 UTC
Vote for approval (7 days)
· Start: 2025-11-05 17:40:00 UTC
· End: 2025-11-12 17:40:00 UTC
--
Hogeun Yoo
-----Original Message-----
From: "'Gurleen Grewal' via Server Certificate WG (CA/B Forum)"<server...@groups.cabforum.org>
To: <server...@groups.cabforum.org>;
Cc:
Sent: 2025. 11. 6. (목) 02:40 (GMT+09:00)
Subject: [Servercert-wg] Voting period begins: Ballot SC-91: Sunset 3.2.2.5.3 Reverse Address Lookup Validation, proposal of new DNS-based validation using Persistent DCV TXT Record for IP addresses Inbox
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/CAHidiLEC7aTqSoHX6w1nEWy5xvH6tuVggY6_HHHcL9iFLYxOeg%40mail.gmail.com.
Josselin ALLEMANDOU
CERTIGNA votes YES on ballot SC-91.
20 Allée de la Râperie, 59650 Villeneuve-d'Ascq
Maximizing Digital Trust |
www.certigna.com
| www.dhimyotis.com
LinkedIn
| Twitter
| YouTube
On Wed, Nov 5, 2025 at 10:40 AM 'Gurleen Grewal' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:
Note: Please disregard the previous email as it had incorrect dates for the voting period. If you have already voted, please vote again by responding to this email.
Purpose of Ballot SC-91
This ballot sunsets 3.2.2.5.3 (“Reverse Address Lookup”) and introduces 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”) as its replacement.
Background
The “Reverse Address Lookup” method (3.2.2.5.3) has been recognized as insecure due to its reliance on PTR records and indirect validation of domains instead of IP addresses. However, DNS-based validation of IP addresses is useful for many specific client use cases (e.g., ssh frontends, DoH servers) where HTTP- or TLS-based validation is infeasible due to security concerns with opening associated ports or difficulty with serving challenges from anycasted addresses. For the replacement of “Reverse Address Lookup,” we offer another validation method, “DNS TXT Record with Persistent Value in the Reverse Namespace.” The new method is a more secure replacement of 3.2.2.5.3, allowing subscribers to validate IP addresses by DNS while mitigating the risk of “crossover” attacks.
The new method addresses two primary security concerns of the “Reverse Address Lookup” method: (1) staleness of PTR records (by requiring a TXT record placed at a validation-specific prefix in the .arpa zone) (2) lack of authentication and crossover risk (by requiring an account-bound credential to be placed in the TXT record).
Justification
For sunsetting the “Reverse Address Lookup” method for IP addresses (3.2.2.5.3):
· The method proves a “weak binding” between the IP address listed in the Certificate and the domain name that ultimately completes DV for the certificate to be issued.
o “Reverse Address Lookup” involves querying PTR records for an IP address’s associated reverse DNS name, and then validating the returned domain name using a DV method listed in 3.2.2.4. Successfully validating the PTR’s domain name proves control over that domain, but does not necessarily prove control of the IP address itself or its reverse zone.
· Stale PTR records represent a critical security risk for this validation method.
o PTR records are often stale, especially due to dynamic IP reassignment in cloud-based environments. “DNS scavenging” (removal of PTR records for decommissioned domain names) is not enabled by default on DNS server implementations. Additionally, there is no mechanism to sync updates in a FQDN’s A or AAAA records to PTR records in the corresponding reverse zone.
o If an IP address’s PTR record(s) point to a domain that is no longer in use, an attacker can gain control of the free domain name, and complete validation for an IP address that they do not actually control or have administrative access to. Thus, the method may allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
o The current reverse name validation method does not require any indication of request to issue in the reverse zone itself; there is no validation-related prefix appended to the reverse name associated with the IP address.
· Reverse Address Lookup allows any DV method for domains in 3.2.2.4 to be applied for validation of the domain listed in the IP address’s PTR records. Thus, it inherits the attack surface of the superset of all domain DV methods; its effective security is tied to the weakest domain validation method still permitted.
o The previous method allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
o This included (previously) weaker WHOIS, email, and phone contact-based methods (scheduled to be sunset as proposed by SC-90). This represents a broader attack surface compared to 3.2.2.5.22, which consists purely of DNS. Compromise of any of the 3.2.2.4 methods could allow an attacker to gain a misissued certificate for an IP address.
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Offers a secure replacement for a DNS-based validation method for IP addresses
o The new method limits the validation challenge to direct DNS TXT queries in the .arpa zone associated with an IP address. This focuses proof of control on the authoritative namespace for that IP, rather than relying on a generic PTR record that may be stale or repurposed for uses unrelated to validation.
o By contrast, “Reverse Address Lookup” allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
· The newly created “DNS TXT Record with Persistent Value” method (SC-088v2, to be 3.2.2.4.22) for validation of domains offers several benefits to subscribers in terms of operational ease, flexibility, and ease of automated certificate issuance. These same benefits can be brought to validation of IP addresses by placement of an Persistent DCV TXT Record within the reverse zone associated with an IP address.
o The method provides a more direct proof of certificate issuance through IP address-associated reverse zones.
o The method minimizes the need to make live record updates in reverse zones to complete validation of an IP address, which may be especially challenging due to the fact that IP address holders may not have direct access to the .arpa zone associated with their IP address.
o We confirm the feasibility of placement of non-PTR records in reverse zones, through consultation with several in-house DNS experts at Google and directly placing test records in an Unbound zonefile.
Benefits of adoption
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Improves validation processes by extending an existing DV method, 3.2.2.4.22 “DNS TXT Record with Persistent Value,” to the validation of IP addresses.
o This ensures that CAs and subscribers can adopt uniform process and tooling for both domain and IP address validation via the Persistent DCV TXT value method, reducing complexity and the risk of inconsistent implementation.
· Promotes stronger validation integrity by ensuring that DV demonstrates a stronger binding to actual administrative control over an IP address, increasing the consistency of trustworthiness of issued certificates.
o Reverse DNS zones (in-addr.arpa and ip6.arpa) are delegated by RIRs and LIRs in accordance with IP address block allocations. This makes the reverse namespace the authoritative DNS context for demonstrating control of IP addresses.
o Direct DNS assertion through IP address-associated reverse zones is a stronger proof of control.
o Publishing a TXT record at a validation specific-prefix directly demonstrates administrative control of the IP resource AS WELL AS request to issue.
o Removes reliance on the correctness/freshness of PTR records and eliminates DV indirection through potentially unrelated domains.
· Improves security posture and reduces risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
o The new method replaces the current allowance in 3.2.2.5.3 to use any domain validation method in 3.2.2.4 with a single, narrowly defined DNS-based method. This strengthens security by eliminating the "weakest link" problem, as the security of 3.2.2.5.3 was inherently bound to the security of the weakest validation method in 3.2.2.4.
o Removes the possibility of “crossover” attacks introduced by tying validation of an IP address to validation of an unrelated domain in a stale PTR record.
o Limits the validation challenge to direct DNS TXT queries in the .arpa zone, minimizing the attack surface to only DNS.
· Facilitates innovation by allowing automation without live DNS updates, supporting shortened certificate lifetimes and more agile re-issuance for IP address certificate subscribers. This is especially helpful because of the administrative burden often inherent in updating .arpa zones.
o Creates opportunities for faster, more efficient certificate lifestyle management and simplification of maintenance of reverse zones.
o Brings the improvements of 3.2.2.4.22 to validation of IP addresses.
· Promote stronger validation integrity by ensuring that DCV proves a stronger, more direct binding to actual administrative control over the reverse namespace associated with an IP address.
Proposed Key Dates
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective immediately:
o Implementation of 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”)
· Effective March 15, 2027:
o Sunset of Method 3.2.2.5.3 (“Reverse Address Lookup”)
Motion
The following motion has been proposed by Gurleen Grewal of Google (Google Trust Services) and endorsed by Michael Slaughter (Amazon Trust Services) and Dimitris Zacharopoulos (HARICA).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.7.1.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 7 days)
· Start: 2025-10-23 16:00:00 UTC
· End time: 2025-11-04 16:00:00 UTC
Vote for approval (7 days)
· Start: 2025-11-05 17:40:00 UTC
· End: 2025-11-12 17:40:00 UTC
Doug Beattie
GlobalSign votes Yes on Ballot SC-91
Doug
From: 'Gurleen Grewal' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, November 5, 2025 12:40 PM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting period begins: Ballot SC-91: Sunset 3.2.2.5.3 Reverse Address Lookup Validation, proposal of new DNS-based validation using Persistent DCV TXT Record for IP addresses Inbox
Note: Please disregard the previous email as it had incorrect dates for the voting period. If you have already voted, please vote again by responding to this email.
Purpose of Ballot SC-91
This ballot sunsets 3.2.2.5.3 (“Reverse Address Lookup”) and introduces 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”) as its replacement.
Background
The “Reverse Address Lookup” method (3.2.2.5.3) has been recognized as insecure due to its reliance on PTR records and indirect validation of domains instead of IP addresses. However, DNS-based validation of IP addresses is useful for many specific client use cases (e.g., ssh frontends, DoH servers) where HTTP- or TLS-based validation is infeasible due to security concerns with opening associated ports or difficulty with serving challenges from anycasted addresses. For the replacement of “Reverse Address Lookup,” we offer another validation method, “DNS TXT Record with Persistent Value in the Reverse Namespace.” The new method is a more secure replacement of 3.2.2.5.3, allowing subscribers to validate IP addresses by DNS while mitigating the risk of “crossover” attacks.
The new method addresses two primary security concerns of the “Reverse Address Lookup” method: (1) staleness of PTR records (by requiring a TXT record placed at a validation-specific prefix in the .arpa zone) (2) lack of authentication and crossover risk (by requiring an account-bound credential to be placed in the TXT record).
Justification
For sunsetting the “Reverse Address Lookup” method for IP addresses (3.2.2.5.3):
· The method proves a “weak binding” between the IP address listed in the Certificate and the domain name that ultimately completes DV for the certificate to be issued.
o “Reverse Address Lookup” involves querying PTR records for an IP address’s associated reverse DNS name, and then validating the returned domain name using a DV method listed in 3.2.2.4. Successfully validating the PTR’s domain name proves control over that domain, but does not necessarily prove control of the IP address itself or its reverse zone.
· Stale PTR records represent a critical security risk for this validation method.
o PTR records are often stale, especially due to dynamic IP reassignment in cloud-based environments. “DNS scavenging” (removal of PTR records for decommissioned domain names) is not enabled by default on DNS server implementations. Additionally, there is no mechanism to sync updates in a FQDN’s A or AAAA records to PTR records in the corresponding reverse zone.
o If an IP address’s PTR record(s) point to a domain that is no longer in use, an attacker can gain control of the free domain name, and complete validation for an IP address that they do not actually control or have administrative access to. Thus, the method may allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
o The current reverse name validation method does not require any indication of request to issue in the reverse zone itself; there is no validation-related prefix appended to the reverse name associated with the IP address.
· Reverse Address Lookup allows any DV method for domains in 3.2.2.4 to be applied for validation of the domain listed in the IP address’s PTR records. Thus, it inherits the attack surface of the superset of all domain DV methods; its effective security is tied to the weakest domain validation method still permitted.
o The previous method allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
o This included (previously) weaker WHOIS, email, and phone contact-based methods (scheduled to be sunset as proposed by SC-90). This represents a broader attack surface compared to 3.2.2.5.22, which consists purely of DNS. Compromise of any of the 3.2.2.4 methods could allow an attacker to gain a misissued certificate for an IP address.
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Offers a secure replacement for a DNS-based validation method for IP addresses
o The new method limits the validation challenge to direct DNS TXT queries in the .arpa zone associated with an IP address. This focuses proof of control on the authoritative namespace for that IP, rather than relying on a generic PTR record that may be stale or repurposed for uses unrelated to validation.
o By contrast, “Reverse Address Lookup” allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
· The newly created “DNS TXT Record with Persistent Value” method (SC-088v2, to be 3.2.2.4.22) for validation of domains offers several benefits to subscribers in terms of operational ease, flexibility, and ease of automated certificate issuance. These same benefits can be brought to validation of IP addresses by placement of an Persistent DCV TXT Record within the reverse zone associated with an IP address.
o The method provides a more direct proof of certificate issuance through IP address-associated reverse zones.
o The method minimizes the need to make live record updates in reverse zones to complete validation of an IP address, which may be especially challenging due to the fact that IP address holders may not have direct access to the .arpa zone associated with their IP address.
o We confirm the feasibility of placement of non-PTR records in reverse zones, through consultation with several in-house DNS experts at Google and directly placing test records in an Unbound zonefile.
Benefits of adoption
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Improves validation processes by extending an existing DV method, 3.2.2.4.22 “DNS TXT Record with Persistent Value,” to the validation of IP addresses.
o This ensures that CAs and subscribers can adopt uniform process and tooling for both domain and IP address validation via the Persistent DCV TXT value method, reducing complexity and the risk of inconsistent implementation.
· Promotes stronger validation integrity by ensuring that DV demonstrates a stronger binding to actual administrative control over an IP address, increasing the consistency of trustworthiness of issued certificates.
o Reverse DNS zones (in-addr.arpa and ip6.arpa) are delegated by RIRs and LIRs in accordance with IP address block allocations. This makes the reverse namespace the authoritative DNS context for demonstrating control of IP addresses.
o Direct DNS assertion through IP address-associated reverse zones is a stronger proof of control.
o Publishing a TXT record at a validation specific-prefix directly demonstrates administrative control of the IP resource AS WELL AS request to issue.
o Removes reliance on the correctness/freshness of PTR records and eliminates DV indirection through potentially unrelated domains.
· Improves security posture and reduces risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
o The new method replaces the current allowance in 3.2.2.5.3 to use any domain validation method in 3.2.2.4 with a single, narrowly defined DNS-based method. This strengthens security by eliminating the "weakest link" problem, as the security of 3.2.2.5.3 was inherently bound to the security of the weakest validation method in 3.2.2.4.
o Removes the possibility of “crossover” attacks introduced by tying validation of an IP address to validation of an unrelated domain in a stale PTR record.
o Limits the validation challenge to direct DNS TXT queries in the .arpa zone, minimizing the attack surface to only DNS.
· Facilitates innovation by allowing automation without live DNS updates, supporting shortened certificate lifetimes and more agile re-issuance for IP address certificate subscribers. This is especially helpful because of the administrative burden often inherent in updating .arpa zones.
o Creates opportunities for faster, more efficient certificate lifestyle management and simplification of maintenance of reverse zones.
o Brings the improvements of 3.2.2.4.22 to validation of IP addresses.
· Promote stronger validation integrity by ensuring that DCV proves a stronger, more direct binding to actual administrative control over the reverse namespace associated with an IP address.
Proposed Key Dates
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective immediately:
o Implementation of 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”)
· Effective March 15, 2027:
o Sunset of Method 3.2.2.5.3 (“Reverse Address Lookup”)
Motion
The following motion has been proposed by Gurleen Grewal of Google (Google Trust Services) and endorsed by Michael Slaughter (Amazon Trust Services) and Dimitris Zacharopoulos (HARICA).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.7.1.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 7 days)
· Start: 2025-10-23 16:00:00 UTC
· End time: 2025-11-04 16:00:00 UTC
Vote for approval (7 days)
· Start: 2025-11-05 17:40:00 UTC
· End: 2025-11-12 17:40:00 UTC
--
Dimitris Zacharopoulos (HARICA)
--
Scott Rea
eMudhra votes YES on Ballot SC-91
From:
'Gurleen Grewal' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Wednesday, 5 November 2025 at 10:40 AM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting period begins: Ballot SC-91: Sunset 3.2.2.5.3 Reverse Address Lookup Validation, proposal of new DNS-based validation using Persistent DCV TXT Record for IP addresses Inbox
|
CAUTION: This email is originated from outside of the organization. Do not open the links or the attachments unless you recognize the sender and know the content is safe. |
Note: Please disregard the previous email as it had incorrect dates for the voting period. If you have already voted, please vote again by responding to this email.
Purpose of Ballot SC-91
This ballot sunsets 3.2.2.5.3 (“Reverse Address Lookup”) and introduces 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”) as its replacement.
Background
The “Reverse Address Lookup” method (3.2.2.5.3) has been recognized as insecure due to its reliance on PTR records and indirect validation of domains instead of IP addresses. However, DNS-based validation of IP addresses is useful for many specific client use cases (e.g., ssh frontends, DoH servers) where HTTP- or TLS-based validation is infeasible due to security concerns with opening associated ports or difficulty with serving challenges from anycasted addresses. For the replacement of “Reverse Address Lookup,” we offer another validation method, “DNS TXT Record with Persistent Value in the Reverse Namespace.” The new method is a more secure replacement of 3.2.2.5.3, allowing subscribers to validate IP addresses by DNS while mitigating the risk of “crossover” attacks.
The new method addresses two primary security concerns of the “Reverse Address Lookup” method: (1) staleness of PTR records (by requiring a TXT record placed at a validation-specific prefix in the .arpa zone) (2) lack of authentication and crossover risk (by requiring an account-bound credential to be placed in the TXT record).
Justification
For sunsetting the “Reverse Address Lookup” method for IP addresses (3.2.2.5.3):
· The method proves a “weak binding” between the IP address listed in the Certificate and the domain name that ultimately completes DV for the certificate to be issued.
o “Reverse Address Lookup” involves querying PTR records for an IP address’s associated reverse DNS name, and then validating the returned domain name using a DV method listed in 3.2.2.4. Successfully validating the PTR’s domain name proves control over that domain, but does not necessarily prove control of the IP address itself or its reverse zone.
· Stale PTR records represent a critical security risk for this validation method.
o PTR records are often stale, especially due to dynamic IP reassignment in cloud-based environments. “DNS scavenging” (removal of PTR records for decommissioned domain names) is not enabled by default on DNS server implementations. Additionally, there is no mechanism to sync updates in a FQDN’s A or AAAA records to PTR records in the corresponding reverse zone.
o If an IP address’s PTR record(s) point to a domain that is no longer in use, an attacker can gain control of the free domain name, and complete validation for an IP address that they do not actually control or have administrative access to. Thus, the method may allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
o
The current reverse name validation method does not require any indication of request to issue in the reverse zone itself; there is no validation-related
prefix appended to the reverse name associated with the IP address.
· Reverse Address Lookup allows any DV method for domains in 3.2.2.4 to be applied for validation of the domain listed in the IP address’s PTR records. Thus, it inherits the attack surface of the superset of all domain DV methods; its effective security is tied to the weakest domain validation method still permitted.
o The previous method allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
o This included (previously) weaker WHOIS, email, and phone contact-based methods (scheduled to be sunset as proposed by SC-90). This represents a broader attack surface compared to 3.2.2.5.22, which consists purely of DNS. Compromise of any of the 3.2.2.4 methods could allow an attacker to gain a misissued certificate for an IP address.
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Offers a secure replacement for a DNS-based validation method for IP addresses
o The new method limits the validation challenge to direct DNS TXT queries in the .arpa zone associated with an IP address. This focuses proof of control on the authoritative namespace for that IP, rather than relying on a generic PTR record that may be stale or repurposed for uses unrelated to validation.
o
By contrast, “Reverse Address Lookup” allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying
IP address validation to validation of an unrelated domain.
· The newly created “DNS TXT Record with Persistent Value” method (SC-088v2, to be 3.2.2.4.22) for validation of domains offers several benefits to subscribers in terms of operational ease, flexibility, and ease of automated certificate issuance. These same benefits can be brought to validation of IP addresses by placement of an Persistent DCV TXT Record within the reverse zone associated with an IP address.
o The method provides a more direct proof of certificate issuance through IP address-associated reverse zones.
o The method minimizes the need to make live record updates in reverse zones to complete validation of an IP address, which may be especially challenging due to the fact that IP address holders may not have direct access to the .arpa zone associated with their IP address.
o We confirm the feasibility of placement of non-PTR records in reverse zones, through consultation with several in-house DNS experts at Google and directly placing test records in an Unbound zonefile.
Benefits of adoption
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Improves validation processes by extending an existing DV method, 3.2.2.4.22 “DNS TXT Record with Persistent Value,” to the validation of IP addresses.
o
This ensures that CAs and subscribers can adopt uniform process and tooling for both domain and IP address validation via the Persistent DCV TXT value method,
reducing complexity and the risk of inconsistent implementation.
· Promotes stronger validation integrity by ensuring that DV demonstrates a stronger binding to actual administrative control over an IP address, increasing the consistency of trustworthiness of issued certificates.
o Reverse DNS zones (in-addr.arpa and ip6.arpa) are delegated by RIRs and LIRs in accordance with IP address block allocations. This makes the reverse namespace the authoritative DNS context for demonstrating control of IP addresses.
o Direct DNS assertion through IP address-associated reverse zones is a stronger proof of control.
o Publishing a TXT record at a validation specific-prefix directly demonstrates administrative control of the IP resource AS WELL AS request to issue.
o
Removes reliance on the correctness/freshness of PTR records and eliminates DV indirection through potentially unrelated domains.
· Improves security posture and reduces risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
o The new method replaces the current allowance in 3.2.2.5.3 to use any domain validation method in 3.2.2.4 with a single, narrowly defined DNS-based method. This strengthens security by eliminating the "weakest link" problem, as the security of 3.2.2.5.3 was inherently bound to the security of the weakest validation method in 3.2.2.4.
o Removes the possibility of “crossover” attacks introduced by tying validation of an IP address to validation of an unrelated domain in a stale PTR record.
o
Limits the validation challenge to direct DNS TXT queries in the .arpa zone, minimizing the attack surface to only DNS.
· Facilitates innovation by allowing automation without live DNS updates, supporting shortened certificate lifetimes and more agile re-issuance for IP address certificate subscribers. This is especially helpful because of the administrative burden often inherent in updating .arpa zones.
o Creates opportunities for faster, more efficient certificate lifestyle management and simplification of maintenance of reverse zones.
o
Brings the improvements of 3.2.2.4.22 to validation of IP addresses.
· Promote stronger validation integrity by ensuring that DCV proves a stronger, more direct binding to actual administrative control over the reverse namespace associated with an IP address.
Proposed Key Dates
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective immediately:
o
Implementation of 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”)
· Effective March 15, 2027:
o Sunset of Method 3.2.2.5.3 (“Reverse Address Lookup”)
Motion
The following motion has been proposed by Gurleen Grewal of Google (Google Trust Services) and endorsed by Michael Slaughter (Amazon Trust Services) and Dimitris Zacharopoulos (HARICA).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.7.1.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 7 days)
· Start: 2025-10-23 16:00:00 UTC
· End time: 2025-11-04 16:00:00 UTC
Vote for approval (7 days)
· Start: 2025-11-05 17:40:00 UTC
· End: 2025-11-12 17:40:00 UTC
--
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/CAHidiLEC7aTqSoHX6w1nEWy5xvH6tuVggY6_HHHcL9iFLYxOeg%40mail.gmail.com.
Marco Schambach
IdenTrust votes Yes on SC-91
Marco S.
TrustID Program Manager
Vastaanottaja: server...@groups.cabforum.org <server...@groups.cabforum.org>
Aihe: [Servercert-wg] Voting period begins: Ballot SC-91: Sunset 3.2.2.5.3 Reverse Address Lookup Validation, proposal of new DNS-based validation using Persistent DCV TXT Record for IP addresses Inbox
Note: Please disregard the previous email as it had incorrect dates for the voting period. If you have already voted, please vote again by responding to this email.
Purpose of Ballot SC-91
This ballot sunsets 3.2.2.5.3 (“Reverse Address Lookup”) and introduces 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”) as its replacement.
Background
The “Reverse Address Lookup” method (3.2.2.5.3) has been recognized as insecure due to its reliance on PTR records and indirect validation of domains instead of IP addresses. However, DNS-based validation of IP addresses is useful for many specific client use cases (e.g., ssh frontends, DoH servers) where HTTP- or TLS-based validation is infeasible due to security concerns with opening associated ports or difficulty with serving challenges from anycasted addresses. For the replacement of “Reverse Address Lookup,” we offer another validation method, “DNS TXT Record with Persistent Value in the Reverse Namespace.” The new method is a more secure replacement of 3.2.2.5.3, allowing subscribers to validate IP addresses by DNS while mitigating the risk of “crossover” attacks.
The new method addresses two primary security concerns of the “Reverse Address Lookup” method: (1) staleness of PTR records (by requiring a TXT record placed at a validation-specific prefix in the .arpa zone) (2) lack of authentication and crossover risk (by requiring an account-bound credential to be placed in the TXT record).
Justification
For sunsetting the “Reverse Address Lookup” method for IP addresses (3.2.2.5.3):
· The method proves a “weak binding” between the IP address listed in the Certificate and the domain name that ultimately completes DV for the certificate to be issued.
o “Reverse Address Lookup” involves querying PTR records for an IP address’s associated reverse DNS name, and then validating the returned domain name using a DV method listed in 3.2.2.4. Successfully validating the PTR’s domain name proves control over that domain, but does not necessarily prove control of the IP address itself or its reverse zone.
· Stale PTR records represent a critical security risk for this validation method.
o PTR records are often stale, especially due to dynamic IP reassignment in cloud-based environments. “DNS scavenging” (removal of PTR records for decommissioned domain names) is not enabled by default on DNS server implementations. Additionally, there is no mechanism to sync updates in a FQDN’s A or AAAA records to PTR records in the corresponding reverse zone.
o If an IP address’s PTR record(s) point to a domain that is no longer in use, an attacker can gain control of the free domain name, and complete validation for an IP address that they do not actually control or have administrative access to. Thus, the method may allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
o The current reverse name validation method does not require any indication of request to issue in the reverse zone itself; there is no validation-related prefix appended to the reverse name associated with the IP address.
· Reverse Address Lookup allows any DV method for domains in 3.2.2.4 to be applied for validation of the domain listed in the IP address’s PTR records. Thus, it inherits the attack surface of the superset of all domain DV methods; its effective security is tied to the weakest domain validation method still permitted.
o The previous method allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
o This included (previously) weaker WHOIS, email, and phone contact-based methods (scheduled to be sunset as proposed by SC-90). This represents a broader attack surface compared to 3.2.2.5.22, which consists purely of DNS. Compromise of any of the 3.2.2.4 methods could allow an attacker to gain a misissued certificate for an IP address.
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Offers a secure replacement for a DNS-based validation method for IP addresses
o The new method limits the validation challenge to direct DNS TXT queries in the .arpa zone associated with an IP address. This focuses proof of control on the authoritative namespace for that IP, rather than relying on a generic PTR record that may be stale or repurposed for uses unrelated to validation.
o By contrast, “Reverse Address Lookup” allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
· The newly created “DNS TXT Record with Persistent Value” method (SC-088v2, to be 3.2.2.4.22) for validation of domains offers several benefits to subscribers in terms of operational ease, flexibility, and ease of automated certificate issuance. These same benefits can be brought to validation of IP addresses by placement of an Persistent DCV TXT Record within the reverse zone associated with an IP address.
o The method provides a more direct proof of certificate issuance through IP address-associated reverse zones.
o The method minimizes the need to make live record updates in reverse zones to complete validation of an IP address, which may be especially challenging due to the fact that IP address holders may not have direct access to the .arpa zone associated with their IP address.
o We confirm the feasibility of placement of non-PTR records in reverse zones, through consultation with several in-house DNS experts at Google and directly placing test records in an Unbound zonefile.
Benefits of adoption
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Improves validation processes by extending an existing DV method, 3.2.2.4.22 “DNS TXT Record with Persistent Value,” to the validation of IP addresses.
o This ensures that CAs and subscribers can adopt uniform process and tooling for both domain and IP address validation via the Persistent DCV TXT value method, reducing complexity and the risk of inconsistent implementation.
· Promotes stronger validation integrity by ensuring that DV demonstrates a stronger binding to actual administrative control over an IP address, increasing the consistency of trustworthiness of issued certificates.
o Reverse DNS zones (in-addr.arpa and ip6.arpa) are delegated by RIRs and LIRs in accordance with IP address block allocations. This makes the reverse namespace the authoritative DNS context for demonstrating control of IP addresses.
o Direct DNS assertion through IP address-associated reverse zones is a stronger proof of control.
o Publishing a TXT record at a validation specific-prefix directly demonstrates administrative control of the IP resource AS WELL AS request to issue.
o Removes reliance on the correctness/freshness of PTR records and eliminates DV indirection through potentially unrelated domains.
· Improves security posture and reduces risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
o The new method replaces the current allowance in 3.2.2.5.3 to use any domain validation method in 3.2.2.4 with a single, narrowly defined DNS-based method. This strengthens security by eliminating the "weakest link" problem, as the security of 3.2.2.5.3 was inherently bound to the security of the weakest validation method in 3.2.2.4.
o Removes the possibility of “crossover” attacks introduced by tying validation of an IP address to validation of an unrelated domain in a stale PTR record.
o Limits the validation challenge to direct DNS TXT queries in the .arpa zone, minimizing the attack surface to only DNS.
· Facilitates innovation by allowing automation without live DNS updates, supporting shortened certificate lifetimes and more agile re-issuance for IP address certificate subscribers. This is especially helpful because of the administrative burden often inherent in updating .arpa zones.
o Creates opportunities for faster, more efficient certificate lifestyle management and simplification of maintenance of reverse zones.
o Brings the improvements of 3.2.2.4.22 to validation of IP addresses.
· Promote stronger validation integrity by ensuring that DCV proves a stronger, more direct binding to actual administrative control over the reverse namespace associated with an IP address.
Proposed Key Dates
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective immediately:
o Implementation of 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”)
· Effective March 15, 2027:
o Sunset of Method 3.2.2.5.3 (“Reverse Address Lookup”)
Motion
The following motion has been proposed by Gurleen Grewal of Google (Google Trust Services) and endorsed by Michael Slaughter (Amazon Trust Services) and Dimitris Zacharopoulos (HARICA).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.7.1.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 7 days)
· Start: 2025-10-23 16:00:00 UTC
· End time: 2025-11-04 16:00:00 UTC
Vote for approval (7 days)
· Start: 2025-11-05 17:40:00 UTC
· End: 2025-11-12 17:40:00 UTC
--
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/CAHidiLEC7aTqSoHX6w1nEWy5xvH6tuVggY6_HHHcL9iFLYxOeg%40mail.gmail.com.
This email may contain information which is privileged or protected against unauthorized disclosure or communication. If you are not the intended recipient, please notify the sender and delete this message and any attachments from your system without producing, distributing or retaining copies thereof or disclosing its contents to any other person.
Telia Company processes emails and other files that may contain personal data in accordance with Telia Company’s Privacy Policy.
--
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.
Kateryna Aleksieieva
Certum votes YES on Ballot SC-91
Kind regards,
Kateryna Aleksieieva
From: 'Gurleen Grewal' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, November 5, 2025 6:40 PM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting period begins: Ballot SC-91: Sunset 3.2.2.5.3 Reverse Address Lookup Validation, proposal of new DNS-based validation using Persistent DCV TXT Record for IP addresses Inbox
Note: Please disregard the previous email as it had incorrect dates for the voting period. If you have already voted, please vote again by responding to this email.
Purpose of Ballot SC-91
This ballot sunsets 3.2.2.5.3 (“Reverse Address Lookup”) and introduces 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”) as its replacement.
Background
The “Reverse Address Lookup” method (3.2.2.5.3) has been recognized as insecure due to its reliance on PTR records and indirect validation of domains instead of IP addresses. However, DNS-based validation of IP addresses is useful for many specific client use cases (e.g., ssh frontends, DoH servers) where HTTP- or TLS-based validation is infeasible due to security concerns with opening associated ports or difficulty with serving challenges from anycasted addresses. For the replacement of “Reverse Address Lookup,” we offer another validation method, “DNS TXT Record with Persistent Value in the Reverse Namespace.” The new method is a more secure replacement of 3.2.2.5.3, allowing subscribers to validate IP addresses by DNS while mitigating the risk of “crossover” attacks.
The new method addresses two primary security concerns of the “Reverse Address Lookup” method: (1) staleness of PTR records (by requiring a TXT record placed at a validation-specific prefix in the .arpa zone) (2) lack of authentication and crossover risk (by requiring an account-bound credential to be placed in the TXT record).
Justification
For sunsetting the “Reverse Address Lookup” method for IP addresses (3.2.2.5.3):
· The method proves a “weak binding” between the IP address listed in the Certificate and the domain name that ultimately completes DV for the certificate to be issued.
o “Reverse Address Lookup” involves querying PTR records for an IP address’s associated reverse DNS name, and then validating the returned domain name using a DV method listed in 3.2.2.4. Successfully validating the PTR’s domain name proves control over that domain, but does not necessarily prove control of the IP address itself or its reverse zone.
· Stale PTR records represent a critical security risk for this validation method.
o PTR records are often stale, especially due to dynamic IP reassignment in cloud-based environments. “DNS scavenging” (removal of PTR records for decommissioned domain names) is not enabled by default on DNS server implementations. Additionally, there is no mechanism to sync updates in a FQDN’s A or AAAA records to PTR records in the corresponding reverse zone.
o If an IP address’s PTR record(s) point to a domain that is no longer in use, an attacker can gain control of the free domain name, and complete validation for an IP address that they do not actually control or have administrative access to. Thus, the method may allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
o The current reverse name validation method does not require any indication of request to issue in the reverse zone itself; there is no validation-related prefix appended to the reverse name associated with the IP address.
· Reverse Address Lookup allows any DV method for domains in 3.2.2.4 to be applied for validation of the domain listed in the IP address’s PTR records. Thus, it inherits the attack surface of the superset of all domain DV methods; its effective security is tied to the weakest domain validation method still permitted.
o The previous method allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
o This included (previously) weaker WHOIS, email, and phone contact-based methods (scheduled to be sunset as proposed by SC-90). This represents a broader attack surface compared to 3.2.2.5.22, which consists purely of DNS. Compromise of any of the 3.2.2.4 methods could allow an attacker to gain a misissued certificate for an IP address.
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Offers a secure replacement for a DNS-based validation method for IP addresses
o The new method limits the validation challenge to direct DNS TXT queries in the .arpa zone associated with an IP address. This focuses proof of control on the authoritative namespace for that IP, rather than relying on a generic PTR record that may be stale or repurposed for uses unrelated to validation.
o By contrast, “Reverse Address Lookup” allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
· The newly created “DNS TXT Record with Persistent Value” method (SC-088v2, to be 3.2.2.4.22) for validation of domains offers several benefits to subscribers in terms of operational ease, flexibility, and ease of automated certificate issuance. These same benefits can be brought to validation of IP addresses by placement of an Persistent DCV TXT Record within the reverse zone associated with an IP address.
o The method provides a more direct proof of certificate issuance through IP address-associated reverse zones.
o The method minimizes the need to make live record updates in reverse zones to complete validation of an IP address, which may be especially challenging due to the fact that IP address holders may not have direct access to the .arpa zone associated with their IP address.
o We confirm the feasibility of placement of non-PTR records in reverse zones, through consultation with several in-house DNS experts at Google and directly placing test records in an Unbound zonefile.
Benefits of adoption
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Improves validation processes by extending an existing DV method, 3.2.2.4.22 “DNS TXT Record with Persistent Value,” to the validation of IP addresses.
o This ensures that CAs and subscribers can adopt uniform process and tooling for both domain and IP address validation via the Persistent DCV TXT value method, reducing complexity and the risk of inconsistent implementation.
· Promotes stronger validation integrity by ensuring that DV demonstrates a stronger binding to actual administrative control over an IP address, increasing the consistency of trustworthiness of issued certificates.
o Reverse DNS zones (in-addr.arpa and ip6.arpa) are delegated by RIRs and LIRs in accordance with IP address block allocations. This makes the reverse namespace the authoritative DNS context for demonstrating control of IP addresses.
o Direct DNS assertion through IP address-associated reverse zones is a stronger proof of control.
o Publishing a TXT record at a validation specific-prefix directly demonstrates administrative control of the IP resource AS WELL AS request to issue.
o Removes reliance on the correctness/freshness of PTR records and eliminates DV indirection through potentially unrelated domains.
· Improves security posture and reduces risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
o The new method replaces the current allowance in 3.2.2.5.3 to use any domain validation method in 3.2.2.4 with a single, narrowly defined DNS-based method. This strengthens security by eliminating the "weakest link" problem, as the security of 3.2.2.5.3 was inherently bound to the security of the weakest validation method in 3.2.2.4.
o Removes the possibility of “crossover” attacks introduced by tying validation of an IP address to validation of an unrelated domain in a stale PTR record.
o Limits the validation challenge to direct DNS TXT queries in the .arpa zone, minimizing the attack surface to only DNS.
· Facilitates innovation by allowing automation without live DNS updates, supporting shortened certificate lifetimes and more agile re-issuance for IP address certificate subscribers. This is especially helpful because of the administrative burden often inherent in updating .arpa zones.
o Creates opportunities for faster, more efficient certificate lifestyle management and simplification of maintenance of reverse zones.
o Brings the improvements of 3.2.2.4.22 to validation of IP addresses.
· Promote stronger validation integrity by ensuring that DCV proves a stronger, more direct binding to actual administrative control over the reverse namespace associated with an IP address.
Proposed Key Dates
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective immediately:
o Implementation of 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”)
· Effective March 15, 2027:
o Sunset of Method 3.2.2.5.3 (“Reverse Address Lookup”)
Motion
The following motion has been proposed by Gurleen Grewal of Google (Google Trust Services) and endorsed by Michael Slaughter (Amazon Trust Services) and Dimitris Zacharopoulos (HARICA).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.7.1.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 7 days)
· Start: 2025-10-23 16:00:00 UTC
· End time: 2025-11-04 16:00:00 UTC
Vote for approval (7 days)
· Start: 2025-11-05 17:40:00 UTC
· End: 2025-11-12 17:40:00 UTC
--
Alvin Wang
Adrian Mueller
SwissSign votes "Yes" on ballot SC-91.
Best regards
Adrian
From: 'Gurleen Grewal' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, November 5, 2025 6:40 PM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting period begins: Ballot SC-91: Sunset 3.2.2.5.3 Reverse Address Lookup Validation, proposal of new DNS-based validation using Persistent DCV TXT Record for IP addresses Inbox
Note: Please disregard the previous email as it had incorrect dates for the voting period. If you have already voted, please vote again by responding to this email.
Purpose of Ballot SC-91
This ballot sunsets 3.2.2.5.3 (“Reverse Address Lookup”) and introduces 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”) as its replacement.
Background
The “Reverse Address Lookup” method (3.2.2.5.3) has been recognized as insecure due to its reliance on PTR records and indirect validation of domains instead of IP addresses. However, DNS-based validation of IP addresses is useful for many specific client use cases (e.g., ssh frontends, DoH servers) where HTTP- or TLS-based validation is infeasible due to security concerns with opening associated ports or difficulty with serving challenges from anycasted addresses. For the replacement of “Reverse Address Lookup,” we offer another validation method, “DNS TXT Record with Persistent Value in the Reverse Namespace.” The new method is a more secure replacement of 3.2.2.5.3, allowing subscribers to validate IP addresses by DNS while mitigating the risk of “crossover” attacks.
The new method addresses two primary security concerns of the “Reverse Address Lookup” method: (1) staleness of PTR records (by requiring a TXT record placed at a validation-specific prefix in the .arpa zone) (2) lack of authentication and crossover risk (by requiring an account-bound credential to be placed in the TXT record).
Justification
For sunsetting the “Reverse Address Lookup” method for IP addresses (3.2.2.5.3):
· The method proves a “weak binding” between the IP address listed in the Certificate and the domain name that ultimately completes DV for the certificate to be issued.
o “Reverse Address Lookup” involves querying PTR records for an IP address’s associated reverse DNS name, and then validating the returned domain name using a DV method listed in 3.2.2.4. Successfully validating the PTR’s domain name proves control over that domain, but does not necessarily prove control of the IP address itself or its reverse zone.
· Stale PTR records represent a critical security risk for this validation method.
o PTR records are often stale, especially due to dynamic IP reassignment in cloud-based environments. “DNS scavenging” (removal of PTR records for decommissioned domain names) is not enabled by default on DNS server implementations. Additionally, there is no mechanism to sync updates in a FQDN’s A or AAAA records to PTR records in the corresponding reverse zone.
o If an IP address’s PTR record(s) point to a domain that is no longer in use, an attacker can gain control of the free domain name, and complete validation for an IP address that they do not actually control or have administrative access to. Thus, the method may allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
o The current reverse name validation method does not require any indication of request to issue in the reverse zone itself; there is no validation-related prefix appended to the reverse name associated with the IP address.
· Reverse Address Lookup allows any DV method for domains in 3.2.2.4 to be applied for validation of the domain listed in the IP address’s PTR records. Thus, it inherits the attack surface of the superset of all domain DV methods; its effective security is tied to the weakest domain validation method still permitted.
o The previous method allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
o This included (previously) weaker WHOIS, email, and phone contact-based methods (scheduled to be sunset as proposed by SC-90). This represents a broader attack surface compared to 3.2.2.5.22, which consists purely of DNS. Compromise of any of the 3.2.2.4 methods could allow an attacker to gain a misissued certificate for an IP address.
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Offers a secure replacement for a DNS-based validation method for IP addresses
o The new method limits the validation challenge to direct DNS TXT queries in the .arpa zone associated with an IP address. This focuses proof of control on the authoritative namespace for that IP, rather than relying on a generic PTR record that may be stale or repurposed for uses unrelated to validation.
o By contrast, “Reverse Address Lookup” allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
· The newly created “DNS TXT Record with Persistent Value” method (SC-088v2, to be 3.2.2.4.22) for validation of domains offers several benefits to subscribers in terms of operational ease, flexibility, and ease of automated certificate issuance. These same benefits can be brought to validation of IP addresses by placement of an Persistent DCV TXT Record within the reverse zone associated with an IP address.
o The method provides a more direct proof of certificate issuance through IP address-associated reverse zones.
o The method minimizes the need to make live record updates in reverse zones to complete validation of an IP address, which may be especially challenging due to the fact that IP address holders may not have direct access to the .arpa zone associated with their IP address.
o We confirm the feasibility of placement of non-PTR records in reverse zones, through consultation with several in-house DNS experts at Google and directly placing test records in an Unbound zonefile.
Benefits of adoption
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Improves validation processes by extending an existing DV method, 3.2.2.4.22 “DNS TXT Record with Persistent Value,” to the validation of IP addresses.
o This ensures that CAs and subscribers can adopt uniform process and tooling for both domain and IP address validation via the Persistent DCV TXT value method, reducing complexity and the risk of inconsistent implementation.
· Promotes stronger validation integrity by ensuring that DV demonstrates a stronger binding to actual administrative control over an IP address, increasing the consistency of trustworthiness of issued certificates.
o Reverse DNS zones (in-addr.arpa and ip6.arpa) are delegated by RIRs and LIRs in accordance with IP address block allocations. This makes the reverse namespace the authoritative DNS context for demonstrating control of IP addresses.
o Direct DNS assertion through IP address-associated reverse zones is a stronger proof of control.
o Publishing a TXT record at a validation specific-prefix directly demonstrates administrative control of the IP resource AS WELL AS request to issue.
o Removes reliance on the correctness/freshness of PTR records and eliminates DV indirection through potentially unrelated domains.
· Improves security posture and reduces risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
o The new method replaces the current allowance in 3.2.2.5.3 to use any domain validation method in 3.2.2.4 with a single, narrowly defined DNS-based method. This strengthens security by eliminating the "weakest link" problem, as the security of 3.2.2.5.3 was inherently bound to the security of the weakest validation method in 3.2.2.4.
o Removes the possibility of “crossover” attacks introduced by tying validation of an IP address to validation of an unrelated domain in a stale PTR record.
o Limits the validation challenge to direct DNS TXT queries in the .arpa zone, minimizing the attack surface to only DNS.
· Facilitates innovation by allowing automation without live DNS updates, supporting shortened certificate lifetimes and more agile re-issuance for IP address certificate subscribers. This is especially helpful because of the administrative burden often inherent in updating .arpa zones.
o Creates opportunities for faster, more efficient certificate lifestyle management and simplification of maintenance of reverse zones.
o Brings the improvements of 3.2.2.4.22 to validation of IP addresses.
· Promote stronger validation integrity by ensuring that DCV proves a stronger, more direct binding to actual administrative control over the reverse namespace associated with an IP address.
Proposed Key Dates
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective immediately:
o Implementation of 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”)
· Effective March 15, 2027:
o Sunset of Method 3.2.2.5.3 (“Reverse Address Lookup”)
Motion
The following motion has been proposed by Gurleen Grewal of Google (Google Trust Services) and endorsed by Michael Slaughter (Amazon Trust Services) and Dimitris Zacharopoulos (HARICA).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.7.1.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 7 days)
· Start: 2025-10-23 16:00:00 UTC
· End time: 2025-11-04 16:00:00 UTC
Vote for approval (7 days)
· Start: 2025-11-05 17:40:00 UTC
· End: 2025-11-12 17:40:00 UTC
--
Jeun, Inkyung (Lynn)
Visa Inc votes “YES” to ballot SC-91.
Best,
Lynn.
Wayne Thayer
--
Nome Huang
黃晟(orca)
TWCA votes “Yes” on ballot SC-91.
Regards,
Sean Huang
Senior R&D Engineer
TEL：02-2370-8886#728
FAX：02-2388-6720
Email：or...@twca.com.tw
10F., No. 85, Yanping South Road,
Taipei, Taiwan (R.O.C.)
From: 'Gurleen Grewal' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Thursday, November 6, 2025 1:40 AM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting period begins: Ballot SC-91: Sunset 3.2.2.5.3 Reverse Address Lookup Validation, proposal of new DNS-based validation using Persistent DCV TXT Record for IP addresses Inbox
Note: Please disregard the previous email as it had incorrect dates for the voting period. If you have already voted, please vote again by responding to this email.
Purpose of Ballot SC-91
This ballot sunsets 3.2.2.5.3 (“Reverse Address Lookup”) and introduces 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”) as its replacement.
Background
The “Reverse Address Lookup” method (3.2.2.5.3) has been recognized as insecure due to its reliance on PTR records and indirect validation of domains instead of IP addresses. However, DNS-based validation of IP addresses is useful for many specific client use cases (e.g., ssh frontends, DoH servers) where HTTP- or TLS-based validation is infeasible due to security concerns with opening associated ports or difficulty with serving challenges from anycasted addresses. For the replacement of “Reverse Address Lookup,” we offer another validation method, “DNS TXT Record with Persistent Value in the Reverse Namespace.” The new method is a more secure replacement of 3.2.2.5.3, allowing subscribers to validate IP addresses by DNS while mitigating the risk of “crossover” attacks.
The new method addresses two primary security concerns of the “Reverse Address Lookup” method: (1) staleness of PTR records (by requiring a TXT record placed at a validation-specific prefix in the .arpa zone) (2) lack of authentication and crossover risk (by requiring an account-bound credential to be placed in the TXT record).
Justification
For sunsetting the “Reverse Address Lookup” method for IP addresses (3.2.2.5.3):
· The method proves a “weak binding” between the IP address listed in the Certificate and the domain name that ultimately completes DV for the certificate to be issued.
o “Reverse Address Lookup” involves querying PTR records for an IP address’s associated reverse DNS name, and then validating the returned domain name using a DV method listed in 3.2.2.4. Successfully validating the PTR’s domain name proves control over that domain, but does not necessarily prove control of the IP address itself or its reverse zone.
· Stale PTR records represent a critical security risk for this validation method.
o PTR records are often stale, especially due to dynamic IP reassignment in cloud-based environments. “DNS scavenging” (removal of PTR records for decommissioned domain names) is not enabled by default on DNS server implementations. Additionally, there is no mechanism to sync updates in a FQDN’s A or AAAA records to PTR records in the corresponding reverse zone.
o If an IP address’s PTR record(s) point to a domain that is no longer in use, an attacker can gain control of the free domain name, and complete validation for an IP address that they do not actually control or have administrative access to. Thus, the method may allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
o The current reverse name validation method does not require any indication of request to issue in the reverse zone itself; there is no validation-related prefix appended to the reverse name associated with the IP address.
· Reverse Address Lookup allows any DV method for domains in 3.2.2.4 to be applied for validation of the domain listed in the IP address’s PTR records. Thus, it inherits the attack surface of the superset of all domain DV methods; its effective security is tied to the weakest domain validation method still permitted.
o The previous method allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
o This included (previously) weaker WHOIS, email, and phone contact-based methods (scheduled to be sunset as proposed by SC-90). This represents a broader attack surface compared to 3.2.2.5.22, which consists purely of DNS. Compromise of any of the 3.2.2.4 methods could allow an attacker to gain a misissued certificate for an IP address.
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Offers a secure replacement for a DNS-based validation method for IP addresses
o The new method limits the validation challenge to direct DNS TXT queries in the .arpa zone associated with an IP address. This focuses proof of control on the authoritative namespace for that IP, rather than relying on a generic PTR record that may be stale or repurposed for uses unrelated to validation.
o By contrast, “Reverse Address Lookup” allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
· The newly created “DNS TXT Record with Persistent Value” method (SC-088v2, to be 3.2.2.4.22) for validation of domains offers several benefits to subscribers in terms of operational ease, flexibility, and ease of automated certificate issuance. These same benefits can be brought to validation of IP addresses by placement of an Persistent DCV TXT Record within the reverse zone associated with an IP address.
o The method provides a more direct proof of certificate issuance through IP address-associated reverse zones.
o The method minimizes the need to make live record updates in reverse zones to complete validation of an IP address, which may be especially challenging due to the fact that IP address holders may not have direct access to the .arpa zone associated with their IP address.
o We confirm the feasibility of placement of non-PTR records in reverse zones, through consultation with several in-house DNS experts at Google and directly placing test records in an Unbound zonefile.
Benefits of adoption
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Improves validation processes by extending an existing DV method, 3.2.2.4.22 “DNS TXT Record with Persistent Value,” to the validation of IP addresses.
o This ensures that CAs and subscribers can adopt uniform process and tooling for both domain and IP address validation via the Persistent DCV TXT value method, reducing complexity and the risk of inconsistent implementation.
· Promotes stronger validation integrity by ensuring that DV demonstrates a stronger binding to actual administrative control over an IP address, increasing the consistency of trustworthiness of issued certificates.
o Reverse DNS zones (in-addr.arpa and ip6.arpa) are delegated by RIRs and LIRs in accordance with IP address block allocations. This makes the reverse namespace the authoritative DNS context for demonstrating control of IP addresses.
o Direct DNS assertion through IP address-associated reverse zones is a stronger proof of control.
o Publishing a TXT record at a validation specific-prefix directly demonstrates administrative control of the IP resource AS WELL AS request to issue.
o Removes reliance on the correctness/freshness of PTR records and eliminates DV indirection through potentially unrelated domains.
· Improves security posture and reduces risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
o The new method replaces the current allowance in 3.2.2.5.3 to use any domain validation method in 3.2.2.4 with a single, narrowly defined DNS-based method. This strengthens security by eliminating the "weakest link" problem, as the security of 3.2.2.5.3 was inherently bound to the security of the weakest validation method in 3.2.2.4.
o Removes the possibility of “crossover” attacks introduced by tying validation of an IP address to validation of an unrelated domain in a stale PTR record.
o Limits the validation challenge to direct DNS TXT queries in the .arpa zone, minimizing the attack surface to only DNS.
· Facilitates innovation by allowing automation without live DNS updates, supporting shortened certificate lifetimes and more agile re-issuance for IP address certificate subscribers. This is especially helpful because of the administrative burden often inherent in updating .arpa zones.
o Creates opportunities for faster, more efficient certificate lifestyle management and simplification of maintenance of reverse zones.
o Brings the improvements of 3.2.2.4.22 to validation of IP addresses.
· Promote stronger validation integrity by ensuring that DCV proves a stronger, more direct binding to actual administrative control over the reverse namespace associated with an IP address.
Proposed Key Dates
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective immediately:
o Implementation of 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”)
· Effective March 15, 2027:
o Sunset of Method 3.2.2.5.3 (“Reverse Address Lookup”)
Motion
The following motion has been proposed by Gurleen Grewal of Google (Google Trust Services) and endorsed by Michael Slaughter (Amazon Trust Services) and Dimitris Zacharopoulos (HARICA).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.7.1.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 7 days)
· Start: 2025-10-23 16:00:00 UTC
· End time: 2025-11-04 16:00:00 UTC
Vote for approval (7 days)
· Start: 2025-11-05 17:40:00 UTC
· End: 2025-11-12 17:40:00 UTC
--
jun....@cybertrust.co.jp
-----Original Message-----
From: 'Gurleen Grewal' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Thursday, November 6, 2025 2:40 AM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting period begins: Ballot SC-91: Sunset 3.2.2.5.3 Reverse Address Lookup Validation, proposal of new DNS-based validation using Persistent DCV TXT Record for IP addresses Inbox
Purpose of Ballot SC-91
This ballot sunsets 3.2.2.5.3 (“Reverse Address Lookup”) and introduces 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”) as its replacement.
Background
The new method addresses two primary security concerns of the “Reverse Address Lookup” method: (1) staleness of PTR records (by requiring a TXT record placed at a validation-specific prefix in the .arpa zone) (2) lack of authentication and crossover risk (by requiring an account-bound credential to be placed in the TXT record).
Justification
* The method proves a “weak binding” between the IP address listed in the Certificate and the domain name that ultimately completes DV for the certificate to be issued.
* “Reverse Address Lookup” involves querying PTR records for an IP address’s associated reverse DNS name, and then validating the returned domain name using a DV method listed in 3.2.2.4. Successfully validating the PTR’s domain name proves control over that domain, but does not necessarily prove control of the IP address itself or its reverse zone.
* Stale PTR records represent a critical security risk for this validation method.
* PTR records are often stale, especially due to dynamic IP reassignment in cloud-based environments. “DNS scavenging” (removal of PTR records for decommissioned domain names) is not enabled by default on DNS server implementations. Additionally, there is no mechanism to sync updates in a FQDN’s A or AAAA records to PTR records in the corresponding reverse zone.
* If an IP address’s PTR record(s) point to a domain that is no longer in use, an attacker can gain control of the free domain name, and complete validation for an IP address that they do not actually control or have administrative access to. Thus, the method may allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
* The current reverse name validation method does not require any indication of request to issue in the reverse zone itself; there is no validation-related prefix appended to the reverse name associated with the IP address.
* Reverse Address Lookup allows any DV method for domains in 3.2.2.4 <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#3224-validation-of-domain-authorization-or-control> to be applied for validation of the domain listed in the IP address’s PTR records. Thus, it inherits the attack surface of the superset of all domain DV methods; its effective security is tied to the weakest domain validation method still permitted.
* The previous method allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
* This included (previously) weaker WHOIS, email, and phone contact-based methods (scheduled to be sunset as proposed by SC-90 <https://docs.google.com/document/d/1B7ZwGa-lZRlSJFhzbb5PgXbHAnVFH4-7mKPcXAMmaCo/edit?usp=sharing> ). This represents a broader attack surface compared to 3.2.2.5.22, which consists purely of DNS. Compromise of any of the 3.2.2.4 methods could allow an attacker to gain a misissued certificate for an IP address.
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
* The new method limits the validation challenge to direct DNS TXT queries in the .arpa zone associated with an IP address. This focuses proof of control on the authoritative namespace for that IP, rather than relying on a generic PTR record that may be stale or repurposed for uses unrelated to validation.
* By contrast, “Reverse Address Lookup” allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
* The newly created “DNS TXT Record with Persistent Value” method (SC-088v2 <https://github.com/cabforum/servercert/pull/608> , to be 3.2.2.4.22) for validation of domains offers several benefits to subscribers in terms of operational ease, flexibility, and ease of automated certificate issuance. These same benefits can be brought to validation of IP addresses by placement of an Persistent DCV TXT Record within the reverse zone associated with an IP address.
* The method provides a more direct proof of certificate issuance through IP address-associated reverse zones.
* The method minimizes the need to make live record updates in reverse zones to complete validation of an IP address, which may be especially challenging due to the fact that IP address holders may not have direct access to the .arpa zone associated with their IP address.
* We confirm the feasibility of placement of non-PTR records in reverse zones, through consultation with several in-house DNS experts at Google and directly placing test records in an Unbound zonefile.
Benefits of adoption
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
* This ensures that CAs and subscribers can adopt uniform process and tooling for both domain and IP address validation via the Persistent DCV TXT value method, reducing complexity and the risk of inconsistent implementation.
* Promotes stronger validation integrity by ensuring that DV demonstrates a stronger binding to actual administrative control over an IP address, increasing the consistency of trustworthiness of issued certificates.
* Reverse DNS zones (in-addr.arpa <http://in-addr.arpa/> and ip6.arpa <http://ip6.arpa/> ) are delegated by RIRs and LIRs in accordance with IP address block allocations. This makes the reverse namespace the authoritative DNS context for demonstrating control of IP addresses.
* Direct DNS assertion through IP address-associated reverse zones is a stronger proof of control.
* Publishing a TXT record at a validation specific-prefix directly demonstrates administrative control of the IP resource AS WELL AS request to issue.
* Removes reliance on the correctness/freshness of PTR records and eliminates DV indirection through potentially unrelated domains.
* Improves security posture and reduces risk of improper certificate issuance by sunsetting a method that enables "crossover <https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/cf60cd18-3f58-4d5f-818a-770cd6450514n%40groups.cabforum.org?utm_medium=email&utm_source=footer> " attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
* The new method replaces the current allowance in 3.2.2.5.3 to use any domain validation method in 3.2.2.4 with a single, narrowly defined DNS-based method. This strengthens security by eliminating the "weakest link" problem, as the security of 3.2.2.5.3 was inherently bound to the security of the weakest validation method in 3.2.2.4.
* Removes the possibility of “crossover” attacks introduced by tying validation of an IP address to validation of an unrelated domain in a stale PTR record.
* Limits the validation challenge to direct DNS TXT queries in the .arpa zone, minimizing the attack surface to only DNS.
* Facilitates innovation by allowing automation without live DNS updates, supporting shortened certificate lifetimes and more agile re-issuance for IP address certificate subscribers. This is especially helpful because of the administrative burden often inherent in updating .arpa zones.
* Creates opportunities for faster, more efficient certificate lifestyle management and simplification of maintenance of reverse zones.
* Brings the improvements of 3.2.2.4.22 to validation of IP addresses.
* Promote stronger validation integrity by ensuring that DCV proves a stronger, more direct binding to actual administrative control over the reverse namespace associated with an IP address.
Proposed Key Dates
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
* Implementation of 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”)
* Effective March 15, 2027:
* Sunset of Method 3.2.2.5.3 (“Reverse Address Lookup”)
Motion
The following motion has been proposed by Gurleen Grewal of Google (Google Trust Services) and endorsed by Michael Slaughter (Amazon Trust Services) and Dimitris Zacharopoulos (HARICA).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.7.1.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 7 days)
* End time: 2025-11-04 16:00:00 UTC
Vote for approval (7 days)
* End: 2025-11-12 17:40:00 UTC
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAHidiLEC7aTqSoHX6w1nEWy5xvH6tuVggY6_HHHcL9iFLYxOeg%40mail.gmail.com <https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAHidiLEC7aTqSoHX6w1nEWy5xvH6tuVggY6_HHHcL9iFLYxOeg%40mail.gmail.com?utm_medium=email&utm_source=footer> .
qi_ji...@itrus.com.cn
Date: 2025-11-06 01:40To: servercert-wgSubject: [Servercert-wg] Voting period begins: Ballot SC-91: Sunset 3.2.2.5.3 Reverse Address Lookup Validation, proposal of new DNS-based validation using Persistent DCV TXT Record for IP addresses Inbox
Note: Please disregard the previous email as it had incorrect dates for the voting period. If you have already voted, please vote again by responding to this email.
--
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/CAHidiLEC7aTqSoHX6w1nEWy5xvH6tuVggY6_HHHcL9iFLYxOeg%40mail.gmail.com.
Aaron Poulsen
Amazon Trust Services votes "Yes" to ballot SC-091.
Entschew, Enrico
D-Trust votes „Yes“ on Ballot SC-91.
Thanks,
Enrico
Von: 'Gurleen Grewal' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Gesendet: Mittwoch, 5. November 2025 18:40
An: server...@groups.cabforum.org
Betreff: [Servercert-wg] Voting period begins: Ballot SC-91: Sunset 3.2.2.5.3 Reverse Address Lookup Validation, proposal of new DNS-based validation using Persistent DCV TXT Record for IP addresses Inbox
Note: Please disregard the previous email as it had incorrect dates for the voting period. If you have already voted, please vote again by responding to this email.
Purpose of Ballot SC-91
This ballot sunsets 3.2.2.5.3 (“Reverse Address Lookup”) and introduces 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”) as its replacement.
Background
The “Reverse Address Lookup” method (3.2.2.5.3) has been recognized as insecure due to its reliance on PTR records and indirect validation of domains instead of IP addresses. However, DNS-based validation of IP addresses is useful for many specific client use cases (e.g., ssh frontends, DoH servers) where HTTP- or TLS-based validation is infeasible due to security concerns with opening associated ports or difficulty with serving challenges from anycasted addresses. For the replacement of “Reverse Address Lookup,” we offer another validation method, “DNS TXT Record with Persistent Value in the Reverse Namespace.” The new method is a more secure replacement of 3.2.2.5.3, allowing subscribers to validate IP addresses by DNS while mitigating the risk of “crossover” attacks.
The new method addresses two primary security concerns of the “Reverse Address Lookup” method: (1) staleness of PTR records (by requiring a TXT record placed at a validation-specific prefix in the .arpa zone) (2) lack of authentication and crossover risk (by requiring an account-bound credential to be placed in the TXT record).
Justification
For sunsetting the “Reverse Address Lookup” method for IP addresses (3.2.2.5.3):
· The method proves a “weak binding” between the IP address listed in the Certificate and the domain name that ultimately completes DV for the certificate to be issued.
o “Reverse Address Lookup” involves querying PTR records for an IP address’s associated reverse DNS name, and then validating the returned domain name using a DV method listed in 3.2.2.4. Successfully validating the PTR’s domain name proves control over that domain, but does not necessarily prove control of the IP address itself or its reverse zone.
· Stale PTR records represent a critical security risk for this validation method.
o PTR records are often stale, especially due to dynamic IP reassignment in cloud-based environments. “DNS scavenging” (removal of PTR records for decommissioned domain names) is not enabled by default on DNS server implementations. Additionally, there is no mechanism to sync updates in a FQDN’s A or AAAA records to PTR records in the corresponding reverse zone.
o If an IP address’s PTR record(s) point to a domain that is no longer in use, an attacker can gain control of the free domain name, and complete validation for an IP address that they do not actually control or have administrative access to. Thus, the method may allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
o The current reverse name validation method does not require any indication of request to issue in the reverse zone itself; there is no validation-related prefix appended to the reverse name associated with the IP address.
· Reverse Address Lookup allows any DV method for domains in 3.2.2.4 to be applied for validation of the domain listed in the IP address’s PTR records. Thus, it inherits the attack surface of the superset of all domain DV methods; its effective security is tied to the weakest domain validation method still permitted.
o The previous method allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
o This included (previously) weaker WHOIS, email, and phone contact-based methods (scheduled to be sunset as proposed by SC-90). This represents a broader attack surface compared to 3.2.2.5.22, which consists purely of DNS. Compromise of any of the 3.2.2.4 methods could allow an attacker to gain a misissued certificate for an IP address.
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Offers a secure replacement for a DNS-based validation method for IP addresses
o The new method limits the validation challenge to direct DNS TXT queries in the .arpa zone associated with an IP address. This focuses proof of control on the authoritative namespace for that IP, rather than relying on a generic PTR record that may be stale or repurposed for uses unrelated to validation.
o By contrast, “Reverse Address Lookup” allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
· The newly created “DNS TXT Record with Persistent Value” method (SC-088v2, to be 3.2.2.4.22) for validation of domains offers several benefits to subscribers in terms of operational ease, flexibility, and ease of automated certificate issuance. These same benefits can be brought to validation of IP addresses by placement of an Persistent DCV TXT Record within the reverse zone associated with an IP address.
o The method provides a more direct proof of certificate issuance through IP address-associated reverse zones.
o The method minimizes the need to make live record updates in reverse zones to complete validation of an IP address, which may be especially challenging due to the fact that IP address holders may not have direct access to the .arpa zone associated with their IP address.
o We confirm the feasibility of placement of non-PTR records in reverse zones, through consultation with several in-house DNS experts at Google and directly placing test records in an Unbound zonefile.
Benefits of adoption
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Improves validation processes by extending an existing DV method, 3.2.2.4.22 “DNS TXT Record with Persistent Value,” to the validation of IP addresses.
o This ensures that CAs and subscribers can adopt uniform process and tooling for both domain and IP address validation via the Persistent DCV TXT value method, reducing complexity and the risk of inconsistent implementation.
· Promotes stronger validation integrity by ensuring that DV demonstrates a stronger binding to actual administrative control over an IP address, increasing the consistency of trustworthiness of issued certificates.
o Reverse DNS zones (in-addr.arpa and ip6.arpa) are delegated by RIRs and LIRs in accordance with IP address block allocations. This makes the reverse namespace the authoritative DNS context for demonstrating control of IP addresses.
o Direct DNS assertion through IP address-associated reverse zones is a stronger proof of control.
o Publishing a TXT record at a validation specific-prefix directly demonstrates administrative control of the IP resource AS WELL AS request to issue.
o Removes reliance on the correctness/freshness of PTR records and eliminates DV indirection through potentially unrelated domains.
· Improves security posture and reduces risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
o The new method replaces the current allowance in 3.2.2.5.3 to use any domain validation method in 3.2.2.4 with a single, narrowly defined DNS-based method. This strengthens security by eliminating the "weakest link" problem, as the security of 3.2.2.5.3 was inherently bound to the security of the weakest validation method in 3.2.2.4.
o Removes the possibility of “crossover” attacks introduced by tying validation of an IP address to validation of an unrelated domain in a stale PTR record.
o Limits the validation challenge to direct DNS TXT queries in the .arpa zone, minimizing the attack surface to only DNS.
· Facilitates innovation by allowing automation without live DNS updates, supporting shortened certificate lifetimes and more agile re-issuance for IP address certificate subscribers. This is especially helpful because of the administrative burden often inherent in updating .arpa zones.
o Creates opportunities for faster, more efficient certificate lifestyle management and simplification of maintenance of reverse zones.
o Brings the improvements of 3.2.2.4.22 to validation of IP addresses.
· Promote stronger validation integrity by ensuring that DCV proves a stronger, more direct binding to actual administrative control over the reverse namespace associated with an IP address.
Proposed Key Dates
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective immediately:
o Implementation of 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”)
· Effective March 15, 2027:
o Sunset of Method 3.2.2.5.3 (“Reverse Address Lookup”)
Motion
The following motion has been proposed by Gurleen Grewal of Google (Google Trust Services) and endorsed by Michael Slaughter (Amazon Trust Services) and Dimitris Zacharopoulos (HARICA).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.7.1.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 7 days)
· Start: 2025-10-23 16:00:00 UTC
· End time: 2025-11-04 16:00:00 UTC
Vote for approval (7 days)
· Start: 2025-11-05 17:40:00 UTC
· End: 2025-11-12 17:40:00 UTC
--
Tom Zermeno
SSL.com would like to vote “YES” on SC-91.
Thanks,
From: 'Gurleen Grewal' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, November 5, 2025 11:40 AM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting period begins: Ballot SC-91: Sunset 3.2.2.5.3 Reverse Address Lookup Validation, proposal of new DNS-based validation using Persistent DCV TXT Record for IP addresses Inbox
Note: Please disregard the previous email as it had incorrect dates for the voting period. If you have already voted, please vote again by responding to this email.
Purpose of Ballot SC-91
This ballot sunsets 3.2.2.5.3 (“Reverse Address Lookup”) and introduces 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”) as its replacement.
Background
The “Reverse Address Lookup” method (3.2.2.5.3) has been recognized as insecure due to its reliance on PTR records and indirect validation of domains instead of IP addresses. However, DNS-based validation of IP addresses is useful for many specific client use cases (e.g., ssh frontends, DoH servers) where HTTP- or TLS-based validation is infeasible due to security concerns with opening associated ports or difficulty with serving challenges from anycasted addresses. For the replacement of “Reverse Address Lookup,” we offer another validation method, “DNS TXT Record with Persistent Value in the Reverse Namespace.” The new method is a more secure replacement of 3.2.2.5.3, allowing subscribers to validate IP addresses by DNS while mitigating the risk of “crossover” attacks.
The new method addresses two primary security concerns of the “Reverse Address Lookup” method: (1) staleness of PTR records (by requiring a TXT record placed at a validation-specific prefix in the .arpa zone) (2) lack of authentication and crossover risk (by requiring an account-bound credential to be placed in the TXT record).
Justification
For sunsetting the “Reverse Address Lookup” method for IP addresses (3.2.2.5.3):
· The method proves a “weak binding” between the IP address listed in the Certificate and the domain name that ultimately completes DV for the certificate to be issued.
o “Reverse Address Lookup” involves querying PTR records for an IP address’s associated reverse DNS name, and then validating the returned domain name using a DV method listed in 3.2.2.4. Successfully validating the PTR’s domain name proves control over that domain, but does not necessarily prove control of the IP address itself or its reverse zone.
· Stale PTR records represent a critical security risk for this validation method.
o PTR records are often stale, especially due to dynamic IP reassignment in cloud-based environments. “DNS scavenging” (removal of PTR records for decommissioned domain names) is not enabled by default on DNS server implementations. Additionally, there is no mechanism to sync updates in a FQDN’s A or AAAA records to PTR records in the corresponding reverse zone.
o If an IP address’s PTR record(s) point to a domain that is no longer in use, an attacker can gain control of the free domain name, and complete validation for an IP address that they do not actually control or have administrative access to. Thus, the method may allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
o The current reverse name validation method does not require any indication of request to issue in the reverse zone itself; there is no validation-related prefix appended to the reverse name associated with the IP address.
· Reverse Address Lookup allows any DV method for domains in 3.2.2.4 to be applied for validation of the domain listed in the IP address’s PTR records. Thus, it inherits the attack surface of the superset of all domain DV methods; its effective security is tied to the weakest domain validation method still permitted.
o The previous method allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
o This included (previously) weaker WHOIS, email, and phone contact-based methods (scheduled to be sunset as proposed by SC-90). This represents a broader attack surface compared to 3.2.2.5.22, which consists purely of DNS. Compromise of any of the 3.2.2.4 methods could allow an attacker to gain a misissued certificate for an IP address.
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Offers a secure replacement for a DNS-based validation method for IP addresses
o The new method limits the validation challenge to direct DNS TXT queries in the .arpa zone associated with an IP address. This focuses proof of control on the authoritative namespace for that IP, rather than relying on a generic PTR record that may be stale or repurposed for uses unrelated to validation.
o By contrast, “Reverse Address Lookup” allowed ANY of the 3.2.2.4 methods to be used to validate the IP address, introducing “crossover” attack risk by tying IP address validation to validation of an unrelated domain.
· The newly created “DNS TXT Record with Persistent Value” method (SC-088v2, to be 3.2.2.4.22) for validation of domains offers several benefits to subscribers in terms of operational ease, flexibility, and ease of automated certificate issuance. These same benefits can be brought to validation of IP addresses by placement of an Persistent DCV TXT Record within the reverse zone associated with an IP address.
o The method provides a more direct proof of certificate issuance through IP address-associated reverse zones.
o The method minimizes the need to make live record updates in reverse zones to complete validation of an IP address, which may be especially challenging due to the fact that IP address holders may not have direct access to the .arpa zone associated with their IP address.
o We confirm the feasibility of placement of non-PTR records in reverse zones, through consultation with several in-house DNS experts at Google and directly placing test records in an Unbound zonefile.
Benefits of adoption
For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
· Improves validation processes by extending an existing DV method, 3.2.2.4.22 “DNS TXT Record with Persistent Value,” to the validation of IP addresses.
o This ensures that CAs and subscribers can adopt uniform process and tooling for both domain and IP address validation via the Persistent DCV TXT value method, reducing complexity and the risk of inconsistent implementation.
· Promotes stronger validation integrity by ensuring that DV demonstrates a stronger binding to actual administrative control over an IP address, increasing the consistency of trustworthiness of issued certificates.
o Reverse DNS zones (in-addr.arpa and ip6.arpa) are delegated by RIRs and LIRs in accordance with IP address block allocations. This makes the reverse namespace the authoritative DNS context for demonstrating control of IP addresses.
o Direct DNS assertion through IP address-associated reverse zones is a stronger proof of control.
o Publishing a TXT record at a validation specific-prefix directly demonstrates administrative control of the IP resource AS WELL AS request to issue.
o Removes reliance on the correctness/freshness of PTR records and eliminates DV indirection through potentially unrelated domains.
· Improves security posture and reduces risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
o The new method replaces the current allowance in 3.2.2.5.3 to use any domain validation method in 3.2.2.4 with a single, narrowly defined DNS-based method. This strengthens security by eliminating the "weakest link" problem, as the security of 3.2.2.5.3 was inherently bound to the security of the weakest validation method in 3.2.2.4.
o Removes the possibility of “crossover” attacks introduced by tying validation of an IP address to validation of an unrelated domain in a stale PTR record.
o Limits the validation challenge to direct DNS TXT queries in the .arpa zone, minimizing the attack surface to only DNS.
· Facilitates innovation by allowing automation without live DNS updates, supporting shortened certificate lifetimes and more agile re-issuance for IP address certificate subscribers. This is especially helpful because of the administrative burden often inherent in updating .arpa zones.
o Creates opportunities for faster, more efficient certificate lifestyle management and simplification of maintenance of reverse zones.
o Brings the improvements of 3.2.2.4.22 to validation of IP addresses.
· Promote stronger validation integrity by ensuring that DCV proves a stronger, more direct binding to actual administrative control over the reverse namespace associated with an IP address.
Proposed Key Dates
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective immediately:
o Implementation of 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”)
· Effective March 15, 2027:
o Sunset of Method 3.2.2.5.3 (“Reverse Address Lookup”)
Motion
The following motion has been proposed by Gurleen Grewal of Google (Google Trust Services) and endorsed by Michael Slaughter (Amazon Trust Services) and Dimitris Zacharopoulos (HARICA).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.7.1.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 7 days)
· Start: 2025-10-23 16:00:00 UTC
· End time: 2025-11-04 16:00:00 UTC
Vote for approval (7 days)
· Start: 2025-11-05 17:40:00 UTC
· End: 2025-11-12 17:40:00 UTC
--
郭宗閔
Chunghwa Telecom votes “Yes” on SC-091.
Best regards,
Chunghwa Telecom Co., Ltd.,
Tsung-Min Kuo
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/SA1PR13MB6541F4552E89260C8746D6D7AFCFA%40SA1PR13MB6541.namprd13.prod.outlook.com.
本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.
Yoshihiko Matsuo
Yoshihiko Matsuo(JPRS)
On Wed, 5 Nov 2025 09:40:03 -0800
"'Gurleen Grewal' via Server Certificate WG (CA/B Forum)" <server...@groups.cabforum.org> wrote:
> Note: Please disregard the previous email as it had incorrect dates for the voting period. If you have?already voted, please vote again by responding to this email.
>
>
> Purpose of Ballot SC-91
> This ballot sunsets 3.2.2.5.3 (“Reverse Address Lookup”) and introduces 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”) as its replacement.?
>
>
> Background
>
>
> The “Reverse Address Lookup” method (<https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32253-reverse-address-lookup>3.2.2.5.3) has been recognized as insecure due to its reliance on PTR records and indirect validation of domains instead of IP addresses. However, DNS-based validation of IP addresses is useful for many specific client use cases (e.g., ssh frontends, DoH servers) where HTTP- or TLS-based validation is infeasible due to security concerns with opening associated ports or difficulty with serving challenges from anycasted addresses. For the replacement of “Reverse Address Lookup,” we offer another validation method, “DNS TXT Record with Persistent Value in the Reverse Namespace.” The new method is a more secure replacement of 3.2.2.5.3, allowing subscribers to validate IP addresses by DNS while mitigating the risk of “<https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/cf60cd18-
3f58-4d5f-818a-770cd6450514n%40groups.cabforum.org?utm_medium=email&utm_source=footer>crossover” attacks.?
>
> The new method addresses two primary security concerns of the “Reverse Address Lookup” method: (1) staleness of PTR records (by requiring a TXT record placed at a validation-specific prefix in the .arpa zone) (2) lack of authentication and crossover risk (by requiring an account-bound credential to be placed in the TXT record).
>
> Justification
>
> The method proves a “weak binding” between the IP address listed in the Certificate and the domain name that ultimately completes DV for the certificate to be issued.
> Stale PTR records represent a critical security risk for this validation method.?
> If an IP address’s PTR record(s) point to a domain that is no longer in use, an attacker can gain control of the free domain name, and complete validation for an IP address that they do not actually control or have administrative access to. Thus, the method may allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
> The current reverse name validation method does not require any indication of request to issue in the reverse zone itself; there is no validation-related prefix appended to the reverse name associated with the IP address.
>
>
> For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
>
> Offers a secure replacement for a DNS-based validation method for IP addresses
>
>
> The method provides a more direct proof of certificate issuance through IP address-associated reverse zones.?
> We confirm the feasibility of placement of non-PTR records in reverse zones, through consultation with several in-house DNS experts at Google and directly placing test records in an Unbound zonefile.
>
>
> Benefits of adoption
>
> For creation of 3.2.2.5.8, “DNS TXT Record with Persistent Value in the Reverse Namespace”:
>
> Improves validation processes by extending an existing DV method, 3.2.2.4.22 “DNS TXT Record with Persistent Value,” to the validation of IP addresses.
> This ensures that CAs and subscribers can adopt uniform process and tooling for both domain and IP address validation via the Persistent DCV TXT value method, reducing complexity and the risk of inconsistent implementation.
>
>
> Promotes stronger validation integrity by ensuring that DV demonstrates a stronger binding to actual administrative control over an IP address, increasing the consistency of trustworthiness of issued certificates.
> Direct DNS assertion through IP address-associated reverse zones is a stronger proof of control.?
> Removes reliance on the correctness/freshness of PTR records and eliminates DV indirection through potentially unrelated domains.
>
>
> The new method replaces the current allowance in 3.2.2.5.3 to use any domain validation method in 3.2.2.4 with a single, narrowly defined DNS-based method. This strengthens security by eliminating the "weakest link" problem, as the security of 3.2.2.5.3 was inherently bound to the security of the weakest validation method in 3.2.2.4.?
> Limits the validation challenge to direct DNS TXT queries in the .arpa zone, minimizing the attack surface to only DNS.
>
>
> Facilitates innovation by allowing automation without live DNS updates, supporting shortened certificate lifetimes and more agile re-issuance for IP address certificate subscribers. This is especially helpful because of the administrative burden often inherent in updating .arpa zones.
> Creates opportunities for faster, more efficient certificate lifestyle management and simplification of maintenance of reverse zones.
> Brings the improvements of 3.2.2.4.22 to validation of IP addresses.
>
>
> Promote stronger validation integrity by ensuring that DCV proves a stronger, more direct binding to actual administrative control over the reverse namespace associated with an IP address.
>
>
> Proposed Key Dates
> The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
>
> Effective immediately:
> Implementation of 3.2.2.5.8 (“DNS TXT Record with Persistent Value in the Reverse Namespace”)
>
>
> Effective March 15, 2027:
> Sunset of Method 3.2.2.5.3 (“Reverse Address Lookup”)
>
> Motion
>
>
> The following motion has been proposed by Gurleen Grewal of Google (Google Trust Services) and endorsed by Michael Slaughter (Amazon Trust Services) and Dimitris Zacharopoulos (HARICA).
>
>
>
> This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.7.1.
>
>
> MODIFY the Baseline Requirements as specified in the following Redline:
>
>
>
>
> ? Motion Ends ?
>
> This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
>
>
> Discussion (no less than 7 days)
> Start: 2025-10-23 16:00:00 UTC
> End time: 2025-11-04 16:00:00 UTC
>
>
> Vote for approval (7 days)
> End:?2025-11-12 17:40:00 UTC
>
> --
> 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.
Martijn Katerbarg
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting period begins: Ballot SC-91: Sunset 3.2.2.5.3 Reverse Address Lookup Validation, proposal of new DNS-based validation using Persistent DCV TXT Record for IP addresses Inbox
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.