Security & Threat Intelligence · 25.07.2026, 15:29 UTC
RCS and DNS: The NAPTR Record, (Mon, Jul 6th)
| Schweregrad | info |
|---|---|
| Kategorie | Security & Threat Intelligence |
| Quelle | SANS Internet Storm Center ↗ |
| Veröffentlicht | 25.07.2026 UTC |
Sicherheitsmeldung mit Schweregrad noch nicht bewertet. Technische Details im Tab „Originaltext“; empfohlene Schritte in der Checkliste.
Over the last year, with recent updates to iOS and Android, RCS (Rich Communication Services) has become an increasingly used protocol [1]. RCS is supposed to eventually replace SMS, and in addition to richer formatting, provides added (but optional) security. RCS messages may be end-to-end encrypted and digitally signed. Unlike SMS, which was "bolted on" to existing voice-focused phone standards. The SMS standard was based on old-fashioned pagers and allowed for limited clear-text communications. RCS is built from the ground up around modern IP-based network infrastructure and behaves more like IP chat services (think iMessage, WhatsApp...). RCS defines the message format, while protocols like SIP are used to establish connections and transport messages.
"Do as you say", I do from time to time take a look at odd DNS traffic on my network. An activity I recommend when teaching SEC503. Recently, I noticed more "NAPTR" queries, a record type I had not seen before. The record type is defined in RFC 2915 [2], which was ratified in 2000. It is not a new record. But so far, at least in my network, it has not really shown up before.
The description of the record sounds rather ominous:
"a Resource Record that included a regular expression that would be used by a client program to rewrite a string into a domain name."
Wow. Regular expressions to rewrite resource records? What could possibly go wrong? However, right now, I just want to talk about how it "goes right" and how these records are currently being used for RCS.
Below is the relevant part of the t-shark decode of a …