Mailing List Archive

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:
> 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.



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?

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

>
> 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.net

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.net
>
> 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.net
> >
> > 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
>
>

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