none
DNS settings between domains in different trees.

    Question

  • Hi guys,

    Please refer to the diagram below,

    I just created a new root domain to a new tree in an existing forest called “far.co.uk”. Trust  between domains are created automatically.

    My Question  

    In terms of DNS, what do I need to do – Do I need to create Stub zone in each domain pointing to the other? Or just  a conditional forwarder.

    Does DNS replication between domains in different trees come into play here?

    Do I need to do anything in terms of Sites in my existing forest? (Man.com)

    Thanks Guys…

    Sunday, September 08, 2013 3:28 PM

Answers

  • As I see, you are single a single AD forest with multiple AD domains. You can simply make your DNS zones AD-integrated and replicated to all DCs in your forest. Like that, all your DCs will be authoritative for all DNS zones in your forest.


    This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    Get Active Directory User Last Logon

    Create an Active Directory test domain similar to the production one

    Management of test accounts in an Active Directory production domain - Part I

    Management of test accounts in an Active Directory production domain - Part II

    Management of test accounts in an Active Directory production domain - Part III

    Reset Active Directory user password

    • Marked as answer by MassonTech Monday, September 09, 2013 8:59 PM
    Sunday, September 08, 2013 5:13 PM
  • Hello,

    just to understand you correct "new root domain to a new tree" means you have created a new tree in the forest MAN.COM named FAR.CO.UK?

    If that is the case then you don't have a new ROOT domain as the ROOT is still MAN.COM, the first created domain in the forest.

    So I suggest for DNS to use Stub zones, AD integrated, as they are the best option. See differences from another posting that I add here:

    ------

    1. if your DNS server is running Windows 2000 --> use secondary zones
    2. if your DNS server is running Windows 2003 --> you can use secondaries, conditional forwarders or stub zones

    * secondaries
      - will require that you weaken security to some extent to permit the transfer
      - susceptible to 'expiry' during periods of downtime that exceed the SOA record's 'Expire after' value
        - this can be increased but only on the or a primary copy of the zone which you don't necessary have permission to alter
      - cannot be AD-integrated and, therefore, imposes a potential admin. overhead
        - if you have 2 or more of your own DNS servers, you must place a secondary on each
          - you can replicate one secondary from another if security or bandwidth is a concern/problems
      - limited fault-tolerance
      - not self updating in the event of DNS reconfiguration on the other side

    * conditional forwarders (not global forwarders)
      - no weakening of security
      - no unnecessary transfer of data
      - expiry is no problem since they're not zones
      - they are NOT load-balanced in any way
        - the list of addresses you enter is ordinal or used in sequence following the timeout period
          - this places all the load on whichever DNS server comes first in the list
          - if you have 2 or more of your own DNS servers, you must configure the conditional forwarders on each
      - they can be AD-integrated
        - if you do so, you'll simply compound the problem of load
          - this may be moot depending on the scale involved
      - limited fault tolerance
      - not self updating in the event of DNS reconfiguration on the other side

    * stub zones
      - no weakening of security
      - no unnecessary transfer of large amounts of data
        - stub zones are built from the SOA, NS and necessary A records only
      - well load-balanced
        - all queries are answered
          - from cache populated due to previous query for same record
          - or by dividing the query load against all name servers defined by the NS records within the master zone
      - fault tolerant for the same reasons as they're load-balanced
      - self-updating
        - since stub zones are aware of all name servers serving the zone, they can failover to any other
          - this is true for all forms of name resolution
          - capable of handling name server additions and removals with the exception of the following
            - if the name server configured as the the stub's master(s) is removed, it will not auto failover to other name servers even though it possesses sufficient knowledge to do so
              (a design flaw in my opinion that I've yelled about for years)

    ... that's all that springs to mind for now.

    PS - as you may have noticed and within the context of this question -- I dislike the use secondaries, I consider conditional forwarders as a lazy solution and recommend stub zones wherever possible.

    --------


    Best regards

    Meinolf Weber
    MVP, MCP, MCTS
    Microsoft MVP - Directory Services
    My Blog: http://msmvps.com/blogs/mweber/

    Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.

    • Marked as answer by MassonTech Monday, September 09, 2013 8:59 PM
    Sunday, September 08, 2013 5:26 PM
  • Thanks guys , 

    So i solved the problem by creating conditional forwarders in all DNS servers. And all went well. I also added DNS  search suffix to each DNS server in the forest.

    But my next question is  - In an enterprise environment where i have to deploy about tens of servers - is it best practice to implement conditional forwarders?  

    Monday, September 09, 2013 8:24 AM

All replies

  • As I see, you are single a single AD forest with multiple AD domains. You can simply make your DNS zones AD-integrated and replicated to all DCs in your forest. Like that, all your DCs will be authoritative for all DNS zones in your forest.


    This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    Get Active Directory User Last Logon

    Create an Active Directory test domain similar to the production one

    Management of test accounts in an Active Directory production domain - Part I

    Management of test accounts in an Active Directory production domain - Part II

    Management of test accounts in an Active Directory production domain - Part III

    Reset Active Directory user password

    • Marked as answer by MassonTech Monday, September 09, 2013 8:59 PM
    Sunday, September 08, 2013 5:13 PM
  • Hello,

    just to understand you correct "new root domain to a new tree" means you have created a new tree in the forest MAN.COM named FAR.CO.UK?

    If that is the case then you don't have a new ROOT domain as the ROOT is still MAN.COM, the first created domain in the forest.

    So I suggest for DNS to use Stub zones, AD integrated, as they are the best option. See differences from another posting that I add here:

    ------

    1. if your DNS server is running Windows 2000 --> use secondary zones
    2. if your DNS server is running Windows 2003 --> you can use secondaries, conditional forwarders or stub zones

    * secondaries
      - will require that you weaken security to some extent to permit the transfer
      - susceptible to 'expiry' during periods of downtime that exceed the SOA record's 'Expire after' value
        - this can be increased but only on the or a primary copy of the zone which you don't necessary have permission to alter
      - cannot be AD-integrated and, therefore, imposes a potential admin. overhead
        - if you have 2 or more of your own DNS servers, you must place a secondary on each
          - you can replicate one secondary from another if security or bandwidth is a concern/problems
      - limited fault-tolerance
      - not self updating in the event of DNS reconfiguration on the other side

    * conditional forwarders (not global forwarders)
      - no weakening of security
      - no unnecessary transfer of data
      - expiry is no problem since they're not zones
      - they are NOT load-balanced in any way
        - the list of addresses you enter is ordinal or used in sequence following the timeout period
          - this places all the load on whichever DNS server comes first in the list
          - if you have 2 or more of your own DNS servers, you must configure the conditional forwarders on each
      - they can be AD-integrated
        - if you do so, you'll simply compound the problem of load
          - this may be moot depending on the scale involved
      - limited fault tolerance
      - not self updating in the event of DNS reconfiguration on the other side

    * stub zones
      - no weakening of security
      - no unnecessary transfer of large amounts of data
        - stub zones are built from the SOA, NS and necessary A records only
      - well load-balanced
        - all queries are answered
          - from cache populated due to previous query for same record
          - or by dividing the query load against all name servers defined by the NS records within the master zone
      - fault tolerant for the same reasons as they're load-balanced
      - self-updating
        - since stub zones are aware of all name servers serving the zone, they can failover to any other
          - this is true for all forms of name resolution
          - capable of handling name server additions and removals with the exception of the following
            - if the name server configured as the the stub's master(s) is removed, it will not auto failover to other name servers even though it possesses sufficient knowledge to do so
              (a design flaw in my opinion that I've yelled about for years)

    ... that's all that springs to mind for now.

    PS - as you may have noticed and within the context of this question -- I dislike the use secondaries, I consider conditional forwarders as a lazy solution and recommend stub zones wherever possible.

    --------


    Best regards

    Meinolf Weber
    MVP, MCP, MCTS
    Microsoft MVP - Directory Services
    My Blog: http://msmvps.com/blogs/mweber/

    Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.

    • Marked as answer by MassonTech Monday, September 09, 2013 8:59 PM
    Sunday, September 08, 2013 5:26 PM
  • Thanks guys , 

    So i solved the problem by creating conditional forwarders in all DNS servers. And all went well. I also added DNS  search suffix to each DNS server in the forest.

    But my next question is  - In an enterprise environment where i have to deploy about tens of servers - is it best practice to implement conditional forwarders?  

    Monday, September 09, 2013 8:24 AM
  • Monday, September 09, 2013 7:40 PM