BIND 9 API & GUI

[Kirk]

I have been looking for a way to provide both an API and a GUI interface 
for my multi-master/slave BIND infrastructure.


There are obviously many GUI options, but finding a solution that will 
allow for external programs to add/change/delete records (API), and 
allow administrators to manually make the same kinds of changes (GUI) 
without each process interfering with each other has proven more 
difficult than I expected.


This seems like it would be a common need, and I can't be the only one 
in this "bind".


Has anyone else solved this problem?


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Loaded zone files query

[Kirk Hoganson]

Does anyone know of a simple way to discover how many zone files bind 
has successfully loaded after the daemon starts?



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

bind-9.5.2 build warnings

[Kirk]

OS == Solaris 9
Compilers == Sun or GCC

Anyone know what causes these warnings?

./configure --with-openssl=no --with-libxml2=/usr/local --disable-threads

snip to last line of configure output
configure: WARNING: Unrecognized options: --with-openssl, --with-libxml2

or


./configure --without-openssl --with-libxml2=/usr/local --disable-threads

snip to last line of configure output
configure: WARNING: Unrecognized options: --without-openssl, --with-libxml2








___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Assistance with reverse lookup zone

[Kirk]

Frank Pikelner wrote:

Thank you for everyone's assistance. I have updated the zone files.
After the updates and restarting BIND, I run dig +trace ptr
170.3.187.64.in-addr.arpa and the result stops just prior to getting to
my DNS server and correctly resolving the name of the IP address. I'm
new to dig and do not know whether this is correct for an RFC2317 zone
delegation or whether the trace should be completing at my servers and
resolving the name. My guess is there must be something still incorrect
on my end. 


Though, using NSLOOKUP against opendns servers for
170.3.187.64.in-addr.arpa does resolve the name correctly.


NAMED.CONF has the zone defined as follows:

zone 162-27.3.187.64.in-addr.arpa IN {
type master;
file 64_187_3_162-27.rev;
};


The zone file looks as follows:

$ORIGIN .
$TTL 86400  ; 1 day
162-27.3.187.64.in-addr.arpa.   IN SOA  ns1.blue-dot.ca.
dnsadmin.ns1.blue-dot.ca. (
2009051202 ; serial
1800   ; refresh (30 minutes)
900; retry (15 minutes)
604800 ; expire (1 week)
1800   ; minimum (30 minutes)
)
NS  ns1.blue-dot.ca.
NS  ns2.blue-dot.ca.
NS  ns3.blue-dot.ca.
$ORIGIN 162-27.3.187.64.in-addr.arpa.
170 PTR smtp3.netcraftcommunications.com.




*Looks like its working to me.*

% dig 170.3.187.64.in-addr.arpa. ptr

;  DiG 9.4.3-P2  170.3.187.64.in-addr.arpa. ptr
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 1748
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;170.3.187.64.in-addr.arpa. IN  PTR

;; ANSWER SECTION:
170.3.187.64.in-addr.arpa. 3941 IN  CNAME   
170.162-27.3.187.64.in-addr.arpa.
170.162-27.3.187.64.in-addr.arpa. 86335 IN PTR  
smtp3.netcraftcommunications.com.

*Using dig to test at the opendns servers.*

% dig @208.67.222.222 170.3.187.64.in-addr.arpa. ptr

;  DiG 9.4.3-P2  @208.67.222.222 170.3.187.64.in-addr.arpa. ptr
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 436
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;170.3.187.64.in-addr.arpa. IN  PTR

;; ANSWER SECTION:
170.3.187.64.in-addr.arpa. 86400 IN CNAME   
170.162-27.3.187.64.in-addr.arpa.
170.162-27.3.187.64.in-addr.arpa. 86400 IN PTR  
smtp3.netcraftcommunications.com.


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Assistance with reverse lookup zone

[Kirk]

Frank Pikelner wrote:


Every now and then we get a bounce on emails that are sent through one 
of our mails servers located on 64.187.3.170. The bounce messages look 
as follows and appear to indicate that our reverse zone is missing a 
record, though the record is there and resolves through nslookup. The 
ISP delegates a number of IP addresses from the zone back to us (16 IP 
addresses). So my guess is that our zone file needs to be rewritten or 
there may be something else I'm missing.



first_l...@some_domain.com: host mx.some_domain.com[xxx.xx.xx.xx] 
said: 450 4.7.1 Client
host rejected: cannot find your hostname, [64.187.3.170] (in reply 
to RCPT

TO command)


Performing a manual reverse lookup correctly displays the correct name 
for 170.3.187.64.in-addr.arpa. Our zone file looks as follows (other 
records removed):


$ORIGIN .
$TTL 86400  ; 1 day
3.187.64.in-addr.arpa   IN SOA  ns1.blue-dot.ca. dnsadmin.ns1.blue-dot.ca. (
2009011401 ; serial
1800   ; refresh (30 minutes)
900; retry (15 minutes)
604800 ; expire (1 week)
1800   ; minimum (30 minutes)
)
NS  ns1.blue-dot.ca.
NS  ns2.blue-dot.ca.
NS  ns3.blue-dot.ca.
$ORIGIN 3.187.64.in-addr.arpa.
170 PTR smtp3.netcraftcommunications.com.




Read up on RFC2317.  Your ISP has delegated the block to you via this 
method.


Also do a dig +trace -x 64.187.3.170 to see the delegation.


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Testing - please ignore

[Kirk]

This is a test.  Please disregard.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: delegating to 3rd Windows nameserver

[Kirk]

When I do a nslookup or dig I only see the first two servers and not sec2:
--
ns-1: nslookup

 set type=ns
 _tcp.utmck.edu

Non-authoritative answer:
_tcp.utmck.edu  nameserver = pri1.utmck.edu
_tcp.utmck.edu  nameserver = sec1.utmck.edu
 
Authoritative answers can be found from:

pri1.utmck.edu   internet address = 165.6.12.12
sec1.utmck.edu  internet address = 165.6.14.13
--
 
Is there anything wrong with this configuration? Why is the sec2 server 
not seen

in the query for nameservers?
 
Thanks very much for your assistance.

Steve


try setting your query focus on the primary.


ns-1: nslookup
 server 165.6.12.12
 set type=ns
 _tcp.utmck.edu


Also, become more familiar with the dig command.  It's much better 
than nslookup.


dig @165.6.12.12 _tcp.utmck.edu. NS
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users