Also, you should NOT use the same filename for slave zones in different
views.
In article ,
Mark Andrews wrote:
> 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 wi
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:
J
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>, Chuc
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 us
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 the
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.
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-clien
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 name
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: e
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 unreach
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 zon
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.
appa
12 matches
Mail list logo
