On Tue, 28 Jun 2011, Cathy Almond wrote:
BIND does take notice of this and it's something we're looking at to
make better in future releases. But at the moment it's not foolproof
and its effectiveness is dependent on circumstances.
There is short term caching of learned 'we don't support EDNS'
On 27/06/11 16:39, Paul Wouters wrote:
> On Mon, 27 Jun 2011, Florian Weimer wrote:
>
>>> 1 Is this problem happening because EDNS failure is not remembered for
>>> forwarders?
>>
>> There is no realiable way to detect EDNS support in forwarders, so there
>> isn't anything to remember, really. Sa
On Mon, 27 Jun 2011, Florian Weimer wrote:
1 Is this problem happening because EDNS failure is not remembered for
forwarders?
There is no realiable way to detect EDNS support in forwarders, so there
isn't anything to remember, really. Sadly, the situation with
authoritative servers is not muc
* Paul Wouters:
> 1 Is this problem happening because EDNS failure is not remembered for
> forwarders?
There is no realiable way to detect EDNS support in forwarders, so there
isn't anything to remember, really. Sadly, the situation with
authoritative servers is not much better.
--
Florian Wei
Hi Paul,
Which version of named are you running? You've likely run into an issue
that we've seen before - basically, as you have surmised, your server
has to retry each query and never gets a response regarding edns (so it
can't "remember"). Let me know which version you are running and I'll
Hi,
I'm investigating an outage that happened on a bind server. It was
configured as a caching resolving name server. It was forwarding for
one specific zone. This zone had two nameservers/forwarders of which one
at some point was unreachable due to a cable cut. The other nameserver
turned out t
6 matches
Mail list logo
