How to disable DNSSEC/EDNS for lwresd

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/listi

Re: How to disable DNSSEC/EDNS for lwresd

f 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.

running named built with --enable-native-pkcs11 without HSM provider library

n 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-

Re: running named built with --enable-native-pkcs11 without HSM provider library

- Original Message - > Tomas Hozza 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 do

Re: running named built with --enable-native-pkcs11 without HSM provider library

; 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.

recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'

SIZE rcvd: 51 I think this behavior (with unsigned records) may not be completely correct. I think since the chain of trust built from the root server proves that the domain name is not signed, the following unsuccessful validation using DLV should not make the whole lookup fail. However I might be

Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'

ting 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.i

Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'

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 > looku

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 server

Re: Possible bug in dig

e 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 __

RPZ zone defined in a view

ned 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 documenta

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 > > opt

ISC DHCP does not work with BIND 9.10

ULL 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,

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 wrote: > > > There's [1] a packaging policy on Fedora, > > that packages can't be shipped with bundled libraries, > > which is a case of BIND b

Re: ISC DHCP does not work with BIND 9.10

nother 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

Re: running named built with --enable-native-pkcs11 without HSM provider library

aries with OpenSSL, but also named-pkcs11 binary and *-pkcs11 versions of appropriate libraries. This way user can install whichever version they need. Note that we use SoftHSM v2 as a provider by default. I know only about FreeIPA project, which requested the named to be available also wi

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

Mitigation of server's load by queries for non-existing domains

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 Engi

Re: Mitigation of server's load by queries for non-existing domains

On 12.01.2016 18:16, Tony Finch wrote: > Tomas Hozza 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-d