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

Gurleen Grewal

unread,

Nov 4, 2025, 11:01:47 AMNov 4

to server...@groups.cabforum.org

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:

https://github.com/cabforum/servercert/compare/b6a014d4aee244c019ef6ca41667045cdbfefb81..052a3f50923386a1a1f61e3d0da8121140e55537

— 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-23-10 16:00:00 UTC
End time: 2025-04-11 16:00:00 UTC

Vote for approval (7 days)

Start: 2025-04-11 16:00:00 UTC
End: 2025-04-18 16:00:00 UTC

Dimitris Zacharopoulos (HARICA)

unread,

Nov 4, 2025, 11:41:08 AMNov 4

to server...@groups.cabforum.org

HARICA votes "yes" to ballot SC-91

--
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/CAHidiLEPkpNonjvdgCwd1obS%3DW99WjjmSuK0TBCXz6ymR9eX%3DA%40mail.gmail.com.

Roman Fischer

unread,

Nov 5, 2025, 1:26:31 AMNov 5

to server...@groups.cabforum.org

Dear Gurleen,

I think the voting period has somehow been mangled up. Can you please check?

Thanks
Roman

From: 'Gurleen Grewal' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Dienstag, 4. November 2025 17:00
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

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:

https://github.com/cabforum/servercert/compare/b6a014d4aee244c019ef6ca41667045cdbfefb81..052a3f50923386a1a1f61e3d0da8121140e55537

— 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-23-10 16:00:00 UTC

· End time: 2025-04-11 16:00:00 UTC

Vote for approval (7 days)

· Start: 2025-04-11 16:00:00 UTC

· End: 2025-04-18 16:00:00 UTC

--

Backman, Antti

unread,

Nov 5, 2025, 7:59:55 AMNov 5

to server...@groups.cabforum.org

Telia votes ‘Yes’ on Ballot SC-91

//Antti

From: 'Gurleen Grewal' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Tuesday, 4. November 2025 at 18.01
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

Backman, Antti

unread,

Nov 5, 2025, 9:24:20 AMNov 5

to server...@groups.cabforum.org

Telia votes ‘Yes’ on Ballot SC-91

//Antti

Lähettäjä: 'Gurleen Grewal' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Lähetetty: tiistaina, marraskuuta 4, 2025 6:01 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

--
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/CAHidiLEPkpNonjvdgCwd1obS%3DW99WjjmSuK0TBCXz6ymR9eX%3DA%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.

Pedro FUENTES

unread,

Nov 5, 2025, 9:40:20 AMNov 5

to server...@groups.cabforum.org

OISTE Votes Yes to SC91

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/GVYP280MB1215C9FDE00E98B7C13EA14886C5A%40GVYP280MB1215.SWEP280.PROD.OUTLOOK.COM.

WISeKey SA

Pedro Fuentes
CSO - Trust Services Manager
Office: + 41 (0) 22 594 30 00
Mobile: + 41 (0) 791 274 790

Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland

Stay connected with WISeKey

THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks

CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender

DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.

Gurleen Grewal

unread,

Nov 5, 2025, 11:20:59 AMNov 5

to server...@groups.cabforum.org

Hi Roman,

Thank you for flagging. Yes, the voting period in the ballot is incorrect. This is because I'm perpetually confused about whether the month or the day goes first.

I'm not familiar enough with the bylaws to know if I should re-start the voting period or whether I can make a correction. Could someone familiar with the bylaws please advise on the appropriate next steps?

Thanks,

Gurleen

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/ZR0P278MB0170D183891E0461C9C32215FAC5A%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM.

Dimitris Zacharopoulos (HARICA)

unread,

Nov 5, 2025, 11:50:36 AMNov 5

to server...@groups.cabforum.org

Hi Gurleen,

Please restart the voting period with clear indication of the start and end date/time.

Those that voted will have to re-cast their votes.

Thank you,

Dimitris.

--
Dimitris Zacharopoulos
CA/B Forum SCWG Chair

Hogeun Yoo

unread,

Nov 5, 2025, 11:33:46 PMNov 5

to server...@groups.cabforum.org

NAVER Cloud Trust Services votes "YES" on SC-91

Thanks,

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. 5. (수) 01:00 (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

--
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/CAHidiLEPkpNonjvdgCwd1obS%3DW99WjjmSuK0TBCXz6ymR9eX%3DA%40mail.gmail.com.

黃晟(orca)

unread,

Nov 6, 2025, 10:49:07 PMNov 6

to server...@groups.cabforum.org

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: Wednesday, November 5, 2025 12:00 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