[dns-operations] Looping wildcard CNAMEs can be an obstacle for DANE, (googledomains.com-hosted example)

Viktor Dukhovni ietf-dane at dukhovni.org
Tue Apr 17 18:44:09 UTC 2018

> On Apr 17, 2018, at 2:28 PM, John Levine <johnl at taugh.com> wrote:
>> The Postfix DNS lookup glue dates back to 1997. "The past is a foreign
>> country, they do things differently there." [1]
> Ah.  There is a CNAME hack in qmail dating from 1998.  It was probably
> the same bug in some long dead version of BIND.

Makes sense.  But, for the record, looping CNAMEs in response to TLSA
queries will remain an issue for DANE-enabled Postfix even if internal
recursion is eliminated, when the nameserver returns ServFail, i.e.
is not BIND or the CNAME loop is not "direct".

So any operator that has domains with such data (often due a zone-apex
wildcard pointing to a non-existent name in the same zone) should ideally
contact the domain owner to fix the damage.

In particular:

  *.frasier.family. IN CNAME \@

breaks email delivery to that domain from DANE-enabled Postfix or Exim.

Presumably, the domain owner meant to say:

  *.frasier.family. IN CNAME frasier.family.

Not clear what interface snafu got them to insert a literal "@" as
the CNAME value.  Perhaps unlike BIND zone files where "@" refers
to $ORIGIN, some DNS interface wrote "@" verbatim into a database,
where its meaning is more literal.


More information about the dns-operations mailing list