Hi everyone,
The DNS Security Extensions (DNSSEC) add integrity and authenticity to the
Domain Name System (DNS). Now, more than 17 years after their
standardization, we would like to hear from DNS recursive resolver operators
about their experience with DNSSEC. For this reason, we have set up a short
survey. It’s directed mainly towards organisations that run a recursive
resolver. Filling out the survey should take roughly 5 to 10 minutes.
https://forms.gle/FxTD9FofaogdvLqcA (link directs to Google Forms)
This survey is carried out by SIDN Labs (https://sidnlabs.nl) and by the
Swedish Internet Foundation (https://internetstiftelsen.se/en/). You can
contact us via email: moritz.muller(a)sidn.nl
Please excuse us, if you have received this email via different mailing
lists.
—
Moritz Müller Research Engineer at SIDN Labs
Running 5.4.4, adding an NTA seems very straightforward:-
>> trust_anchors.set_insecure( {"fj"} )
>
>> trust_anchors.summary()
>'fj. is negative trust anchor
>. 172800 DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ; Valid: ; KeyTag:20326
>'
What is the precise incantation to remove it when it is no longer required?
The following do not work:-
>> trust_anchors.remove('fj')
>false
>> trust_anchors.remove('fj.')
>false
>> trust_anchors.remove( {"fj"} )
>false
Any help would be appreciated.
Also, does Knot Resolver allow an automatic timeout when setting NTAs as
Bind does?
---
Best wishes,
Matthew
Hello,
I am trying to import custom generated RPZ list into kresd, but daemon
fails with following error "[policy] RPZ: invalid domain name character". I
am using UTF-8 as encoding for file. Any pointers how to convince kres to
ingest these domain names would be greatly appreciated.
Best regards,
Łukasz Jarosz
Hello,
I'd like to kindly ask for help with following issue.
I am considering to deploy knot-resolver to the DNS solution where it
should coexist with other DNS daemons namely Unbound. I am running
dnsdist <https://dnsdist.org/> in front of the pool of resolvers where I
have just added also the latest release (5.5.4) of knot-resolver. It
receives a portion of requests at the rate about 500qps. There are 6
kresd processes on a VM running with cache in tmpfs. Cache size is 2GB
(8GB mounted to tmpfs). Resolver is running Debian Bullseye. The
solution is serving real customers - the traffic is not artificial.
The configuration enables some modules:
modules = {
'hints > iterate', -- Load /etc/hosts and allow custom root hints
'stats', -- Track internal statistics
'predict', -- Prefetch expiring/frequent records
'bogus_log', -- DNSSEC validation failure logging
'nsid',
'prefill',
'rebinding < iterate'
}
cache.size = cache.fssize() - 6*GB
modules = {
predict = {
window = 15, -- 15 minutes sampling window
period = 6*(60/15) -- track last 6 hours
}
}
policy.add(
policy.rpz(policy.DENY,
'/var/cache/unbound/db.rpz.xxx.cz',
true)
)
And the Carbon protocol reporting is enabled with the sample rate of 5s.
The performance in terms of response time is equal or even better when
comparing with Unbound. I am measuring the performance of the dnsdist's
backend servers (daemons) - the latency, dropped requests and the
requests rate using Carbon protocol with sample rate of 5s. The backend
servers kresd included are receiving requests from just several clients
at the moment (source IPs of the balancers).
What is wrong here is some kind of repeated packet drops reported for
kresd instance by dnsdist. It appears in about 15 min. interval. When it
occurs the drop rate increases from about 0.5 req/s (standard behavior)
to 5-10 req/s which causes a positive feedback and increased packet
rate. There are such peaks every 15 min. When I restart the kresd
instances drops go away and everything is stellar for couple of hours.
I have no explanation for that. It is apparently not related to the
requests - I have tried to simulate this by replaying the traffic
captured when the problem occurs several times without success. kresd
can even process 20k qps on this instance with no increase of drop rate
from the balancer's point of view. But after a while... The fact that
restarting kresd helps immediately shows that there might be something
wrong inside.
I have tried to increase the number of kresd processes, cache size and
disabling the cache persistence. Nothing helps here. I am pretty sure
there are no network issues on the VM or surrounding network.
I can provide some graphical representations of this behavior of it is
needed or a packet capture of the real traffic.
Many thanks
With best regards
Ales Rygl
