Home / server / Questions / 1156593
Accepted
JohnLBevan
Asked: 2024-03-20 19:36:14 +0800 CST

DNS Oddities with Microsoft Dynamics Finance and Operations

  • 772

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 returns ns1.example.com; so ns1.example.com is the authoritative name server for example.com.
  • Running Resolve-DnsName -Name subdomain.example.com -Type NS -Server 1.1.1.1 returns ns2.example.com; so ns2.example.com is the authoritative name server for subdomain.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

screenshot of the above error

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:

Screenshot showing that getting name servers for subdomains from cloudflare works, whilst getting them from the parent domain's name servers gives an error

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.

domain-name-system

1 Answers

  1. Best Answer

    but trying to get the authorative name servers for the subdomain from the authorative name servers for their parent domain fails

    This looks more like a PowerShell failure than a DNS failure. Wireshark tells me that the server gives a successful reply – but it's a referral that has the NS records in the 'Authority' section, not in the 'Answer' section (the "parent copy" of the NS records does not produce answers – it is only used for referrals), and PowerShell apparently does not expect that.

    Try to do the same query using other tools:

    • Windows nslookup -d -q=NS operations.dynamics.com. ns1-205.azure-dns.com.
      (ignore the PTR query that shows up, nslookup always does one)

    • Linux/WSL dig operations.dynamics.com. NS @ns1-205.azure-dns.com.

    I would recommend having a very recent version of dig, as it supports DNS EDE – Extended Error Data, which lets a resolver such as 1.1.1.1 give much more detailed information about why it's giving you a SERVFAIL. (This is not really related to your PowerShell errors as you were directly querying an authoritative server without any intermediary anyway; it's more of a general recommendation.)

    Is my understanding correct, or can a subdomain have different nameservers to its parent without its parent domain hosting NS records for the subdomain?

    The two lists ought to match, but things would continue to work as long as the NS records at the parent domain point to a set of valid nameservers. Mismatching sets of NS records are not strictly correct but might remain unnoticed for a long time.

    The NS list at subdomain nameservers is what you get from a manual -Type NS query against public resolvers, but only the NS list at parent nameservers is what will be used for referrals from parent to child (because, of course, the contents of child nameservers cannot possibly be known at that point yet).

    So if the subdomain actually has more nameservers that are missing from the parent's copy of the NS list, it should not cause failures – the extra nameservers will just remain unused (even though they will show up in a manual -Type NS query against public resolvers).

    So to summarize:

    • If the parent's list is incomplete, then the missing servers simply won't be used at all, even if the child zone lists them (and equally, if the child has bogus entries, they won't be used).

      This is the only issue that DNSViz reports for your domain.

    • If the parent's list has extraneous nameservers that weren't configured to host the child domain (i.e. they return either REFUSED or a sideways referral), that's a major problem and will cause you to see SERVFAILs.

    • If the child's own list is incomplete, you'll only notice this in -Type NS queries but otherwise nothing much happens.

    • If the child's own list has extraneous nameservers, you'll likewise only notice it in manual queries, but otherwise nothing much happens – they won't be contacted by resolvers.

    As an example, if the parent zone (example.com) has:

    sub.example.com. NS ns1.example.com.
sub.example.com. NS ns2.example.com.

    and the child zone (sub.example.com) has:

    sub.example.com. NS ns2.example.com.
sub.example.com. NS ns3.example.com.
sub.example.com. NS ns4.example.com.

    then both ns1/ns2 are expected to be the authoritative servers, while ns3/ns4 will not be used for anything, even though making an explicit -Type NS query will return "NS ns2, ns3, ns4"

    If, however, you have this configuration but ns1/ns2 aren't configured to host the child zone, then they'll respond with a REFUSED to the resolver, and that propagates as a SERVFAIL to you. Additionally, ns1/ns2 are not allowed to respond with a "sideways referral" to ns3/ns4 – you will get a SERVFAIL if that occurs.

    • 1