Please Allow "*" Wildcard...
Please Allow "*" Wildcard in our DNS TXT Records as Valid Characters according to RFC4592
- Casa
- Pannello di controllo
- Forum della Comunità
- Services
- Dynamic DNS Service
- Please Allow "*" Wildcard in our DNS TXT Records as Valid Characters according to RFC4592
- Forum della Comunità
- Please Allow "*" Wildcard in our DNS TXT Records as Valid Characters according to RFC4592
Argomento: Please Allow "*" Wildcard in our DNS TXT Records as Valid Characters according to RFC4592

di DrewDynuMann69 su sabato 19 luglio 2025
To Whom It May Concern at Dynu;Please Allow "*" Wildcard Characters in DNS TXT Records as Valid Characters as shown in RFC 4592 on your DNS Servers for Customer Hosted DNS Domain Zones.According to RFC 4592, Wildcard Characters ARE valid for use in DNS TXT Records, and are successfully used by multiple DNS Providers across the Internet. This is especially true for protecting against Email Spoofing of Non-Existent Subdomains using SPF and DKIM, and even DMARC Records. Here are examples of these types of Records;DKIM TXT Record to Protect Against Spoofing of Subdomains not explicitly defined:TXT Record = *._domainkey.example.com.TXT Value = v=DKIM1; p=TTL = 00:02SPF TXT Record to Protect Against Spoofing of Subdomains not explicitly defined:TXT Record = *.example.com.TXT Value = v=spf1 -allTTL = 00:02If a Subdomain is explicitly defined, it will override these protections above and will take on the specific records' values defined for the Subdomain. But when a Subdomain is NOT explicitly defined, these "*" Wildcard Records will protect against Spoofing of NON-Existent Sub Domains, for example;AnyEmailName@NON-ExistentSubdomain.Example.Com, orExampleEmail@NOTValidSubDomain.ValidDomain.Com, orSpoofedUser@1.dynu.com (just as an example)But if DKIM and SPF are specifically defined for the following Subdomains then they will override the above protections;ValidUser@ValidSubDomain.ValidDomain.comBelow is an excerpt from RFC 4592 that shows examples of Valid TXT Records containing "*" Wildcard Characters, as well as where it is not valid to use a Wildcard;https://datatracker.ietf.org/doc/html/rfc4592IETF RFC 4592 Example DNS TXT Records:2.2.1. An Example To illustrate what is meant by existence consider this complete zone: $ORIGIN example. example. 3600 IN SOA <SOA RDATA> example. 3600 NS ns.example.com. example. 3600 NS ns.example.net. *.example. 3600 TXT "this is a wildcard" *.example. 3600 MX 10 host1.example. sub.*.example. 3600 TXT "this is not a wildcard" host1.example. 3600 A 192.0.2.1 _ssh._tcp.host1.example. 3600 SRV <SRV RDATA> _ssh._tcp.host2.example. 3600 SRV <SRV RDATA> subdel.example. 3600 NS ns.example.com. subdel.example. 3600 NS ns.example.net.(Please refer to IETF RFC 4592 link above for further explanations and examples)Please Allow "*" Wildcard Characters in DNS TXT Records as Valid Characters as shown in RFC 4592 on your DNS Servers for Customer Hosted DNS Domain Zones.
Rispondi con citazione | Segnalare
Autore | Argomento: Please Allow "*" Wildcard in our DNS TXT Records as Valid Characters according to RFC4592 |
---|---|
DrewDynuMann69 Iscritto: 23/05/2023 |
![]() sabato 19 luglio 2025 15:27
To Whom It May Concern at Dynu;Please Allow "*" Wildcard Characters in DNS TXT Records as Valid Characters as shown in RFC 4592 on your DNS Servers for Customer Hosted DNS Domain Zones.According to RFC 4592, Wildcard Characters ARE valid for use in DNS TXT Records, and are successfully used by multiple DNS Providers across the Internet. This is especially true for protecting against Email Spoofing of Non-Existent Subdomains using SPF and DKIM, and even DMARC Records. Here are examples of these types of Records;DKIM TXT Record to Protect Against Spoofing of Subdomains not explicitly defined:TXT Record = *._domainkey.example.com.TXT Value = v=DKIM1; p=TTL = 00:02SPF TXT Record to Protect Against Spoofing of Subdomains not explicitly defined:TXT Record = *.example.com.TXT Value = v=spf1 -allTTL = 00:02If a Subdomain is explicitly defined, it will override these protections above and will take on the specific records' values defined for the Subdomain. But when a Subdomain is NOT explicitly defined, these "*" Wildcard Records will protect against Spoofing of NON-Existent Sub Domains, for example;AnyEmailName@NON-ExistentSubdomain.Example.Com, orExampleEmail@NOTValidSubDomain.ValidDomain.Com, orSpoofedUser@1.dynu.com (just as an example)But if DKIM and SPF are specifically defined for the following Subdomains then they will override the above protections;ValidUser@ValidSubDomain.ValidDomain.comBelow is an excerpt from RFC 4592 that shows examples of Valid TXT Records containing "*" Wildcard Characters, as well as where it is not valid to use a Wildcard;https://datatracker.ietf.org/doc/html/rfc4592IETF RFC 4592 Example DNS TXT Records:2.2.1. An Example To illustrate what is meant by existence consider this complete zone: $ORIGIN example. example. 3600 IN SOA <SOA RDATA> example. 3600 NS ns.example.com. example. 3600 NS ns.example.net. *.example. 3600 TXT "this is a wildcard" *.example. 3600 MX 10 host1.example. sub.*.example. 3600 TXT "this is not a wildcard" host1.example. 3600 A 192.0.2.1 _ssh._tcp.host1.example. 3600 SRV <SRV RDATA> _ssh._tcp.host2.example. 3600 SRV <SRV RDATA> subdel.example. 3600 NS ns.example.com. subdel.example. 3600 NS ns.example.net.(Please refer to IETF RFC 4592 link above for further explanations and examples)Please Allow "*" Wildcard Characters in DNS TXT Records as Valid Characters as shown in RFC 4592 on your DNS Servers for Customer Hosted DNS Domain Zones.
|

domenica 20 luglio 2025 15:17