On Thu, Oct 29, 2009 at 09:24:48AM +0100,
Stephane Bortzmeyer wrote
a message of 25 lines which said:
> > - Support for RFC 5011 automated trust anchor maintenance (see
> > README.rfc5011 for additional details).
Hmmm, it suddenly had a problem:
02-Nov-2009 10:59:14.945 zone manage
>> On 31.10.09 12:07, Jukka Pakkanen wrote:
>>> For some reason the slaves don't update the zone unless I restart the
>>> BIND service in the server, and after a while, fail to respond to
>>> queries.
> Matus UHLAR - fantomas kirjoitti:
>> Is the master updating SOA serial?
On 01.11.09 16:59,
In article ,
Chris Buxton wrote:
> As I recall, named-checkzone calls out to the operating system stub
> resolver to look up these names. Is there any way the stub resolver
> could be getting different data? Is there anything in the stub
> resolver config (/etc/{hosts,resolv.conf}) that mi
Matus UHLAR - fantomas kirjoitti:
On 31.10.09 12:07, Jukka Pakkanen wrote:
For some reason the slaves don't update the zone unless I restart the
BIND service in the server, and after a while, fail to respond to
queries.
Matus UHLAR - fantomas kirjoitti:
Is the mast
Morning!
I have been struggling with getting two internal views to work on three
BIND servers running on Ubuntu Linux 8.04.2 x64
( kernel 2.6.24-23-server ) for two straight working days
(OK, I have other projects too. :-)
Scope: present different CNAMES and A records to one subnet
(10.x.D.0/
Jukka Pakkanen wrote:
>Our Bind 9.6.1-P1 Windows servers are slaves to a Windows 2003 DNS
>server, zone "company.local".
>
>For some reason t he slaves don't update the zone unless I restart the
>BIND service in the server, and after a while, fail to respond to queries.
>
>Example, after a coup
I have two servers that users query that as as cache servers.
The server having the problem is CentOS 4.4 running bind 9.2.4
The second server configured similarly is CentOS 3.9 also running bind
9.2.4.
There is one A record on Godaddy's DNS servers that fails look ups on the
4.4 server start ar
It may be useful for you to show us what you tried (configurations and
that it is restarted), how you tested, and any network traces and log
files showing that it is not working.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org
The issue is that the A record no longer gets resolved.
The command dig mail.alexandertelecominc.com @firstserver times out. Not
sure what else I can provide that would help.
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
"When you have eliminated
Kevin Darcy wrote:
Daemon as unbound, pdns-recursor - much faster in recursion queries,
that bind. :(
___
So, you don't cache locally, you forward to another daemon that (in the
best case) answers from *its* cache.
How have you improved performance
> I am looking for any suggestions or ideas to help fix this issue. Thanks in
> advance!
To get good help, you may want to tell us what the issue is. Provide
real names and show your real tests. Also the version of BIND you are
using is out of date and is no longer supported.___
bsfin...@anl.gov kirjoitti:
Jukka Pakkanen wrote:
Our Bind 9.6.1-P1 Windows servers are slaves to a Windows 2003 DNS
server, zone "company.local".
For some reason t he slaves don't update the zone unless I restart the
BIND service in the server, and after a while, fail to respond to quer
Matus UHLAR - fantomas wrote:
Bind answer authoritative for all clients, and forward (if allowed)
recursive queries to recursive server.
why shouldn't it cache those responses?
Bind cache is slow. It allocate a lot of memory and make high CPU usage.
_
Josh Luthman said:
> --000e0cd32f54da30b8047764ddcc
> Content-Type: text/plain; charset=ISO-8859-1
>
> The issue is that the A record no longer gets resolved.
>
> The command dig mail.alexandertelecominc.com @firstserver times out. Not
> sure what else I can provide that would help.
Well, whe
Let me say it this way...
Starting ~7PM EST Sunday evening the command
dig mail.alexandertelecominc.com @74.218.88.168 #fails
dig mail.alexandertelecominc.com @4.2.2.2 #works
until I issue
rndc reload && /etc/init.d/named restart #on the 74.218.88.168 server
Josh Luthman
Office: 937-552-2340
D
On Mon, 2 Nov 2009, Josh Luthman wrote:
> dig mail.alexandertelecominc.com @74.218.88.168 #fails
What does "fails" mean?
> dig mail.alexandertelecominc.com @4.2.2.2 #works
>
> until I issue
>
> rndc reload && /etc/init.d/named restart #on the 74.218.88.168 server
Check named logs and look at
Josh Luthman said:
> Let me say it this way...
>
> Starting ~7PM EST Sunday evening the command
>
> dig mail.alexandertelecominc.com @74.218.88.168 #fails
> dig mail.alexandertelecominc.com @4.2.2.2 #works
>
> until I issue
>
> rndc reload && /etc/init.d/named restart #on the 74.218.88.168 se
Agreed. Will do. As time permits today. Thank you for your help!
Paul Krash from mobile +01.314.283.4942
- Original Message -
From: Jeremy C. Reed
To: Krash, Paul
Cc: bind-users@lists.isc.org
Sent: Mon Nov 02 09:09:50 2009
Subject: Re: multiple internal views not working
It may be usefu
It has happened the last 4 or 5 Sunday nights.
Currently there are no logs - what categories would you suggest I start
logging?
The server comes back with simply no response. It just times out. It
resolves every other record I could think of to ask it. Also, it may or may
not be relevant but i
Dmitry Rybin wrote:
Kevin Darcy wrote:
Daemon as unbound, pdns-recursor - much faster in recursion queries,
that bind. :(
___
So, you don't cache locally, you forward to another daemon that (in
the best case) answers from *its* cache.
How have you
> Is it serious? The file managed-keys.bind looks normal.
It's concerning. How many 5011-maintained zones are you running? Can I
see your managed-keys.bind file?
I would expect the result of this to be that keys are not properly updated
in managed-keys.bind until the problem with committing to
I you control all of the resolvers in this scenario, and the clients
aren't doing their own caching-and-reordering-of-responses, you might
consider using sortlists and round-robins instead of views. That would
get you out of having to maintain the same zones in parallel.
Note that if the clien
Jeremy C. Reed wrote:
It may be useful for you to show us what you tried (configurations and
that it is restarted), how you tested, and any network traces and log
files showing that it is not working.
All, the 'dot5' view works great. The 'internal' view does not serve.
If I reverse the view or
On Mon, 2 Nov 2009, Paul Krash wrote:
> > view internal {
> >
> > zone "eng.exegy.net" {
Do you have anything to match here? By default, match-clients and
match-destinations default to matching all addresses (even not
"internal"). So when you reversed, the other view (dot5) would never
Confused. Looks like the clients are matching the correct view, but
"fckd.net" is not defined in either view, so what exactly was the point
of having views? fckd.net names are going to get resolved the same
regardless.
- Kevin
Paul Krash wrote:
Jeremy C. Reed wrote:
It may be useful for you
Barry Margolin wrote:
In article ,
Kevin Darcy wrote:
Chris Thompson wrote:
On Oct 30 2009, Michael Hare wrote:
For those of us that are still running auth and recursive on the same
IP, I believe the benefit would be to deploy a best practices
recursive only nameserver on a
Jeremy C. Reed wrote:
>
> Do you have anything to match here? By default, match-clients and
> match-destinations default to matching all addresses (even not
> "internal"). So when you reversed, the other view (dot5) would never
> match and wouldn't work.
>
Hey Mr. Reed!
Would this statement be e
Kevin Darcy asked:
>Confused. Looks like the clients are matching the
>correct view, but "fckd.net" is not defined in either view,
> so what exactly was the point of having views? fckd.net names are
>going to get resolved the same regardless.
I attempted to obfuscate our internal domain name, Mr
Krash, Paul wrote:
Kevin Darcy asked:
Confused. Looks like the clients are matching the
correct view, but "fckd.net" is not defined in either view,
so what exactly was the point of having views? fckd.net names are
going to get resolved the same regardless.
I attempted to obfuscate ou
Kevin Darcy wrote:
Views are matched in order, so "!10.x.5.0/24;" is redundant -- anything
in that range would have been matched by the previous view.
But, but by explicitly putting it there, the ordering of the views is
no-longer important. "Better safe than sorry".
AlanC
Alan Clegg wrote:
Kevin Darcy wrote:
Views are matched in order, so "!10.x.5.0/24;" is redundant --
anything in that range would have been matched by the previous view.
But, but by explicitly putting it there, the ordering of the views is
no-longer important. "Better safe than sorry".
If I
All,
thanks so much for your help in understanding match-clients in the view
statement for zones.
For historical purposes (and future searchers) this statement works:
match clients { !10.x.5.0/24; 10.x.0.0/16; }
doesn't serve .5, but serves everything else.
Thank you Mr. Clegg (where do I s
In article ,
"Paul Krash" wrote:
> Morning!
>
> I have been struggling with getting two internal views to work on three
> BIND servers running on Ubuntu Linux 8.04.2 x64
> ( kernel 2.6.24-23-server ) for two straight working days
> (OK, I have other projects too. :-)
>
> Scope: present differ
In article ,
Josh Luthman wrote:
> It has happened the last 4 or 5 Sunday nights.
>
> Currently there are no logs - what categories would you suggest I start
> logging?
>
> The server comes back with simply no response. It just times out. It
> resolves every other record I could think of to
34 matches
Mail list logo
