DNS
--
Questions
--
Followers
Top Experts
DNS Zones not AXFR'ing from primary
I'm having a quite strange problem. It seems that some zones refuses to transfer from the master while others transfers without problems. This only happens within the Windows DNS. If I use dig there is no problems in obtaining the zonetransfer.
dnscmd /zoneinfo says that: shutdown = 1
on the zones that are not working - however, I cannot find out what that means and how to change it.
However, if I use dig AXFR to test if the server is allowed to do transfers - it works out well. Also, a lot of other zones replicates without problems from the same master.
If I take the /enumzones in dnscmd it also says "Down" on the right of the zones that are not working.
What am I missing?
dnscmd /zoneinfo says that: shutdown = 1
on the zones that are not working - however, I cannot find out what that means and how to change it.
C:\Windows\system32>dnscmdserver2 /zoneinfo domain.tld
Zone query result:
Zone info:
ptr = 000000000019F7B0
zone name = domain.tld
zone type = 2
shutdown = 1
paused = 0
update = 0
DS integrated = 0
read only zone = 0
data file = (null)
using WINS = 0
using Nbstat = 0
aging = 0
refresh interval = 0
no refresh = 0
scavenge available = 0
Zone Masters
Ptr = 0000000000194F50
MaxCount = 1
AddrCount = 1
Master[0] => af=2, salen=16, [sub=0, flag=00000000] p=13568, addr=xx.xx.xx.xx
Zone Secondaries NULL IP Array.
secure secs = 3
last successful xfr = not since restart (0)
last successful SOA check = not since restart (0)
last transfer attempt = not since restart (0)
last transfer result = 0
However, if I use dig AXFR to test if the server is allowed to do transfers - it works out well. Also, a lot of other zones replicates without problems from the same master.
C:\dig>dig axfr @ns1.domain.tld querydomain.tld
; <<>> DiG 9.3.2 <<>> axfr @ns1.domain.tld querydomain.tld
; (1 server found)
;; global options: printcmd
querydomain.tld. 3600 IN SOA ns1.domain.tld. hostmaster.domain.tld. 27 900 600 86400 3600
querydomain.tld. 3600 IN NS ns5.domain.tld.
querydomain.tld. 3600 IN NS ns3.domain.tld.
querydomain.tld. 3600 IN NS ns1.domain.tld.
querydomain.tld. 3600 IN NS ns2.domain.tld.
querydomain.tld. 3600 IN NS ns4.domain.tld.
querydomain.tld. 3600 IN CNAME www.bilbasen.dk.
ns3.domain.tld. 3600 IN A xxx.xxx.xxx.xxx
ns2.domain.tld. 3600 IN A xxx.xxx.xxx.xxx
querydomain.tld. 3600 IN SOA ns1.domain.tld. hostmaster.domain.tld. 27 900 600 86400 3600
;; Query time: 234 msec
;; SERVER: xx.xx.xx.xx#53(xx.xx.xx.xx)
;; WHEN: Thu Jul 08 13:46:25 2010
;; XFR size: 11 records (messages 11)
If I take the /enumzones in dnscmd it also says "Down" on the right of the zones that are not working.
What am I missing?
Zero AI Policy
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
Do you have a record for the seconday NS setup in the zones on the primary?
If the primary does not acknowledge that the server is a secondary it will not transfer the zone.
If the primary does not acknowledge that the server is a secondary it will not transfer the zone.
The primary nameserver knows about the secondary server, also the primary does allow the secondary to transfer zones. There are no problems in transfering zones using the dig command from the secondary server.
Also there are hundreds of other zones working in this setup. This is why I find it very strange that only certain zones does not work.
Also there are hundreds of other zones working in this setup. This is why I find it very strange that only certain zones does not work.
In each zone though, there needs to be a NS record for the secondary server. Regardless of whether the root server itself knows about the secondary.
Make sure the zones that do not work have that NS record for the secondary server.
And dig should not return AXFRs, that is a HUGE security hole.
Make sure the zones that do not work have that NS record for the secondary server.
And dig should not return AXFRs, that is a HUGE security hole.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
The NS records are in place.
And yes, of course dig should be able to AXFR as long as it is done from the secondary nameserver, the one that is supposed to run the zone secondarily.
The primary server only allows AXFR's to the secondary servers given in NS records.
Everything is set up _equally_ for more than 500 zones and all of them except for around 20 are not working, however there are no settings that are different when probing them except for the "shutdown" bit shown in ZoneInfo with dnscmd.
And yes, of course dig should be able to AXFR as long as it is done from the secondary nameserver, the one that is supposed to run the zone secondarily.
The primary server only allows AXFR's to the secondary servers given in NS records.
Everything is set up _equally_ for more than 500 zones and all of them except for around 20 are not working, however there are no settings that are different when probing them except for the "shutdown" bit shown in ZoneInfo with dnscmd.
In your event viewer, are you getting errors in the DNS event log on the secondary server?
ASKER CERTIFIED SOLUTION
membership
Log in or create a free account to see answer.
Signing up is free and takes 30 seconds. No credit card required.
So I was correct several posts ago when I said you needed to verify the NS records?
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
The NS records in the actual zone were correct, but there was also placed a wrong CNAME record on the primary nameserver.
DNS
--
Questions
--
Followers
Top Experts
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.