On 26/02/13 21:34, Bryan Harris wrote:
Hi Robert,
On Feb 26, 2013, at 2:23 PM, Robert Moskowitz r...@htt-consult.com wrote:
On 02/26/2013 01:57 PM, Doug Barton wrote:
On 02/26/2013 10:38 AM, Robert Moskowitz wrote:
I would like a scalpel for lame logging, but probably would not discover
Continuing to 'clean up' my new server by reviewing logged messages.
Researching a common one:
Feb 26 07:30:29 onlo named[19336]: error (unexpected RCODE SERVFAIL)
resolving 'foo.com/MX/IN': 1.2.3.4#53
I get the drift that my server has been directed to a 'lame server' and
logs that fact.
On 02/26/2013 08:38 AM, Robert Moskowitz wrote:
Continuing to 'clean up' my new server by reviewing logged messages.
Researching a common one:
Feb 26 07:30:29 onlo named[19336]: error (unexpected RCODE SERVFAIL)
resolving 'foo.com/MX/IN': 1.2.3.4#53
I get the drift that my server has been
On 26/02/13 13:54, Robert Moskowitz wrote:
I would be interested in which client is requesting these lookups that
end up going to lame servers. I am assuming the IP address in the log
is the address of the lame server, not the requesting client.
Look at the query logs?
On 02/26/2013 09:13 AM, Phil Mayers wrote:
On 26/02/13 13:54, Robert Moskowitz wrote:
I would be interested in which client is requesting these lookups that
end up going to lame servers. I am assuming the IP address in the log
is the address of the lame server, not the requesting client.
On 02/26/2013 09:25 AM, Robert Moskowitz wrote:
On 02/26/2013 09:13 AM, Phil Mayers wrote:
On 26/02/13 13:54, Robert Moskowitz wrote:
I would be interested in which client is requesting these lookups that
end up going to lame servers. I am assuming the IP address in the log
is the address
On 26/02/13 14:31, Robert Moskowitz wrote:
On 02/26/2013 09:25 AM, Robert Moskowitz wrote:
On 02/26/2013 09:13 AM, Phil Mayers wrote:
On 26/02/13 13:54, Robert Moskowitz wrote:
I would be interested in which client is requesting these lookups that
end up going to lame servers. I am
On 02/26/2013 09:37 AM, Phil Mayers wrote:
On 26/02/13 14:31, Robert Moskowitz wrote:
On 02/26/2013 09:25 AM, Robert Moskowitz wrote:
On 02/26/2013 09:13 AM, Phil Mayers wrote:
On 26/02/13 13:54, Robert Moskowitz wrote:
I would be interested in which client is requesting these lookups
On 26/02/13 14:50, Robert Moskowitz wrote:
Yes. Note that you can enable this by default in the options
statement. This is all pretty well documented and easy to find in the
ARM...
This is traffic I only want occationally! I am trying to reduce the
logging size to find new problems.
Fair
On 26/02/13 15:50, Robert Moskowitz wrote:
I would expect that a namecaching server on the mailserver would
reduce traffic and resources all the way around.
I don't need my mailserver to constantly be asking my name server
about, say, zen.spamhaus.org.
This is one reason my mailserver has a
On 2/26/13 10:43 AM, Sten Carlsen st...@s-carlsen.dk wrote:
On 26/02/13 15:50, Robert Moskowitz wrote:
I would expect that a namecaching server on the mailserver would reduce
traffic and resources all the way around.
I don't need my mailserver to constantly be asking my
On 02/26/2013 11:43 AM, Sten Carlsen wrote:
On 26/02/13 15:50, Robert Moskowitz wrote:
I would expect that a namecaching server on the mailserver would
reduce traffic and resources all the way around.
I don't need my mailserver to constantly be asking my name server
about, say,
From: Daniel McDonald dan.mcdon...@austinenergy.com
That's not to say that there is currently any cache-poisoning vulnerability
that someone might exploit, or that any current malware makes use of this
two-phase approach to exploit desktops. But why take the risk when setting
up bind as a
On 26/02/13 18:06, Robert Moskowitz wrote:
On 02/26/2013 11:43 AM, Sten Carlsen wrote:
On 26/02/13 15:50, Robert Moskowitz wrote:
I would expect that a namecaching server on the mailserver would
reduce traffic and resources all the way around.
I don't need my mailserver to constantly be
On 02/26/2013 12:58 PM, Sten Carlsen wrote:
On 26/02/13 18:06, Robert Moskowitz wrote:
On 02/26/2013 11:43 AM, Sten Carlsen wrote:
On 26/02/13 15:50, Robert Moskowitz wrote:
I would expect that a namecaching server on the mailserver would
reduce traffic and resources all the way around.
You want to set up your resolver on your mail server to forward to your
main resolver, using the forward only option. This will allow your mail
server resolver to benefit from the cache already populated on your main
resolver, while still maintaining the value of caching the answers
itself
On 02/26/2013 01:19 PM, Doug Barton wrote:
You want to set up your resolver on your mail server to forward to
your main resolver, using the forward only option. This will allow
your mail server resolver to benefit from the cache already populated
on your main resolver, while still maintaining
On 02/26/2013 10:38 AM, Robert Moskowitz wrote:
I would like a scalpel for lame logging, but probably would not discover
any actionable data.
There is a logging category for lame-servers. It's in the ARM.
Doug
___
Please visit
On 02/26/2013 01:57 PM, Doug Barton wrote:
On 02/26/2013 10:38 AM, Robert Moskowitz wrote:
I would like a scalpel for lame logging, but probably would not discover
any actionable data.
There is a logging category for lame-servers. It's in the ARM.
So far 2 reads and I am not getting out of
Robert wrote on 02/26/2013 02:23:44 PM:
There is a logging category for lame-servers. It's in the ARM.
So far 2 reads and I am not getting out of it what to do for selective
logging based on return codes. I am going to let it stay for now as I
move on to other parts of this project.
On 26/02/13 19:09, Robert Moskowitz wrote:
On 02/26/2013 12:58 PM, Sten Carlsen wrote:
On 26/02/13 18:06, Robert Moskowitz wrote:
On 02/26/2013 11:43 AM, Sten Carlsen wrote:
On 26/02/13 15:50, Robert Moskowitz wrote:
I would expect that a namecaching server on the mailserver would
Hi Robert,
On Feb 26, 2013, at 2:23 PM, Robert Moskowitz r...@htt-consult.com wrote:
On 02/26/2013 01:57 PM, Doug Barton wrote:
On 02/26/2013 10:38 AM, Robert Moskowitz wrote:
I would like a scalpel for lame logging, but probably would not discover
any actionable data.
There is a
22 matches
Mail list logo
