Join Log in
Score:0
avatar Server

weird DNS resolving issue

cn flag
Slav

I'm having super weird domain / DNS resolving issue. My domain is spidersoft.com.au - it's registered via AWS - DNS servers are also hosted on AWS.

It's not a fresh domain - I'm using it for couple years now, but recently I had some problems with resolving domain name.

when I do dig spidersoft.com.au based on my internet provider or VPN I'm able to get correct response, buy none of big players doesn't give me correct results. dig spidersoft.com.au @1.1.1.1 or dig spidersoft.com.au @8.8.8.8

https://cachecheck.opendns.com gives me SERVFAIL ?

Could anyone paint me to the right direction ? Where is the issue ?

38
1 + 1
Patrick Mevzek avatar
cn flag
Patrick Mevzek
The problem is clear on https://dnsviz.net/d/spidersoft.com.au/YSS2uA/dnssec/ (most of the times when DNSViz shows RED it means your DNS configuration is broken somehow). DNSSEC is broken on your domain. You have 3 DS but no matching DNSKEY records in your zone. You either changed the key and forgot to update the DS or just did not upload the correct DS to registry. Reach out to your DNS provider for help fixing things, and your registrar through which you upload DS keys. You might need to first go back to no DNSSEC at all, and then fix it.
0
Reply
Score:1
avatar Server
cn flag
Håkan Lindqvist

The delegation specifies that the zone is supposed to be signed, as per:

spidersoft.com.au.      900     IN      DS      53542 8 1 410D8843D8EE59CC30F788EC2581BDDE09CF3BD9
spidersoft.com.au.      900     IN      DS      2371 13 2 15D49FF575EAE3467EE343069296BC78B942F5A8806160893DED476E CB9E8B75
spidersoft.com.au.      900     IN      DS      10717 8 1 EFD0A37F5128E60444AEA34C2974309B607488B3

It's a little bit strange with these multiple DS records for different keys, but disregarding that...

$ dig @ns-1851.awsdns-39.co.uk spidersoft.com.au DNSKEY +dnssec +norec

; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> @ns-1851.awsdns-39.co.uk spidersoft.com.au DNSKEY +dnssec +norec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49231
;; flags: qr aa ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;spidersoft.com.au.             IN      DNSKEY

;; AUTHORITY SECTION:
spidersoft.com.au.      900     IN      SOA     ns-1851.awsdns-39.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 22 msec
;; SERVER: 2600:9000:5307:3b00::1#53(2600:9000:5307:3b00::1)
;; WHEN: Tue Aug 24 10:08:48 CEST 2021
;; MSG SIZE  rcvd: 133

$

...there are no keys at all.

You need to either sign the zone and publish the corresponding DS or remove the DS if the zone is actually intended to be unsigned. The DS records are managed through your registrar (if this is all with Route53, this effectively means the "domain registration part of the interface", as opposed to the the "DNS hosting part of the interface").

See the Route53 documentation for the specifics of signing a zone hosted with their service.

0 + 9
cn flag
Slav
"You can't add keys to this domain because Route 53 doesn't support DNSSEC for the .com.au TLD." how to remove parent DS records ? I moved domain from the another registrar - so maybe they left some breadcrumbs which are messing my domain ?
0
Reply
cn flag
Håkan Lindqvist
@Slav It is very likely something left behind from before. If there is no option for managing `DS` for your registered domain in the Route53 interface, you'll have to contact the AWS Support, I believe.
0
Reply
cn flag
Håkan Lindqvist
@Slav (Or as a very messy workaround, transfer the domain to some registrar that will let you manage `DS`)
0
Reply
Patrick Mevzek avatar
cn flag
Patrick Mevzek
"It's a little bit strange with these multiple DS records for different keys, but disregarding that..." Routinely happens, for multiple digest algorithms or key rotations
0
Reply
cn flag
Håkan Lindqvist
@PatrickMevzek What I find a little strange is having `DS` records for three different keys, as is shown above. But maybe I should rephrase if what I wrote reads as "there should never be multiple `DS`".
0
Reply
Patrick Mevzek avatar
cn flag
Patrick Mevzek
Still not sure to understand the sentence, sorry. Look at `icann.org`, there are 3 DS too (for 2 keys plus one not published per "standard" practice of backup key)
0
Reply
cn flag
Håkan Lindqvist
@PatrickMevzek To be clear, I'm not saying that you are wrong. The sentence rather reflects my impression that it seems likely that it's mess resulting from not really managing the `DS` records, when there are two algorithm 8 keys (digest algorithm 1), one algorithm 13 key (digest algorithm 2), and in a context where all actual keys are missing too. It could of course be that it was all done according to plan and either a simultaneous key rotation and algorithm rollover or inconsistent policies for backup keys or whatnot (and inconsistent policy for digest algorithm usage as well).
0
Reply
Patrick Mevzek avatar
cn flag
Patrick Mevzek
I am not saying you are wrong either :-) Here, clearly, there is a DNSSEC misconfiguration, so the 3 DS look wrong, but I wanted to make sure that readers stumbling upon this do not draw the conclusion that 3 DS is always and obviously wrong. It is wrong here because no associated DNSKEY, but in other situations, if the configuration is right, having 3 DS can be a completely legit case (permanently or temporarily).
0
Reply
cn flag
Slav
In general issue was related with moving registrars - I moved from some "local" registrar to AWS. "local" registrar didn't cleaned up DNSEC records and AWS doesn't allow to setup DNSSEC with .com.au extensions. Currently I moved back to "local" registrar - removed DNSSEC at all and everything works as expected. I just needed to be pointer to the right direction.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.