If your organization has rolled out RCS (Rich Communication Services) messaging on iOS or Android, your devices are now quietly making a DNS query type most network defenders have never watched before: the NAPTR record (Naming Authority Pointer). Johannes Ullrich of SANS.edu noticed a rise in these queries on his own network and traced them directly to RCS phone-to-service lookups. This matters because NAPTR sits at the seam between two systems you probably monitor separately—DNS and your messaging infrastructure. (Source: Isc)

Here is what a NAPTR record actually does in plain terms. Instead of returning an IP address like a normal DNS lookup, it returns instructions for finding a service URI. In the RCS case, a phone queries a name like fp-us-verizon.rcs.telephony.goog and gets back a record pointing to a secure SIP service.

The chain is layered on purpose:

• The NAPTR record carries a Service field of SIPS+D2T ("Secure SIP Direct to TCP"), meaning SIP over TLS using TCP transport, as defined in RFC 3263.
• Its "S" flag tells the client the next step is an SRV lookup rather than a direct URI.
• That SRV query returns the actual servers, ports (5223 and 443 in the observed traffic), and finally standard A/AAAA lookups resolve the host.

The NAPTR standard also allows something more consequential: a regular expression that rewrites a queried string into a domain name, per RFC 2915. In the RCS traffic observed, that regex field is empty, so nothing is rewritten today. But the capability is defined and available.

"a Resource Record that included a regular expression that would be used by a client program to rewrite a string into a domain name."

For business leaders, the takeaway is that RCS enablement quietly extends your attack surface into DNS-driven service discovery for encrypted messaging—infrastructure that carries employee and customer communications. Ullrich notes the regex feature will draw interest from bug hunters and penetration testers, which is the practical reason to know these records now sit in your traffic.

Attack Chain: From NAPTR Manipulation to Credential Theft and Service Hijacking

The exploitation risk in RCS resolution comes from a chain of unauthenticated DNS lookups. An RCS client on iOS or Android resolves its provisioning server by walking from a NAPTR record to an SRV record to the final A/AAAA address. Each hop trusts the answer it gets back, and none of these record types carries a cryptographic guarantee unless DNSSEC is fully deployed end to end.

Consider the resolution path Johannes Ullrich documented on his network. The client queries a NAPTR record such as fp-us-verizon.rcs.telephony.goog, which returns a service field of SIPS+D2T (Secure SIP Direct to TCP) and an s flag pointing to the next SRV lookup. That SRV query resolves to two targets with priority 20 on port 5223 and priority 30 on port 443. Whoever controls those answers controls where the phone connects for SIP session setup.

Here is how an attacker abuses that trust chain:

• Step 1 — Gain control of the answer. The attacker either poisons the resolver cache, sits on the network path as a machine-in-the-middle, or obtains write access to a DNS zone that serves the RCS provisioning domain. The empty regex field in these NAPTR records simplifies the task, but the RFC 2915 design permits a regular expression that rewrites the query string into an entirely different domain name.
• Step 2 — Redirect the SIP endpoint. By altering the SRV target or the A/AAAA answer, the attacker steers the client's SIPS+D2T connection to a server they control instead of the legitimate telephony backend.
• Step 3 — Intercept the session. Because the client is establishing a SIP-over-TLS session, the attacker's server must present a certificate the client accepts. Where certificate validation is weak or the TLS trust anchor is manipulated, the authentication exchange and any session tokens pass through the attacker's endpoint.
• Step 4 — Pivot. SIP is not unique to consumer messaging. The same NAPTR-to-SRV discovery pattern underpins enterprise SIP trunking and VoIP call routing, so a poisoned record on a corporate resolver can redirect voice traffic as well as RCS messages.

For your business, the practical exposure is this: RCS messages may be end-to-end encrypted and digitally signed, but that protection assumes the client reached the correct server in the first place. If the DNS discovery step is subverted before the TLS handshake, an attacker positioned at the redirected endpoint can attempt to capture provisioning credentials or observe session establishment.

The regex rewrite capability is the part worth watching. Ullrich flagged it directly.

"I am sure that the use of regular expressions will be of interest to bug hunters and penetration testers."

A NAPTR record that rewrites an input string into an arbitrary domain gives an attacker a flexible primitive for redirection that a plain SRV or CNAME record does not offer. Today these records ship with an empty regex, so the mechanism is dormant, but the field is defined and available.

The source does not identify a published proof-of-concept or CVE tied to RCS NAPTR abuse. The concern is structural rather than tied to a specific patchable flaw: the discovery chain relies on record types that most network teams monitor separately from their messaging infrastructure, which means a poisoned NAPTR or SRV answer can route around the encryption RCS advertises without ever touching the encrypted payload itself.

Enterprise Risk: Messaging Interception, Compliance Exposure, and Supply Chain Implications

RCS increasingly carries the messages that gate access to your systems: one-time passcodes, transaction confirmations, delivery alerts, and account recovery links. If an attacker sits in the resolution path and diverts an RCS client to a server they control, the authentication factor you assume is private is no longer private.

That breaks the core assumption behind SMS and RCS-based multi-factor authentication. A one-time code is only a second factor if the channel delivering it is trustworthy. When the delivery path can be redirected through DNS manipulation, the code becomes a shared secret an attacker can read, and your "something you have" collapses into "something the attacker also has."

For regulated industries, the consequences extend past account takeover. If you operate in finance or healthcare, customer communications are often subject to confidentiality and integrity requirements. Diverted or intercepted RCS messages containing account details, appointment information, or payment confirmations can put you on the wrong side of those obligations.

• Financial services: intercepted transaction alerts and authentication codes can enable fraudulent transfers, triggering breach notification duties and regulatory scrutiny of your customer authentication controls.
• Healthcare: RCS messages carrying patient information that are diverted to an attacker-controlled endpoint can qualify as an unauthorized disclosure of protected health data.
• Telecom carriers and messaging providers: if the failure traces to your provisioning infrastructure, you face carrier-specific regulatory exposure in addition to contractual liability to downstream customers.

The supply chain dimension is what makes this hard to bound. RCS resolution depends on infrastructure you do not run and cannot directly inspect—the carrier's provisioning servers, the DNS zones hosting records like the rcs.telephony.goog domains, and the TLS termination points behind them. A compromise at any of those third parties affects every organization whose employees and customers rely on that carrier.

It is not a new record—but in many enterprise networks it is showing up in DNS traffic for the first time, tied directly to RCS provisioning.

That means your risk is inherited. You may run tight controls internally, yet still be exposed because a telecom vendor or their DNS hosting provider is the actual point of failure. Vendor risk assessments that stop at "do they support TLS" miss this, because the interception happens before the encrypted session is ever negotiated—at the DNS lookup that decides which server your device trusts.

Reputational fallout follows the same pattern as any breach where customers learn their private messages were exposed. If your customers discover that verification codes or account notifications were diverted, the practical result is lost trust, support-desk volume, and customer churn—costs that persist after the technical issue is closed.

There is also a research-driven angle that raises the ceiling on future risk. The NAPTR record's regular-expression rewrite capability, though currently unused in the RCS records observed, is exactly the kind of feature that draws attention from bug hunters and penetration testers. As RCS adoption grows across iOS and Android, the population of enterprises quietly depending on this resolution chain grows with it, which means the business exposure scales alongside deployment.

Detection: Identifying Suspicious NAPTR Changes and Anomalous RCS Traffic

Start with your DNS logs, because NAPTR queries are the earliest observable in the RCS resolution chain and the record type least likely to appear in a legitimate baseline. If you are not already logging NAPTR (type 35) lookups at your resolvers, turn that on first. Most enterprise DNS query logging captures A and AAAA records but drops or ignores less common types, which means the NAPTR-to-SRV walk that RCS clients perform can pass through unrecorded.

Following the NIST Cybersecurity Framework, the priority here is detection over prevention. You likely do not control Google's rcs.telephony.goog zone or your carrier's authoritative nameservers, so your job is to spot when an answer looks wrong, not to lock down infrastructure you do not own.

Build an inventory of what "normal" RCS resolution looks like on your network. Capture the legitimate NAPTR service field and the SRV targets, ports, and priorities your carrier returns. In the documented example, the SRV records pointed to port 5223 (priority 20) and port 443 (priority 30) at a *.rcs.telephony.goog target. Record those values so any deviation stands out.

For detection rules, focus on these signals:

• Unexpected NAPTR responses: Alert when a NAPTR answer for an RCS-related name returns a non-empty Regex field. The observed records carried an empty regex; a populated one means the answer is rewriting the target string, which is worth investigating.
• SRV targets outside carrier space: Flag any _sips._tcp SRV response whose target resolves to an IP outside your carrier's or Google's expected address ranges. A redirect to unfamiliar hosting or residential space is the clearest sign of tampering.
• Non-standard ports: Watch for SRV answers advertising ports other than the expected 5223 and 443, or a downgrade from the SIPS+D2T secure transport to plain SIP.
• Anomalous TTLs: The legitimate records carried short TTLs (295 and 300 seconds). A response with an unusually long or short TTL can indicate cache poisoning attempts or an attacker holding a diverted answer in place.

A basic SIEM correlation is straightforward: join DNS query events where qtype = NAPTR or qtype = SRV against a name-match on *.rcs.telephony.goog, then compare the returned target and port against your baseline table. Any mismatch raises an alert. In environments Capstone manages, Adlumin correlates these DNS anomalies with authentication telemetry, so a NAPTR or SRV change that lines up with a burst of failed RCS-delivered one-time-code logins surfaces as a single investigable event rather than two unrelated signals.

Correlating failed authentication with resolution changes matters because a redirected RCS client often produces both a DNS anomaly and a downstream login failure. If users report codes that never arrive, or you see repeated MFA retries clustered in time, check whether the NAPTR or SRV answers those devices received changed in the same window.

Finally, review your DNS transaction logs for zone transfer activity against any domain that hosts RCS or SIP service records. AXFR requests to these zones from unauthorized hosts suggest an attacker mapping the record structure before attempting to spoof it. Most authoritative servers should reject AXFR from unknown clients outright, so a logged attempt is itself the alert.

Because RCS resolution walks through record types many teams have never watched, the practical win is visibility. Once NAPTR and SRV answers are logged and baselined, a diverted RCS client stops being invisible and becomes an alert you can act on.

Remediation and Hardening: DNS Security, RCS Configuration, and Verification

Start by auditing every NAPTR record published in domains you control, and confirm each one matches what your telecom or messaging provider documents. The RCS resolution chain begins here, and a NAPTR record pointing to an unexpected service field or replacement string is the first sign someone altered your provisioning path.

If you use DNS management with audit logging, review the change history for NAPTR and SRV records over the last 30 days. Confirm that any modifications trace back to a known change ticket and an authorized account. Unexplained edits to these record types deserve investigation before anything else.

Once your records are verified, tighten who can touch them. Two protective measures matter most here:

• Enable DNSSEC on any zone hosting RCS-related records so resolvers can cryptographically validate that a NAPTR or SRV answer came from the authoritative source and was not altered in transit.
• Restrict DNS update permissions to a minimal set of named accounts, and require MFA on every DNS management console and registrar login. Compromised registrar credentials let an attacker rewrite the resolution chain without ever touching your network.

Access-control gaps at the DNS management layer are an identity problem as much as a DNS problem. Adlumin monitors authentication behavior across managed environments, flagging logins to DNS and registrar accounts that fall outside normal patterns—unusual geography, off-hours access, or a first-time session from an unfamiliar device. Catching an anomalous login to the account that controls your NAPTR records is the difference between spotting a takeover attempt and discovering it after RCS traffic has already been diverted.

DNSSEC only helps if validation happens end to end. If your zone is signed but your resolvers do not enforce validation, the signatures accomplish nothing.

NAPTR, SRV, and A/AAAA records each trust the answer they receive. Without DNSSEC validation at every hop, none of them carries a guarantee that the response is authentic.

For the longer term, move toward DNSSEC-validated RCS discovery as the default rather than an exception, and confirm your recursive resolvers reject responses that fail validation. This closes the window where a forged answer in the NAPTR-to-SRV walk gets accepted as legitimate.

Work with your telecom and messaging providers to understand how they validate NAPTR responses at the carrier level. Because you do not control the provider's authoritative zone, ask what protections exist upstream and whether they sign the records your devices resolve. Providers that publish signed records give you a verification anchor you can check against.

Where your environment allows it, consider pinning RCS endpoints to the known carrier IP ranges documented by your provider. Pinning limits the value of a diverted DNS answer, because a client configured to reach only approved addresses will reject a redirection to an attacker-controlled host even if the DNS response resolves.

Document the verified NAPTR and SRV values as a baseline, and re-check them on a schedule. When a record changes, you want to know within hours whether the change came from your provider's normal operations or from someone who should not have write access to your zone.

Key Action: Audit NAPTR Records and Enable DNSSEC Immediately

The single most important action is to inventory every NAPTR record in the DNS zones you control and enable DNSSEC on those zones. NAPTR (type 35) is a record you likely never watched before RCS adoption, which means it has probably never appeared in a change-review process either.

Give yourself a 48-hour window for the audit. Pull the current NAPTR entries from your authoritative zones and compare each service field and replacement string against what your RCS or telecom provider documents. The record Johannes Ullrich decoded resolved cleanly to a SIPS+D2T service pointing at a matching _sips._tcp replacement, so you have a known-good shape to compare against.

DNSSEC matters here because the entire RCS resolution walk—from NAPTR to SRV to A/AAAA—trusts each answer without cryptographic proof of origin. Signing your zones adds that proof at the authoritative source, so a forged NAPTR or SRV answer fails validation instead of being accepted.

Two reasons this belongs at the top of your list:

• It works at the DNS layer, so you do not need to touch RCS clients on iOS or Android, negotiate changes with your carrier, or wait on Google's rcs.telephony.goog zone.
• It protects the messaging path that increasingly carries authentication codes and account-recovery links, without adding operational burden to end users.

It is not a new record type—it is simply one most defenders have never validated, signed, or reviewed.

Enabling DNSSEC on the zones you publish and confirming your NAPTR records match provider documentation is the minimum viable response. It closes the spoofing path at the layer where the resolution chain begins.