Over in DNSOP the usual arguments about CNAME and domain name variants
are being rerun. (Short summary: too many people believe that
variants can be made "the same" purely within the DNS, because they
don't understand the problem.)
One of the harder issues is application configuration. For some older
protocols like telnet, if you can resolve a name to an A or AAAA
you're done, but for interesting ones like mail and http, the server
also needs to know what domains it handles and what to do with them.
It's long been clear that any real solution to "the same" will involve
some way for application servers to configure themselves automatically
to match what the DNS expects them to handle.
So is this a new idea? Let's say your mail server gets a RCPT TO
for a domain it doesn't recognize, e.g. RCPT TO:<bob@f��.com>.
Before it rejects it, it does a DNS lookup, and let's say it
finds this CNAME:
f��.com. IN CNAME foo.com.
It treats the message as though it were to bob(_at_)foo(_dot_)com.* Poof, you
just set up the CNAMEs or DNAMEs and the mail server handles them
automagically.
I can think of a variety of reasons this would be a bad idea,
but before I start enumerating them, has someone done it before?
R's,
John
* - This is an example. I know you can't put a CNAME at the zone apex.
You can pretend it was f��.xn--kprw13d. and the CNAME was synthesized
from the DNAME.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp