dig postdonbass.com @1.1.1.1
;; ANSWER SECTION:
postdonbass.com. 3523 IN A 172.22.127.127 - WRONG !!!
Why ???
dig postdonbass.com @1.1.1.1
;; ANSWER SECTION:
postdonbass.com. 3523 IN A 172.22.127.127 - WRONG !!!
Why ???
Resolves for me to an 87 address.
What does
dig postdonbass.com @1.0.0.1
return?
Are you on Unix or Windows?
the same:
;; ANSWER SECTION:
postdonbass.com. 3600 IN A 172.22.127.127
on unix and soho routers (tplink, dlink, asus,… etc)
nslookup on windows gets the same result.
real ip of postdonbass.com - 87.226.218.132
google-dns resolv correct.
All right, next step.
Whats the output of
curl -v 'https://1.1.1.1/dns-query?ct=application/dns-json&name=postdonbass.com'
~$ curl -v ‘https://1.1.1.1/dns-query?ct=application/dns-json&name=postdonbass.com’
- Trying 1.1.1.1…
- Connected to 1.1.1.1 (1.1.1.1) port 443 (#0)
- found 148 certificates in /etc/ssl/certs/ca-certificates.crt
- found 592 certificates in /etc/ssl/certs
- ALPN, offering http/1.1
- SSL connection using TLS1.2 / ECDHE_ECDSA_AES_128_GCM_SHA256
server certificate verification OK
server certificate status verification SKIPPED
common name: Cloudflare-dns.com (matched)
server certificate expiration date OK
server certificate activation date OK
certificate public key: EC
certificate version: #3
subject: C=US,ST=California,L=San Francisco,O=Cloudflare\, Inc.,CN=Cloudflare-dns.com
start date: Mon, 28 Jan 2019 00:00:00 GMT
expire date: Mon, 01 Feb 2021 12:00:00 GMT
issuer: C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA
compression: NULL
- ALPN, server accepted to use http/1.1
GET /dns-query?ct=application/dns-json&name=postdonbass.com HTTP/1.1
Host: 1.1.1.1
User-Agent: curl/7.47.0
Accept: /< HTTP/1.1 200 OK
< Date: Thu, 02 May 2019 16:09:52 GMT
< Content-Type: application/dns-json
< Content-Length: 216
< Connection: keep-alive
< Access-Control-Allow-Origin: *
< cache-control: max-age=3053
< Expect-CT: max-age=604800, report-uri=“https://report-uri.Cloudflare.com/cdn-cgi/beacon/expect-ct”
< Server: Cloudflare
< CF-RAY: 4d0b43149b198e23-DME
<
- Connection #0 to host 1.1.1.1 left intact
{“Status”: 0,“TC”: false,“RD”: true, “RA”: true, “AD”: false,“CD”: false,“Question”:[{“name”: “postdonbass.com.”, " type": 1}],“Answer”:[{“name”: “postdonbass.com.”, “type”: 1, “TTL”: 3053, “data”: “172.22.127.127”}]}
So we can rule out that somebody hijacked 1.1.1.1.
It really seems as if Cloudflare returned an incorrect address. I’d open a support ticket at this point.
Also, tagging @cloonan
how to do it ???
i’m about “open a support ticket” (never did it before)…
Not found? You sent an email to the address above (including the domain of course) and got an error?
Well, I omitted the full address on purpose, but anyhow.
Yes, their [email protected]
address will most likely go to that domain
BIG snx
ha-ha-ha… they answer…
We’ve detected your ticket may be related to Cloudflare Resolver.
With Cloudflare Resolver, we’re fixing the foundation of the Internet by building a faster, privacy-centric, and more secure DNS resolver. The resolver,
1.1.1.1
, is available publicly for everyone to use.In order to provide the best possible support to our customer base, please direct any Cloudflare Resolver questions or feedback to our community forum.
Was that just an autoresponder or is the ticket actually closed?
status - open.
I will wait. maybe that will answer efficient …
Post the ticket number here so that @cloonan can keep track too.
Considering I can resolve the right IP address on 1.1.1.1 it would seem as if it could be specific to Cloudflare’s Moscow PoP.
Yes, please do post ticket number. Also, please reply back to the email you received with a link to this thread and a link to the report from http://dnsviz.net for the affected domain.
ticket #1681001
Thank you for contacting Cloudflare Support. I am sorry to hear that you are experiencing some difficulties here.
It looks like we are now resolving correctly:
❯ dig postdonbass.com @1.1.1.1 +short
87.226.218.132I suspect this was due to older records being cached. Did you change the record recently? If this was the case, you can tell us to purge the records via this web interface: https://1.1.1.1/purge-cache/
We will mark this as solved for the time being. Please let us know if you have any further questions or issues by replying to this e-mail or ticket to have it automatically reopened.
The ticket claims it is working now. Is it for you?