Score:0

Any idea why a domain hosted in Azure would result in Windows DNS (caching resolver) failing all look ups?

ar flag

We suddenly, as of last week, are experiencing problems resolving a FQDN (syrex.quosalsell.com) in our corporate network. The Windows servers last had updates installed on them after patch Tuesday in January so no changes there.

Looks to me that Azure is doing something wrong, as another near identical domain hosted elsewhere works perfectly. I however can't figure out what they are doing wrong.

We don't own the domain, it's associated with a service we consume where that service provider is telling us that it's a problem in our environment. To validate we spun up a new clean unjoined Windows Server 2022, installed the DNS role and then retrieved the Trust anchor (DNSSEC validation is enabled by default since Windows Server 2016 but the trust anchor isn't automatically retrieved so it's effectively disabled until one does this).

We retrieved the trust anchor, thereby enabling DNSSEC validation, with the following command: Get-DnsServerTrustAnchor -Name .

NB: We are able to resolve the domain via Google (8.8.8.8), Cloudflare (1.1.1.1) and our own recursive DNS resolvers (BIND v9.16.37-1~deb11u1) which all have DNSSEC validation enabled. THis does not appear to be a case where there is a DS record configured but the zone isn't signed.

The nuance is the following: If we send normal 'A' queries for the domain it works as expected but when we send a query for the 'DS' record Windows Server 2022's DNS server caches the SERVFAIL response and thereafter responds with SERVFAIL to any further client queries in relation to this FQDN.

In the below examples we sent queries to the new DNS server from a client (192.168.1.77) which has forwarding configured towards Google (8.8.8.8). The problem is however not with Google as Windows DNS behaves the same when we use our own recursive resolvers (BIND running on Debian 11) or Cloudflare (1.1.1.1).

Problematic domain hosted in Azure:

2023/02/07 21:04:34 158C PACKET  00000221C36BE530 UDP Snd 8.8.8.8         e95b   Q [1001   D   NOERROR] DNSKEY (0)
2023/02/07 21:04:35 1A68 PACKET  00000221C508D0B0 UDP Rcv 8.8.8.8         e95b R Q [b081   DR  NOERROR] DNSKEY (0)
2023/02/07 21:04:36 1A68 PACKET  00000221C322E5E0 UDP Rcv 192.168.1.77    a476   Q [2001   D   NOERROR] DS     (5)syrex(10)quosalsell(3)com(0)
2023/02/07 21:04:36 1A68 PACKET  00000221C36A58A0 UDP Snd 8.8.8.8         58c3   Q [1001   D   NOERROR] DS     (5)syrex(10)quosalsell(3)com(0)
2023/02/07 21:04:36 1A68 PACKET  00000221C6CEBDC0 UDP Rcv 8.8.8.8         58c3 R Q [9081   DR  NOERROR] DS     (5)syrex(10)quosalsell(3)com(0)
2023/02/07 21:04:36 1A68 PACKET  00000221CA727910 UDP Snd 8.8.8.8         1f93   Q [1001   D   NOERROR] DS     (5)syrex(10)quosalsell(3)com(0)
2023/02/07 21:04:37 1A68 PACKET  00000221C4D61CC0 UDP Rcv 8.8.8.8         1f93 R Q [9281   DR SERVFAIL] DS     (5)syrex(10)quosalsell(3)com(0)
2023/02/07 21:04:37 1A68 PACKET  00000221C322E5E0 UDP Snd 192.168.1.77    a476 R Q [8281   DR SERVFAIL] DS     (5)syrex(10)quosalsell(3)com(0)
2023/02/07 21:04:38 1A68 PACKET  00000221C32310A0 UDP Rcv 192.168.1.77    5c95   Q [2001   D   NOERROR] NS     (5)syrex(10)quosalsell(3)com(0)
2023/02/07 21:04:38 1A68 PACKET  00000221C32310A0 UDP Snd 192.168.1.77    5c95 R Q [8281   DR SERVFAIL] NS     (5)syrex(10)quosalsell(3)com(0)
2023/02/07 21:04:39 1A68 PACKET  00000221C508D0B0 UDP Rcv 192.168.1.77    4d06   Q [2001   D   NOERROR] A      (5)syrex(10)quosalsell(3)com(0)
2023/02/07 21:04:39 1A68 PACKET  00000221C508D0B0 UDP Snd 192.168.1.77    4d06 R Q [8281   DR SERVFAIL] A      (5)syrex(10)quosalsell(3)com(0)

After a bit of searching we finally found another (non affiliated) FQDN which also makes zero use of DNSSEC where the FQDN resolves to a CNAME to another FQDN. In this case the problem doesn't occur, it only occurs on DNS zones hosted in Azure:

2023/02/07 21:50:50 1FBC PACKET  00000242ED8BBB20 UDP Snd 8.8.8.8         dd69   Q [1001   D   NOERROR] DNSKEY (0)
2023/02/07 21:50:51 17CC PACKET  00000242EE6699A0 UDP Rcv 8.8.8.8         dd69 R Q [b081   DR  NOERROR] DNSKEY (0)
2023/02/07 21:50:52 17CC PACKET  00000242ED8C9650 UDP Rcv 192.168.1.77    fa6d   Q [2001   D   NOERROR] DS     (3)www(6)rsaweb(2)co(2)za(0)
2023/02/07 21:50:52 17CC PACKET  00000242ED8B9060 UDP Snd 8.8.8.8         1f42   Q [1001   D   NOERROR] DS     (3)www(6)rsaweb(2)co(2)za(0)
2023/02/07 21:50:53 17CC PACKET  00000242EDD95D40 UDP Rcv 8.8.8.8         1f42 R Q [9081   DR  NOERROR] DS     (3)www(6)rsaweb(2)co(2)za(0)
2023/02/07 21:50:53 17CC PACKET  00000242F4D9C070 UDP Snd 8.8.8.8         d346   Q [1001   D   NOERROR] DS     (3)www(6)rsaweb(2)co(2)za(0)
2023/02/07 21:50:53 17CC PACKET  00000242F07191B0 UDP Rcv 8.8.8.8         d346 R Q [9081   DR  NOERROR] DS     (3)www(6)rsaweb(2)co(2)za(0)
2023/02/07 21:50:53 17CC PACKET  00000242F4D9C070 UDP Snd 8.8.8.8         16a2   Q [1001   D   NOERROR] DS     (6)rsaweb(2)co(2)za(0)
2023/02/07 21:50:53 17CC PACKET  00000242F0B968D0 UDP Rcv 8.8.8.8         16a2 R Q [9081   DR  NOERROR] DS     (6)rsaweb(2)co(2)za(0)
2023/02/07 21:50:53 17CC PACKET  00000242F4DB4D00 UDP Snd 8.8.8.8         37f2   Q [1001   D   NOERROR] DS     (2)co(2)za(0)
2023/02/07 21:50:53 17CC PACKET  00000242F0CA40F0 UDP Rcv 8.8.8.8         37f2 R Q [9081   DR  NOERROR] DS     (2)co(2)za(0)
2023/02/07 21:50:53 17CC PACKET  00000242F4DBFD40 UDP Snd 8.8.8.8         eaa1   Q [1001   D   NOERROR] DNSKEY (2)za(0)
2023/02/07 21:50:53 17CC PACKET  00000242EFDB2D80 UDP Rcv 8.8.8.8         eaa1 R Q [b081   DR  NOERROR] DNSKEY (2)za(0)
2023/02/07 21:50:53 17CC PACKET  00000242F4DC2950 UDP Snd 8.8.8.8         7e83   Q [1001   D   NOERROR] DS     (2)za(0)
2023/02/07 21:50:53 17CC PACKET  00000242F0923990 UDP Rcv 8.8.8.8         7e83 R Q [9081   DR  NOERROR] DS     (2)za(0)
2023/02/07 21:50:53 17CC PACKET  00000242F4DBFD40 UDP Snd 8.8.8.8         0082   Q [1001   D   NOERROR] DNSKEY (2)co(2)za(0)
2023/02/07 21:50:53 17CC PACKET  00000242F0CD58A0 UDP Rcv 8.8.8.8         0082 R Q [b081   DR  NOERROR] DNSKEY (2)co(2)za(0)
2023/02/07 21:50:53 17CC PACKET  00000242F4DB4D00 UDP Snd 8.8.8.8         d7e1   Q [1001   D   NOERROR] DS     (2)za(0)
2023/02/07 21:50:53 17CC PACKET  00000242EE4649E0 UDP Rcv 8.8.8.8         d7e1 R Q [9081   DR  NOERROR] DS     (2)za(0)
2023/02/07 21:50:53 17CC PACKET  00000242F4D9C070 UDP Snd 8.8.8.8         a2e6   Q [1001   D   NOERROR] DNSKEY (10)cloudflare(3)NET(0)
2023/02/07 21:50:54 17CC PACKET  00000242F063FDD0 UDP Rcv 8.8.8.8         a2e6 R Q [b081   DR  NOERROR] DNSKEY (10)cloudflare(3)NET(0)
2023/02/07 21:50:54 17CC PACKET  00000242F4DB4D00 UDP Snd 8.8.8.8         a3d6   Q [1001   D   NOERROR] DS     (10)cloudflare(3)NET(0)
2023/02/07 21:50:54 17CC PACKET  00000242F1137890 UDP Rcv 8.8.8.8         a3d6 R Q [b081   DR  NOERROR] DS     (10)cloudflare(3)NET(0)
2023/02/07 21:50:54 17CC PACKET  00000242F4DBFD40 UDP Snd 8.8.8.8         b3ca   Q [1001   D   NOERROR] DNSKEY (3)NET(0)
2023/02/07 21:50:54 17CC PACKET  00000242EEDE5990 UDP Rcv 8.8.8.8         b3ca R Q [b081   DR  NOERROR] DNSKEY (3)NET(0)
2023/02/07 21:50:54 17CC PACKET  00000242F4DC2950 UDP Snd 8.8.8.8         6e5e   Q [1001   D   NOERROR] DS     (3)NET(0)
2023/02/07 21:50:54 17CC PACKET  00000242F016D0C0 UDP Rcv 8.8.8.8         6e5e R Q [b081   DR  NOERROR] DS     (3)NET(0)
2023/02/07 21:50:54 17CC PACKET  00000242ED8C9650 UDP Snd 192.168.1.77    fa6d R Q [8281   DR SERVFAIL] DS     (3)www(6)rsaweb(2)co(2)za(0)
2023/02/07 21:50:56 17CC PACKET  00000242ED8CC110 UDP Rcv 192.168.1.77    1f52   Q [2001   D   NOERROR] NS     (3)www(6)rsaweb(2)co(2)za(0)
2023/02/07 21:50:56 17CC PACKET  00000242ED8C9650 UDP Snd 8.8.8.8         6d76   Q [1001   D   NOERROR] NS     (3)www(6)rsaweb(2)co(2)za(3)cdn(10)cloudflare(3)NET(0)
2023/02/07 21:50:56 17CC PACKET  00000242EE0CE070 UDP Rcv 8.8.8.8         6d76 R Q [b081   DR  NOERROR] NS     (3)www(6)rsaweb(2)co(2)za(3)cdn(10)cloudflare(3)NET(0)
2023/02/07 21:50:56 17CC PACKET  00000242ED8CC110 UDP Snd 192.168.1.77    1f52 R Q [8081   DR  NOERROR] NS     (3)www(6)rsaweb(2)co(2)za(0)
2023/02/07 21:50:58 17CC PACKET  00000242EE6699A0 UDP Rcv 192.168.1.77    f63c   Q [2001   D   NOERROR] A      (3)www(6)rsaweb(2)co(2)za(0)
2023/02/07 21:50:58 17CC PACKET  00000242ED8CC110 UDP Snd 8.8.8.8         ded8   Q [1001   D   NOERROR] A      (3)www(6)rsaweb(2)co(2)za(3)cdn(10)cloudflare(3)NET(0)
2023/02/07 21:50:58 17CC PACKET  00000242EED2A9E0 UDP Rcv 8.8.8.8         ded8 R Q [9081   DR  NOERROR] A      (3)www(6)rsaweb(2)co(2)za(3)cdn(10)cloudflare(3)NET(0)
2023/02/07 21:50:58 17CC PACKET  00000242EE6699A0 UDP Snd 192.168.1.77    f63c R Q [8081   DR  NOERROR] A      (3)www(6)rsaweb(2)co(2)za(0)
David Herselman avatar
ar flag
What I find interesting is that www.microsoft.com is also hosted in Azure DNS and does not behave the same way. I additionally reviewed additional error information when attempting to resolve the FQDNs via Cloudflare's recursive resolver. NB: Yes, none of these domains are DNSSEC signed, that's not the issue. The problem is that Azure DNS is responding with a SERVFAIL when querying some domains and not others.
David Herselman avatar
ar flag
[davidh@linux-test ~]$ dig @1.1.1.1 +dnssec syrex.quosalsell.com DS ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24092 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; EDE: 22 (No Reachable Authority): (at delegation quosalsell.com.) ; EDE: 23 (Network Error): ([2603:1061:0:700::9]:53 rcode=SERVFAIL for syrex.quosalsell.com DS)
David Herselman avatar
ar flag
[davidh@linux-test ~]$ dig @1.1.1.1 +dnssec www.microsoft.com DS ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ;; QUESTION SECTION: ;www.microsoft.com. IN DS ;; ANSWER SECTION: www.microsoft.com. 3600 IN CNAME www.microsoft.com-c-3.edgekey.net. www.microsoft.com-c-3.edgekey.net. 900 IN CNAME www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net. www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net. 900 IN CNAME e13678.dscb.akamaiedge.net.
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.