Can't resolve blog.solori.net (over https), but it works on other servers


#1

Cloudflare DNS (over https):

$ curl 'https://cloudflare-dns.com/dns-query?ct=application/dns-json&name=blog.solori.net&type=A'
{"Status": 2,"TC": false,"RD": true, "RA": true, "AD": false,"CD": false,"Question":[{"name": "blog.solori.net.", "type": 1}]}

Google DNS (over https):

$ curl 'https://dns.google.com/resolve?name=blog.solori.net'
{"Status": 0,"TC": false,"RD": true,"RA": true,"AD": false,"CD": false,"Question":[ {"name": "blog.solori.net.","type": 1}],"Answer":[ {"name": "blog.solori.net.","type": 5,"TTL": 3599,"data": "solori.wordpress.com."},{"name": "solori.wordpress.com.","type": 5,"TTL": 14399,"data": "lb.wordpress.com."},{"name": "lb.wordpress.com.","type": 1,"TTL": 299,"data": "192.0.78.12"},{"name": "lb.wordpress.com.","type": 1,"TTL": 299,"data": "192.0.78.13"}],"Comment": "Response from 2620:115:c00f::c000:4b09."}

#2

Still doesn’t work. Any ideas?


#3

It seems like 1.1.1.1 can’t get the address to the name server while 8.8.8.8 can. It seems also that only Google gets that IP to the name servers, 9.9.9.9 fails as well. You should check the glue records.

Asking @cscharff for help on the backend, though!


#4

Disclaimer this was literally the first time I’ve played with the API and I often have trouble spelling DNS… blog.solori.net is a CNAME record so

curl 'https://cloudflare-dns.com/dns-query?ct=application/dns-json&name=blog.solori.net&type=CNAME'

returns the CNAME value it points to and not specifying the record type returns the full DNS response I think you were expecting.

'https://cloudflare-dns.com/dns-query?ct=application/dns-json&name=blog.solori.net'


#5

The Cloudflare API never gives me an answer, independently of whether I choose A or CNAME record types or whether I don’t specify the type. Note that it also fails if I try to resolve it normally (using ‘host blog.solori.net’ command), using DNS over TLS to connect to 1.1.1.1.

Please note that this hostname is not mine, I simply use it to diagnose DNS resolution issues, because it seems to fail in some DNS resolver configurations but not in others.

For example, note that http://dnsviz.net/d/blog.solori.net/dnssec/ works correctly, it doesn’t return a warning or error either.

I suspect it may have something to do with Path MTU issues (maybe on their end?), but I’m not really sure.

If I remember correctly, it didn’t use to resolve for me when I was using UDP to contact 8.8.8.8, but when I forced Unbound to use TCP to connect to 8.8.8.8 I think it solved the issue for me (though I may be misremembering), although this would indicate the issue to be on the network path from my ISP to 8.8.8.8.

However, using the Cloudflare HTTPS API (which uses TCP) rules out an issue between my ISP and 1.1.1.1, so it would probably be an issue between 1.1.1.1 and the blog.solori.net DNS nameservers.


#6

Would you mind running dig @1.1.1.1 id.server CH TXT and sharing the output please? It’s resolving for me so I want to pass along to the network team to see if they can examine responses at your POP.


#7
$ dig @1.1.1.1 id.server CH TXT

; <<>> DiG 9.11.2-P1 <<>> @1.1.1.1 id.server CH TXT
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63486
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1536
;; QUESTION SECTION:
;id.server.			CH	TXT

;; ANSWER SECTION:
id.server.		0	CH	TXT	"mad01"

;; Query time: 3 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Apr 05 20:30:36 CEST 2018
;; MSG SIZE  rcvd: 56

#8

I’ve logged an issue with our internal teams. Thanks!


#9

Would you mind also doing a dig @1.1.1.1 for blog.solori.net and posting that here as well? TIA.


#10
$ dig @1.1.1.1 blog.solori.net

; <<>> DiG 9.11.2-P1 <<>> @1.1.1.1 blog.solori.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24646
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1536
;; QUESTION SECTION:
;blog.solori.net.		IN	A

;; Query time: 3005 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Apr 06 22:10:05 CEST 2018
;; MSG SIZE  rcvd: 44

#11

Hi, it fails to resolve in several PoPs (in Europe) because it seems like we can’t reach the authoritative NSs from a couple places. We’ll try to find out whether it’s blocked intentionally or misconfigured.


#12

$ dig NS blog.solori.net @8.8.8.8

; <<>> DiG 9.12.1 <<>> NS blog.solori.net @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63497
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;blog.solori.net. IN NS

;; ANSWER SECTION:
blog.solori.net. 3599 IN CNAME solori.wordpress.com.
solori.wordpress.com. 14399 IN CNAME lb.wordpress.com.

;; AUTHORITY SECTION:
wordpress.com. 56 IN SOA ns1.wordpress.com. mmmmmm.gmail.com. 2005071858 14400 7200 604800 60

i’ve never seen anything like this…
the NS points to a CNAME?


#13

No. The domains are set up so that solori.net. and wordpress.com. are zones, but blog.solori.net., solori.wordpress.com. and lb.wordpress.com. are not separate zones, so they don’t have separate NS records.

You can use “dig NS solori.net” or “dig NS wordpress.com” to see the zones’ NS records.


#14

I don’t think it really does, the zone break is at solori.net, blog.solori.net is just a regular CNAME under solori.net. You can ask for any type of record you want from a label which is a CNAME, you’ll get the CNAME back (and only by following the CNAME will you learn what records actually exist). But unless anything tries to use blog.solori.net in an NS record, everything is fine.

The only real issue I see is that the two nameservers are pointing to the same IP, while the RFCs require separate servers, ideally in unique AS. But this is really just a single point of failure and might cause outages, but otherwise no big deal:

;; ADDITIONAL SECTION:
ns1.solori.net. 14400 IN A 99.8.196.243
ns2.solori.net. 3600 IN A 99.8.196.243

The TTLs are an odd choice, but modern resolvers should handle it without difficulty.

(And this single point of failure could easily be what caused the underlying problem here, anything from a routing issue to a firewall/misconfiguration on the authoritative NS)


#15

Looks like their DNS server has all kinds of availability problems from multiple points on the internet, exacerbated by the fact that both nameservers point to the same IP providing no redundancy/ alternatives.

If you know the zone owner you might suggest they look to add a true secondary DNS server or move to a service with better availability.

Not sure there is really anything we can do here.