Windows 2003 DCs changing DNS zones in BIND

  • Thread starter Thread starter benlonguk
  • Start date Start date
B

benlonguk

Hi,

Hopefully someone can help with this despite it being one of those
problems where you're not 100% sure on what group if should belong. So
I will probably end up repeating this in other groups if I have no
luck.

We have a Windows 2003 Active Directory using BIND for DNS running on
UNIX servers. Our DCs are the only machines allowed to dynamically
update DNS so we're sure the DCs are causing the problem.

The problem is our developers in their wisdom have created a number of
test web servers with dots in their name e.g. test.server and web.test.
These are registered in DNS as aliases so they can be accessed using
the hostname. When our DCs start up they intepret the dots and changes
the zone information so that they're sub zones so web.test becomes an
host entry web in the sub zone test.ourcompany.com.

It wouldn't be so bad if it worked but web.test and
web.test.ourcompany.com doesn't work either.

Has anyone seen this happen or can anyone think of a fix to prevent the
DCs trying to be helpful and fixing this problem.

Thanks for your time

Ben.
 
In
Hi,

Hopefully someone can help with this despite it being one of those
problems where you're not 100% sure on what group if should belong. So
I will probably end up repeating this in other groups if I have no
luck.

We have a Windows 2003 Active Directory using BIND for DNS running on
UNIX servers. Our DCs are the only machines allowed to dynamically
update DNS so we're sure the DCs are causing the problem.

The problem is our developers in their wisdom have created a number of
test web servers with dots in their name e.g. test.server and
web.test. These are registered in DNS as aliases so they can be
accessed using the hostname. When our DCs start up they intepret the
dots and changes the zone information so that they're sub zones so
web.test becomes an host entry web in the sub zone
test.ourcompany.com.

It wouldn't be so bad if it worked but web.test and
web.test.ourcompany.com doesn't work either.

Has anyone seen this happen or can anyone think of a fix to prevent
the DCs trying to be helpful and fixing this problem.

Thanks for your time

Ben.
Click to expand...

I'm not sure I entirely understand the problem. What exactly is not working
with web.test or web.test.company.com? You mean accessing the web server?
Using IE, when you enter http://web.test.company.com, does it resolve to the
correct IP address of the webserver? Is the webserver the DC?

Now if you try to enter http://web.test, I can understand that not being
able to work, since that will not resolve.

How is web.test being registered by the DCs? Was that zone added as a suffix
in IP properties, advanced, DNS tab, and set to "register this connection in
DNS"?

What exactly did the web devs do on the DC?

Also, if accessing IIS, keep in mind hostheaders play a major role and if
they don't match the URL (which should be the FQDN), it won't connect.

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

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

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft Windows MVP - Windows Server - Directory Services
Infinite Diversities in Infinite Combinations.
=================================
 
Hi,

Thanks for your reply.

The DCs are not registering web.test, they were originally in the DNS
configuration as pointers. What is happening is that the DCs are seeing
this pointer and changing it to zones. The problem is that these are
application servers which are used by front end web servers and the
code is wriiten to refer to it as web.test, which does not resolve. And
yes host headers are used on some of these.

It was pretty daft to use a dots in this fashion but it was done years
back and the until the Active Directory went in it was never a problem.
Now the DNS guys are moaning that AD is screwing up their config.

What I really need is a setting on the DC to say don't go fixing other
problems in DNS just worry about your own.

Cheers

Ben.
 
In
Hi,

Thanks for your reply.

The DCs are not registering web.test, they were originally in the DNS
configuration as pointers. What is happening is that the DCs are
seeing this pointer and changing it to zones. The problem is that
these are application servers which are used by front end web servers
and the code is wriiten to refer to it as web.test, which does not
resolve. And yes host headers are used on some of these.

It was pretty daft to use a dots in this fashion but it was done years
back and the until the Active Directory went in it was never a
problem. Now the DNS guys are moaning that AD is screwing up their
config.

What I really need is a setting on the DC to say don't go fixing other
problems in DNS just worry about your own.

Cheers

Ben.
Click to expand...


Curious, how do you have BIND set up to only allow the DCs to update the
zone? It appears that the web test servers are attempting to update the
zone, as long as the zone is allowed updates, and the setting in IP
properties, advanced, DNS tab, is set to update into that zone. If the
webservers are upating, and their primary DNS suffix is web.test, and the
DNS address is set to the BIND servers, then it will atempt to register into
the zone.

So I don't believe the DCs are "altering" the data, but rather BIND (or any
other DNS server that has update capabilties), interprets the update request
that way.

You are fighting the way the DNS hierarchy works and how dynamic
registration is based on it. It doesn't appear the DCs are changing it to a
zone, but rather I believe the web machines are configured with a Primary
DNS suffix of web.test, and since registration is enabled by default on the

Instead of fighting it, do you think you could allow it to just create that
child zone called 'test' under company.com, create the record called 'web'
give it the IP, and create a hostheader under the website properties called
web.test.company.com.?

Or eliminate dynamic updates completely, and manually update DNS with the
DC's info by pulling the data from system32\config\netlogon.dns file. This
will prove it is NOT the DCs. Matter of fact, the ONLY thing a DC will
update into the zone is what's in that file. Nothign else, and it will NOT
"change" anything else. Each machine is responsible for it's own updates,
unless using DHCP and configured DHCP to force updates on behalf of clients.

Or change the name of the test machine's zonename .

Or one more possibility, rename AD with a different TLD.

Ace
 
Hi,

We've actually tested and it is actually the DCs performing the update,
the only 4 IPs allowed to update DNS belong to the AD domain
controllers. 2 minutes after rebooting a DC (typically a GC) the DNS
zones are 'broken' or 'fixed' depending on what way you look at it. I
couldn't believe it either thinking it must have been the web servers,
but no it appears to be the DCs.

Ben.
 
In
Hi,

We've actually tested and it is actually the DCs performing the
update, the only 4 IPs allowed to update DNS belong to the AD domain
controllers. 2 minutes after rebooting a DC (typically a GC) the DNS
zones are 'broken' or 'fixed' depending on what way you look at it. I
couldn't believe it either thinking it must have been the web servers,
but no it appears to be the DCs.

Ben.
Click to expand...

If the DCs are performing the update, then I would take a look at their
configuration. Registration into a specific zone is based on the machine's
Primary DNS Suffix (and any other specific suffixes that may have been
added) that match the zone name in DNS that is allowing (or not allowing
updates in your situation), and what DNS servers it's configured with in
it's IP properties. This is default behavior of a DC to attempt to register
at certain time intervals to keep the SRV data up to date. If the DCs are
configured with a web.test suffix, then I can see why they are attempting to
update into that zone.

Do you know that you can disable DNS registration on a DC?

Back to a previous statement you made that I am trying to understand:

"The DCs are not registering web.test, they were originally in the DNS
configuration as pointers. What is happening is that the DCs are seeing
this pointer and changing it to zones. "

I'm not sure I understand what a "pointer" is in this scenario. Can you
elaborate? How were the DNS servers configured as a 'pointer'? Is this on
the BIND servers or is DNS running on the DCs?

Ace
 
Back
Top