Multiple questions regarding a DNS migration to MSDNS
infinitiguy
problems/issues that I'm running into. Most of these issues are stemming
from just a lack of personal time to actually be able to reasearch this
enough without having people bother me... so here goes.
Currently I have two internal DNS servers, one in boston and one in dublin.
They run BIND on Solaris. Their IP's are 10.65.6.2 and 10.2.2.49. They do
not serve any external content. The plan is to move them to microsoft DNS.
My first problem, in reading the forums is with the domain controllers. My
original plan was to have them be active directory integrated from the start,
and simply add a 2nd IP to my domain controller when I de-commissioned the
DNS servers. So I'd have my DC be 10.65.6.34 and add a 2nd IP of 10.65.6.2
and force DNS to listen on that. There have been recommendations that it may
not be the best idea... so I guess I'd be reduced to having to have a
standalone DNS server that I could just re-IP to be 10.65.6.2 and then I'd
have to promote it to be a domain controller? Does that seem to be accurate?
I also seem to have an issue with linux clients registering in DNS(A records
and PTR records) has anyone else seen any issues with this? If so, what were
the circumstances? Also, what is the reason I would ever need to allow
non-secure DNS entries? For testing I've been allowing non-secure... but I'd
like to try to keep things somewhat secure when I go into production.
Lastly, and this I thought I would be able to figure out short term... but
it doesn't seem to be that way.... I need to restrict one of my zones to be
administered by non-domain admins. So... in production I'll have the
following zones
a: america
b: beijing
c: canada
d: dublin
Domain admins can administer all 4 zones, but I need to be able to specify
one domain user in canada, to be able to install the dns.msc on his machine,
and administer only the canada zone. Is this possible? I thought it could
be done within the security tab within the zone and then if I just give the
entire server read writes that should do it... but it didn't work out that
way... my test restricted user was able to create entries in any zone, with
"Read" rights to the server and "write" rights to zone C. This was with
non-secure updates enabled. I changed it to only allow secure updates and my
test user was no longer able to see anything(including zone C). This was
only a few hours ago so I got frustrated and went home.
Anyways, any insight anyone can shed on any of this.. would be
appreciated. More questions will probably spawn from this.
Kevin D. Goodknecht Sr. [MVP]
In news:F42B7DD2-88DD-437D...@microsoft.com,
infinitiguy <infin...@discussions.microsoft.com> typed:
> I'm in the middle of testing for a internal DNS migration and I have
> a few problems/issues that I'm running into. Most of these issues
> are stemming from just a lack of personal time to actually be able to
> reasearch this enough without having people bother me... so here goes.
>
> Currently I have two internal DNS servers, one in boston and one in
> dublin. They run BIND on Solaris. Their IP's are 10.65.6.2 and
> 10.2.2.49. They do not serve any external content. The plan is to
> move them to microsoft DNS. My first problem, in reading the forums
> is with the domain controllers. My original plan was to have them be
> active directory integrated from the start, and simply add a 2nd IP
> to my domain controller when I de-commissioned the DNS servers. So
> I'd have my DC be 10.65.6.34 and add a 2nd IP of 10.65.6.2 and force
> DNS to listen on that. There have been recommendations that it may
> not be the best idea... so I guess I'd be reduced to having to have a
> standalone DNS server that I could just re-IP to be 10.65.6.2 and
> then I'd have to promote it to be a domain controller? Does that
> seem to be accurate?
IT would be very difficult to give good advice on the little bit of
information you are giving. But I take it that the content that is on the
BIND servers will eventually be moved to ADI zones on a Windows Server 2003
Domain controller, is this the plan?
You would also apparently have a lot or Statically addressed clients with
these IPs and this is the reason for moving the BIND IP to the
WinServer2003?
Yes, this would make some sense, and to make things go more smoothly, you
can keep the BIND servers up and use them for Forwarders for the Windows
DNS.
>
> I also seem to have an issue with Linux clients registering in DNS(A
> records and PTR records) has anyone else seen any issues with this?
> If so, what were the circumstances? Also, what is the reason I would
> ever need to allow non-secure DNS entries? For testing I've been
> allowing non-secure... but I'd like to try to keep things somewhat
> secure when I go into production.
You can make Linux register in Microsoft DNS by making them DHCP clients and
then let Win2k3 DHCP register in DNS for the Linux clients.
Another way to achieve this would be to not worry about the Linux clients
registering in DNS, just configure the zone on the Windows DNS to search
WINS for unknown hosts such as the Linux. This assumes you already have WINS
in place and working.
>
> Lastly, and this I thought I would be able to figure out short
> term... but it doesn't seem to be that way.... I need to restrict one
> of my zones to be administered by non-domain admins. So... in
> production I'll have the following zones
> a: America
> b: Beijing
> c: Canada
> d: Dublin
> Domain admins can administer all 4 zones, but I need to be able to
> specify one domain user in Canada, to be able to install the dns.msc
> on his machine, and administer only the Canada zone. Is this
> possible? I thought it could be done within the security tab within
> the zone and then if I just give the entire server read writes that
> should do it... but it didn't work out that way... my test
> restricted user was able to create entries in any zone, with "Read"
> rights to the server and "write" rights to zone C. This was with
> non-secure updates enabled. I changed it to only allow secure
> updates and my test user was no longer able to see anything(including
> zone C). This was only a few hours ago so I got frustrated and went
> home.
>
> Anyways, any insight anyone can shed on any of this.. would be
> appreciated. More questions will probably spawn from this.
In a real world situation, I'm responsible for maintaining 5 separate
networks totaling about 100 machines, I have access by RDP and VNC to each
computer on these networks by name since it is easier to remember a name
than an IP. All Clients are DHCP so using IPs would be impossible to track.
I can resolve each of these machines in my own domain zone by using WINS
lookups on my zone, even though my zone only contains 6 A records. It make
for a much cleaner DNS and I also have NetBIOS resolution for these
networks. (This means I can browse those networks in My Network Places)
--
Best regards,
Kevin D. Goodknecht Sr. [MVP]
Hope This Helps
===================================
When responding to posts, please "Reply to Group"
via your newsreader so that others may learn and
benefit from your issue, to respond directly to
me remove the nospam. from my email address.
===================================
http://www.lonestaramerica.com/
http://support.wftx.us/
http://message.wftx.us/
===================================
Use Outlook Express?... Get OE_Quotefix:
It will strip signature out and more
http://home.in.tum.de/~jain/software/oe-quotefix/
===================================
Keep a back up of your OE settings and folders
with OEBackup:
http://www.oehelp.com/OEBackup/Default.aspx
===================================
infinitiguy
in each one of my zones. We have 50% of our servers as various flavors of
unix(solaris, aix, hpux etc...) all of which are statically set, which is
the reason to need to keep the same IP address of 10.65.6.2. We don't want
to keep the BIND servers around(actually they are incognito DNS, but it's not
widely used so for post purposes I called it BIND).
Yes, the content of the BIND servers will be moving to ADI DNS. I believe
we should be able to import in all the records without an issue, which I'll
verify in testing.
Can you see any issues with promoting the primary DNS server to a DC in my
domain and then changing the DNS model from primary to ADI once things are
moved over and in production? Are there any pitfalls I need to look out for?
I'm never a fan of making changes like this to production machines, but in
this case there seems to be very little I can actually do while keeping the
outage to a minimal.
regarding the Linux clients.. I think this was more so an issue on my side
with my DHCP lease. In testing I may have deleted my A and PTR records for
my linux test client and the lease was for 2 days so without it expiring it
wouldn't re-register itself(i.e. the DHCP server wouldn't re-register it).
I'll test this again on monday after the lease has expired and see what
happens.
re: WINS. We have WINS working on the production network, from our old
infrastructure, but I don't have it running on my test network yet. I am
planning on getting it running at some point soon however, so I will keep
that in mind and try that. I assume with WINS and the linux clients a linux
DHCP client in Boston should be able to lookup a linux DHCP client in dublin
with no issues.
re: my last question regarding segregation of zone administration... I
don't quite follow what you said. You maintain 5 separate networks and have
access to each computer by name... I understand why we use DNS etc... but
here, I'm trying to figure out how to give a non administrator access to his
own zone(an Engineer in canada). It's for political reasons that I need to
allow him to make changes to his own zone, and no other zone, while I retain
access to make changes to all of the zones. I figured this could've been
done with security tab permissions on each of the zones and the main server
itself, but whatever I tried didn't seem to work.
Kevin D. Goodknecht Sr. [MVP]
In news:3D1A5F4F-2712-43CC...@microsoft.com,
infinitiguy <infin...@discussions.microsoft.com> typed:
> Here's some more information. We probably have at least 100 static
> records in each one of my zones. We have 50% of our servers as
> various flavors of unix(solaris, aix, hpux etc...) all of which are
> statically set, which is the reason to need to keep the same IP
> address of 10.65.6.2. We don't want to keep the BIND servers
> around(actually they are incognito DNS, but it's not widely used so
> for post purposes I called it BIND).
> Yes, the content of the BIND servers will be moving to ADI DNS. I
> believe
> we should be able to import in all the records without an issue,
> which I'll verify in testing.
>
> Can you see any issues with promoting the primary DNS server to a DC
> in my domain and then changing the DNS model from primary to ADI once
> things are moved over and in production?
There are any real issues in just promoting a DNS server to a DC, but so far
as converting to ADI goes, before I can tell you any other problems, I'd
need to know more about the infrastructure.
Like:
Is this a new domain you're promoting, or is it an existing AD domain with
other DCs with DNS installed? Does the zone already exist for the domain
name you are going use? Do they have any other zones? What zone types?
Will it be your only DC?
There are many other things that have to be thought through depending on the
existing infrastructure.
> Are there any pitfalls I need to look out for? I'm never a fan of making
> changes > like this to
> production machines, but in this case there seems to be very little I
> can actually do while keeping the outage to a minimal.
The biggest mistake people make is when they tried to mix zone types between
different DCs. If you change a zone to ADI on one DC, you have to remove
other zone types for the domain that may exist on other DCs.
>
> regarding the Linux clients.. I think this was more so an issue on
> my side with my DHCP lease. In testing I may have deleted my A and
> PTR records for my Linux test client and the lease was for 2 days so
> without it expiring it wouldn't re-register itself(i.e. the DHCP
> server wouldn't re-register it). I'll test this again on monday after
> the lease has expired and see what happens.
What kind of DHCP server are you using?
You should be using Win2k3 for DHCP, it can (and should) be configured with
credentials to authenticate with DNS.
>
> re: WINS. We have WINS working on the production network, from our
> old infrastructure, but I don't have it running on my test network
> yet. I am planning on getting it running at some point soon however,
> so I will keep that in mind and try that. I assume with WINS and the
> Linux clients a Linux DHCP client in Boston should be able to lookup
> a Linux DHCP client in dublin with no issues.
Yes, if your WINS server replication is working.
>
> re: my last question regarding segregation of zone administration...
> I don't quite follow what you said. You maintain 5 separate networks
> and have access to each computer by name... I understand why we use
> DNS etc... but here, I'm trying to figure out how to give a non
> administrator access to his own zone(an Engineer in canada). It's
> for political reasons that I need to allow him to make changes to his
> own zone, and no other zone, while I retain access to make changes to
> all of the zones. I figured this could've been done with security
> tab permissions on each of the zones and the main server itself, but
> whatever I tried didn't seem to work.
The only way you can do this is with Connection Specific DNS suffixes
assigned by DHCP. Then just like any other child domain, you have to
delegate these in the parent Domain's zone.
infinitiguy
> There are any real issues in just promoting a DNS server to a DC, but so far
> as converting to ADI goes, before I can tell you any other problems, I'd
> need to know more about the infrastructure.
> Like:
> Is this a new domain you're promoting, or is it an existing AD domain with
> other DCs with DNS installed? Does the zone already exist for the domain
> name you are going use? Do they have any other zones? What zone types?
> Will it be your only DC?
here's a layout of the existing infrastructure as it is today:
10.65.6.2: incognito DNS and DHCP running on Solaris 10 for boston
10.2.2.49: incognito DNS and DHCP running on Solaris 10 for dublin
we have 4 AD domains
bostongroup.com
dublingroup.com
apacgroup.com
globalgroup.com
the first 3 are win2k3 based domains(running in mixed mode) while the 4th is
a win2k domain running in mixed mode. This domain was built to support our
exchange 2000 environment back in 2001 or 2002. Up until now it had only
been in place to support exchange. We're in the middle of a domain
consolidation project so we will collapse all domains into globalgroup.com.
We have 3 DC's in globalgroup.com 2 of them are win2k and one is win2k3.
The current globalgroup.com zone is an ADI zone. This zone is only
replicated within the two win2k servers. The win2k3 server does not have DNS
installed on it. The zone is more heavily used as we migrate user
workstations over to globalgroup.com so AD DNS is working currently within
our environment, but I have very little experience with it(hence all the
testing first).
The exchange servers look at the two win2k globalgroup.com DC's for their
dns, and then the 2 incognito DNS servers as 3rd and 4th. ipconfig /all
10.65.6.82
10.65.5.25
10.65.6.2
10.2.2.49 - dublin secondary internal DNS.
There is an identical setup(dc's and exchange) in Dublin, but I'll only
focus on boston for now. The DNS switchover will not be completed until the
domain consolidation has been completed. We're trying to keep matters as
simple as possible.
>
> The biggest mistake people make is when they tried to mix zone types between
> different DCs. If you change a zone to ADI on one DC, you have to remove
> other zone types for the domain that may exist on other DCs.
>
re: mixing zone types. So, this kind of brings up a question. As above,
the exchange servers look at the 2 existing DC's for DNS... if they are ADI
integrated, and as in a previous post, the migration plan was going to need
to have a primary/secondary structure while I re-IP'ed the DNS server and
then promoted it to a DC... this will seem to cause issue as I'll have
primary/seconaries as well as ADI.. on the other hand.. if I have my
10.65.6.2 IP be the primary, that would force the DC's that exchange used to
use to be secondaries(it won't force, but I'd need to make them
secondaries)... and if they are using that for DNS... and it becomes
readonly.. I'd suspect something might break there. It may make sense to
have to force exchange to use 10.65.6.2 as it's primary IP during the
conversion.
> What kind of DHCP server are you using?
> You should be using Win2k3 for DHCP, it can (and should) be configured with
> credentials to authenticate with DNS.
>
The DHCP server is an incognito DHCP server.. the plan is to move this to
MSDNS as well, but in a 2 phased approach. We decided to move DNS first..
and let incognito DHCP hand out scope options for another week or so while we
made sure DNS worked fine, then migrate DHCP over. This whole process is
the reason for the test environment. I want to mimick everything that will
happen first, to see what kinds of weird behaviours I come across. Alot of
the reason for doing this migration is the instability and buggyness of the
incognito product.
> The only way you can do this is with Connection Specific DNS suffixes
> assigned by DHCP. Then just like any other child domain, you have to
> delegate these in the parent Domain's zone.
>
I had thought that might be how I needed to do it, but the description of
the delegation was kind of weird. The delegation option seemed to indicate
that i would be allowing another DNS server to control that zone, and not
necesarrily another user account. Misconception on my part... I should've
actually tried it out before writing it off that it wasn't going to work.
infinitiguy
solaris machine... is it a best practice(or recommended) with MS, to keep
dhcp on a separate machine than DNS? I know I can run 2 servers at 80/20
which I will plan on doing anyways, but should I keep the dhcp service
completely off of the DNS servers(and since adi... the domain controllers as
well)
Kevin D. Goodknecht Sr. [MVP]
In news:95D77BBE-DD5F-4740...@microsoft.com,
infinitiguy <infin...@discussions.microsoft.com> typed:
As I said in my first post, you'd be better off using Win2k3 DHCP, whether
it on a DNS server, Domain controller or what.
Win2k3 DHCP supports registering in a Microsoft DNS where other DHCP servers
do not. Plus, the Win2k3 DHCP can register in a secure zone using alternate
credentials for authentication.
How to configure DNS dynamic updates in Windows Server 2003:
http://support.microsoft.com/kb/816592/
infinitiguy
at the same time as DNS. I want to do it in a two phased approach. I just
didn't know if it's a best practice to host DHCP on a different server than
the DNS/Domain Controllers, or if it didn't really matter. Our current DHCP
server will do dynamic DNS registrations. It may not be able to do the
proper job of registering any of the clients in a secure environment, and it
looks like it does a dodgy job of doing linux in a non-secure, but in the
transition phase, I'll keep it set to do non-secure and secure, then once I'm
on MS DHCP I'll switch everything over to secure. I'm in the process of
getting a test DHCP environment set up to test more of these features.
Also, in an effort to try to limit the amount of steps within the migration,
I think I may try to do something in the effect of having 10.65.6.2 set up as
a forwarding server(or maybe the better term is a stub server), to forward
all requests to another DNS server.
The reason for this is so the forwarder/stub server will not be a domain
controller so it can be re-IP'ed without having to worry about domain
implications, and then we can have our other DNS/DC combo's set up ready to
go.
Does this seem feasible? Will it work, and would it be a stub server I'd
want to use in this case? From what I understand of stub servers, they are
meant to be an index of sorts for other DNS servers so clients can have a
single IP to point to and it will take care of figuring out which DNS servers
actually exist in the background. I'm going to do some more reading on
stub's but it seems like it may do what I want.