none
Queries about DDNS update and refresh behavior when using stub zones and multiple DNS instances. RRS feed

  • Question

  • I was hoping someone could clarify a few questions about Dynamic DNS host record update and refresh behavior when using stub zones and multiple DNS instances. I have 3 questions based on the scenarios below. I can find a lot of documentation on the web about how stub zones resolve queries, but not so much about how DDNS zone updates are handled. I need to make sure I have a good understanding of this before we implement DNS scavenging. This is the scenario basics (I have simplified a bit) -

    • My customer has 3 separate un-trusted internal forests, let’s call them Prod.local, UAT.local and Dev.local (not real names) and have 2 DCs each acting as DNS servers. They are non-contiguous namespaces.
    • Each forest hosts its own DNS forward lookup zone, so Prod.local DC hosts the Prod.local DNS zone, UAT DCs host UAT.local DNS zone, etc.
    • DHCP scopes are only hosted on the Prod.local DCs. DHCP DDNS is setup to only update when clients request.
    • All DNS zones are AD integrated and all accept secure dynamic updates
    • There currently have no stub zones implemented or any forwarders or conditional forwarders
    • Suffix search list GPOs have been rolled out to all clients and servers featuring all 3 suffixes.
    • Windows only clients and servers

    Scenario 1:

    A Windows member server for uat.local is accidentally configured with a static IP and network settings pointing to DNS servers for the prod.local domain.

    Q1. I would expect the Windows member server in question to not be able to be able to update\refresh its Prod.local host record DDNS, as the DNS server IP that it is configured with is not hosting the zone and does not know where prod.local is hosted. IS THIS CORRECT?  [There are probably going to be some cross domain resolution issues as well, but this is not what this question is about so do not get hung up on this].

    Scenario 2:

    I implement 2 stub zones on each DC for the other DNS zones that they do not host. So the DCs hosting prod.local have stub zones for uat.local and dev.local, etc.

    As before, a Windows member server for uat.local is accidentally configured with a static IP and network settings pointing to DNS servers for the prod.local domain

    Q2. What happens with DDNS in this scenario when the member server is rebooted or ipconfig /registerdns is run? The Windows member server should now be able to resolve queries in other domains. However the DNS server it has in its settings is still not hosting the uat.local zone it needs to update. As a stub zone for the correct zone is configured on that DNS server, does the DNS server forward the DDNS request to the correct uat.local DNS server for uat.local zone update, or does it update the prod.local zone it hosts, or does it ignore\drop the DDNS request?

    Scenario 3:

    I implement 2 stub zones on each DC for the other DNS zones that they do not host. So the DCs hosting prod.local have stub zones for uat.local and dev.local, etc.

    A Windows 7 client using DHCP, with DNS servers for the prod domain, is added to the dev.local domain membership.

    Q3. What happens with DDNS in this scenario when the client or DHCP updates\refreshes the DDNS record? The Windows client should now be able to resolve queries in other domains. However the DNS server it has in its settings is still not hosting the dev.local zone it needs to update. As a stub zone for the correct zone is configured on that DNS server, does the DNS server forward the DDNS request to the correct server for dev.local zone update, update the prod.local zone it does host or drop the DDNS request? Also what is the DHCP involvement here, can it help update the correct zone? I thought clients updated their own records?

    Any help in clarifying the above would be appreciated.



    • Edited by PeteMitch99 Wednesday, June 7, 2017 12:56 PM
    Friday, June 2, 2017 5:35 PM

All replies

  • Hi PeteMitch99

    Based on your question, we need do more researches. If we have any updates or any thoughts about this issue, we will keep you posted as soon as possible. Your kind understanding is appreciated. If you have further information during this period, you could post it on the forum.

    Best Regards,

    Candy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, June 5, 2017 7:33 AM
  • Well i have a theory but it is not an answer because i am far from sure of it.

    My theory is that with Scenario 2 and 3, the dynamic update will query the SOA for the correct DNS server and be directed to the correct DNS server that hosts the zone. However as the DNS server is in a different un-trusted DNS forest the dynamic update would fail. However it may work if the host zone was set to accept 'non-secure' updates?

    If anyone could confirm that or not confirm that or have a go at the scenarios that would be helpful.
    Wednesday, June 7, 2017 1:03 PM
  • Hi PeteMitch99,

    I have test in my lab and get the following results:

    >>My customer has 3 separate un-trusted internal forests

    Dymaic update would fail because it could not across the un-trusted forests.

    >>However it may work if the host zone was set to accept 'non-secure' updates?

     Generally, un-trusted forests will deny the request of DDNS even though you set the host zone to accept 'none-secure' updates.

    Best Regards,

    Candy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, June 13, 2017 7:25 AM
  • Hi Candy,

    Thanks for the response, happy with the first part, however i do not understand the second part of the answer. Could you help me understand why?:

    >>However it may work if the host zone was set to accept 'non-secure' updates?

      >Generally, un-trusted forests will deny the request of DDNS even though you set the host zone to accept 'none-secure' updates.

    Why would the the stub zone pointing to the correct AD hosted zone in a different not forward the dynamic update of the client to the correct DNS implementation based on the SOA and then update the zone if non-secure updates were selected (as no authentication is necessary for non-secure updates)?

    DDNS Update Process:

    1. The DNS Client service sends a start of authority (SOA)–type query using the DNS domain name of the computer. The client computer uses the currently configured FQDN of the computer (such as newhost.tailspintoys.com) as the name that is specified in this query.
    2. The authoritative DNS server for the zone that contains the client FQDN responds to the SOA-type query. For standard primary zones, the primary server (owner) that is returned in the SOA query response is fixed and static. It always matches the exact DNS name as it appears in the SOA resource record that is stored with the zone. If, however, the zone being updated is directory integrated, any DNS server that is loading the zone can respond and dynamically insert its own name as the primary server (owner) of the zone in the SOA query response.
    3. The DNS Client service then attempts to contact the primary DNS server. The client processes the SOA query response for its name to determine the IP address of the DNS server that is authorized as the primary server for accepting its name. It then proceeds to perform the following sequence of steps as needed to contact and dynamically update its primary server:
      • It sends a dynamic update request to the primary server that is determined in the SOA query response. If the update succeeds, no further action is taken.
      • If this update fails, the client next sends a name server (NS)–type query for the zone name that is specified in the SOA record.
      • When it receives a response to this query, it sends an SOA query to the first DNS server that is listed in the response.
      • After the SOA query is resolved, the client sends a dynamic update to the server that is specified in the returned SOA record. If the update succeeds, no further action is taken.
      • If this update fails, the client repeats the SOA query process by sending to the next DNS server that is listed in the response.
    4. After the primary server that can perform the update is contacted, the client sends the update request and the server processes it. The contents of the update request include instructions to add host (A) (and possibly pointer (PTR)) resource records for newhost.tailspintoys.com and to remove these same record types for oldhost.tailspintoys.com, the name that was registered previously. The server also checks to ensure that updates are permitted for the client request. For standard primary zones, dynamic updates are not secured; therefore, any client attempt to update succeeds. For AD DS-integrated zones, updates are secured and performed using directory-based security settings.

    Dynamic updates are sent or refreshed periodically. By default, computers send a refresh once every seven days. If the update results in no changes to zone data, the zone remains at its current version and no changes are written. Updates result in actual zone changes or increased zone transfer only if names or addresses actually change.

    When the DNS Client service registers host (A) and pointer (PTR) resource records for a computer, it uses a default caching Time to Live (TTL) of 15 minutes for host records. This determines how long other DNS servers and clients cache a computer's records when the records are included in a query response.

    From here: https://technet.microsoft.com/en-us/library/cc771255%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396

    Wednesday, June 14, 2017 2:24 PM
  • Hi PeteMitch99

    Non-security is not a good option.

    You will under Potential risk with the records in your DC.

    Best Regards,

    Candy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, June 20, 2017 7:53 AM