Re: Mitigation of server's load by queries for non-existing domains
On 12.01.2016 18:16, Tony Finch wrote: > Tomas Hozza <tho...@redhat.com> wrote: >> >> Recently I was trying to find a mechanism in BIND that could prevent the >> server from processing a recursive query for non-existing domains. > > Have a look at https://www.isc.org/blogs/tldr-resolver-ddos-mitigation/ > >> I was thinking about using RPZ with QNAME policy trigger, but this >> applies only to the responses to queries and still makes the server to >> try to resolve it. > > RPZ has a "qname-wait-recurse no" option. This is exactly the thing I was looking for. Thank you very much! Tomas > Tony. > ___ 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
Mitigation of server's load by queries for non-existing domains
Hello all. Recently I was trying to find a mechanism in BIND that could prevent the server from processing a recursive query for non-existing domains. The issue I was trying to solve was that when server was getting too many queries for such domains it was not able to handle other relevant queries. The non-exiting domains have just few common non-existing parent domains, so one can match most of them by wildcard RR. I was thinking about using RPZ with QNAME policy trigger, but this applies only to the responses to queries and still makes the server to try to resolve it. As far as I'm familiar with RRL, it will also not help, since it also applies to the response to a query. One possible solution that came to my mind was to define a zone for each of the "parent" domains and then just return localhost address or something similar to any query to that domain. I know this is kind of dummy, but this was the first thing that came to my mind. I know the server will still process the query, but will at least not do any recursion. Is there any better mechanism to solve such problem? Thank you in advance. Regards, Tomas -- Tomas Hozza Senior Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com ___ 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
BIND and RFC4074
Hi. I would like to ask if there is any documentation describing if any version of BIND didn't comply with RFC 4074. And in case there was such version, in which release it was fixed? I tried to go through CHANGELOG and to Google it, but without any luck. Thanks. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+2 (CEST) Red Hat Inc. http://cz.redhat.com ___ 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
Re: ISC DHCP does not work with BIND 9.10
On 02/19/2015 07:30 PM, Evan Hunt wrote: dhcp is only expected to work with the generic library (and also disabling epoll), but this comment now seems to be obsolete as there's no generic (formerly called export) version of the library. Assuming the issue with epoll is somehow resolved, I suspect we'd need some run-time mechanism to enable the multiple task managers mode (while still enabling threads). As far as I know the current implementation doesn't allow it. Pretty much exactly correct. Our intention was to allow both named and dhcpd to use the same set of libisc and libdns libraries, no longer requiring separate libraries to be built for each; a global variable set at runtime (isc_bind9) takes the place of #ifdef BIND9, where the internal and export versions of the libraries had different behavior. We ran out of time on this project when we were working on BIND 9.10 and DHCP 4.3, and haven't had time to get back to it, so the work is largely but complete but not entirely. DHCP still needs some adaptations to deal with the new-style task manager, and libisc needs a runtime mechanism for choosing to use select vs epoll/kqueue/devpoll. I think there were a few other items on the to do list as well, but those were the big ones. Thank you for the explanation. Is there any estimate or plan when this could be finished? This situation complicates things significantly on Fedora. If we want to ship BIND 9.10 we have to either build DHCP using bundled BIND (which is against Fedora guidelines and requires special approval) or build another version of libisc and libdns with special options which will require us hacking BIND's build process. Since both workarounds are just temporary from our point of view, we would like you to really consider finishing the work so DHCP can be built against BIND 9.10. Thank you! Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com ___ 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
ISC DHCP does not work with BIND 9.10
Hi all. There's [1] a packaging policy on Fedora, that packages can't be shipped with bundled libraries, which is a case of BIND bundled in DHCP tarball. We'd like to ship bind-9.10.2 dhcp-4.3.2 with next Fedora release (22). Problem is, that dhclient/dhcpd don't play well with bind-9.10. Jiri Popelka (the DHCP maintainer in Fedora) did some investigation and they can't be stopped (have to be 'kill -9'ed) and don't work at all when running in background. dhcpd - backtrace: #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f41c136a46b in isc.app_ctxrun () from /lib64/libisc.so.148 #2 0x7f41c24721e1 in dispatch () #3 0x7f41c24229cd in main () dhclient - backtrace: #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f9c1941f480 in run () from /lib64/libisc.so.148 #2 0x7f9c187ad52a in start_thread (arg=0x7f9c13885700) at pthread_create.c:310 #3 0x7f9c18cc779d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 dhcpd - strace: futex(0x7f41c23290bc, FUTEX_WAIT_PRIVATE, 1, NULL dhclient - strace: futex(0x7f9c1a3e80a4, FUTEX_WAIT_PRIVATE, 5, NULL Anybody has any idea what might cause this or where to start debugging ? We tried to build bind with '--with-locktype=standard' to no avail. [1] http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries Thank you! Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com ___ 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
Re: ISC DHCP does not work with BIND 9.10
Thank you for your reply. On 02/19/2015 06:01 PM, 神明達哉 wrote: At Thu, 19 Feb 2015 17:26:19 +0100, Tomas Hozza tho...@redhat.com wrote: There's [1] a packaging policy on Fedora, that packages can't be shipped with bundled libraries, which is a case of BIND bundled in DHCP tarball. We'd like to ship bind-9.10.2 dhcp-4.3.2 with next Fedora release (22). Problem is, that dhclient/dhcpd don't play well with bind-9.10. Jiri Popelka (the DHCP maintainer in Fedora) did some investigation and they can't be stopped (have to be 'kill -9'ed) and don't work at all when running in background. First off, do you mean dhcp-4.3.2rc1? (I can't find a final release version of 4.3.2 on the ISC ftp site). I meant dhcp-4.3.2b1. Secondly: did you try to link libisc/libdns etc from bind-9.10.2 to dhcp-4.3.2(rc1) instead of the one included in the dhcp source directory? We are linking DHCP against separate build of BIND 9.10.2. In other words we don't use the bundled bind in DHCP sources. If so, unless something has substantially changed in the dhcp side, that wouldn't work in my experience for the following two reasons: 1. On Linux libisc would enable epoll by default. dhcp doesn't work well with it; you'll need a library built disabling the epoll support. 2. You stack trace seems to suggest libisc is built with enabling threads. dhcp doesn't work well with it either. Also possibly related to the second point, see comments in lib/isc/task.c: * For BIND9 internal applications: * when built with threads we use multiple worker threads shared by the whole * application. * when built without threads we share a single global task manager and use * an integrated event loop for socket, timer, and other generic task events. * For generic library: * we don't use either of them: an application can have multiple task managers * whether or not it's threaded, and if the application is threaded each thread * is expected to have a separate manager; no worker threads are shared by * the application threads. dhcp is only expected to work with the generic library (and also disabling epoll), but this comment now seems to be obsolete as there's no generic (formerly called export) version of the library. Assuming the issue with epoll is somehow resolved, I suspect we'd need some run-time mechanism to enable the multiple task managers mode (while still enabling threads). As far as I know the current implementation doesn't allow it. -- JINMEI, Tatuya We have been linking DHCP against separately built BIND in the past and everything worked for years. Only thing that changed is that we updated latest BIND 9.9 to latest 9.10. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com ___ 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
RPZ zone defined in a view
Hello.
The BIND ARM documentation in section 6.2.16.20 says that
Response policy zones are named in the response-policy
option for the view or among the global options if there
is no response-policy option for the view.
However named with the following configuration fails to start:
--
options {
directory /var/named;
dump-file /var/named/data/cache_dump.db;
statistics-file /var/named/data/named_stats.txt;
memstatistics-file /var/named/data/named_mem_stats.txt;
allow-query { any; };
recursion yes;
dnssec-enable no;
dnssec-validation no;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file /etc/named.iscdlv.key;
managed-keys-directory /var/named/dynamic;
response-policy { zone rpz; };
};
logging {
channel default_debug {
file data/named.run versions 3 size 50M;
severity dynamic;
};
};
view trusted {
zone . IN {
type hint;
file named.ca;
};
zone rpz {
type master;
file rpz.zone;
};
};
view untrusted {
match-clients { any; };
zone . IN {
type hint;
file named.ca;
};
};
--
It ends with:
...
07-Jan-2015 13:12:58.641 /etc/named.conf:18: 'rpz' is not a master or slave zone
07-Jan-2015 13:12:58.642 loading configuration: not found
07-Jan-2015 13:12:58.642 exiting (due to fatal error)
I think the problem is that if the response-policy statement
is used within the options statement, then named looks for
the zone only in the _default view. However if you use view
statements, then all zones have to be defined in some view,
thus making the RPZ zone non-existing for the global
response-policy statement.
If I move the response-policy statement to the trusted view
it starts to work.
However based on the documentation it should work also in the
first case.
Is the documentation wrong or is it a bug in the RPZ implementation?
Thanks!
Regards,
--
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience
PGP: 1D9F3C2D
Red Hat Inc. http://cz.redhat.com
___
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
Re: RPZ zone defined in a view
On 01/07/2015 02:31 PM, Mark Andrews wrote:
In message 54ad246d.7080...@redhat.com, Tomas Hozza writes:
Hello.
The BIND ARM documentation in section 6.2.16.20 says that
Response policy zones are named in the response-policy
option for the view or among the global options if there
is no response-policy option for the view.
However named with the following configuration fails to start:
--
options {
directory /var/named;
dump-file /var/named/data/cache_dump.db;
statistics-file /var/named/data/named_stats.txt;
memstatistics-file /var/named/data/named_mem_stats.txt;
allow-query { any; };
recursion yes;
dnssec-enable no;
dnssec-validation no;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file /etc/named.iscdlv.key;
managed-keys-directory /var/named/dynamic;
response-policy { zone rpz; };
};
logging {
channel default_debug {
file data/named.run versions 3 size 50M;
severity dynamic;
};
};
view trusted {
zone . IN {
type hint;
file named.ca;
};
zone rpz {
type master;
file rpz.zone;
};
};
view untrusted {
match-clients { any; };
zone . IN {
type hint;
file named.ca;
};
};
--
It ends with:
...
07-Jan-2015 13:12:58.641 /etc/named.conf:18: 'rpz' is not a master or slave
z
one
07-Jan-2015 13:12:58.642 loading configuration: not found
07-Jan-2015 13:12:58.642 exiting (due to fatal error)
I think the problem is that if the response-policy statement
is used within the options statement, then named looks for
the zone only in the _default view. However if you use view
statements, then all zones have to be defined in some view,
thus making the RPZ zone non-existing for the global
response-policy statement.
By adding it to options you are saying that all views have a rpz zone
but that is not the case. untrusted does not have a rpz zone.
Ahh, that is the case. It wasn't clear to me from the documentation. It works
with the rpz zone in both views.
Thank you for the answer.
If I move the response-policy statement to the trusted view
it starts to work.
However based on the documentation it should work also in the
first case.
Is the documentation wrong or is it a bug in the RPZ implementation?
Thanks!
Regards,
--
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience
PGP: 1D9F3C2D
Red Hat Inc. http://cz.redhat.com
___
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
--
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience
PGP: 1D9F3C2D
Red Hat Inc. http://cz.redhat.com
___
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
Re: Possible bug in dig
On 11/28/2014 02:10 PM, Daniel Ryšlink wrote: Happened in dig from bind-tools 9.9 and 9.10, both on Linux and FreeBSD. After issuing the following command, dig ends with a core dump: dig +trace +topdown +sigchase +trusted-key=./key.txt rhybar.cz mx Launch a query to find a RRset of type DNSKEY for zone: . message.c:2306: REQUIRE(msg-cursors[section] != ((void *)0)) failed, back trace #0 0x53b113 in ?? #1 0x53b0aa in ?? #2 0x4300ab in ?? #3 0x411850 in ?? #4 0x4149bf in ?? #5 0x555a5f in ?? #6 0x80179b4a4 in ?? #7 0x0 in ?? Abort trap (core dumped) key.txt is attached Hi. You should report the issue to bind9-b...@isc.org . AFAIK from my previous bug reports, the sigchase functionality is not considered stable and is not compiled by default. However for example in Fedora, we compile it. For example running: # dig @8.8.8.8 +trace +topdown +sigchase rhybar.cz mx\ crashes too with a different backtrace ;) Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com ___ 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
recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
list before submitting a bug. Thanks! Regards, - -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJT/HswAAoJEMWIetUdnzwtNkoH/it+eUSHs9n6doXeweAgwc6V GnE+sfdZ28Hm77euf6ACRPGBgP9ZA9vq3k2hvFo2JbNejoFd1gj0WTNphlL2tSoE QECltLCbCHSZj8vo7dOoN9kusRKSuKi9rP0Lp/DXCDvhqJ+Woq8y5cgvkLRT5snA lgR3hfc44Rc9Tp4K6NoLX7pBVt1nWRWp4hFyJUuZ5B0qXWMCNyBioeNSe2yIFowE uV33TazpImavG4qXUjwV1f4EXSgjuSzEUUn2sAm9LdD6knMAOYPpCXw203mtSCan +JoXUcwxN+gZHEQaMSBoTsw7DxZS8NVtfdMxrvpL+Ro+LTzs3CJZioc1JjuVpas= =0zaE -END PGP SIGNATURE- ___ 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
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
On Tue 26 Aug 2014 02:32:24 PM CEST, Kevin Darcy wrote:
So you care enough about security to implement DNSSEC, but you run your
forwarder on port 80. Interesting...
- Kevin
It is completely artificial setup for testing purpose only.
On 8/26/2014 8:19 AM, Tomas Hozza wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello.
I found out that when bind is configured as recursive resolver with
dnssec-lookaside set to 'auto' and dlv.isc.org is unreachable, all
lookups for unsigned (UNSECURE) names fail even if the validation
succeeds (IOW the validation of NSEC3 answer proves that DS does not
exist so domain (name) is not signed).
I tested it with one server set up as forwarder running on 127.0.0.1@80
configured not to answer queries for dlv.isc.org (query will timeout).
I have bind (9.9.4-P2) configured with:
forward only;
forwarders { 127.0.0.1 port 80; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
Doing a lookup for (unsigned) google.com A record times out:
# dig @127.0.0.1 google.com A
; DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 @127.0.0.1 google.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 12157
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.INA
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 26 14:08:03 CEST 2014
;; MSG SIZE rcvd: 39
in named log I can see:
...
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: in
authvalidated
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: resuming
nsecvalidate
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking
for
relevant NSEC3
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking
for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates potential closest encloser: 'com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 at
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
proves
name does not exist: 'google.com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates optout
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 at
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS:
nonexistence
proof(s) found
26-Aug-2014 13:45:49.127 fctx 0x7ff97a28a440(google.com/DS): received
validation
completion event
26-Aug-2014 13:45:49.127 validator @0x7ff9745af3d0: dns_validator_destroy
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): nonexistence
validation OK
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): clone_results
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): done
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): stopeverything
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): cancelqueries
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): sendevents
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: in
dsfetched2: ncache nxrrset
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: plain
DNSSEC
returns unsecure (google.com): looking for DLV
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: looking
for
DLV google.com.dlv.isc.org
...
This looks to me that the result of DNSSEC validation of A record
for google.com proved that it is UNSECURE.
However the validation using DLV proceeds and fails in the end since
dlv.isc.org can not be resolved.
Doing a lookup for (signed) nic.cz A record succeeds:
[root@unused-4-247 ~]# dig @127.0.0.1 nic.cz A
; DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 @127.0.0.1 nic.cz A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 25002
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nic.cz.INA
;; ANSWER SECTION:
nic.cz.1163INA217.31.205.50
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/26/2014 02:27 PM, Mark Andrews wrote:
Why would you expect them to succeed?
Because validation using root servers and authoritative servers proved
that the domain is intentionally unsecure.
If you use DLV you are
expecting anything for which DLV is used as a trust anchor to be
safe from being spoofed. The *only* way this can happen is to fail
if the DLV lookup fails for any reason.
I can understand that. It just didn't seem correct to me for the reason
stated above. Thanks for acknowledging that this behavior is expected.
Tomas
Mark
In message 53fc7b35.6040...@redhat.com, Tomas Hozza writes:
Hello.
I found out that when bind is configured as recursive resolver with
dnssec-lookaside set to 'auto' and dlv.isc.org is unreachable, all
lookups for unsigned (UNSECURE) names fail even if the validation
succeeds (IOW the validation of NSEC3 answer proves that DS does not
exist so domain (name) is not signed).
I tested it with one server set up as forwarder running on 127.0.0.1@80
configured not to answer queries for dlv.isc.org (query will timeout).
I have bind (9.9.4-P2) configured with:
forward only;
forwarders { 127.0.0.1 port 80; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
Doing a lookup for (unsigned) google.com A record times out:
# dig @127.0.0.1 google.com A
; DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 @127.0.0.1 google.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 12157
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN A
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 26 14:08:03 CEST 2014
;; MSG SIZE rcvd: 39
in named log I can see:
...
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: in authva
lidated
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: resuming
nsecvalidate
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking f
or
relevant NSEC3
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates potential closest encloser: 'com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 at
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 pro
ves
name does not exist: 'google.com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates optout
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 at
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: nonexiste
nce
proof(s) found
26-Aug-2014 13:45:49.127 fctx 0x7ff97a28a440(google.com/DS): received validat
ion
completion event
26-Aug-2014 13:45:49.127 validator @0x7ff9745af3d0: dns_validator_destroy
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): nonexistence
validation OK
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): clone_results
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): done
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): stopeverything
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): cancelqueries
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): sendevents
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: in
dsfetched2: ncache nxrrset
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: plain DNSS
EC
returns unsecure (google.com): looking for DLV
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: looking fo
r
DLV google.com.dlv.isc.org
...
This looks to me that the result of DNSSEC validation of A record
for google.com proved that it is UNSECURE.
However the validation using DLV proceeds and fails in the end since
dlv.isc.org can not be resolved.
Doing a lookup for (signed) nic.cz A record succeeds:
[root@unused-4-247 ~]# dig @127.0.0.1 nic.cz A
; DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 @127.0.0.1 nic.cz A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
On Tue 26 Aug 2014 03:07:22 PM CEST, Mark Andrews wrote:
In message 53fc827e.7090...@redhat.com, Tomas Hozza writes:
On 08/26/2014 02:27 PM, Mark Andrews wrote:
Why would you expect them to succeed?
Because validation using root servers and authoritative servers proved
that the domain is intentionally unsecure.
No. It only proves that there is not a trust path from the root
to the zone. This is *not* the same thing as saying the zone is
unsigned. It is insecure *with* *respect* *to* the root trust
anchor. It may or may not be insecure w.r.t. other trust anchors
like those distributed in the dlv.isc.org zone.
OK, now I understand why it has to fail if configured to use DLV
but the validation using DLV failed for whatever reason.
Thank you!
If you use DLV you are
expecting anything for which DLV is used as a trust anchor to be
safe from being spoofed. The *only* way this can happen is to fail
if the DLV lookup fails for any reason.
I can understand that. It just didn't seem correct to me for the reason
stated above. Thanks for acknowledging that this behavior is expected.
Tomas
Mark
In message 53fc7b35.6040...@redhat.com, Tomas Hozza writes:
Hello.
I found out that when bind is configured as recursive resolver with
dnssec-lookaside set to 'auto' and dlv.isc.org is unreachable, all
lookups for unsigned (UNSECURE) names fail even if the validation
succeeds (IOW the validation of NSEC3 answer proves that DS does not
exist so domain (name) is not signed).
I tested it with one server set up as forwarder running on 127.0.0.1@80
configured not to answer queries for dlv.isc.org (query will timeout).
I have bind (9.9.4-P2) configured with:
forward only;
forwarders { 127.0.0.1 port 80; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
Doing a lookup for (unsigned) google.com A record times out:
# dig @127.0.0.1 google.com A
; DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 @127.0.0.1 google.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 12157
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.IN A
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 26 14:08:03 CEST 2014
;; MSG SIZE rcvd: 39
in named log I can see:
...
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: in auth
va
lidated
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: resumin
g
nsecvalidate
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking
f
or
relevant NSEC3
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking
f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates potential closest encloser: 'com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 a
t
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 p
ro
ves
name does not exist: 'google.com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates optout
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 a
t
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking
f
or
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: nonexis
te
nce
proof(s) found
26-Aug-2014 13:45:49.127 fctx 0x7ff97a28a440(google.com/DS): received valid
at
ion
completion event
26-Aug-2014 13:45:49.127 validator @0x7ff9745af3d0: dns_validator_destroy
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): nonexistence
validation OK
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): clone_results
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): done
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): stopeverything
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): cancelqueries
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): sendevents
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: in
dsfetched2: ncache nxrrset
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: plain DN
SS
EC
returns unsecure (google.com): looking for DLV
26-Aug-2014 13:45:49.128 validating
running named built with --enable-native-pkcs11 without HSM provider library
Hello. I'm trying to figure out how can named be built with --enable-native-pkcs11 and run without the PKCS#11 provider library. Our use-case is that given how OpenSSL does not support PKCS#11 properly, we would like to use the the native-pkcs11 if using some HSM, but by default run named without the need to have HSM. In case not having HSM, use OpenSSL for example. Right now it is not possible, and when named is built with --enable-native-pkcs11 it can not run without HSM and some PKCS#11 provider library. Would it be possible to make named to operate in a manner described in the previous section? Thanks in advance. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com ___ 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
Re: running named built with --enable-native-pkcs11 without HSM provider library
- Original Message - Tomas Hozza tho...@redhat.com wrote: Right now it is not possible, and when named is built with --enable-native-pkcs11 it can not run without HSM and some PKCS#11 provider library. Would using SoftHSM solve your problem? No. We don't want to install SoftHSM by default, only if explicitly chosen by the user. Basically we want to enable user to use native-pkcs11 with SoftHSM if needed. However by default have named running without it. http://www.opendnssec.org/softhsm/ http://ftp.isc.org/isc/bind9/9.10.0-P2/doc/arm/Bv9ARM.ch04.html#id2666009 Yeah, I read the ARM PKCS#11 section, that's why I think it is not possible. However I wanted to hear some opinions from named guys. Thanks. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com ___ 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
Re: running named built with --enable-native-pkcs11 without HSM provider library
- Original Message - On Wed, Aug 06, 2014 at 05:14:53PM +0100, Tony Finch wrote: Right now it is not possible, and when named is built with --enable-native-pkcs11 it can not run without HSM and some PKCS#11 provider library. Would using SoftHSM solve your problem? http://www.opendnssec.org/softhsm/ http://ftp.isc.org/isc/bind9/9.10.0-P2/doc/arm/Bv9ARM.ch04.html#id2666009 SoftHSM version 1 doesn't supply enough of the PKCS#11 API to meet all of BIND's crypto needs, but SoftHSMv2 works beautifully. Last I checked, version 2 hadn't been formally released yet, but it can be cloned from github: https://github.com/opendnssec/SoftHSMv2. The way things are currently set up, BIND can only drive one PKCS#11 provider library at a time. You build with a default provider, and it can be overridden via a command line option, but that's a little cumbersome. As far as I understand, without native-pkcs11 OpenSSL is used for crypto operations if the provided PKCS#11 library did not support some operation, or if the PKCS#11 provider library was not provided/was not available at all. With native-pkcs11 the the PKCS#11 provider library has to be provided and available all the time. I'm interested if there is any chance to fall-back to OpenSSL in that case OR specify OpenSSL as provider library (however preferably without the needed patch) during the build and if needed, specify e.g. the SoftHSMv2 provider library on the command line using '-E' during the runtime. I've been thinking about using a shim provider that would pass along PKCS#11 primitives to a back-end according to context, so you could switch seamlessly between providers -- that might be useful, for example, if you wanted to use a proper HSM for your KSK, but SoftHSM for the ZSK because it's faster. It might also enable us to drive an HSM that didn't have a complete PKCS#11 implementation, using SoftHSM to fill in the functional gaps. Haven't done any work on it, though. It sound like it would solve use-case I described. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com ___ 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
Re: How to disable DNSSEC/EDNS for lwresd
- Original Message -
In message 483759859.6291670.1398781076480.javamail.zim...@redhat.com,
Tomas H
ozza writes:
Hi.
I'm trying to disable DNSSEC/EDNS for the lwresd using the
following lwresd.conf:
options {
directory /var/named/;
dnssec-enable no;
dnssec-validation no;
pid-file /run/named/lwresd.pid;
session-keyfile /run/named/session.key;
};
lwres {
search {example1.;};
ndots 1;
};
But it seems that the 'dnssec-enable no;' statement has no
influence on the EDNS usage in queries sent by lwresd.
dnssec-enable no; controls how named responds to DO=1 queries.
It is a no-op to lwresd as it is not processing DNS requests.
I was able to disable EDNS when lwres is run as named
using:
server 0.0.0.0/0 {
edns no;
};
server ::/0 {
edns no;
};
Just add the server clauses to lwresd.conf.
lwresd -c lwresd.conf is running as lwresd
lwresd -C resolv.conf is running as lwresd
lwresd is the same as lwresd -C /etc/resolv.conf
named -c named.conf (with a lwres clause) is running as both named and
lwresd
named -c named.conf (without a lwres clause) is running as just named
Thank you for the explanation. I was apparently running lwresd with pointing
it to resolv.conf instead of lwresd.conf. Everything works fine now.
Regards,
Tomas
in the configuration. However I was not able to disable EDNS
when running lwresd.
We have a user that would like to disable EDNS to reduce the
overhead it adds and improve the performance. The DNSSEC is
not a priority for them.
Is there way to disable DNSSEC/EDNS for lwresd?
Thank you in advance.
Regards,
--
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience
PGP: 1D9F3C2D
Red Hat Inc. http://cz.redhat.com
___
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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
--
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience
PGP: 1D9F3C2D
Red Hat Inc. http://cz.redhat.com
___
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
How to disable DNSSEC/EDNS for lwresd
Hi.
I'm trying to disable DNSSEC/EDNS for the lwresd using the
following lwresd.conf:
options {
directory /var/named/;
dnssec-enable no;
dnssec-validation no;
pid-file /run/named/lwresd.pid;
session-keyfile /run/named/session.key;
};
lwres {
search {example1.;};
ndots 1;
};
But it seems that the 'dnssec-enable no;' statement has no
influence on the EDNS usage in queries sent by lwresd.
I was able to disable EDNS when lwres is run as named
using:
server 0.0.0.0/0 {
edns no;
};
server ::/0 {
edns no;
};
in the configuration. However I was not able to disable EDNS
when running lwresd.
We have a user that would like to disable EDNS to reduce the
overhead it adds and improve the performance. The DNSSEC is
not a priority for them.
Is there way to disable DNSSEC/EDNS for lwresd?
Thank you in advance.
Regards,
--
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience
PGP: 1D9F3C2D
Red Hat Inc. http://cz.redhat.com
___
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
