Reverse Lookup zones...

  • Thread starter Thread starter Tim
  • Start date Start date
T

Tim

If I have a single site that uses a class C ip scheme
(192.168.1.x), I always create an AD intergrated Reverse
lookup zone of 192.168.1.x subnet.

What if I have more sites that uses different class C ip
schemes (192.168.2.x). Should I create another AD
intergrated Reverse Lookup zone of 192.168.2.x subnet?
 
If I have a single site that uses a class C ip scheme
(192.168.1.x), I always create an AD intergrated Reverse
lookup zone of 192.168.1.x subnet.

What if I have more sites that uses different class C ip
schemes (192.168.2.x). Should I create another AD
intergrated Reverse Lookup zone of 192.168.2.x subnet?
Click to expand...

Short answer ... YES :-)
 
T> If I have a single site that uses a class C ip scheme
T> (192.168.1.x), I always create an AD intergrated Reverse
T> lookup zone of 192.168.1.x subnet.

You should do more than that.

When employing non-public IP address ranges, one should ensure, by configuring
one's "split horizon" DNS service appropriately, that DNS queries for the
_entire_ non-public IP address range don't leak out over one's borders, even
if one doesn't happen to be using that entire address range at the moment.

So you should be handling _everything_ at and below "168.192.in-addr.arpa."
yourself, within your organization, even if you are only using a couple of
/24s within 192.168.*.* right now.

(Compare with what you are already doing with 127.*.*.*. Even though you are
very probably only using a _single_ /32 within that entire non-public IP
address range, namely 127.0.0.1, you are dealing with the _whole_ of the
namespace subtree rooted at "127.in-addr.arpa." privately.)
 
Back
Top