More thinking on this, probably the best approach here is to define a
flags sub-field in the MS RR, which allows for domain indirection.
Two flags which could be used right away:
bit 1 off=value refers to a host
on=value refers to a domain
bit 2 off=use A/AAAA RRs associated with value
on=use MX RRs associated with value
Combining these flags would allow for various functions, with a minimal
amount of overhead. Some examples below.
Use the IP addresses associated with outbound.example.com as the
authorized relay servers for example.com:
[Answer Section]
example.com. MS 0 outbound.example.com.
[Additional-Data Section]
outbound.example.com. A 10.0.0.3
Use the MX RRs associated with mail.example.com as the authorized relay
servers for example.com:
[Answer Section]
example.com. MS 3 mail.example.com.
[Additional-Data Section]
mail.example.com. MX 5 mx-1.example.com.
mail.example.com. MX 5 mx-2.example.com.
mx-1.example.com. A 10.0.0.1
mx-2.example.com. A 10.0.0.2
[note that the MX RRs would not be provided in the Additional-Data section
if a query for ALL resulted in them being provided in the Answer section
of the response]
Any and all hosts in the mail.example.com domain are authorized relay
servers for example.com:
[Answer Section]
example.com. MS 1 mail.example.com.
[Additional-Data Section]
<empty>
[the PTR for the current mail session should be examined, and if it
resides within the specified domain, then it is authorized]
These could also be cumulative. EG, use the IP addresses associated with
outbound.example.com PLUS the MX RRs associated with the mail.example.com
domain as the authorized relay servers for example.com:
[Answer Section]
example.com. MS 0 outbound.example.com.
MS 3 mail.example.com.
[Additional-Data Section]
outbound.example.com. A 10.0.0.3
mail.example.com. MX 5 mx-1.example.com.
mail.example.com. MX 5 mx-2.example.com.
mx-1.example.com. A 10.0.0.1
mx-2.example.com. A 10.0.0.2
The benefit of this approach is that it allows for sender-based
customization of the interpretation (hosts vs MX lists), but minimizes the
risk of overloads. The above needs more smoothing out but I think it is
workable.
Any other flags which would be useful? Any comments on this approach?
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/