Few questions . .

LEONJSLEONJS Member Posts: 12 ■□□□□□□□□□
I've been trying to research the answer to these but havent been able to figure out;

In a situation where you have a Primary DNS server and your implementing multiple new dns servers in the same domain which kind of dns requires you to modify settings on the primary dns server? It seems obvious that it would be necessary for a secondary server, how about a cache or stub server?

When creating a new mx record in a zone the very first box you can write text in is "host or child domain" the context written below states that in most cases thats left blank. Can some one clarify for me when it is necessary to insert information there or does it matter?

Also according to Sybex when setting up WSUS you do it through the Default Domain Policy. Ive seen conflicting resources that state you should create a new GPO and and attach it to a specific OU and Ive seen where it should be done through the Default Domain Policy. . Iam a bit confused.

Any help appreciated.



  • royalroyal Member Posts: 3,352 ■■■■□□□□□□
    Zone Q/A:
    You really only modify your primary zones and that's all. Secondarys will do zone transfer from primary through SOA record. Stub dynamically updates through SOA and just helps improve name resolution as well as does delegation.

    MX Q/A:
    The reason why the above field is usually left blank, is because most admins are authoritative for their own namespaces. What do I mean? Well basically, if you are in a forest with lets say 1 parent dns server with 5 child domains. You can typically leave the parent dns server authortiative for all dns namespaces but child domains might be hosting an Exchange server for their own domain namespace. Because dns is all controlled on the parent server, you might have to create an entry in the "above field" that specifies the mail server name that hosts mail for that child domain name. So let's say we have domain.com as the parent and child.domain.com. We'd have to create external nameserver records for child.domain.com that point to the dns servers pointing in domain.com. So when someone wants to send mail to a mail server in child.domain.com, they will see that for dns for this domain, they will have to contact the dns server in domain.com. Because domain.com hosts MX record for child domain, that "above field" needs to have the child domain specified in there.

    Now most domains are going to be authoritative for their own namespace. This is why the "above field" is going to usually be left blank. Because the MX record is going to usually say that mail for this domain is going to be sent to the specified mailserver.

    WSUS Q/A:
    Depends on your set up. Is the same WSUS server going to distribute updates to every system in your entire directory? If you have a Pilot OU that is going to be served by a test WSUS server, you clearly would not to use the Default Domain Policy.

    As a side note, I would not recommended modifying the Default Domain Policy ever really. If you get used to modifying this policy, if something ever happens and you ultimately (last resort) have to use dcgpofix, you lost tons of policies. Personally, I recommend at the very least to create a new GPO in the root of the domain (same place Default Domain Policy exists) and/or create a Root OU. Some settings still need to be placed in the root of the domain however, such as Account Settings such as password policy, account lockout settings, etc.. Even for those, I would definitely create a new policy instead of using the Default Domain Policy.

    Hope this helps.
    “For success, attitude is equally as important as ability.” - Harry F. Banks
  • LEONJSLEONJS Member Posts: 12 ■□□□□□□□□□
    Thanks for the quick reply. Your answer is very clear, Thank you.
Sign In or Register to comment.