On Jan 16, Marco d'Itri wrote:
> > Since we finally have 9.15 in experimental, could you please try this
> > and give feedback?
> Testing.
Confirmed: 9.15 fixed this.
--
ciao,
Marco
signature.asc
Description: PGP signature
I was seeing this same issue on Ubuntu 18.04.4 running BIND 9.11.3.
DNSSEC enabled, and after restarting the system BIND wouldn't resolve addresses
until I restarted the daemon. I verified DNSSEC-Validation was set to auto and
that time was sync'd properly.
The issue was resolved, for me, by ad
On Wed, Dec 11, 2019 at 12:54:23AM +0100, Marco d'Itri wrote:
> Control: forwarded -1 https://gitlab.isc.org/isc-projects/bind9/issues/1483
>
> On Nov 24, Ondřej Surý wrote:
>
> > could you please fill an upstream issue?
> Done.
>
> I will also add that I have found a workaround: sending SIGSTO
On Jan 16, Bernhard Schmidt wrote:
> Since we finally have 9.15 in experimental, could you please try this
> and give feedback?
Testing.
BTW, you need to clean up after /usr/share/bind9/:
root@bongo:~# ls -l /usr/share/bind9/
totale 4
-rw-r--r-- 1 root root 53 Feb 20 2012 bind9-default.md5sum
Control: forwarded -1 https://gitlab.isc.org/isc-projects/bind9/issues/1483
On Nov 24, Ondřej Surý wrote:
> could you please fill an upstream issue?
Done.
I will also add that I have found a workaround: sending SIGSTOP to named
before suspend and SIGCONT a few seconds after resume.
--
ciao,
M
Marco,
could you please fill an upstream issue?
Ondřej
--
Ondřej Surý
> On 24 Nov 2019, at 19:30, Marco d'Itri wrote:
>
> On Feb 21, Marco d'Itri wrote:
>
>>> That TTL is extremely suspicious and is way longer than anything
>>> warranted by IT zone contents. Looks like the clock went back
On Feb 21, Marco d'Itri wrote:
> > That TTL is extremely suspicious and is way longer than anything
> > warranted by IT zone contents. Looks like the clock went back almost
> > seven days since the entry was added to the cache.
> I cannot see how this could be possible: the hardware clock is cor
On Feb 20, Florian Weimer wrote:
> That TTL is extremely suspicious and is way longer than anything
> warranted by IT zone contents. Looks like the clock went back almost
> seven days since the entry was added to the cache.
I cannot see how this could be possible: the hardware clock is correct
* Marco d'Itri:
> ; Bad cache
> ;
> ; intercom.it/DS [ttl 590265]
That TTL is extremely suspicious and is way longer than anything
warranted by IT zone contents. Looks like the clock went back almost
seven days since the entry was added to the cache.
I suspect what happens is this: System wakes
On Nov 18, Florian Weimer wrote:
> Is it possible that you can share the output of "rndc dumpdb"?
The relevant parts follow.
; glue
intercom.it.10790 NS adns1.intercom.it.
10790 NS adns2.intercom.it.
10790 NS adns3.
Control: -1 DNSSEC validation fails on system resume
On Nov 18, Florian Weimer wrote:
> Is your system clock correct?
>
> I wonder if this is a clock issue, or if BIND incorrectly marks the
> DLV servers as dead.
The clock is correct and this is not related to DLV.
Most of the times my laptop r
18.11.2012 14:50, Florian Weimer пишет:
> * Yury Stankevich:
>
>> 4. on resume, network will be unavailable for some time (modem load can take
>> a minutes)
>>but once modem loaded - bind will not resolve addresses and log a
>> messages like
> Is your system clock correct?
>
> I wonder if thi
* Yury Stankevich:
> 4. on resume, network will be unavailable for some time (modem load can take
> a minutes)
>but once modem loaded - bind will not resolve addresses and log a messages
> like
Is your system clock correct?
I wonder if this is a clock issue, or if BIND incorrectly marks th
Package: bind9
Version: 1:9.8.1.dfsg.P1-4.1
Severity: normal
bind can stop resolving.
steps to reproduce:
1. configure dnssec
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
2. run bind, make some work
3. suspend pc for a while, turn off modem, resume, turn o
14 matches
Mail list logo