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
Jukka Pakkanen jukka.pakka...@qnet.fi 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.
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
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
bsfin...@anl.gov kirjoitti:
Jukka Pakkanen jukka.pakka...@qnet.fi 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,
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 j...@imaginenetworksllc.com 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
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
Josh Luthman j...@imaginenetworksllc.com 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
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 jr...@isc.org
To: Krash, Paul
Cc: bind-users@lists.isc.org bind-users@lists.isc.org
Sent: Mon Nov 02 09:09:50 2009
Subject: Re: multiple
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
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
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
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
match
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 mailman.834.1256928257.14796.bind-us...@lists.isc.org,
Kevin Darcy k...@chrysler.com 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
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 enough
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 our
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
In article mailman.858.1257173865.14796.bind-us...@lists.isc.org,
Paul Krash pkr...@exegy.com 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
In article mailman.872.1257181286.14796.bind-us...@lists.isc.org,
Josh Luthman j...@imaginenetworksllc.com 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.
27 matches
Mail list logo
