On 7 Apr 2021, at 17:20, Bjørn Mork <bjorn@mork.no> wrote:
Bjørn Mork <bjorn@mork.no> writes:
Seth Mattinen <sethm@rollernet.us> writes:
On 4/6/21 11:35 AM, Arne Jensen wrote:
login.authorize.net. is a CNAME, but does not have any A records itself.
This one returns A records:
Looks like they host DNS on both cloudflare and akami, but zone contents are different on the two platforms:
bjorn@miraculix:~$ for s in $(dig +short ns authorize.net|sort); do echo -n "$s: ";dig +short login.authorize.net @$s|xargs; done a10-64.akam.net.: login.authorize.net.cdn.cloudflare.net. a1-190.akam.net.: login.authorize.net.cdn.cloudflare.net. a2-65.akam.net.: login.authorize.net.cdn.cloudflare.net. a9-64.akam.net.: login.authorize.net.cdn.cloudflare.net. ns0090.secondary.cloudflare.com.: 104.18.8.127 104.18.9.127 ns0210.secondary.cloudflare.com.: 104.18.9.127 104.18.8.127
Doh! I should know better. Sorry, ignore that. Don't ask for A records if you want to see CNAMEs..
It shouldn’t matter. Only non-rfc-compliant servers allow A and CNAME to co-exist at the same name. That combination was prohibited by RFC 1034. "The domain system provides such a feature using the canonical name (CNAME) RR. A CNAME RR identifies its owner name as an alias, and specifies the corresponding canonical name in the RDATA section of the RR. If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types.” Returning a signed CNAME is cryptographic proof that an A record does not exist at the name with DNSSEC. Mark
Bjørn
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org