login.authorize.net has A and CNAME records
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.
On 4/6/21 9:33 AM, Seth Mattinen wrote:
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.
Den 06-04-2021 kl. 19:50 skrev Seth Mattinen:
On 4/6/21 9:33 AM, Seth Mattinen wrote:
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). :'( -- Med venlig hilsen / Kind regards, Arne Jensen
On 4/6/21 11:35 AM, Arne Jensen wrote:
On 4/6/21 9:33 AM, Seth Mattinen wrote:
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
Den 06-04-2021 kl. 19:50 skrev Seth Mattinen: the CloudFlare facility you're being routed to.
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?
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.
Seth Mattinen <sethm@rollernet.us> wrote:
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. -- f.anthony.n.finch <dot@dotat.at> https://dotat.at/ Lyme Regis to Lands End including the Isles of Scilly: North or northwest 5 or 6, occasionally 7 at first near headlands, decreasing 2 to 4. Slight or moderate, becoming smooth in east. Showers, wintry at first. Good, occasionally moderate at first.
Den 06-04-2021 kl. 21:47 skrev Seth Mattinen:
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: -> https://dnssec-analyzer.verisignlabs.com/login.authorize.net.cdn.cloudflare.... Is looking at login.authorize.net.cdn.cloudflare.net/DNSKEY, but failing due to the SERVFAIL. -> https://dnsviz.net/d/login.authorize.net.cdn.cloudflare.net/dnssec/ 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... -- Med venlig hilsen / Kind regards, Arne Jensen
On 7 Apr 2021, at 05:59, Arne Jensen <darkdevil@darkdevil.dk> wrote:
Den 06-04-2021 kl. 21:47 skrev Seth Mattinen:
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:
-> https://dnssec-analyzer.verisignlabs.com/login.authorize.net.cdn.cloudflare....
Is looking at login.authorize.net.cdn.cloudflare.net/DNSKEY, but failing due to the SERVFAIL.
-> https://dnsviz.net/d/login.authorize.net.cdn.cloudflare.net/dnssec/
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 %
Or if "cdn.cloudflare.net" had been a sub-delegation, then at that point...
-- Med venlig hilsen / Kind regards, Arne Jensen
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
For the thread -- we're aware and looking into this. noc@cloudflare.com being the best place to report these kinds of things. <https://www.cloudflare.com/> __________________ *Justin Paine* He/Him/His Head of Trust & Safety 101 Townsend St, San Francisco, CA 94107 <https://www.cloudflare.com/> *PGP:* BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D <https://keys.openpgp.org/vks/v1/by-fingerprint/BBAA6BCE33057FD66452711557B60114DE0B314D> On Tue, Apr 6, 2021 at 2:49 PM Mark Andrews <marka@isc.org> wrote:
On 7 Apr 2021, at 05:59, Arne Jensen <darkdevil@darkdevil.dk> wrote:
Den 06-04-2021 kl. 21:47 skrev Seth Mattinen:
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:
->
https://dnssec-analyzer.verisignlabs.com/login.authorize.net.cdn.cloudflare....
Is looking at login.authorize.net.cdn.cloudflare.net/DNSKEY, but failing due to the SERVFAIL.
-> https://dnsviz.net/d/login.authorize.net.cdn.cloudflare.net/dnssec/
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
%
Or if "cdn.cloudflare.net" had been a sub-delegation, then at that point...
-- Med venlig hilsen / Kind regards, Arne Jensen
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
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: ; <<>> 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
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 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:
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.. Bjørn
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
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
participants (6)
-
Arne Jensen -
Bjørn Mork -
Justin Paine -
Mark Andrews -
Seth Mattinen -
Tony Finch