Hello List
Today our bind server started with the following log contents:
11-Mar-2019 07:41:06.599 general: warning: dns_dnssec_findzonekeys2: error
reading
/usr/local/etc/namedb/keys/glattweb.ch/Kglattweb.ch.+013+33518.private: file
not found
11-Mar-2019 07:41:06.600 general: warning:
>On 4 Mar 2019, at 16:20, Paul Kosinski wrote:
>> provides our users with general caching DNS service for
>> all other domains.
>
>[...]
>
>> Its "named.conf" file doesn't list any "forwarders" any more, and
>> "forward-only" is gone, but it still has a leftover "recursion yes"
>> clause. Am I
You are using the wrong control.
Max-udp-size is what you want.
--
Mark Andrews
> On 11 Mar 2019, at 20:14, Stéphane Bortzmeyer wrote:
>
> This machine has 'edns-udp-size: 1432' and, indeed, in the reply, it
> displays this buffer size. But it does not respect that limit. Here,
> with a big
This machine has 'edns-udp-size: 1432' and, indeed, in the reply, it
displays this buffer size. But it does not respect that limit. Here,
with a big DNSKEY RRset, BIND should have truncated the answer and set
the TC bit but it didn't:
% dig @194.0.9.1 DNSKEY ma
; <<>> DiG 9.10.3-P4-Debian <<>>
Because you removed the key from disk before it was removed from the zone.
Presumably named
was logging other error messages before you removed the key from disk or the
machine was off
for a period or you mismanaged the key roll and named keep the key alive.
Named’s re-signing strategy is
Hi list
We're sometimes receiving the same error as described in
https://gitlab.isc.org/isc-projects/bind9/issues/256 after reloading BIND.
zone example.com/IN (signed): receive_secure_serial: unchanged
What does this error exactly means? What can I do to prevent this error?
It seems, that
On Mon, Mar 11, 2019 at 09:39:58PM +1100,
Mark Andrews wrote
a message of 119 lines which said:
> You are using the wrong control.
> Max-udp-size is what you want.
Thanks it works as expected now.
% dig +ignore @194.0.9.1 DNSKEY ma
; <<>> DiG 9.10.3-P4-Debian <<>> +ignore @194.0.9.1
On Mon, Mar 11, 2019 at 12:57:02PM +,
Tony Finch wrote
a message of 40 lines which said:
> > ; <<>> DiG 9.10.3-P4-Debian <<>> @194.0.9.1 DNSKEY ma
>
> To properly diagnose UDP message size issues you need +ignore +notcp on
> the command line. (You actually need both options to stop dig
Stéphane Bortzmeyer wrote:
>
> Does minimal-responses make sense for an authoritative name server?
> (Note there was no glue involved.)
I think it helps reduce fragmentation if the max-udp-size is larger than
the MSS, but apart from that it probably doesn't make much difference.
As far as I can
Stéphane Bortzmeyer wrote:
> ; <<>> DiG 9.10.3-P4-Debian <<>> @194.0.9.1 DNSKEY ma
To properly diagnose UDP message size issues you need +ignore +notcp on
the command line. (You actually need both options to stop dig using TCP in
all situations.) The response you pasted looked to me like what I
On 11-Mar-19 03:52, Mark Andrews wrote:
> Because you removed the key from disk before it was removed from the zone.
> Presumably named
> was logging other error messages before you removed the key from disk or the
> machine was off
> for a period or you mismanaged the key roll and named keep
I actually HATE this behaviour by TLDs. There is no need to restrict the EDNS
UDP size at the authoritative server to prevent fragmentation. If the path
block fragments the client will adjust their EDNS UDP size to match. If the
path supports fragmentation (which is the actual RFC requirement)
12 matches
Mail list logo
