PTR records via legacy Geographic zones

[haigh]

Here's the deal

We're running AD in an environment with UNIX BIND. The support and
security personnel are used to performing reverse lookups on client
machines based on old geographic-based zones. This allows them to
resolve an IP address to host name that tells them where the client is
located (i.e. by geographic zone name).

By default, AD clients register their A and PTR records according to
their primary DNS suffix based on their AD domain membership, which is
common across an entire region and is not geographically specific as
they are accustomed to.

I'd like to be able to use DHCP to assign a connection suffix that
maintains the geographic based zone syntax and have the PTR record
registered via this connection suffix and not the AD domain suffix.

Is this possible and if so, how is it accomplished?

 

[Herb Martin]

Here's the deal

We're running AD in an environment with UNIX BIND. The support and
security personnel are used to performing reverse lookups on client
machines based on old geographic-based zones. This allows them to
resolve an IP address to host name that tells them where the client is
located (i.e. by geographic zone name).

Give them a list of subnets and let them just
look it up in Excel or something.

There is NO technical relationship between
a "domain or forward zone" and the IP-reverse
zones -- this is merely a human convention or
effect.

(Many people have machines from the "same
domain or zone" spread all over the world.)

By default, AD clients register their A and PTR records according to
their primary DNS suffix based on their AD domain membership,

Actually based on their ZONE name suffix which is
USUALLY the same thing.

which is
common across an entire region and is not geographically specific as
they are accustomed to.

I'd like to be able to use DHCP to assign a connection suffix that
maintains the geographic based zone syntax and have the PTR record
registered via this connection suffix and not the AD domain suffix.

Connection speficic suffixes exist (and you can play
with that), but the DHCP server won't do this -- for
the DHCP server it is basically all or nothing.

The client can (at least in theory) do this for different
NICs differently but it may interfere (at times) with
the main registration.

Note this is all easily covered by giving the techs
a MAP or DATABASE (Excel or text file even)
of the network.

(Or even providing a simple web page they can
use.)

Is this possible and if so, how is it accomplished?

It would interfere with the normal workings of the
client registration (which may not matter) and it
isn't even necessary to give them the info they need:

Since presumably SUBNETS are (reasonably) static
locations.

 

[Kevin D. Goodknecht Sr. [MVP]]

In

Here's the deal

We're running AD in an environment with UNIX BIND. The
support and security personnel are used to performing
reverse lookups on client machines based on old
geographic-based zones. This allows them to resolve an
IP address to host name that tells them where the client
is located (i.e. by geographic zone name).

By default, AD clients register their A and PTR records
according to their primary DNS suffix based on their AD
domain membership, which is common across an entire
region and is not geographically specific as they are
accustomed to.

I'd like to be able to use DHCP to assign a connection
suffix that maintains the geographic based zone syntax
and have the PTR record registered via this connection
suffix and not the AD domain suffix.

Is this possible and if so, how is it accomplished?

Yes it is possible, you'll need to assign option 015 on the DHCP for each
region, then have a zone for each region name in DNS.

You'll have to use DHCP that supports BIND's implementation of DDNS, or
clients that support DDNS because Windows DHCP won't register in a BIND DNS.