My issue is that (both of) my AD servers will not even attempt to reload or
transfer the zones from the master (BIND) server. I've triple checked all the
settings on both sides and do not see any issues with the configuration. I've
also checked for connectivity between the two servers. I've even deleted the
zones on the Windows servers and recreated them. One of the zones I'm trying
to add is brand new and the other is an old one that I'm trying to update the
zone on (it's about a year behind on the serial # it has vs. the new one).
When I right click either zone and select reload from master or transfer from
master it instantly fails without any explanation in the event logs. Also I
never see any attempt to transfer according to my Linux server logs.
Can anyone help? This is extremely frustrating and I need to get DNS service
up for these zones ASAP on my AD side of my network.
Thanks!
Have you enabled dns debugging?
Have you attempted to run Wireshark to see if you see any traffic on the
wire?
Have you run any diagnostics at all such as dnscmd?
dnscmd /zoneinfo zone_name_failing
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009
Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
"roitsupport" <roits...@discussions.microsoft.com> wrote in message
news:D0F7CFAB-A886-4FBE...@microsoft.com...
Silly question: Can either AD server query the master server via
nslookup or use it as their DNS server?
Grant. . . .
As Paul mentioned, I would suggest to use Wireshark to determine if the
transfer request is actually reaching the master. Keep in mind, TCP & UDP 53
both need to be opened to make this work.
--
Ace
This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.
Please reply back to the newsgroup or forum for collaboration benefit among
responding engineers, and to help others benefit from your resolution.
Ace Fekay, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA
2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
For urgent issues, please contact Microsoft PSS directly. Please check
http://support.microsoft.com for regional support phone numbers.
No firewall blocking traffic. I can telnet to port 53 both from the Windows
server to the Linux server and vise versa.
I do not see any attempts in the BIND logs on the Linux server where the
Windows server even tries to contact it when I force reload and transfers
from the Windows slaves.
I enabled debugging, restarted the DNS server and attempted to transfer and
reload the zone again from the master and I get nothing relating to transfers
in the debug file. The only thing I have in there is normal activity.
Wireshark traces show SOA queries to the Linux server upon manually doing
"transfer from master". When the Windows server does the standard query SOA,
the Linux server returns the standard query response with the domain name,
type SOA and then a list of root servers.
Shouldn't the Windows server request a zone transfer rather than a SOA query
if it wants to receive a copy of the zone?
"Paul Bergson [MVP-DS]" wrote:
> .
>
That's unusual. Telnet uses TCP, so that's not the best thing to test it
with. Transfers use UDP. Is anything blocking UDP, such as on the server
itself (a security app?) or in the firewall? If you delete the secondary,
and recreate it, does it work?
Ace
Actually, it's not _that_ bad a choice in this one specific
instance.
AF> Transfers use UDP.
No. Ordinary AXFR "zone transfers" use DNS/TCP.
<URL:http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dns-
shaped-firewall-holes.html#ZoneTransfer>
And although there is a SOA lookup preceding the actual transfer, it
just so happens that Microsoft's DNS server (incorrectly) uses DNS/TCP
to do that as well.
<URL:http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dns-
shaped-firewall-holes.html#ZoneTransferAdditional>
Then something is wrong. The NS resource records in the response
should be for the zone being queried. Let me make a guess at the most
obvious cause: You've mis-spelled the zone name at the Microsoft DNS
end.
The runner up cause, by the way, is forgetting to configure and
populate the zone on the BIND server in the first place.
r> Shouldn't the Windows server request a zone transfer rather than
r> a SOA query if it wants to receive a copy of the zone?
Most "zone transfer" clients, including the "zone transfer" client in
Microsoft's DNS server, do an SOA query first. Only then, after they
receive a successful response, do they actually perform the task that
they are there to do. They do this so that they can check that they
even need to do the "zone transfer" in the first place. It's a short-
cut optimization to prevent unnecessary duplicate transfers, that is
based upon the "SERIAL" field of the SOA resource record.
<URL:http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dns-soa-
field-semantics.html#Replication>
You're going to have to tell us what the SOA response from the BIND
server actually is if you want more help with this. Don't expect
people whom you haven't told the exact contents of the SOA and NS
records in the response to diagnose from thin air what the problem
actually is.