Connect the SOA contact to an alias
05A DNS zone’s SOA record contains RNAME, a DNS-name representation of its administrator’s mailbox. A stable alias can route this mail to whichever team is responsible.
The fictional HOSTMASTER alias routes to the chosen zone-administration team. The alias recommendation is separate from its configured destination.
Key idea: HOSTMASTER is strongly recommended here, not the only permitted simple name.
Terms
- SOA
- Start of Authority: a DNS record with zone administration and timing information.
- RNAME
- The SOA field encoding the responsible person’s mailbox as a DNS name.
Rules & examples
HOSTMASTER is strongly recommended here, not the only permitted simple name.
- RFC2142§7 requires a simple mailbox word without metacharacters such as %, ! or ::, recommends an alias on the mail exchangers, and strongly recommends HOSTMASTER for regularity.
- The DNS SOA field is not written as a literal address with @. RFC1035§3.3.13 defines RNAME as a domain name specifying the responsible mailbox; §8 describes mailbox encoding. For the simple example hostmaster@picnic.example, the presentation is hostmaster.picnic.example.
- The final dot in hostmaster.picnic.example. marks an absolute DNS name in presentation notation. The field sketch omits the other SOA fields and is not a packet-width diagram.
- A different simple alias such as dns-ops can meet the word restriction. HOSTMASTER remains strongly recommended, rather than a MUST-only choice.
- Choosing another SOA word does not remove a separate HOSTMASTER service-contact requirement when the associated DNS service is offered (§§1,5).
- The configured alias can lead to an appropriate zone administrator. DNS syntax and a familiar role name do not authenticate whoever sends a message.
This bounded illustration uses simple ASCII words with no escaping and does not implement general DNS RNAME escaping or arbitrary mailbox syntax. An empty or metacharacter-containing word is rejected by the teaching helper.
Sources
New to this? Start hereA quick picture + helpful background
Address the function, then route its mail
Imagine addressing a department rather than one employee. The department label stays stable while its internal recipient can change. The destination domain and its mail exchanger still have to recognize that label; a familiar name is not proof of the sender’s identity.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.