On 07.01.11 12:54, Jay G. Scott wrote:
i get, and have always gotten, billions of these messages.
Jan 2 07:37:43 ns2 named[3028]: client 10.4.1.6#33823: view internal: error
sending response: host unreachable
the story is that these are the results of attempted zone transfers.
On 07.01.11 12:08, blr maani wrote:
You can develop scripts to do the following:
Develop script(s) and run on a host which has access to both Master(s) and
Slave(s). The script should do the following:
1. For each zones, check serial number on both master(s) and slave(s) for
the zone and
hi,
thanks for the replies. however, i didn't learn much. i'm more of
a network newbie than i thought.
but what i can say is this:
(repeating the problem)
i get zillions of these msgs:
Jan 10 12:36:24 ns2 named[3037]: client 10.4.1.6#59926: view internal: error
sending response: host
Jay G. Scott wrote:
hi,
thanks for the replies. however, i didn't learn much. i'm more of
a network newbie than i thought.
but what i can say is this:
(repeating the problem)
i get zillions of these msgs:
Jan 10 12:36:24 ns2 named[3037]: client 10.4.1.6#59926: view internal: error
On Mon, Jan 10, 2011 at 12:41:48PM -0600, Jay G. Scott wrote:
hi,
thanks for the replies. however, i didn't learn much. i'm more of
a network newbie than i thought.
but what i can say is this:
(repeating the problem)
i get zillions of these msgs:
Jan 10 12:36:24 ns2 named[3037]:
I'm using bind-9.5.1-P3 (yes, I know it's old). I have a zone in
multiple views. When I update the zone and reload, the match-clients
{ any } view sees new DNS records right away, but another view
doesn't see them for a while.
Given this configuration:
view global {
match-clients {
On Mon, Jan 10, 2011 at 12:52:16PM -0600, Lyle Giese wrote:
[snip]
Jay
Please do the following two queries from the secondary server and show
us the results:
dig @146.6.211.1 +tcp arlut.utexas.edu
dig @146.6.211.1 -tcp arlut.utexas.edu
Lyle Giese
LCR Computer Services, Inc.
okay.
sorry about that. I don't normally use these options But it's
dig @146.6.211.1 +tcp arlut.utexas.edu
dig @146.6.211.1 +notcp arlut.utexas.edu
But UDP is default and the second query should have been transmitted
using UDP. The end result is that you have TCP and UDP port 53 openned
properly in
It was pointed out to me that order of views matters, and indeed I do
have the correct order in my config--I just pasted it out of order in
my original email. Here is the corrected version where I still have
this problem.
On Mon, Jan 10, 2011 at 03:09:40PM -0500, Chuck Anderson wrote:
I'm
The NOTIFY message is only going to one view (external). The simple
solution is to have the internal view transfer the zone from the
external view. I posted how to do this within the last month so
check the archives for examples.
Mark
In message 20110110200940.gn28...@angus.ind.wpi.edu, Chuck
On 1/10/2011 2:04 PM, Jay G. Scott wrote:
On Mon, Jan 10, 2011 at 12:41:48PM -0600, Jay G. Scott wrote:
hi,
thanks for the replies. however, i didn't learn much. i'm more of
a network newbie than i thought.
but what i can say is this:
(repeating the problem)
i get zillions of these msgs:
Also, you should NOT use the same filename for slave zones in different
views.
In article mailman.1305.1294698399.555.bind-us...@lists.isc.org,
Mark Andrews ma...@isc.org wrote:
The NOTIFY message is only going to one view (external). The simple
solution is to have the internal view
12 matches
Mail list logo
