Can anyone from ISC comment on what Linux kernel version(s) they are seeing
the issue described at
https://deepthought.isc.org/article/AA-01213/0/What-causes-refresh%3A-failure-trying-master-...%3A-operation-canceled-error-messages.html
on and whether there is any new info on this issue that might
In message <552bb1d3.10...@imperial.ac.uk>, Phil Mayers writes:
> On 11/04/15 14:03, Chuck Anderson wrote:
>
> > I can't stop clients from making certain kinds of queries (unless BIND
> > has a feature to refuse such queries or not recurse for them?).
> > Whenever a client makes the 'ANY' query,
On Mon, Apr 13, 2015 at 11:17:41AM -0700, Frank Even wrote:
> I have to apologize for that. I'd still definitely be curious to know
> what info is stored in the ADB though since according to the docs ADB
> was never intended to be flushed with a "flushtree" (although that has
> now apparently been
On Mon, Apr 13, 2015 at 11:10 AM, Evan Hunt wrote:
> On Mon, Apr 13, 2015 at 11:05:05AM -0700, Frank Even wrote:
>> ...and where could I find info on what is stored in ADB and any other
>> particular items that flushname might not deal with? That's where my
>> frustration largely is, that I can't
On Mon, Apr 13, 2015 at 11:05:05AM -0700, Frank Even wrote:
> ...and where could I find info on what is stored in ADB and any other
> particular items that flushname might not deal with? That's where my
> frustration largely is, that I can't find clear documentation on this
> point.
I believe "rn
On Sat, Apr 11, 2015 at 6:49 AM, Tony Finch wrote:
> There was a bug in 9.9 and earlier that rndc flushtree only flushed the main
> cache, not adb or bad cache. This was fixed in 9.10 - see item 3606 in the
> CHANGES file.
...and where could I find info on what is stored in ADB and any other
pa
I think showing this line on start is a good thing. I'm updating our DNS
servers regularly and debugging a problem and checking the old logs it's
useful to find which version was running at the time and how it was built.
Emil
On Mon, Apr 13, 2015 at 8:19 PM, Alan Clegg wrote:
>
>
> On 4/13/15 1
On 4/13/15 1:18 PM, Reindl Harald wrote:
> Am 13.04.2015 um 19:14 schrieb SH Development:
>> For me, it’s in the interest of keeping clean easy to read log files.
>> Seems like this info should be available to turn on and off when
>> needed for debugging, not every time the config is changed.
>
Am 13.04.2015 um 19:14 schrieb SH Development:
For me, it’s in the interest of keeping clean easy to read log files. Seems
like this info should be available to turn on and off when needed for
debugging, not every time the config is changed.
this line appears only when named is started
in
For me, it’s in the interest of keeping clean easy to read log files. Seems
like this info should be available to turn on and off when needed for
debugging, not every time the config is changed.
Jeff
> On Apr 13, 2015, at 9:10 AM, Alan Clegg wrote:
>
> On 4/13/15 2:08 AM, SH Development wro
On 13/04/15 14:28, Tony Finch wrote:
Phil Mayers wrote:
Be interesting to see what happens. I like the NSEC/TYPExxx idea for
simplicity.
The best suggestion so far is
http://www.ietf.org/mail-archive/web/dnsop/current/msg13945.html
Nice, didn't spot that one.
__
On 4/13/15 2:08 AM, SH Development wrote:
> Is there a way to suppress the build information in the log every time BIND
> restarts/reloads? I’m getting:
>
> built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu'
> '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--
Phil Mayers wrote:
>
> Be interesting to see what happens. I like the NSEC/TYPExxx idea for
> simplicity.
The best suggestion so far is
http://www.ietf.org/mail-archive/web/dnsop/current/msg13945.html
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Tyne, Dogger: Variable 3 or 4, becoming southwe
On 13/04/15 14:12, Tony Finch wrote:
Phil Mayers wrote:
Ah ha. This is interesting.
If you like that you'll loathe this:
http://www.ietf.org/mail-archive/web/dnsop/current/msg13667.html
Yowza! The threads surrounding that one... I see djb chimed in.
ANY is useful. It would be a marginal p
Phil Mayers wrote:
>
> Ah ha. This is interesting.
If you like that you'll loathe this:
http://www.ietf.org/mail-archive/web/dnsop/current/msg13667.html
There has been a fair amount of discussion about taming ANY queries on the
dnsop list in recent weeks, though it has mostly focussed on positiv
On 13/04/15 13:48, Tony Finch wrote:
Phil Mayers wrote:
TBH I wonder if bind mightn't be better caching ANY as a separate
pseudo-type, if I'm understanding the problem correctly.
Actually I think you are asking for BIND not to treat ANY specially :-)
Maybe. I don't have ANY (ha! ha! oh my
Phil Mayers wrote:
>
> TBH I wonder if bind mightn't be better caching ANY as a separate
> pseudo-type, if I'm understanding the problem correctly.
Actually I think you are asking for BIND not to treat ANY specially :-)
If BIND gets a positive answer to an ANY query, it caches each RRset from
th
On 11/04/15 14:03, Chuck Anderson wrote:
I can't stop clients from making certain kinds of queries (unless BIND
has a feature to refuse such queries or not recurse for them?).
Whenever a client makes the 'ANY' query, it effectively causes a DoS
on that name. Luckily the MinTTL is only 30 second
Am 13.04.2015 um 08:08 schrieb SH Development:
Is there a way to suppress the build information in the log every time BIND
restarts/reloads? I’m getting:
to filter that out is the job of the syslog daemon
rsyslog.conf:
:msg, contains, "host=x86_64-redhat-linux-gnu" stop
built with '--bui
19 matches
Mail list logo
