<div>
<br />
Reverse Lookup Zones have separate delegation paths from Forward Lookup Zones. That is, a delegation for c-dom won't help at all with reverse lookup for associated records in that zone.<br />
<br />
2003 is a bit odd about Conditional Forwarders for Reverse Lookup Zones. It can be done, but you'll never be able to use the GUI to manage Forwarders from that point on.<br />
<br />
This is simply because Reverse Lookup zones are like d.c.b.a.in-addr.arpa (for the ip a.b.c.d), a conditional forwarder would have to be written to forward requests for c.b.a.in-addr.arpa to the appropriate DNS Servers. The irritation comes when MS DNS &quot;helpfully&quot; changes the in-addr.arpa form to the &quot;friendly&quot; form a.b.c.x Subnet. If you go in via the GUI again it tells you the forwarder is invalid and you must remove it to make further changes through the GUI.<br />
<br />
Windows 2008 doesn't suffer from this problem at all, thankfully.<br />
<br />
Instead of all that, if all your servers are 2003 I'd recommend changing the replication scope of the Reverse Lookup Zones to All DNS Servers in the Forest. It represents a very small amount of data and will make it available to all servers with little trouble.<br />
<br />
HTH<br />
<br />
Chris<br />

</div>


<div>
Thanks for that info.<br />
Why do all of the internet reverse-lookups work? &nbsp;Obviously none of them are defined in any of our DNS servers.<br />
<br />
One other thing is this all worked fine before we converted the one domain to a parent-child config. &nbsp;When they were two separate domains, reverse lookups worked without issue.<br />
Thanks.
</div>


<div>
Question about your last comment...<br />
<br />
How do I change the replication scope of the Reverse Lookup Zones to All DNS Servers in the Forest?
</div>


<div>
<br />
Did you previously forward all unresolved queries rather than using conditional forwarders.<br />
<br />
The public records work for the same reason that lookups for <a href="http://www.google.com" rel="ugc">www.google.com</a>&nbsp;and such work. The Root Servers know the way to the servers responsible for the ip range zones. They're delegated in the same way that public zones are. e.g.:<br />
<br />
w.in-addr.arpa is delegated to basil.arin.net<br />
basil.arin.net knows directions to x.w.in-addr.arpa.net<br />
<br />
Continue down the chain until you arrive at z.y.x.w.in-addr.arpa.<br />
<br />
Chris<br />

</div>


<div>
<br />
The zone is AD Integrated? If so, right click on the zone and open the properties (from the DNS console). The replication scope should be one of the three options at the top.<br />
<br />
Chris<br />

</div>


<div>
I just checked and in both domains they are already set to to &quot;Replication: All DNS Servers in the Forest&quot;. &nbsp;<br />
To further clarify, these are two different forests.<br />
Is there anything that can be done between two different forests?
</div>


<div>
<br />
Ahh apologies, didn't realise they were separate.<br />
<br />
Given that Conditional Forwarders make life difficult I would normally go for either a delegation or a Secondary Zone.<br />
<br />
The Delegation would require you to host a zone one level above the zones in question.<br />
<br />
e.g.<br />
<br />
Domain 1 - 10.10.x.x<br />
Domain 2 - 10.20.x.x<br />
<br />
You would create a zone for 10.x.x.x (or 10.in-addr.arpa) then delegate 10 and 20 down to their respective DNS servers.<br />
<br />
The Secondary zone would require permission to Transfer the zone from the master, and TCP Port 53 to be open.<br />
<br />
Chris<br />

</div>


<div>
No problem. &nbsp;I didn't specifically say that in my first comment.<br />
<br />
So in my organization, I have:<br />
<br />
the c-dom domain is all 10.10.x.x addresses<br />
<br />
the t-dom domain is 172.16.x.x<br />
<br />
I understand about your example but are you saying to put a 172.16.x.x reference into the parent child domain and a 10.10.x.x in the t-dom domain?<br />
<br />
When I look in Reverse lookup zones on the c-dom domain I see:<br />
10.10.x.x subnet<br />
10.20.x.x subnet<br />
etc.<br />
<br />
In the t-dom Reveress lookup zones I see:<br />
172.16.x.x subnet<br />
<br />
So, I would select new reverse lookup zone, secondary zone, 172.16 etc.?
</div>


<div>
<br />
&gt;&nbsp;I understand about your example but are you saying to put a 172.16.x.x reference into the parent child <br />
&gt;&nbsp;domain and a 10.10.x.x in the t-dom domain?<br />
<br />
Doesn't work well for the 172.x.x.x. subnet, part of that is public and taking a level up to provide a delegation would tend to break things we don't want breaking.<br />
<br />
So instead you're better going with the Secondary Zones, your naming is right. That'll give you a zone called 16.172.in-addr.arpa (it'll show you that zone name with View \ Advanced).<br />
<br />
It's a bit annoying, that 2003 can't quite deal with the conditional forwarders properly. It being fixed in 2008 isn't much help if you don't have those :)<br />
<br />
Chris<br />

</div>


<div>
Ok, I tried this but it isn't working yet.<br />
<br />
The Seconday zones are showing status: expired.<br />
And have a big red x through them.<br />
I tried putting them in an 172.16.x<br />
and<br />
172.16.1.x<br />
Both give the same results.<br />
Am I following your recommendation correctly?
</div>


<div>
<br />
<br />
&nbsp;It'll expire if it fails to retrieve a zone for the duration of the expiry interval.<br />
<br />
Expired already? That implies and extremely low Expiry time in the source Start of Authority Record. I think AD defaults that to rather silly low figure. I'd ramp that up to a few days, or even a few months.<br />
<br />
When you first set it, did Transfer from Master run correctly?<br />
<br />
Chris<br />

</div>


<div>
More info:<br />
<br />
In the right hand pane I am getting the following info:<br />
&quot;Zone Not Loaded by DNS Server<br />
The DNS server encountered a problem while attempting to load the zone. &nbsp;The transfer of zone data from the master server failed.&quot;
</div>


<div>
I don't think it ever transferred correclty. &nbsp;It almost instantly goes to the big red X.
</div>


<div>
<br />
Okay, you did permit zone transfers to this server from the master? It's not permitted by default.<br />
<br />
Chris<br />

</div>


<div>
I hate to be dense but the master for this zone is the DNS server in the other forest that we are trying to get the reverse lookups from?<br />
<br />
How do you permit the zone transfer?<br />
<br />
Thanks again for all of your help.
</div>


<div>
<br />
That's right, yes.<br />
<br />
If you open up the zone on the master, then go to it's properties. You should have a tab there for Zone Transfers, this is where you need to grant permission to the server requesting the zone.<br />
<br />
Bear in mind that if you have Network Address Translation in operation between the two networks you'll have to take account of that when you grant permission (it'll use the IP it appears to come from rather than the real one if it's NATed).<br />
<br />
Chris<br />

</div>


<div>
Ok, this is almost working now.<br />
I have it set up in both forests on all of the DNS servers (had to do them all by hand).<br />
When I first set it up the zones transferred without an issue.<br />
But now it only works one way (from the c-dom to t-dom). &nbsp;The c-dom can do forward and reverse lookups.<br />
On the t-dom side after a pretty short time it says Expired and zone transfer failed. &nbsp;The update time is 15 minutes and the expiration is 1 day.<br />
When I look in the actual zone folders it didn't transfer eveything, looks like it got aprtially done and then expired.<br />
<br />
I have them set up as Seconday zones. &nbsp;I tried changing it to primary and it changed nothing.<br />
I have not selected Primary - AD integrated. &nbsp;Does that change anything? &nbsp;Should I set it up that way?<br />
<br />
So close but yet so far....
</div>


<div>
I deleted and recreated the zone. It hasn't expired yet but it won't load the whole thing. &nbsp;In the individual subfolders I am getting about 1/4 to 1/3 of the entries from the zone. <br />
The ones that it transferred seem to be fine.<br />
<br />
When I try the soft load I get and error saying &quot;*** Can't list domain 10.10.in-addr.arpa: Querry refused.<br />
The DNS server refused tto transfer the zone...&quot;<br />
<br />
Why does it start to load but then stop?<br />
<br />
btw, in the time that I type this it has now expired again..<br />
<br />
This worked beautifully from the other side but this side is being flaky.<br />
Any ideas?
</div>


<div>
For some reason today it seems to have settled down.<br />
<br />
I have noticed this though, concerning the partial transfer of entries, when I started working on this the original zone on the master was fully populated (approx. 100 entries or more per subfolder). &nbsp;Once the zone transfer was working I noticed that there were only about 20 entries in each folder. &nbsp;Now when I look back at the master it is only populating the 20 entries. &nbsp;Most of the reverse lookup entries are not populated in the masters sub folders.<br />
I have tried deleting the secondary zones and removing the zone transfer entries but nothing has changed.<br />
<br />
Do you know why the reverse lookup zones on the masters are not fully populated?<br />
Thanks for your help!
</div>


<div>
<br />
On the master? That's odd, the transfer is entirely one way so doing that shouldn't (and couldn't) have done anything to the master.<br />
<br />
Has scavenging run over-night?<br />
<br />
Chris<br />

</div>


<div>
I might have not clarified that, I don't think that the transfer caused this.<br />
What I was saying is that do to whatever it explains why I'm seeing &quot;partial&quot; transfers. &nbsp;THey aren't really partial.<br />
I was kind of asking a different question to see if you knew of any reason why the reverse lookup zones on the masters might not be full populated. &nbsp;Sorry for the confusion.<br />
<br />
I would imagine it ran over night.<br />
When I look at the masters, they show scavenging and aging to be 6 hours.
</div>


<div>
<br />
That would make sense then :)<br />
<br />
It helps to know how frequently things attempt to Refresh / Update their records in DNS.<br />
<br />
If you're using DHCP to update DNS the DHCP server will update DNS on granting the lease, then Refresh the record half way through the lease. For a lease of 4 days that means a Refresh after 2.<br />
<br />
If the clients are updating directly the DHCP Client Server will issue one Refresh every 24 hours (unless you reboot / restart the DHCP Client Service / run &quot;ipconfig /registerdns&quot;). The DHCP client updating applies whether the server has an address granted by DHCP or not, so you might end up with statically configured systems losing PTR Records because of the low aging intervals.<br />
<br />
In addition to those, and just so it's mentioned, the NetLogon Service is responsible for registering Service Records for DCs in the Forward Lookup Zone. As with the above, the Refresh is issued once every 24 hours, unless the system is restarted or the service is restarted.<br />
<br />
Chris<br />

</div>


<div>
I am now confused.<br />
My users are getting their addresses via DHCP (which has a one day lease time).<br />
Are you saying that every time scavenging runs, I will lose reverse-lookups untll DHCP refreshes the record?<br />
<br />
I'm trying to figure out how to keep reverse-lookups populated all the time (without having to statically define all of the addresses or something like that).<br />
<br />
This all worked perfectly before we did the parent-child conversion.<br />
<br />
Do I need to extend the DHCP lease time or change the scavenging times?
</div>


<div>
<br />
I find it better to make the Aging intervals work with the DHCP Lease time. I also prefer to use slightly longer DHCP scopes (5 - 10 Days). The slower rate of change makes maintenance easy. Private IP addresses are very easy to scope for this.<br />
<br />
If I had a Lease of 10 Days I would set the No-Refresh Interval to 4 days and Refresh to 6 days (for a total matching the lease time to make sure those one-off clients are removed quickly).<br />
<br />
It works easier if you have an example.<br />
<br />
ComputerA gets a lease from the DHCP Server a 1am. As soon as the lease is issued the DHCP server updates DNS (A and PTR; Forward and Reverse) with the IP and name.<br />
<br />
Because of the 1 day Lease DHCP will attempt to Refresh the records (A and PTR) at 1pm (12 hours later).<br />
<br />
Now we need to bring in the Aging intervals. What are all those set to at the moment? This example shows a very short aging interval. No-Refresh 3 Hours, Refresh 3 Hours.<br />
<br />
For the first 3 hours nothing can Refresh the record. That's there to prevent unnecessary AD replication because of constant Refresh requests and updates to Timestamps.<br />
<br />
Next the record enters the Refresh Interval. If the record passes all the way through this without a Refresh request it will be considered Stale. If it gets Refreshed the timestamp is updated and the counter starts again at the beginning of the No-Refresh interval.<br />
<br />
In this scenario, if the Scavenging process runs between 7am and 12:59pm the record will be removed until 1pm when Refresh will change to Update and re-add the record.<br />
<br />
This becomes much more problematic if you have a slightly longer Lease, say 4 days. Then it would Update on issuing the lease, and Refresh after 2 days. The short Aging intervals in that situation means the record will be missing from DNS for quite some time.<br />
<br />
Chris<br />

</div>


<div>
<div class="content wysiwyg-content">
We have a parent-child domain setup (just went through a conversion) that can not perform reverse-DNS lookups to a second domain in our organization.<br />
The Parent domain (call it p-dom) has a single child domain (call it c-dom). &nbsp;We will be adding other child domains later.<br />
There is another domain in a different location in our company (call it t-dom)<br />
In either domain you can do a forward DNS lookup (by name) (i.e. nslookup machine1 returns 1.1.1.1) but if you turn around to do a reverse lookup (by IP address) it fails (i.e. nslookup 1.1.1.1 &nbsp;it says &nbsp;dnsserver can't find 1.1.1.1 Non-existent domain).<br />
Both domains have the appropriate forwarders defined (i.e. in t-dom there is a forwarder to c-dom AND in c-dom there is a forwarder to t-dom). &nbsp;Both domains also have forwarders defined for &quot;all other domains&quot; to go to our internet DNS servers.<br />
<br />
What am I missing? &nbsp;Is this a parent-child thing or is there something about reverse DNS lookups that I am missing.<br />
<br />
One other note is that reverse DNS lookups to the internet DO work (i.e. nslookup yahoo.com returns 68.180.206.184 and nslookup 68.180.206.184 returns w2.rc.vip.sp1.yahoo.com).<br />
<br />
Lastly there is a firewall between the two domains but there are rules to allow all IP traffic from each domain server to the other, both ways, across the firewall. Just thought I'd mention this but I don't think it enters into it.<br />
<br />
ANy help would be great!!!<br />
Thanks.
</div>
</div>


We have a parent-child domain setup (just went through a conversion) that can not perform reverse-DNS lookups to a second domain in our organization.
The Parent domain (call it p-dom) has a single child domain (call it c-dom).  We will be adding other child domains later.
There is another domain in a different location in our company (call it t-dom)
In either domain you can do a forward DNS lookup (by name) (i.e. nslookup machine1 returns 1.1.1.1) but if you turn around to do a reverse lookup (by IP address) it fails (i.e. nslookup 1.1.1.1  it says  dnsserver can't find 1.1.1.1 Non-existent domain).
Both domains have the appropriate forwarders defined (i.e. in t-dom there is a forwarder to c-dom AND in c-dom there is a forwarder to t-dom).  Both domains also have forwarders defined for "all other domains" to go to our internet DNS servers.

What am I missing?  Is this a parent-child thing or is there something about reverse DNS lookups that I am missing.

One other note is that reverse DNS lookups to the internet DO work (i.e. nslookup yahoo.com returns 68.180.206.184 and nslookup 68.180.206.184 returns w2.rc.vip.sp1.yahoo.com).

Lastly there is a firewall between the two domains but there are rules to allow all IP traffic from each domain server to the other, both ways, across the firewall. Just thought I'd mention this but I don't think it enters into it.

ANy help would be great!!!
Thanks.

Reverse DNS lookups do not work in our new parent-child domain to another domain in our organization

Windows Server 2003 was based on Windows XP and was released in four editions: Web, Standard, Enterprise and Datacenter. It also had derivative versions for clusters, storage and Microsoft’s Small Business Server. Important upgrades included integrating Internet Information Services (IIS), improvements to Active Directory (AD) and Group Policy (GP), and the migration to Automated System Recovery (ASR).

Windows Server 2003

The Domain Name System (DNS) is a hierarchical, globally distributed system responsible for associating the name of a computer, service or other resource into an IP address for connecting to the Internet or a private network. Most prominently, it translates domain names to the numerical IP addresses needed for the purpose of computer services and devices worldwide.