On Sun, Sep 14, 2025 at 07:01:58PM +0200, Matus UHLAR - fantomas via
Postfix-users wrote:
> On 14.09.25 11:03, Viktor Dukhovni via Postfix-users wrote:
> > No, not a violation of DNS, rather such a rewrite is a violation of
> > RFC2321 (and its successors: 5321, 5321bis[1]) which changed the
> > semantics of CNAME-valued address domain parts from RFC821.
>
> it IS a violation of DNS at least since RFC973, which says:
>
> If a node has a CNAME RR, it should have no other RRs.
>
> further RFCs (1034, 2181) support this as well.
>
> Domain bizpro.cn violates this RFC:
>
> bizpro.cn. 3600 IN MX 10 mx1-n.global-mail.cn.
> bizpro.cn. 3600 IN MX 5 mx-n.global-mail.cn.
> bizpro.cn. 3600 IN TXT "v=spf1
> include:spf.global-mail.cn ~all"
> bizpro.cn. 86400 IN NS dns19.hichina.com.
> bizpro.cn. 86400 IN NS dns20.hichina.com.
>
> bizpro.cn. 600 IN CNAME jsdzwy233com.gotoip2.com.
>
> So, while the OPs problem is caused by sendmail processing, there's DNS
> violation as well.
I see, one of those hacky zone-apex CNAMEs. THe "NS" and "SOA" records
are required, by the customer wants to return a CNAME for any RRtypes
that that are not explicitly provisioned. This is a very fragile
configuration, since if an A/AAAA query happens first, the CNAME will be
cached, and then the MX will fail to be resolved. A bad idea all
around.
Avoiding such broken hacks is why HTTPS (and SVCB) records were
invented.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
