Hi,
I've got two bind9 servers, one master (192.168.2.251) and one slave
(192.168.2.252).
I've configured zone transfers, and after a change of a zone on the
master, the slave gets the notification, downloads successfully the
new zone file, but still has
On NS #2, if you run rndc freeze/rndc thaw, what does the actual zone file
look like? Also, what does your cache look like? Is
101.250.168.192.in-addr.arpa PTR cached?
John
On Thu, Jul 24, 2014 at 10:25 AM, Ricardo Esteves maverick...@gmail.com
wrote:
Hi,
I've got two bind9 servers, one
Hi,
It seems it's taking some time to sync after the transfer, because
now it resolves ok with the new data.
nslookup 192.168.250.101 192.168.2.251
Server: 192.168.2.251
Address: 192.168.2.251#53
101.250.168.192.in-addr.arpa name =
To check your cache, just run rndc dump. It'll write a dump of the BIND
cache to your data directory (wherever you've got it configured).
John
On Thu, Jul 24, 2014 at 10:51 AM, Ricardo Esteves maverick...@gmail.com
wrote:
Hi,
It seems it's taking some time to sync after the transfer,
+1.
Both Windows and Mac cache DNS records, so if you had the old one cached
prior to making the change, you'd either have to flush your local cache or
wait for the record's TTL to expire.
On Linux, at least, nslookup is a deprecated tool: dig is better in many
ways. In Windows, obviously,
John Miller johnm...@brandeis.edu writes:
On Linux, at least, nslookup is a deprecated tool: dig is better in
many ways. In Windows, obviously, nslookup is all you#39;ve got by
default :-(John
in the latest Windows releases (8.1, 2012R2 Server), nslookup has been
replaced by PowerShell
6 matches
Mail list logo