Has there been any word on when (if?) a new edition of "DNS and BIND" will be
available covering BIND 10?
James.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.
In message <512d0222.5020...@chrysler.com>, Kevin Darcy writes:
> If all you want to do is run a private namespace, I wouldn't be fiddling
> around with forwarding at all. Set up your own root zone, propagate a
> private set of hints data, and be happy. I know that you once thrived in
> such a
Hi Robert,
On Feb 26, 2013, at 2:23 PM, Robert Moskowitz 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 logging categ
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
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 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
hey, Kevin, hope you are hanging well back at the old stomping ground!
On 02/26/2013 01:42 PM, Kevin Darcy wrote:
On 2/26/2013 11:39 AM, Robert Moskowitz wrote:
On 02/26/2013 11:14 AM, Phil Mayers wrote:
On 26/02/13 16:07, Robert Moskowitz wrote:
And I am having challenges with the forward
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 https://lists.isc.org/
On 2/26/2013 11:39 AM, Robert Moskowitz wrote:
On 02/26/2013 11:14 AM, Phil Mayers wrote:
On 26/02/13 16:07, Robert Moskowitz wrote:
And I am having challenges with the forward option. It reads that
'forward only' will always ask the forwarder about the query and seems
to defeat caching? An
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 Feb 25, 2013, at 8:25 PM, Robert Moskowitz wrote:
> So should I change this to an include and put dnssec-validation back to yes?
No. "dnssec-validation auto;" is correct for 90% of cases. An Internet
validating resolver should almost certainly use this. Mark is simply being
precise and comple
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 loca
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.
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 mailserv
> From: Daniel McDonald
> 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 recursive server pointing
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, zen.spamha
On 2/26/13 10: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 n
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
On 02/26/2013 11:14 AM, Phil Mayers wrote:
On 26/02/13 16:07, Robert Moskowitz wrote:
And I am having challenges with the forward option. It reads that
'forward only' will always ask the forwarder about the query and seems
to defeat caching? And 'forward first' only looks in cache after a
fo
On 26/02/13 16:07, Robert Moskowitz wrote:
And I am having challenges with the forward option. It reads that
'forward only' will always ask the forwarder about the query and seems
to defeat caching? And 'forward first' only looks in cache after a
forward fails? This does not sound right and I
So now I am working on adding a name caching service to my mailserver.
And I am reading up on namecaching. For RHEL/Centos, there is not much
to doing this as the default install of bind SEEMS to be a name caching
server. But I want it to NOT go out on the net for queries, but to
direct all
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 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
tha
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 assumin
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 o
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.
Lo
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 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 d
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. S
29 matches
Mail list logo
