No subject
Tue Apr 2 00:56:56 UTC 2013
#dig sap-server.abc.com
; <<>> DiG 2.0 <<>> sap-server
;; ->>HEADER<<- opcode: QUERY , status: NXDOMAIN, id: 6
;; flags: qr aa rd ra ; Ques: 1, Ans: 0, Auth: 1, Addit: 0
;; QUESTIONS:
;; sap-server.abc.com, type = A, class = IN
;; AUTHORITY RECORDS:
abc.com. 86400 SOA ns1.abc.com. root.ns1.abc.com. (
122 ;serial
3600 ;refresh
3600 ;retry
604800 ;expire
86400 ) ;minim
;; Sent 1 pkts, answer found in time: 13 msec
;; FROM:bx1 to SERVER: default -- 10.0.0.22
;; WHEN: Wed Sep 15 11:23:41 1999
;; MSG SIZE sent: 50 rcvd: 118
The serial number for this record is actually pulling the files
for the external dns records. This is really strange, since the
/etc/resolv.conf
files are pointed to the appropriate dns server.
Some notes:
*adding a static ip address for the sap-server on server 2 works
and a response can be generated via dig, similar to the response
for server 1
* the ip address for sap-server is pingable
* the internal named instance is master and the server1 named
process is slave, ie....server1 internal is primary , and server2 is
secondary...basically the records are identical
<Question 1>: Why am i receiving the dig response from the external
server (since the registration # 122 is for the external server) ?
Why don't i obtain the same outcome when i run dig on the
server 1?
Does this have to do with server 2
having two interfaces doing named for the same domain, and
named not knowing which one is authoritative?
<Question 2>: On server 2, I have pointed the /etc/resolv.conf to the
internal
ip address, named is running appropriately and listening on that ip,
why am i pulling the external db records? Is it because the named
process on the external is authoritative over the whole domain?
Details if you please....
<Question 3>: How do i resolve this problem to get server2 to
be able to resolve this sap-server?
<Question 4>: What needs to change in server 2 to accomodate
this change?
Thanks in advance....If possible as much detail would be helpful
i can clarify anything...
Thanks.
Warmest regards,
A. Rahman
Systems Engineer
More information about the bind-users
mailing list