1.1.1.1 not resolving SP.EDU.SG

FYI sp.edu.sg belongs to a Polytechnic institute under Singapore government education ministry.

Previously was able to contact a Cloudflare tech to resolve it but the problem appears to be back again.

> dig @1.1.1.1 sp.edu.sg

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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;sp.edu.sg.                     IN      A

;; Query time: 102 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Jan 30 12:31:52 MPST 2019
;; MSG SIZE  rcvd: 38




> dig @8.8.8.8 sp.edu.sg

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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;sp.edu.sg.                     IN      A

;; ANSWER SECTION:
sp.edu.sg.              3599    IN      A       35.201.83.130

;; Query time: 10 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jan 30 12:32:01 MPST 2019
;; MSG SIZE  rcvd: 54

Please see Unable to resolve domain with DNSSEC

I’m not using DNSSEC, just regular DNS lookup with Windows clients set to use 1.1.1.1.

Other well known public resolvers don’t seem to have a issue with sp.edu.sg. Cloudflare also seems fine with other edu.sg domains.

nslookup show this:

> nslookup www.sp.edu.sg 1.1.1.1
Server:         1.1.1.1
Address:        1.1.1.1#53

** server can't find www.sp.edu.sg: SERVFAIL




> nslookup www.sp.edu.sg 9.9.9.9
Server:         9.9.9.9
Address:        9.9.9.9#53

Non-authoritative answer:
www.sp.edu.sg   canonical name = da4oz2t8ub3br.cloudfront.net.
Name:   da4oz2t8ub3br.cloudfront.net
Address: 54.192.151.112
Name:   da4oz2t8ub3br.cloudfront.net
Address: 54.192.151.29
Name:   da4oz2t8ub3br.cloudfront.net
Address: 54.192.151.25
Name:   da4oz2t8ub3br.cloudfront.net
Address: 54.192.151.30
Name:   da4oz2t8ub3br.cloudfront.net
Address: 2600:9000:2003:c200:17:108c:e5c0:93a1
Name:   da4oz2t8ub3br.cloudfront.net
Address: 2600:9000:2003:0:17:108c:e5c0:93a1
Name:   da4oz2t8ub3br.cloudfront.net
Address: 2600:9000:2003:d400:17:108c:e5c0:93a1
Name:   da4oz2t8ub3br.cloudfront.net
Address: 2600:9000:2003:2000:17:108c:e5c0:93a1
Name:   da4oz2t8ub3br.cloudfront.net
Address: 2600:9000:2003:e800:17:108c:e5c0:93a1
Name:   da4oz2t8ub3br.cloudfront.net
Address: 2600:9000:2003:3000:17:108c:e5c0:93a1
Name:   da4oz2t8ub3br.cloudfront.net
Address: 2600:9000:2003:4400:17:108c:e5c0:93a1
Name:   da4oz2t8ub3br.cloudfront.net
Address: 2600:9000:2003:b800:17:108c:e5c0:93a1

1.1.1.1 is a DNSSEC-validating resolver, so if a domain has it set up then 1^4 will SERVFAIL if the DNSSEC validation fails.

As for the actual issue, that thread and the dnsviz report sums it up

sp.edu.sg zone: The server(s) were not responsive to queries over TCP.

sp.edu.sg zone: The server(s) were not responsive to queries over UDP.

Sorry if my level of DNS knowledge don’t reach DNSSEC level.

But to the end users, can we try to understand where the issue lies? Is it a problem with sp.edu.sg’s DNS servers? If yes, then why does the other public DNS servers works but 1.1.1.1 don’t?

Also the last time, the Cloudflare did something after I highlighted it on social media (can’t remember where) and he did fix it for a time. Can Cloudflare tech please review what was previously done and repeat the fix.

Yeah, it’s an issue with their nameservers. The issue is that they’re painfully slow, they don’t support EDNS(1), or both. Cloudflare doesn’t like to wait more than a few seconds (citation needed) before returning a SERVFAIL.

Chances are they cache the DNS result for huge gaps of time to mitigate the issue of the slow-responding server, or they have “compatibility mode” for those domains so that they don’t get complaints about the domains not working.

Cloudflare sticks pretty heavily to the standards (without EDNS client subnet), validates DNSSEC, and generally doesn’t deviate or add in compatibility modules to make sure domains work, even when it’s highly requested to get them working.

By design and configuration, different DNS implementations have different limits for how large UDP responses can be before they will use TCP.

Since sp.edu.sg currently has 1748 byte DNSKEY responses, and broken TCP, validating resolvers with smaller maximum EDNS buffer sizes (like 1.1.1.1 and some 9.9.9.9 instances) fail while resolvers with larger sizes (like 8.8.8.8 and some 9.9.9.9 instances) succeed.

If you send a few queries for stuff under sp.edu.sg to 9.9.9.9, some of them should fail.

They probably “fixed” it by disabling DNSSEC for the zone.

They might have automatically reenabled it, since permanently disabling security features to work around what are often temporary issues is a bad idea.

2 Likes

Seeing EDNS and DNSSEC mentioned here. Does these issues in any way affect security?

Security being apparently the reason why Cloudflare 1.1.1.1 is strict with the standards or specs, thereby having issues with these domains?

So by not compromising with so-called compatibility mode, 1.1.1.1 is protecting users from misconfigured or security compromised DNS servers serving SP.EDU.SG?

Trying to understand this from a less technical point of view.

Yes and no.

The issue is simply that sp.edu.sg's nameservers do not work right: they don’t support TCP.

That doesn’t directly have anything to do with security or DNSSEC. It’s just wrong.

DNS usually uses UDP. TCP is primarily used for big responses, and big responses mostly involve DNSSEC.

The maximum UDP response size resolvers will accept is a technical decision that partly considers security. (But I’m pretty sure most resolvers chose their current setting for non-security reasons.)

Edit: They have other bugs, but the TCP thing is the main reason 1.1.1.1 can’t resolve them.

1 Like