DNS recursion using wrong NS for delegated zone CNAME
When Server 2016 DNS Server has a delgation within a primary zone, CNAME records in that delegation result in queries to the delgation's name servers, not forwarders / root hints.
Primary zone: one.example
Delegation: foo.one.example, with nameserver ns.bar.com
In that delegated zone, there exists a record:
baz.foo.one.example IN CNAME other.two.example
two.example's zone, hosted by ns.somethingelse.com, has a record:
other.two.example IN A 184.108.40.206
From a client pointed at the DNS server, query baz.foo.one.example.
I would expect the server to query ns.bar.com for baz, receive a reply of other.two.example, and then query either two.example's nameserver, or use the default forwarders to do the same, resulting in a recursive resolution passed back to the client of 220.127.116.11.
What actually happens, in Server 2016, is that only the CNAME is returned. With debug logging enabled, the DNS server issues a query to ns.bar.com for other.two.example, and of course gets a REFUSED response.
In Server 2012 R2, with the same configuration, baz.foo.one.example is resolved recursively to 18.104.22.168.
I'm pretty sure the new behaviour is incorrect?
Austin Calvert commented
This is equally frustrating delegating subdomains to Azure DNS for services which are ultimately front ended by other Azure services requiring a recursive CNAME lookup.
Acey Man commented
This is killing us for our subdomains zones that are delegated to Route 53. How has MSFT not gotten more pushback from this? My team is not in control of the AD/DNS configurations but from what I can tell this is NOT related to the new ability to control 'recursion scope' that's offered in Windows Server 2016 -- it's just flat broken.