If you have the public key file you can do:
dnssec-dsfromkey Kexample.com.+013+55640.key
example.com. IN DS 55640 13 2
CF681BA4D66B41912B4DC525ADFC948218EC3DBA724F266D25BD1702BE8A8BA9
Or you can query the auth nameserver like this:
dig @localhost example.com. DNSKEY | egrep "IN\sDNSKEY\s257" |
Hello Danilo,
A simple schema to change DNSSEC algorithms is as follows:
1. Add new KSK/ZSK and double sign DNSKEY and all zone RRs
with both the new and old algorithm
2. Replace DS at parent
3. Remove old DNSKEY and all RRSIGs from the old algorithm
Before step 2 wait the max zone TTL to
You might use an operating system / crypto library which do not support
SHA1 anymore. paypal.com is signed with RSASHA1.
See warnings on https://dnsviz.net/d/paypal.com/YjSWxg/dnssec/
Just curious what answer to you get from your resolver?
servfail or a missing ad-bit?
Daniel
On 18.03.22
rews wrote:
> SPF records are TXT record which are NOT subject to check-names processing.
>
> If you created a seperate zone use nameservers that DO NOT live within the
> zone.
> ns1._spf.switch.ch is NOT a legal hostname as it is not LDH.
>
>> On 4 Jan 2021, at 20:01, Daniel
Hello all,
I changed SPF for switch.ch to use SPF macros (RFC 7208). I wanted to
use the "_spf" label but bind9 check-names complained with a "bad owner
name (check-names)" message.
I have now used "spf" instead of "_spf", e.g. exists:%{ir}.spf.switch.ch
I didn't want to disable check-names for
Or
> did you enable DNSSEC by adding 'dnssec-policy'?
>
> If you have them, would you be able to share with me (off list) the logs
> and the key (state) files?
>
> - Matthijs
>
>
> On 23-12-2020 10:47, Daniel Stirnimann wrote:
>> Hello Matthijs,
>>
>&g
for a given key has
> been published.
>
> Best regards,
>
> Matthijs
>
> On 23-12-2020 09:53, Daniel Stirnimann wrote:
>> Hi all,
>>
>> I'm testing the key rollover behavior of BIND 9.16 with the new
>> introduced "dnssec-policy" stateme
Hi all,
I'm testing the key rollover behavior of BIND 9.16 with the new
introduced "dnssec-policy" statement.
The ISC DNSSEC Guide, chapter Working with the Parent Zone (2) [1] states:
"At the time of this writing (mid-2020) BIND does not check for the
presence of a DS record in the parent zone
tact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
--
SWITCH
Daniel Stirnimann, SWITCH-CERT
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerlan
I believe, "minimal-any" is for authoritative nameservers only and has
no effect on recursive resolvers. Where did you configure "minimal-any yes"?
Daniel
On 08.09.20 13:30, ShubhamGoyal wrote:
> Dear All,
> We have enabled " *minimal-any yes;"* in our Bind
> DNS Sever,
Hello Mohammed,
I don't see that you specified a "response-policy" [1] statement. You
need something like this as well:
response-policy {
zone "rpz.local" policy given;
}
// Apply RPZ policy to DNSSEC signed zones
break-dnssec yes
;
[1]
Hello Mohammed,
You can use RPZ (Response Policy Zone). The following link should give
you a good introduction on how to set this up:
Building DNS Firewalls with Response Policy Zones (RPZ)
https://kb.isc.org/docs/aa-00525
Daniel
On 13.07.20 08:44, MEjaz wrote:
> Hell all,
>
>
>
>
>
>
On 09.07.20 11:51, Klaus Darilion wrote:
>>> So, how is the correct process to add an additional DNSKEY (only the public
>> key is known).
>>
>> I think you are looking for `dnssec-importkey`.
>
> Indeed. I imported the key and got a .key and .private file. I put those
> files in the same
Hello Paulo,
I noticed the same some time ago and made an issue on gitlab.isc.org:
https://gitlab.isc.org/isc-projects/bind9/-/issues/1619
For your information, you cannot whitelist with wildcards anymore
starting from bind 9.14.6 and newer.
What still works is if the blacklist contains a
On 11.05.20 08:18, Vadim Pavlov via bind-users wrote:
> The main issue that bind does’t provide an authentication method. So in
> any case you somehow should manage the access to the DNS server vice
> versa it will became open resolver and will be used for DDoS attacks.
If you were to use DoH,
On 13.04.20 21:07, sth...@nethelp.no wrote:
>> general: error: TCP connection failed: quota reached
>
> I had some of these too, until I explicitly set this named option:
>
> tcp-listen-queue 20;
>
> Looks like the default is 10. The way I interpret this parameter is
> that this sets the
Hello all,
I believe this problem should be fixed in 9.16.1:
5361. [bug] named might not accept new connections after
hitting tcp-clients quota. [GL #1643]
However, we had two authoritative name servers running 9.16.1 which
stopped accepting new TCP
> Just don’t do that, there’s no sensible reason to change salt that often (or
> ever). I don’t know where the advice to change salt often comes from, but
> the advice has been wrong for so many years.
I agree that re-salting is kind of pointless (we still do it for .ch
though because so far
federate.secure.barclays.com. is a CNAME pointing to
federate-secure.glbaa.barclays.com
The authoritative name servers for federate-secure.glbaa.barclays.com
are broken:
glbaa.barclays.com. 900 IN NS ns24.barclays.net.
glbaa.barclays.com. 900 IN NS
Hello Alessandro,
On 18.10.19 19:20, Alessandro Vesely wrote:
> Did a better way arrive between 2014 and 2017? What does that warning
> mean?
The how to in this article manually creates keys or does key rollovers.
Most DNS software have automated that part, see for example section
Policy
You cannot block DoH with RPZ but you can block bootstrapping DoH if the
web browser is configured to use "normal" DNS to lookup the DoH
endpoint. See also:
https://github.com/bambenek/block-doh
Daniel
On 02.10.19 13:23, Blason R wrote:
> Hi Folks,
>
> Wondering if anyone has any clue or
On 05.06.19 14:35, Borja Marcos wrote:> Problem 1:
> I had a problem resolving the rigol.com domain. Looking at packet
> captures and comparing I saw that the authoritative servers for
> rigol.com were ignoring packets with a cookie option.
>
> On 9.14 the operation got stuck when sending a
Hi
On 24.05.19 12:41, Witold Krecicki wrote:
> Could you try the attached patch (instead of the one you provided) and
> see what happens? It stops trying to do qname minimization earlier if it
> sees any failures in resolution (e.g. lame servers, as with the domains
> you provided), it should
Dear all,
We run BIND 9.14.2 on our resolver. The introduction of DNS query
minimization (qmin) has so far caused a huge increase in customer
reports about domain names which cannot be resolved.
In comparison to other open source DNS resolvers which support query
minimization, BIND seems to be
Hello Alex,
> Is this expected behaviour? Is there any way to make the server avoid
> proceeding with the resolution, when the initial client requests is
> blocked?
Yes, this is expected behavior. You need "qname-wait-recurse no" to
change the behavior:
response-policy {
zone
Hello Philippe,
> Is there a direct way to set the NSEC3PARAM?
No idea.
> Switch, the registry for .ch and .li domains is using/testing CDS
> records. Can I tell named, to create the CDS Records for me?
If your keys have appropriate timing metadata, then the CDS/CDNSKEY
records are published
Hello Tom,
> My feeded RPZ blocks othercompany.com and *.othercompany.com. Therefore
> any qtype (MX, A, ...) are blocked for this domain. Is there a way
> with BIND just to whitelist the MX for othercompany.com and the
> consequent A-Record (ex. mail.othercompany.com) that we are able to
Hello all,
DNSSEC validating BIND resolver could not resolve cdn.ckeditor.com.
Meanwhile the zone owner "fixed" the problem and the domain name can be
resolved again. However, I wonder if BIND should do better for an
island-of-trust zone.
BIND resolver:
(1) ask upstream com. servers for
Hello Maurizio,
> forwarders {
> 194.126.200.5;
> 81.221.250.11;
> 81.221.252.11;
> };
I can only guess what you want to achieve with this configuration but
these ip addresses are authoritative name servers and not recursive
On 03.08.18 03:13, Randy Bush wrote:
>> We run about 300 TLD's on our DNS platform and get roughly 5-10% TCP
>> queries.
>
> that is quite a variance
>
>> In comparison, we get about 25-30% IPv6 queries.
>
> wonder how that compares to others
We have slightly less then 25% for IPv6 queries.
Hello Randy,
> so, i guess there is a named tcp dos going around. using bind9, is
> there an amelioration? or am i misconfigured in some way?
It looks to me that this is a side effect of a very permissive RRL
configuration. My tests with the following command indicate that you
have set
Hello all,
dnssec-signzone (BIND 9.12.2) sometimes does lowercase DNSSEC records.
This seems a problem especially for NSEC records which are case
sensitive. dnssec-verify is moaning with errors like this:
Bad NSEC record for ipad-rigi-2.switch.ch, bit map mismatch
Example:
dnssec-signzone -o
Dear all,
I have the configure option "--disable-crypto-rand" for some BIND 9.12
builds. Building BIND with this option fails for the latest BIND 9.12.2:
BUILDSTDERR: openssl_link.c: In function 'dst__openssl_init':
BUILDSTDERR: openssl_link.c:274:2: error: 're' undeclared (first use in
this
> Note, "[ log yes_or_no ]" has been added in BIND 9.12.
Sorry, this has been added in BIND 9.11 already.
Daniel
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
On 26.04.18 10:10, Blason R wrote:
> 9.12 is not yet stable; i believe?
9.12 is stable. 9.13 is current development. 9.11 is the current
Extended Support Version (ESV).
You may want to read this:
https://www.isc.org/blogs/bind-release-strategy-updated/
https://kb.isc.org/article/AA-01540
On 26.04.18 09:46, Blason R wrote:
> Oh thats great...in that case general practice would be always whitelist
> the zones first then blacklist?
I'm using:
whitelist with "policy passthru log no"
test zones with "policy passthru"
blacklists with "policy cname LANDINGPAGE"
Note, "[ log yes_or_no
> response-policy { zone "malware.trap"; zone "whitelist.allow" policy
> passthru; };
...
> So which one will take precendence in this case?
Policy processing will search the zone files in the order in which they
appear in the response-policy statement.
So, you need to change the order in
On 18.04.18 10:57, Blason R wrote:
> Well it just loads fine when I run from command line i.e. named -u named
> -n 4 -c /etc/named.conf
Just a guess. If you use and have SELinux in enforcing mode (see
getenforce), this could be a reason. Your user process runs unconfined
that's why it works from
Hello Carsten,
> RFC 2308 "DNS NCACHE" defines the last field of the SOA RR as "the TTL of
> negative responses".
Negative caching TTL is not defined as the last field of the SOA RR:
"When the authoritative server creates this record its TTL
is taken from the minimum of the SOA.MINIMUM field
> Am 31.01.2018 um 16:35 schrieb Daniel Stirnimann:
>>> that don't change the fact that from that moment on all protections for
>>> *that* service are gone while with layered security and
>>> systemd-hardening are still in place
>>
>> Where is the layere
> it is completly irrelevant because when you switch SELinux to
> "permissive" in case you need to debug something it's gone and hence
> layered-security is always the way to go
I don't understand this negative perception of SELinux. Why do you think
debugging differs from any other applied
> domains: if you know the algorithm, you can pre-generate the malicious
> domains and add them to your RPZ in advance.
RPZ by default will not stop the upstream query. You would have to use
"qname-wait-recurse yes" in addition if stopping upstream queries is
your goal.
I believe this malware
Hello all,
Just wondering, if one is already using selinux in enforcing mode, does
systemd hardening provide any additional benefit?
Daniel
On 16.01.18 12:21, Ludovic Gasc wrote:
> Hi,
>
> I have merged config files from Tony, Robert, and me.
> I have tried to be the most generic, the result
I doubt you can use RPZ for that.
We use https://dnsdist.org/ for that, our rule:
-- WPAD Name Collission Vulnerability
-- US-CERT TA16-144A. Redirect to landing page
addAction(RegexRule("^wpad\\."),SpoofAction("192.168.1.2", "2001:DB8::2"))
Daniel
On 29.11.17 19:12, Grant Taylor via
On 26.11.17 16:48, Blason R wrote:
> Strange...when I started with command line it started successfully even
> catering all my zones and sinkholing the requests as well
>
> /usr/sbin/named -u named -d 10 -c /etc/named.conf
Might be a SELinux issue. Your configuration is likely not compatible
5
As I've read today BIND 9.11.1 can be used with openssl 1.1.0
Daniel
--
SWITCH
Daniel Stirnimann, SWITCH-CERT
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 16 24
daniel.stirnim...@switch.ch, http:
> Named doesn't have a switch to force EDNS though I suppose we could
> add one to 9.12. e.g. server ... { edns force; };
I would find this useful.
> I really don't want to add new automatic work arounds for broken
> servers but it requires people being willing to accepting that
> lookups will
Hello all,
Our resolver failed to contact an upstream name server as a result of
network connectivity issues. named retries eventually worked but as it
reverted back to not using EDNS and the answer should have been signed,
the query response failed to validate. Subsequent queries towards this
Apart from DSC which has been mentioned here, we are also using munin
(www.munin-monitoring.org)
Shumon Huque has written a python plug-in for munin which retrieves the
data from BIND statistics server (via localhost HTTP requests).
https://github.com/shuque/bind9stats
Daniel
> Our DNS resolvers are not only used by stub resolvers but by DNS
> resolvers using DNS forwarding as well. I wonder what happens if DNS
> forwarding resolvers do DNSSEC validation? It looks like they would
> return SERVFAIL to the user as the RPZ response omits any RRSIG for the
> landing page.
Hi all,
We use RPZ to block malicious domain names. Specifically, we redirect to
a landing page. Our landing page (landingpage.ph.rpz.switch.ch) is
DNSSEC signed. However, if I get a RPZ response from our validating dns
resolver it omits any RRSIG. Example:
dig @ www.oyubaimai[.]top +dnssec
;
Hello all,
I've been wondering for years why I get occasional log messages like the
following:
07-Dec-2016 21:06:53.783 dnssec: info: validating abuse.ch/SOA: got
insecure response; parent indicates it should be secure
07-Dec-2016 21:07:02.984 dnssec: info: validating abuse.ch/SOA: got
I think prefetch (enabled by default) already does what you need
although in a different way.
https://deepthought.isc.org/article/AA-01122/0/Early-refresh-of-cache-records-cache-prefetch-in-BIND-9.10.html
Daniel
On 18.11.16 10:24, Job wrote:
> Hello,
>
> for heavy-use cache improvements, i
>> I have upgraded some of our BIND resolvers from BIND 9.9.9-P3 to BIND
>> 9.11.0 and I notice timeouts for 3 - 5 seconds about every 1 to 5 hour.
>
> Something to do with dlv.isc.org?
No, I can rule out dlv.isc.org.
It currently looks like that only having the spamhaus rpz zones active
causes
Hi,
I have upgraded some of our BIND resolvers from BIND 9.9.9-P3 to BIND
9.11.0 and I notice timeouts for 3 - 5 seconds about every 1 to 5 hour.
I have managed to trace this back to our RPZ configuration. I have 14
RPZ zones configured. Some of them are quite large (e.g. Spamhaus). The
only
Dear all,
BIND9 (and not Unbound, PowerDNS Recursor, Google Public DNS) is failing
to validate the following non-existent domain name:
dig @184.105.193.73 ABCD._openpgpkey.posteo.de A +dnssec
; <<>> DiG 9.8.3-P1 <<>> @184.105.193.73 ABCD._openpgpkey.posteo.de A
+dnssec
; (1 server found)
;;
> So what we recommend is using dnsdist to balance to your backends, and have
> it prefer one backend when all things are equal. Then run multiple dnsdists
> which each prefer a different backend. And then announce your dnsdist
> service addresses a few times over BGP.
+1 on this.
We moved
>> We maintain a block list with RPZ on our BIND resolvers. I noticed that
>> the RPZ policy action does not apply for domain names which SERVFAIL
>> (i.e. cannot be resolved by the resolver because of a timeout, lame
>> delegation etc.).
>
> RPZ applies to responses not queries.
>
> You can
Hi all
We maintain a block list with RPZ on our BIND resolvers. I noticed that
the RPZ policy action does not apply for domain names which SERVFAIL
(i.e. cannot be resolved by the resolver because of a timeout, lame
delegation etc.).
This happens on both BIND 9.11.0rc1 and 9.9.9-P2.
Our default
Hello Tom
I only know of Knot having a feature available for this use case:
https://www.knot-dns.cz/docs/2.x/html/configuration.html#synth-record-automatic-forward-reverse-records
Daniel
On 26.08.16 11:51, Tom wrote:
> Many thanks for your quick feedback.
>
> This is the configuration-option,
On 14.04.16 08:31, Daniel Dawalibi wrote:
> Anyone experiencing a reach ability issue toward g.root-servers.net?
Looks like you are not alone!
https://atlas.ripe.net/dnsmon/group/g-root
Daniel
___
Please visit
> While this is not a problem for BIND to load the zone it seems
> unexpected to me. Should dnssec-signzone not remove obsolete signatures?
Found out that this issue is fixed in BIND 9.11.0a1:
4305. [bug]dnssec-signzone was not removing unnecessary rrsigs
from the zone's apex.
Hi Mike,
When BIND first introduced this Case-Insensitive Response Compression
(See https://kb.isc.org/article/AA-01113) I found out that BIND
zone_name case sensitivity in a zone statement is preferred over name
case sensitivity in the zone itself.
So, you can get a google.COM answer because
Dear all,
I have the following test zone files:
8.example.com.signed
K8.example.com.+008+40162.key
K8.example.com.+008+40162.private
I edit the signed zone directly (8.example.com.signed) and remove for
example an A record and then resign the zone as following:
dnssec-signzone -z -o
eally improved dramatically. We
currently have v3.10 and I don't see any problems. However, we don't use
Vmware.
Daniel
--
SWITCH
Daniel Stirnimann, SWITCH-CERT
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 16 24
daniel.stirnim...@swit
Hi Phil,
You can use RPZ for that with a zone record of:
32.1.0.0.127.rpz-ip CNAME rpz-passthru.
See Response Policy Zone (RPZ) Rewriting
http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html
Daniel
___
Please visit
Hello
I have several RPZ zones configured on our caching resolver. e.g.
response-policy {
zone whitelist.rpz.switch.ch. policy passthru;
zone malware.rpz.switch.ch. policy GIVEN;
};
I currently log RPZ hits via syslog to a remote log server. I don't want
the whitelist rpz zone hits to be
.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
SWITCH
Daniel Stirnimann, SWITCH-CERT
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
Hello Stefan
You may also try to disable all DNSSEC algorithms for a zone:
https://lists.dns-oarc.net/pipermail/dns-operations/2014-October/012282.html
Regards,
Daniel
On 13.01.15 14:53, stefan.las...@t-systems.com wrote:
Hi Mukund
and thanks a lot for pointing that out!
It is already
Hello
Sorry, for cross-posting this question. I've posted this question one
week ago on http://lists.redbarn.org/mailman/listinfo/dnsfirewalls
already but got no answer. So, I try it here as well.
I use BIND 9.9.4 on a caching only resolver and have RPZ enabled. If I
do a lookup for any
70 matches
Mail list logo
