Bind Failing no Reason on some Clients
-
I have about 40 clients in a zone with a reverse zone as well that is across 4 subnets i.e 192.168.0.1 x.x.1.1 x.x.2.1 x.x.3.1
I have had corrupted jnl files in the bind DB that where not synced (for whatevrer reason)
These days I cant add any new PTR records without dig failing to recognise them
I am at a loss :(
Here is a copy of my zone file … the last 2 entrys dont work dream2 and dreamdev
$TTL 7200
;
$ORIGIN greeta.local.; Database file greeta.local.DB for greeta.local zone.
; Do not edit this file!!!
; Zone version 2477802727
;
greeta.local. IN SOA davinci.greeta.local. zonemaster.greeta.local. (
2477802727 ; serial
1d ; refresh
2h ; retry
4w ; expire
1h ; default_ttl
);
; Zone Records
;
@ IN NS davinci.greeta.local.
@ IN A 192.168.1.1
box IN A 192.168.1.2
nas IN A 192.168.1.3
davinci IN A 192.168.1.1
ns1 IN CNAME davinci.greeta.local.
cisco IN A 192.168.1.253
davinci IN A 192.168.0.1
davinci IN A 192.168.2.1
davinci IN A 192.168.3.1
neptune IN A 192.168.1.4
rabbit IN A 192.168.1.5
venus IN A 192.168.1.6
falcon IN A 192.168.1.7
dream IN A 192.168.1.8
cog-cont IN A 192.168.1.9
code IN A 192.168.1.10
cog-sql IN A 192.168.1.11
octopus IN A 192.168.1.20
qq IN A 192.168.1.30
soa IN A 192.168.1.40
mars IN A 192.168.2.10
ready IN A 192.168.2.11
bert IN A 192.168.2.2
pluto IN A 192.168.2.5
elvis IN A 192.168.2.6
sqlprod IN A 192.168.2.50
@ IN PTR 192.168.1.1
saas IN PTR 192.168.2.22
kermit IN PTR 192.168.2.40
ernie IN PTR 192.168.1.50
micro IN PTR 192.168.1.51
fuckit IN PTR 192.168.2.44
dream2 IN PTR 192.168.2.66
dreamdev IN PTR 192.168.1.12Any help would be appreciated
thanks
justin
Cant even find itself
C:\WINDOWS\system32>nslookup 192.168.1.1
Server: UnKnown
Address: 192.168.1.1*** UnKnown can't find 192.168.1.1: Server failed
C:\WINDOWS\system32>dig davinci.greeta.local
; <<>> DiG 9.11.0 <<>> davinci.greeta.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31571
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;davinci.greeta.local. IN A;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Mon Nov 21 18:16:22 AUS Eastern Daylight Time 2016
;; MSG SIZE rcvd: 49C:\WINDOWS\system32> :(
-
So did you delete the jnl files? There is some other thread or redmine talking about editing the zone while its live causing issues.
-
A couple of things
- I forget this is a Linux based and windows has made me extremely flipant in the way i do things…i.e bull in a china shop
- Having DHCP on a subnet with static DNS entries also means there are operations occurring at any/all times
- Delete the JNL files and FFS stop the Bind service when you are updating the DNS tables
There is one rig that wont play ball out of about 60, but Im cool with that ???
Check the system Logs as they will tell you what the problem is when DNS resolution is failing
Old Windows habbits of treating machines badly die hard but pfsense and my new friend ubuntu are setting me on the right path.
I am converting all my services off MS based servers and onto ubuntu
-
To add some extra insight
I was running a 168.192.in.appra reverse zone across 4 subnets
I have created a seperate 1.168.192inappra 2.168.192.inappra for each
Also removed DHCP on prod and PreProd Subnets seem to have settled things to a certain extent
I have replaced DIG on all all windows machines and was strange that DIG would fail but nslookup would not
Have still not been able to get suffix domain lookup working on all but the primary subnet i.e 192.168.1.1
I have been experiencing machines not resolving and then a couple of hours later they do. I am sure i am missing something as i cant believe things can be this troublesome
Yip
P.S Learning Lots and Windows is dead to me ina lot of ways ;)
-
"1.168.192inappra" certainly is not a valid reverse zone declaration.
-
What client you use to query shouldn't really matter.. So where do you doing query for any or something vs A..
This stuff is really pretty basic troubleshooting. But we need something to go off of.. like the output of your query, your exact query. Your exact setup. Log of bind when you did the query, etc.