Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 9/3/21 01:55, Michael Sinatra wrote:
'listen-on any;' is the default for v4, so you should actually be
listening on 127.0.0.1 in addition to everything else (since all of
your listen-on's for v4 appear to be commented out). You *should* be
able to remove 'listen-on-v6 { ::1; };' and just leave the
'listen-on-v6 { any; };' in place. Doing a 'sockstat | grep named'
on FreeBSD should confirm this once you restart named (pretty sure you
already knew that, but I thought I'd mention it for completeness).
With "listen-on { 127.0.0.1; };" commented out, BIND will listen only
on the main IPv4 interfaces, and exclude just the localhost.
I've changed it to the below, now:
// If named is being used only as a local resolver, this is a safe default.
// For named to be accessible to the network, comment this option, specify
// the proper IP address, or delete this option.
// listen-on { 127.0.0.1; };
listen-on { any; };
// If you have IPv6 enabled on this system, uncomment this option for
// use as a local resolver. To give access to the network, specify
// an IPv6 address, or the keyword "any".
// listen-on-v6 { ::1; };
listen-on-v6 { any; };
It is now listening on all interfaces, both IPv4 and IPv6 localhost
addresses, as well as the IPv6 link-local addresses.
I've also removed the 'max-cache-size' setting, which should default
BIND to 90% of physical RAM.
Let me monitor and report back. Thanks.
Mark.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact 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
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 9/2/21 2:59 PM, Mark Tinka wrote:
On 9/2/21 23:51, Michael Sinatra wrote:
I have noticed this also and have opened a (similar but different)
issue, but it's a bit weird how it manifests itself.
On your freebsd installation, make sure that all of your interfaces
are configured and that bind can listen on them. (They don't
necessarily need to be up; they just need to be configured.)
Also, 'listen-on[-v6] any;' is more likely to prevent this kind of
memory leaking than having it listen on explicit addresses. But the
way I can (more) reliably reproduce it is to have a 'listen-on'
statement that references a non-existent interface/address.
I think this is a libuv problem, but I have been really short on time
to troubleshoot. But in the meantime, I would check on your
'listen-on' statements and make sure there aren't any stray addresses
in there.
What we have on all of our name servers is the below:
// If named is being used only as a local resolver, this is a safe default.
// For named to be accessible to the network, comment this option, specify
// the proper IP address, or delete this option.
// listen-on { 127.0.0.1; };
// If you have IPv6 enabled on this system, uncomment this option for
// use as a local resolver. To give access to the network, specify
// an IPv6 address, or the keyword "any".
listen-on-v6 { ::1; };
It *feels* like the above ^^ could be the culprit. 'listen-on any'
ought to listen on the loopback interface in addition to all other
configured ethernets and loopbacks. OTOH, the libuv-based versions of
BIND (e.g. >=9.16.x) appear to get kind of weird/confused with certain
types of listen-on statements.
listen-on-v6 { any; };
We are running dual-stack on all name servers, and both IPv4 and IPv6
reachability is confirmed solid.
On IPv4, we are listening on just the main interface. On IPv6, we are
listening on both the localhost and the main interface. Not sure if this
matters.
For local resolution on each name server, it refers to localhost for
both IPv4 and IPv6 in '/etc/resolv.conf'. Given our configuration, it's
using ::1 for local resolution, whenever that may be required, since
127.0.0.1 has nothing listening on it. Thanks.
'listen-on any;' is the default for v4, so you should actually be
listening on 127.0.0.1 in addition to everything else (since all of your
listen-on's for v4 appear to be commented out). You *should* be able to
remove 'listen-on-v6{ ::1; };' and just leave the 'listen-on-v6{
any; };' in place. Doing a 'sockstat | grep named' on FreeBSD should
confirm this once you restart named (pretty sure you already knew that,
but I thought I'd mention it for completeness).
michael
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact 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
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 9/2/21 23:51, Michael Sinatra wrote:
I have noticed this also and have opened a (similar but different)
issue, but it's a bit weird how it manifests itself.
On your freebsd installation, make sure that all of your interfaces
are configured and that bind can listen on them. (They don't
necessarily need to be up; they just need to be configured.)
Also, 'listen-on[-v6] any;' is more likely to prevent this kind of
memory leaking than having it listen on explicit addresses. But the
way I can (more) reliably reproduce it is to have a 'listen-on'
statement that references a non-existent interface/address.
I think this is a libuv problem, but I have been really short on time
to troubleshoot. But in the meantime, I would check on your
'listen-on' statements and make sure there aren't any stray addresses
in there.
What we have on all of our name servers is the below:
// If named is being used only as a local resolver, this is a safe default.
// For named to be accessible to the network, comment this option, specify
// the proper IP address, or delete this option.
// listen-on { 127.0.0.1; };
// If you have IPv6 enabled on this system, uncomment this option for
// use as a local resolver. To give access to the network, specify
// an IPv6 address, or the keyword "any".
listen-on-v6 { ::1; };
listen-on-v6 { any; };
We are running dual-stack on all name servers, and both IPv4 and IPv6
reachability is confirmed solid.
On IPv4, we are listening on just the main interface. On IPv6, we are
listening on both the localhost and the main interface. Not sure if this
matters.
For local resolution on each name server, it refers to localhost for
both IPv4 and IPv6 in '/etc/resolv.conf'. Given our configuration, it's
using ::1 for local resolution, whenever that may be required, since
127.0.0.1 has nothing listening on it. Thanks.
Mark.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact 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
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 9/2/21 2:35 PM, Mark Tinka wrote: Not sure if this issue offers some clue: https://gitlab.isc.org/isc-projects/bind9/-/issues/2575 I see its maintainer just closed it 11hrs ago... I have noticed this also and have opened a (similar but different) issue, but it's a bit weird how it manifests itself. On your freebsd installation, make sure that all of your interfaces are configured and that bind can listen on them. (They don't necessarily need to be up; they just need to be configured.) Also, 'listen-on[-v6] any;' is more likely to prevent this kind of memory leaking than having it listen on explicit addresses. But the way I can (more) reliably reproduce it is to have a 'listen-on' statement that references a non-existent interface/address. I think this is a libuv problem, but I have been really short on time to troubleshoot. But in the meantime, I would check on your 'listen-on' statements and make sure there aren't any stray addresses in there. michael ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact 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
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
Not sure if this issue offers some clue: https://gitlab.isc.org/isc-projects/bind9/-/issues/2575 I see its maintainer just closed it 11hrs ago... Mark. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact 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
Re: KSK signing zone records
Just give it time. Named will choose the appropriate DNSKEY when it comes time to re-sign the RRset. -- Mark Andrews > On 3 Sep 2021, at 03:26, Timothy A. Holtzen wrote: > > Okay, so if I'm interpreting this correctly. When the new alg 14 KSKs > were created and then the zone was signed (either automatically or via a > command) there was probably only a valid alg 8 ZSK available. As a > result bind used the alg 14 KSK as a defacto CSK and singed the zone > RRSets directly. This would make sense given the nature of the issue I > had with my key rotation process. However now I have both valid alg 8 > and alg 14 ZSK available. Is there a way to go back and get bind to > re-evaluate the zone to recognize the valid ZSK records and sign them only? > > Timothy A. Holtzen > Campus Network Administrator > Nebraska Wesleyan University > Public PGP ECC Curve 25519 Key: 11A2 3FDB AD70 12CA D77D C7DD DFFB 7662 24E6 > C30D > Old Public PGP RSA key: CFB4 3AE8 B726 DEBF 00D9 CCFC 426E 76AF DABC B3D7 > >> On 8/31/21 18:07, Mark Andrews wrote: >> Named will continually re-sign parts of the zone as the RRSIGs for a RRset >> fall due >> for replacement. Named looks at which keys are in the active state to >> determine along >> with the afore mentioned controls to work out which DNSKEYs will be used to >> re-sign the >> RRset. If in the past you only had one key type and you now have two, >> different keys >> may be used to re-sign the RRset. If you changed policy in named.conf, the >> new policy >> will be implemented as the RRSIGs are re-generated. >> >> It looks like you told named to re-sign the zone when there was only one >> type of DNSKEY >> key record (or you where unlucky enough for named to check the available >> keys whiles there >> was only one active key present) resulting in named overriding the policy in >> named.conf. >> >> Mark >> On 1 Sep 2021, at 03:44, Timothy A. Holtzen via bind-users wrote: >>> >>> I'm using Algorithm 8 RSA/SHA-256, and Algorithm 14 ECDSA/SHA-384. I >>> have one RSA KSK and one RSA ZSK. In addition I have two ECDSA KSK and >>> two ECDSA ZSK. The RSA KSK seems perfectly happy to sign the ECDSA >>> ZSKs. And both the RSA and ECDSA ZSKs seem to be singing records >>> correctly. It just seems to be the two newer ECDSA KSKs that instead of >>> signing the ZSKs are singing the domain records directly. >>> >>> Even more perplexing is that one of the domains seems to have fixed >>> itself. Now all the KSKs for that domain are singing the ZSKs and the >>> ZSKs are signing the domain records. But I've still got a couple of >>> other domains where it is doing it wrong. Is there some kind of timeout >>> or maintenance that gets run automatically that might have fixed the >>> issue? I've tried running an "rndc sign" command on the domains several >>> times. >>> >>> Timothy A. Holtzen >>> Campus Network Administrator >>> Nebraska Wesleyan University >>> Public PGP ECC Curve 25519 Key: 11A2 3FDB AD70 12CA D77D C7DD DFFB 7662 >>> 24E6 C30D >>> Old Public PGP RSA key: CFB4 3AE8 B726 DEBF 00D9 CCFC 426E 76AF DABC B3D7 >>> >>> On 8/30/21 17:40, raf via bind-users wrote: On Mon, Aug 30, 2021 at 10:13:05AM -0700, Chris Buxton wrote: > What algorithm(s) are you using for ZSK and KSK? If they’re not the > same algorithm, then both will be used to sign the entire zone. > > Regards, > Chris Buxton Just out of curiosity, why is that? Isn't having the KSK sign the ZSK enough? What difference does the nature of the thing being signed make? cheers, raf ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact 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 >>> ___ >>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >>> unsubscribe from this list >>> >>> ISC funds the development of this software with paid support subscriptions. >>> Contact 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 > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact 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
Re: Syntax for ECS ACL Entry
FTR The PROXY protocol is on the todo list, but the demand hasn’t been great so it’s more in the “patches accepted” area then something that’s just around the corner… -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 2. 9. 2021, at 20:27, Ryan McGuire > wrote: > > Thank you, in my searching I failed to come across that. > > Do you know if it's been replaced by something more "practical to deploy"? I > found some discussion regarding support for "The PROXY Protocol" > (https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt) but I don't > believe it's planned. This seems like such a common scenario, I'm surprised > the support that was there was removed but not replaced by anything. I > suppose it is open-source software and I'm free to port it into 9.16, but > this isn't a big enough problem for me personally to justify the time spent. > > -Ryan > > On 9/2/21 2:16 PM, Evan Hunt wrote: >>> I did compile 9.16.20 from source since the latest in Debian repos is >>> 9.16.15 but the result is the same. The doc snippet in my original email >>> was from 9.11 docs -- could this feature not have been brought forward >>> into 9.16 at all? The only related documented removed feature is >>> geoip-use-ecs. >> It was actually removed in 9.14: >> >> 4952. [func] Authoritative server support in named for the >> EDNS CLIENT-SUBNET option (which was experimental >> and not practical to deploy) has been removed. >> >> The ECS option is still supported in dig and mdig >> via the +subnet option, and can be parsed and logged >> when received by named, but it is no longer used >> for ACL processing. The "geoip-use-ecs" option >> is now obsolete; a warning will be logged if it is >> used in named.conf. "ecs" tags in an ACL definition >> are also obsolete and will cause the configuration >> to fail to load. [GL #32] >> >> Sorry about the inadequate documentation. There's a mechanism for flagging >> obsolete options in named.conf and logging a useful message about them, but >> it's not so straightforward when the option is still valid but the >> parameters have changed. >> > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support subscriptions. > Contact 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 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact 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
Re: Syntax for ECS ACL Entry
In this case I use dnsdist (by PowerDNS) for load balancing and failover -- requests are balanced between my internal bind9 servers, and if they are all down queries go to public DNS directly to avoid a total outage. The challenge here is that the source IP for all requests is now coming from dnsdist. They have an article here: https://dnsdist.org/advanced/passing-source-address.html that mentions the functionality supported in dnsdist, but there is no overlap with bind9 -- well, there was apparently up to 9.14, but it's since been removed. Bind is still able to parse (and present) the ECS to you, that works great, but the plumbing into the acl is what is needed to serve up a separate view by source client. Being realistic, this is not a large deployment, if it's an edge case then it is surely not worth anyone's time to add support back in. Thank you again for the replies. -Ryan On 9/2/21 2:42 PM, Evan Hunt wrote: On Thu, Sep 02, 2021 at 02:26:59PM -0400, Ryan McGuire wrote: Thank you, in my searching I failed to come across that. Do you know if it's been replaced by something more "practical to deploy"? I found some discussion regarding support for "The PROXY Protocol" (https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt) but I don't believe it's planned. This seems like such a common scenario, I'm surprised the support that was there was removed but not replaced by anything. I suppose it is open-source software and I'm free to port it into 9.16, but this isn't a big enough problem for me personally to justify the time spent. We do have support for recursive ECS processing in the special-sauce version of BIND we charge money for, but there hasn't been enough demand for support on the authoritiatve side to make it worth the development effort so far. But I would encourage you to put in a feature request with details about your use case, and we'll consider it in the future. Unfortunately, the older auth support was terribly space-inefficient, and also didn't comply with the RFC, so it kind of had to go. I'm not sure which of the open-source auth servers currently have ECS support. PowerDNS maybe? And a quick google search just suggested one called gdnsd, which I hadn't heard of before. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact 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
Re: Syntax for ECS ACL Entry
On Thu, Sep 02, 2021 at 02:26:59PM -0400, Ryan McGuire wrote: > Thank you, in my searching I failed to come across that. > > Do you know if it's been replaced by something more "practical to > deploy"? I found some discussion regarding support for "The PROXY > Protocol" (https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt) > but I don't believe it's planned. This seems like such a common > scenario, I'm surprised the support that was there was removed but not > replaced by anything. I suppose it is open-source software and I'm free > to port it into 9.16, but this isn't a big enough problem for me > personally to justify the time spent. We do have support for recursive ECS processing in the special-sauce version of BIND we charge money for, but there hasn't been enough demand for support on the authoritiatve side to make it worth the development effort so far. But I would encourage you to put in a feature request with details about your use case, and we'll consider it in the future. Unfortunately, the older auth support was terribly space-inefficient, and also didn't comply with the RFC, so it kind of had to go. I'm not sure which of the open-source auth servers currently have ECS support. PowerDNS maybe? And a quick google search just suggested one called gdnsd, which I hadn't heard of before. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact 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
Re: Syntax for ECS ACL Entry
Thank you, in my searching I failed to come across that. Do you know if it's been replaced by something more "practical to deploy"? I found some discussion regarding support for "The PROXY Protocol" (https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt) but I don't believe it's planned. This seems like such a common scenario, I'm surprised the support that was there was removed but not replaced by anything. I suppose it is open-source software and I'm free to port it into 9.16, but this isn't a big enough problem for me personally to justify the time spent. -Ryan On 9/2/21 2:16 PM, Evan Hunt wrote: I did compile 9.16.20 from source since the latest in Debian repos is 9.16.15 but the result is the same. The doc snippet in my original email was from 9.11 docs -- could this feature not have been brought forward into 9.16 at all? The only related documented removed feature is geoip-use-ecs. It was actually removed in 9.14: 4952. [func] Authoritative server support in named for the EDNS CLIENT-SUBNET option (which was experimental and not practical to deploy) has been removed. The ECS option is still supported in dig and mdig via the +subnet option, and can be parsed and logged when received by named, but it is no longer used for ACL processing. The "geoip-use-ecs" option is now obsolete; a warning will be logged if it is used in named.conf. "ecs" tags in an ACL definition are also obsolete and will cause the configuration to fail to load. [GL #32] Sorry about the inadequate documentation. There's a mechanism for flagging obsolete options in named.conf and logging a useful message about them, but it's not so straightforward when the option is still valid but the parameters have changed. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact 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
Re: Syntax for ECS ACL Entry
> I did compile 9.16.20 from source since the latest in Debian repos is > 9.16.15 but the result is the same. The doc snippet in my original email > was from 9.11 docs -- could this feature not have been brought forward > into 9.16 at all? The only related documented removed feature is > geoip-use-ecs. It was actually removed in 9.14: 4952. [func] Authoritative server support in named for the EDNS CLIENT-SUBNET option (which was experimental and not practical to deploy) has been removed. The ECS option is still supported in dig and mdig via the +subnet option, and can be parsed and logged when received by named, but it is no longer used for ACL processing. The "geoip-use-ecs" option is now obsolete; a warning will be logged if it is used in named.conf. "ecs" tags in an ACL definition are also obsolete and will cause the configuration to fail to load. [GL #32] Sorry about the inadequate documentation. There's a mechanism for flagging obsolete options in named.conf and logging a useful message about them, but it's not so straightforward when the option is still valid but the parameters have changed. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact 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
Re: KSK signing zone records
Okay, so if I'm interpreting this correctly. When the new alg 14 KSKs were created and then the zone was signed (either automatically or via a command) there was probably only a valid alg 8 ZSK available. As a result bind used the alg 14 KSK as a defacto CSK and singed the zone RRSets directly. This would make sense given the nature of the issue I had with my key rotation process. However now I have both valid alg 8 and alg 14 ZSK available. Is there a way to go back and get bind to re-evaluate the zone to recognize the valid ZSK records and sign them only? Timothy A. Holtzen Campus Network Administrator Nebraska Wesleyan University Public PGP ECC Curve 25519 Key: 11A2 3FDB AD70 12CA D77D C7DD DFFB 7662 24E6 C30D Old Public PGP RSA key: CFB4 3AE8 B726 DEBF 00D9 CCFC 426E 76AF DABC B3D7 On 8/31/21 18:07, Mark Andrews wrote: > Named will continually re-sign parts of the zone as the RRSIGs for a RRset > fall due > for replacement. Named looks at which keys are in the active state to > determine along > with the afore mentioned controls to work out which DNSKEYs will be used to > re-sign the > RRset. If in the past you only had one key type and you now have two, > different keys > may be used to re-sign the RRset. If you changed policy in named.conf, the > new policy > will be implemented as the RRSIGs are re-generated. > > It looks like you told named to re-sign the zone when there was only one type > of DNSKEY > key record (or you where unlucky enough for named to check the available keys > whiles there > was only one active key present) resulting in named overriding the policy in > named.conf. > > Mark > >> On 1 Sep 2021, at 03:44, Timothy A. Holtzen via bind-users >> wrote: >> >> I'm using Algorithm 8 RSA/SHA-256, and Algorithm 14 ECDSA/SHA-384. I >> have one RSA KSK and one RSA ZSK. In addition I have two ECDSA KSK and >> two ECDSA ZSK. The RSA KSK seems perfectly happy to sign the ECDSA >> ZSKs. And both the RSA and ECDSA ZSKs seem to be singing records >> correctly. It just seems to be the two newer ECDSA KSKs that instead of >> signing the ZSKs are singing the domain records directly. >> >> Even more perplexing is that one of the domains seems to have fixed >> itself. Now all the KSKs for that domain are singing the ZSKs and the >> ZSKs are signing the domain records. But I've still got a couple of >> other domains where it is doing it wrong. Is there some kind of timeout >> or maintenance that gets run automatically that might have fixed the >> issue? I've tried running an "rndc sign" command on the domains several >> times. >> >> Timothy A. Holtzen >> Campus Network Administrator >> Nebraska Wesleyan University >> Public PGP ECC Curve 25519 Key: 11A2 3FDB AD70 12CA D77D C7DD DFFB 7662 >> 24E6 C30D >> Old Public PGP RSA key: CFB4 3AE8 B726 DEBF 00D9 CCFC 426E 76AF DABC B3D7 >> >> On 8/30/21 17:40, raf via bind-users wrote: >>> On Mon, Aug 30, 2021 at 10:13:05AM -0700, Chris Buxton >>> wrote: >>> What algorithm(s) are you using for ZSK and KSK? If they’re not the same algorithm, then both will be used to sign the entire zone. Regards, Chris Buxton >>> Just out of curiosity, why is that? >>> Isn't having the KSK sign the ZSK enough? >>> What difference does the nature of the thing >>> being signed make? >>> >>> cheers, >>> raf >>> >>> ___ >>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >>> unsubscribe from this list >>> >>> ISC funds the development of this software with paid support subscriptions. >>> Contact 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 >> ___ >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >> unsubscribe from this list >> >> ISC funds the development of this software with paid support subscriptions. >> Contact 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 OpenPGP_signature Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact 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
Re: Syntax for ECS ACL Entry
I did compile 9.16.20 from source since the latest in Debian repos is
9.16.15 but the result is the same. The doc snippet in my original email
was from 9.11 docs -- could this feature not have been brought forward
into 9.16 at all? The only related documented removed feature is
geoip-use-ecs.
-Ryan
On 9/2/21 10:06 AM, Ryan McGuire wrote:
I'm setting ECS in dnsdist in hopes of using it in an ACL to choose a
view. The views are working well, and the ECS is read by bind9 (see
log below), but I can't seem to find a syntax for adding an ecs entry
into an acl. Here is what I've tried:
acl "filtered" {
192.168.0.90;
192.168.0.91;
192.168.0.92;
192.168.0.93;
* ecs 192.168.99.0/24;*
};
view filtered-view {
match-clients { filtered; };
{...}
When I try to start bind with this config, I get the following error:
/etc/bind/named.conf.local:6: missing ';' before '192.168.99.0'
Everything works as it should if I remove the ecs entry from the acl.
I can see the ECS is being set by dnsdist when I enable query logging:
client @0x7f21840117e8 192.168.0.1#43466 (elastic.mcguire.local): view
filtered-view: query: elastic.mcguire.local IN A +E(0) (192.168.0.5)
*[ECS 192.168.99.0/24/0]*
From the docs*:*
"An ACL containing an element of the form ecs prefix will match if a
request arrives in containing an ECS option encoding an address within
that prefix. If the request has no ECS option, then "ecs" elements are
simply ignored. Addresses in ACLs that are not prefixed with "ecs" are
matched only against the source address."*
*
I am running bind9 version 9.16.15.
Regards,
Ryan McGuire
p. 260.202.0500 m. 978.501.3620
f. 260.202.0420
w. www.libretechconsulting.com
Libre Tech Consulting
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact 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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact 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
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 9/2/21 16:30, Michal Nowak wrote: Mark, what's the exact BIND 9.16 version which is crashing for you? I started off with 9.16.19 several weeks ago (coming from 9.11), and that was crashing. I upgraded to 9.16.20 last week, and it's crashing too. Why do you say that the reason for crashing is BIND running out of swap? How did you found out? Aug 29 10:56:36 ns-01-emg kernel: pid 59549 (named), jid 0, uid 53, was killed: out of swap space Note that BIND 9.16.19 was tripping over a misplaced assert, see https://downloads.isc.org/isc/bind9/9.16.20/doc/arm/html/notes.html#notes-for-bind-9-16-20. Yes, I saw this and assumed that is what was causing my problem. But alas, given how busy the log files are on a high-load resolver, it was by pure luck that I managed to view the logs at the exact time BIND crashed, last week. Mark. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact 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
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 02/09/2021 13:29, Mark Tinka wrote: Hi all. Ever since we moved from BIND-9.11 to BIND-9.16, we've been experiencing 'named' crashing after 24hrs - 36hrs on high-load resolver-only servers, running on FreeBSD-13.0. We found that the reason for this was due to BIND running out of swap space. An increase in swap space by creating a 4GB swap file did not help. So we are now playing with the 'max-cache-size' value in BIND. The system has 15GB of physical RAM. Limiting BIND to 13GB of memory does not work; 'named' still crashes due to a lack of swap space. We have then switched to % values, and it's still crashing for the same reason at 90% and now 80%. We are now testing 70%. Anyone have some idea of how we can get this under control? Is there a possibility that BIND is not properly understanding how much physical RAM is available to FreeBSD, and just burns through it anyway, tripping swap space in the process? I can't think of any reason why BIND would keep burning RAM if it has been told to limit its demand to a certain value or %. All help appreciated. Thanks. Mark. Mark, what's the exact BIND 9.16 version which is crashing for you? Why do you say that the reason for crashing is BIND running out of swap? How did you found out? Note that BIND 9.16.19 was tripping over a misplaced assert, see https://downloads.isc.org/isc/bind9/9.16.20/doc/arm/html/notes.html#notes-for-bind-9-16-20. Michal ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact 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
Syntax for ECS ACL Entry
I'm setting ECS in dnsdist in hopes of using it in an ACL to choose a
view. The views are working well, and the ECS is read by bind9 (see log
below), but I can't seem to find a syntax for adding an ecs entry into
an acl. Here is what I've tried:
acl "filtered" {
192.168.0.90;
192.168.0.91;
192.168.0.92;
192.168.0.93;
* ecs 192.168.99.0/24;*
};
view filtered-view {
match-clients { filtered; };
{...}
When I try to start bind with this config, I get the following error:
/etc/bind/named.conf.local:6: missing ';' before '192.168.99.0'
Everything works as it should if I remove the ecs entry from the acl.
I can see the ECS is being set by dnsdist when I enable query logging:
client @0x7f21840117e8 192.168.0.1#43466 (elastic.mcguire.local): view
filtered-view: query: elastic.mcguire.local IN A +E(0) (192.168.0.5)
*[ECS 192.168.99.0/24/0]*
From the docs*:*
"An ACL containing an element of the form ecs prefix will match if a
request arrives in containing an ECS option encoding an address within
that prefix. If the request has no ECS option, then "ecs" elements are
simply ignored. Addresses in ACLs that are not prefixed with "ecs" are
matched only against the source address."*
*
I am running bind9 version 9.16.15.
Regards,
Ryan McGuire
p. 260.202.0500 m. 978.501.3620 f.
260.202.0420
w. www.libretechconsulting.com
Libre Tech Consulting
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact 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
BIND 'max-cache-size' Value on FreeBSD-13.0
Hi all. Ever since we moved from BIND-9.11 to BIND-9.16, we've been experiencing 'named' crashing after 24hrs - 36hrs on high-load resolver-only servers, running on FreeBSD-13.0. We found that the reason for this was due to BIND running out of swap space. An increase in swap space by creating a 4GB swap file did not help. So we are now playing with the 'max-cache-size' value in BIND. The system has 15GB of physical RAM. Limiting BIND to 13GB of memory does not work; 'named' still crashes due to a lack of swap space. We have then switched to % values, and it's still crashing for the same reason at 90% and now 80%. We are now testing 70%. Anyone have some idea of how we can get this under control? Is there a possibility that BIND is not properly understanding how much physical RAM is available to FreeBSD, and just burns through it anyway, tripping swap space in the process? I can't think of any reason why BIND would keep burning RAM if it has been told to limit its demand to a certain value or %. All help appreciated. Thanks. Mark. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact 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
