Question
Is it valid for a subdomain to use different nameservers to the parent domain without the parent domain's DNS servers providing NS records for the subdomain?
For example:
- Running
Resolve-DnsName -Name example.com -Type NS -Server 1.1.1.1
returnsns1.example.com
; sons1.example.com
is the authoritative name server forexample.com
. - Running
Resolve-DnsName -Name subdomain.example.com -Type NS -Server 1.1.1.1
returnsns2.example.com
; sons2.example.com
is the authoritative name server forsubdomain.example.com
.
I would expect that ns1.example.com
would contain the NS recordset for subdomain.example.com
to tell the client "I don't manage this subdomain's NS records, for those, talk to its name servers". I.e. I'd expect Resolve-DnsName -Name subdomain.example.com -Type NS -Server ns1.example.com
to return ns2.example.com
.
Note: If the subdomain used the same NS servers as its parent, I wouldn't expect a respose to the above.
(Resolve-DnsName is just an nslookup
command, where the Name
argument is FQDN to fetch, Server
is the nameserver to query against, and Type
allows us to specify the sort of DNS Record we're after).
Is my understanding correct, or can a subdomain have different nameservers to its parent without its parent domain hosting NS records for the subdomain?
Context
We have an intermittent issue with MS Dynamics 365 for Finance and Operations where occasionally users browsing to an instance will see the below error:
The site can’t be reached
Check if there is a typo in EXAMPLE.operations.dynamics.com
If spellling is correct, try running Windows Networkk Diagnostics.
DNS_PROBE_FINISHED_NXDOMAIN
The users are using the correct URI/hostname.
Typically this issue will resolve itself after ~30 mins.
We see this for both production (EXAMPLE.operations.dynamics.com
and test (EXAMPLE.sandbox.operations.dynamics.com
).
On investigation, if I try to resolve the FQDN using our corporate DNS service it fails to resolve; confirming the browser's error; but when we resolve against a public DNS service (e.g. CloudFlare's 1.1.1.1
) things generally resolve correctly. Note: we've also seen this issue where users working remotely (not using our corporate DNS service) have the same issue / here their ISP's DNS service shows that it's failing to resolve the FQDN.
I believe the problem relates to DNS, and that CloudFlare's DNS has generally been more reliable as they cache DNS entries for longer (or since their servers are hit more often, that makes it more likely that they'll have cached entries).
Specifically, when there's an issue resolving the FQDN for our environment, I can generally resolve it against CloudFlare's DNS and against MS's authorative name servers for that subdomain (as you'd expect)... but trying to get the authorative name servers for the subdomain from the authorative name servers for their parent domain fails; e.g. see the 2 highlighted errors below:
Is this an issue with my understanding of DNS (meaning the root cause of our issues requires more investigation on our side), or is this a configuration issue with MS's implementation?
Note: I've reached ou to MS Support for the above, but the team who support Dynamics are an application support team, so were unable to assist with DNS/infrastructure related issues or to route my ticket to a team who could help.