Maybe:
OLD:
Any other
response, specifically including a value that will return a CNAME
record when queried, lies outside the scope of this Standard. The
prohibition on labels in the data that resolve to CNAMEs is discussed
in more detail in RFC 2181, Section 10.3 [33].
response, specifically including a value that will return a CNAME
record when queried, lies outside the scope of this Standard. The
prohibition on labels in the data that resolve to CNAMEs is discussed
in more detail in RFC 2181, Section 10.3 [33].
NEW:
An MX record with a CNAME as its target is a misconfiguration, as explained in RFC2181, Section 1.3 [33].
However, implementations SHOULD still process CNAME responses when received, since a significant number of
servers on the internet are configured with MX records pointing to CNAMEs.
--
I don't think you need to talk about other records. What this standard is saying is, you have to support A records and AAAA records, and CNAME records are a bad idea but you should support them anyway. The implementation has to do a query, and the standard proposes no other queries it might do, so there is no need to say more—if some other record shows up in the additional section, we aren't looking for it, so we don't need to say what to do with it.
On Fri, Oct 18, 2024 at 11:26 AM Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote:
On Fri, Oct 18, 2024 at 10:14:00AM +0200, Ted Lemon wrote:
> That's fair, but it seems like then it might be good to actually say
> that in the document. As an implementor I would be inclined to treat a
> CNAME here as invalid and ignore it based on the text as written.
Can you suggest text that manages to both discourage publication of
CNAME-valued MX "exchange" names, and slightly nudges implementors to
tolerate these, based on today ~1% of domains being in violation of this
advice.
[ I consider 1% too large a fraction to ignore, but if others feel that
this is low enough to proceed to punish them for their negligence,
perhaps MUST is how that 1% could over time (O(decade or two)) be
brought closer to zero. ]
Examples:
0. idaho.gov. IN MX 10 inbound.idaho.gov.
;
inbound.idaho.gov. IN CNAME us-smtp-inbound-1.mimecast.com.
us-smtp-inbound-1.mimecast.com. IN A 170.10.128.141
us-smtp-inbound-1.mimecast.com. IN A 170.10.128.221
us-smtp-inbound-1.mimecast.com. IN A 170.10.128.242
us-smtp-inbound-1.mimecast.com. IN A 205.139.110.141
us-smtp-inbound-1.mimecast.com. IN A 205.139.110.221
us-smtp-inbound-1.mimecast.com. IN A 205.139.110.242
1. gmt.io. IN MX 10 mail.gmt.io.
;
mail.gmt.io. IN CNAME mail.hetzner.gmt.io.
mail.hetzner.gmt.io. IN A 135.181.193.235
2. mijnenergie.be. IN MX 1 mijnenergie-be.mail.protection.outlook.com.
mijnenergie.be. IN MX 5 mail.mijnenergie.be.
mijnenergie.be. IN MX 10 backupmail.mijnenergie.be.
;
mail.mijnenergie.be. IN CNAME pop3.mailprotect.be.
pop3.mailprotect.be. IN CNAME pop.mailprotect.be.
pop.mailprotect.be. IN CNAME smtp.mailprotect.be.
smtp.mailprotect.be. IN A 178.208.39.146
smtp.mailprotect.be. IN A 178.208.39.149
smtp.mailprotect.be. IN A 178.208.39.154
smtp.mailprotect.be. IN A 178.208.39.157
smtp.mailprotect.be. IN A 178.208.39.158
--
Viktor.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
