Is anyone from authorize.net on here? You are publishing both an A and CNAME record for login.authorize.net, and the CNAME points to login.authorize.net.cdn.cloudflare.net which doesn't resolve.
Looks like this may be a cloudflare related issue; I'm just getting servfail responses across the board to my on-net resolvers from cloudflare (not using public dns services).
Sometimes I'll get two A records which do work instead of the CNAME, so login.authorize.net occasionally works if I get lucky. But the TTL is 300 seconds to that luck doesn't last too long.
Is anyone from authorize.net on here? You are publishing both an A
and CNAME record for login.authorize.net, and the CNAME points to
login.authorize.net.cdn.cloudflare.net which doesn't resolve.Looks like this may be a cloudflare related issue; I'm just getting
servfail responses across the board to my on-net resolvers from
cloudflare (not using public dns services).
Sounds more like a local problem on your end, or issues between you and
the CloudFlare facility you're being routed to.
login.authorize.net. is a CNAME, but does not have any A records itself.
login.authorize.net.cdn.cloudflare.net. points to two A records.
Sometimes I'll get two A records which do work instead of the CNAME,
so login.authorize.net occasionally works if I get lucky. But the TTL
is 300 seconds to that luck doesn't last too long.
There seems to be no issues on locations some locations across European
countries such as e.g. Denmark, Germany, Netherlands, France and
(ex-European) United Kingdom.
CloudFlare does have the *SILLY* low 300 seconds TTL on ALL RECORDS that
are proxied through them (and cannot be changed for those). Even on
proxied records that have been the same for like 7 years, and easily
could have been 86400, or even longer (although longer might be ignored
by some resolvers). 
We peer with cloudflare in LAX so the connection is relatively direct.
Example trace:
2021-04-06T10:40:52.859117-07:00 dnscache1 pdns_recursor[522]: Nameserver ns2.cloudflare.net IPs: 2400:cb00:2049:1::c629:de83(3.70ms), 198.41.222.131(8.02ms)
2021-04-06T10:40:52.859410-07:00 dnscache1 pdns_recursor[522]: login.authorize.net.cdn.cloudflare.net: Resolved 'cloudflare.net' NS ns2.cloudflare.net to: 2400:cb00:2049:1::c629:de83, 198.41.222.131
2021-04-06T10:40:52.859720-07:00 dnscache1 pdns_recursor[522]: login.authorize.net.cdn.cloudflare.net: Trying IP [2400:cb00:2049:1::c629:de83]:53, asking 'login.authorize.net.cdn.cloudflare.net|DS'
2021-04-06T10:40:52.860013-07:00 dnscache1 pdns_recursor[522]: login.authorize.net.cdn.cloudflare.net: ns2.cloudflare.net (2400:cb00:2049:1::c629:de83) returned a ServFail, trying sibling IP or NS
2021-04-06T10:40:52.860324-07:00 dnscache1 pdns_recursor[522]: login.authorize.net.cdn.cloudflare.net: Trying IP 198.41.222.131:53, asking 'login.authorize.net.cdn.cloudflare.net|DS'
2021-04-06T10:40:52.860628-07:00 dnscache1 pdns_recursor[522]: login.authorize.net.cdn.cloudflare.net: ns2.cloudflare.net (198.41.222.131) returned a ServFail, trying sibling IP or NS
What kind of local problem or network problems could cause a servfail response from the authoritative ns?
This one returns A records:
; <<>> DiG 9.10.3-P4-Debian <<>> A login.authorize.net @ns0210.secondary.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25350
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;login.authorize.net. IN A
;; ANSWER SECTION:
login.authorize.net. 300 IN A 104.18.9.127
login.authorize.net. 300 IN A 104.18.8.127
;; Query time: 15 msec
;; SERVER: 2606:4700:59::a29f:2155#53(2606:4700:59::a29f:2155)
;; WHEN: Tue Apr 06 11:57:19 PDT 2021
;; MSG SIZE rcvd: 80
What kind of local problem or network problems could cause a servfail response from the authoritative ns?
I'm beginning to think this is a DNSSEC related problem, I'll ask on the pdns-users list. I see it's asking for a DS record on login.authorize.net.cdn.cloudflare.net when the nearest one appears to be at cloudflare.net, so for some reason that's not being applied all the way down.
The probem is that your resolver is trying to prove that
login.authorize.net.cdn.cloudflare.net isn't a delegation point by
querying for its DS record(s). The Cloudflare authoritative DNS servers
return a SERVFAIL for this query, so your resolver isn't able to validate
the answer.
(I also replied on the pdns-users list)
Tony.
I do somehow take that "local problem" part back again, which also
wasn't intended exactly in the way that it was written:
->
https://dnssec-analyzer.verisignlabs.com/login.authorize.net.cdn.cloudflare.net
Is looking at login.authorize.net.cdn.cloudflare.net/DNSKEY, but failing
due to the SERVFAIL.
-> login.authorize.net.cdn.cloudflare.net | DNSViz
Seems to claim that it works just fine.
Asking login.authorize.net.cdn.cloudflare.net/DNSKEY or
login.authorize.net.cdn.cloudflare.net/DS returns SERVFAIL here too.
But I don't think you should be querying /DNSKEY or /DS, except a the
(current) delegation's root, e.g. as you say yourself, at
"cloudflare.net" in this case.
Or if "cdn.cloudflare.net" had been a sub-delegation, then at that point...
What kind of local problem or network problems could cause a servfail
response from the authoritative ns?I'm beginning to think this is a DNSSEC related problem, I'll ask on
the pdns-users list. I see it's asking for a DS record on
login.authorize.net.cdn.cloudflare.net when the nearest one appears to
be at cloudflare.net, so for some reason that's not being applied all
the way down.I do somehow take that "local problem" part back again, which also
wasn't intended exactly in the way that it was written:->
DNSSEC Analyzer - login.authorize.net.cdn.cloudflare.netIs looking at login.authorize.net.cdn.cloudflare.net/DNSKEY, but failing
due to the SERVFAIL.-> login.authorize.net.cdn.cloudflare.net | DNSViz
Seems to claim that it works just fine.
Asking login.authorize.net.cdn.cloudflare.net/DNSKEY or
login.authorize.net.cdn.cloudflare.net/DS returns SERVFAIL here too.But I don't think you should be querying /DNSKEY or /DS, except a the
(current) delegation's root, e.g. as you say yourself, at
"cloudflare.net" in this case.
It shouldn’t matter if you query for them. If the records don’t exist then
you should get back NOERROR/NODATA responses with NSEC/NSEC3 records to prove
those responses.
Note the server claims that TXT records exist at login.authorize.net.cdn.cloudflare.net
but can’t return them.
% dig login.authorize.net.cdn.cloudflare.net type65 @198.41.222.31 +dnssec
; <<>> DiG 9.15.4 <<>> login.authorize.net.cdn.cloudflare.net type65 @198.41.222.31 +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1641
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;login.authorize.net.cdn.cloudflare.net. IN TYPE65
;; AUTHORITY SECTION:
cloudflare.net. 5 IN SOA ns1.cloudflare.net. dns.cloudflare.com. 1617743605 10000 2400 604800 5
login.authorize.net.cdn.cloudflare.net. 5 IN NSEC \000.login.authorize.net.cdn.cloudflare.net. A HINFO MX TXT AAAA LOC SRV NAPTR CERT SSHFP RRSIG NSEC TLSA SMIMEA HIP OPENPGPKEY TYPE64 SPF URI CAA
cloudflare.net. 5 IN RRSIG SOA 13 2 5 20210407221325 20210405201325 34505 cloudflare.net. BfBNcB9zG3T6d7mu5okde144g0OlxBazynPBD78o/ig5y0JHWo+L2ufu mhSfOquAkq6lqa/V+3yySMERlQKcIQ==
login.authorize.net.cdn.cloudflare.net. 5 IN RRSIG NSEC 13 6 5 20210407221325 20210405201325 34505 cloudflare.net. +shgKZcdkQZvH9ZFEZvdXyHe7+FkX1mCit9xe4V7A+uEEYi3L7vnf16x Wyvzs0o4TlQiOJlYBG4vEkKE3d8NwQ==
;; Query time: 17 msec
;; SERVER: 198.41.222.31#53(198.41.222.31)
;; WHEN: Wed Apr 07 07:13:25 AEST 2021
;; MSG SIZE rcvd: 417
%
% dig login.authorize.net.cdn.cloudflare.net txt @198.41.222.31 +dnssec
; <<>> DiG 9.15.4 <<>> login.authorize.net.cdn.cloudflare.net txt @198.41.222.31 +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46557
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;login.authorize.net.cdn.cloudflare.net. IN TXT
;; Query time: 15 msec
;; SERVER: 198.41.222.31#53(198.41.222.31)
;; WHEN: Wed Apr 07 07:14:22 AEST 2021
;; MSG SIZE rcvd: 67
%
For the thread – we’re aware and looking into this. noc@cloudflare.com being the best place to report these kinds of things.
Seth Mattinen <sethm@rollernet.us> writes:
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
Interesting enough the serial number is consistent though:
bjorn@miraculix:~ for s in (dig +short ns authorize.net|sort); do echo -n "$s: ";dig +short soa authorize.net @$s; done
a10-64.akam.net.: ns1.dnsvisa.com. premiumdns.support.neustar. 2019103361 600 300 1209600 300
a1-190.akam.net.: ns1.dnsvisa.com. premiumdns.support.neustar. 2019103361 600 300 1209600 300
a2-65.akam.net.: ns1.dnsvisa.com. premiumdns.support.neustar. 2019103361 600 300 1209600 300
a9-64.akam.net.: ns1.dnsvisa.com. premiumdns.support.neustar. 2019103361 600 300 1209600 300
ns0090.secondary.cloudflare.com.: ns1.dnsvisa.com. premiumdns.support.neustar. 2019103361 600 300 1209600 300
ns0210.secondary.cloudflare.com.: ns1.dnsvisa.com. premiumdns.support.neustar. 2019103361 600 300 1209600 300
I wish I could say that this is surprising....
Bjørn
Bjørn Mork <bjorn@mork.no> writes:
Seth Mattinen <sethm@rollernet.us> writes:
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..
Bjørn
Bjørn Mork <bjorn@mork.no> writes:
Seth Mattinen <sethm@rollernet.us> writes:
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.127Doh! 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
Mark Andrews <marka@isc.org> writes:
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.
Right. Thanks. I confused myself multiple times here 
The issue seems to be that the cloudflare servers takes a shortcut and
convert the CNAME to A, dropping the intermediate CNAME. That's
obviously not OK.
So it looks correct when you do:
bjorn@miraculix:/tmp$ dig CNAME login.authorize.net @ns0210.secondary.cloudflare.com
; <<>> DiG 9.16.13-Debian <<>> CNAME login.authorize.net @ns0210.secondary.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52372
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;login.authorize.net. IN CNAME
;; ANSWER SECTION:
login.authorize.net. 300 IN CNAME login.authorize.net.cdn.cloudflare.net.
;; Query time: 28 msec
;; SERVER: 162.159.33.85#53(162.159.33.85)
;; WHEN: Wed Apr 07 10:01:23 CEST 2021
;; MSG SIZE rcvd: 97
bjorn@miraculix:/tmp$ dig A login.authorize.net.cdn.cloudflare.net @ns0210.secondary.cloudflare.com
; <<>> DiG 9.16.13-Debian <<>> A login.authorize.net.cdn.cloudflare.net @ns0210.secondary.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54740
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;login.authorize.net.cdn.cloudflare.net. IN A
;; ANSWER SECTION:
login.authorize.net.cdn.cloudflare.net. 300 IN A 104.18.8.127
login.authorize.net.cdn.cloudflare.net. 300 IN A 104.18.9.127
;; Query time: 28 msec
;; SERVER: 162.159.33.85#53(162.159.33.85)
;; WHEN: Wed Apr 07 10:01:41 CEST 2021
;; MSG SIZE rcvd: 99
But not when you query for A directly:
bjorn@miraculix:/tmp$ dig A login.authorize.net @ns0210.secondary.cloudflare.com
; <<>> DiG 9.16.13-Debian <<>> A login.authorize.net @ns0210.secondary.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26197
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;login.authorize.net. IN A
;; ANSWER SECTION:
login.authorize.net. 300 IN A 104.18.9.127
login.authorize.net. 300 IN A 104.18.8.127
;; Query time: 24 msec
;; SERVER: 162.159.33.85#53(162.159.33.85)
;; WHEN: Wed Apr 07 10:02:25 CEST 2021
;; MSG SIZE rcvd: 80
So a Cloudflare bug.
Bjørn