AD

Please take a moment and help support this site by visiting our AD. Thank you for your support.

Thursday, June 02, 2011

DNS Command Line and GUI Scenarios Clarified


I suggested that they do the following:
  1. Set it so DNS enables scavenging on all zones by default, so that it's enabled when the zone is created.
  2. Set all of the zones that weren't set to scavenge, to do so.
  3. Set it so DNS zones are automatically set to secure only. ;)
  4. Set all of the zones that weren't set to be secure only, to do so.
Below is what I told them to do to accomplish those simple goals, however since some of the wizards don't explain exactly what they do, and since you can get inconsistent or unexpected results, if you don't know what to expect, I thought I'd clarify a bit.
In order to meet the first goal, to set all newly created zones to scavenge upon creation, I told them to run the following command, obviously changing <server> to their server names.
Dnscmd <server> /config /defaultagingstate 1
Note: By default it's set to 0.  Also, unlike some other commands you can't just type the command without a parameter to see the status.
Also, it's important to note that the /defaultagingstate switch is server specific, so if a zone is created on another DC/DNS server where it's not set to 1, it won't automatically be set to scavenge, unless that command is run for that server as well, or it's enabled via the GUI.
Essentially, that command is the command line equivalent to right clicking the server, selecting "Set Aging/Scavenging for all Zones", checking the "Scavenge Stale Resource Records" box, and then clicking OK.
clip_image001
When you click OK, it'll take you to another screen and then you'd click OK again, leaving the "apply these settings to the existing Active Directory-integrated zones" check box unchecked.
You can also define default no-refresh and refresh intervals (that will be modified on the same screen) by using the /defaultnorefreshinterval and /defaultrefreshinterval switches. Those are also server-level settings and the value is a hex value. Obviously, if you have a small number of DNS servers then the GUI method is easier for changing all of the defaults, but if you have a lot of DNS servers, then you'll want to use the command line or using that via a batch file or script.
The one thing that I'm not a big fan of is that the wizard doesn't explain very well what it is exactly that you're enabling. When selecting "Set Aging/Scavenging for all Zones", to me that sounds like a one time deal where you just run through the wizard.
Also of note, if you define those settings, and then want to run through the wizard to age all of the zones with the same settings, the confirmation screen will be blank, as depicted below and changes will not be propagated to all zones as you might expect:
clip_image002
For example, lets say that 20 new zones were created on another server, but that server doesn't have default aging settings, and later you realize that aging isn't enabled. Well lets say that you go back to the DC that does have default aging settings and you try to use the "Set Aging/Scavenging for all Zones" wizard to set all of the zones to age with your defined settings...you come to realize that it doesn't work.. You see the blank confirmation window above saying that no changes will be made (though it doesn't jump out and say that).
Now, if on that same DC, where you your default settings defined, if you change intervals away from 3 in this example, to 5, then the confirmation will reflect that change for the no-refresh and refresh intervals...but that only changes those intervals (if you check the "apply these settings to the existing Active Directory-integrated zones")...it will not check the "Scavenge Stale Resource Records" box for the newly created zone that was created from the other DC. That's implicitly evident on the confirmation screen though, but you'd need to know what was missing in that screen to know that the "Scavenge Stale Resource Records" check box wouldn't be checked.
clip_image003
If you want to make changes to the no-refresh and refresh intervals, as well as enabled "Scavenge Stale Resource Records" for all zones, as the Wizard implies, after already having these settings defined, you can do that by changing the no-refresh and refresh values, as well as unchecking the "Scavenge Stale Resource Records" box and click ok. In this case, you would not want to check "apply these settings to the existing Active Directory-integrated zones". After you save the changes, you would go back into the wizard, define the settings that you do want applied to all zones, and then click OK.
clip_image004
Notice that this time, we see in the confirmation box, that it will also check the "Scavenge Stale Resource Records" box for the zone, where before that implicitly left out. If we check "apply these settings to the existing Active Directory-integrated zones", now this will apply to all zones as depicted on the confirmation screen, satisfying the second goal. Alternatively, you could make changes from another DNS server that has no defaults defined and that will also do it, among other ways.
To satisfy the third goal of setting the zones to be secured by default...you do absolutely nothing...its set that way by default.
They could have had it set to be unsecured for any number of reasons. In my mind, either they went out of their way to check the "allow both non-secure and secure dynamic updates" button for some requirement that they had (but as far as I know there is no requirement for that in their environment), or those were secondary zones that were created to "migrate" DNS from an old domain that's now collapsed, where they "promoted" those secondary zones to Primary/AD-integrated zones to preserve records, and the zone security settings were also preserved. In this case the old zones were un-secure. Regardless of the reason, they wanted to set them all to be secure.
So to satisfy the last requirement of setting all of the zones to being secure without having to manually do it, we just ran the following command, again changing <server> to their server name:
dnscmd <Server> /config ..AllZones /AllowUpdate 2
When we ran the command however, it threw an error: DNS_ERROR_INVALID_ZONE_TYPE Regardless of the error, the command still worked. But now I had to know why it threw the error...
I only found one internal article that discussed the error when running the same exact command, but they said the cause was due to the customers' server having secondary zones on it. In testing it in my lab, it also threw the same error. I don't have any secondary zones however, nor does my customer, so that was out. The only thing that I noticed when testing in my lab was that when I did a dnscmd /enumzones after running the "dnscmd <Server> /config ..AllZones /AllowUpdate 2" command to set the zones to secure, the only zone that didn't update was the built in TrustAnchors zone (for DNSSEC)...and being that it was my lab and I didn't care, I deleted it. It immediately went away when killing it in ADSI, but it didn't go away when re-enumerating the zones, it just said "Aging Down". Eventually it went away when re-enumerating (though I may have cycled the DNS service) and after that the command ran without error.

No comments:

Post a Comment