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
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.
-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 <https://libretechconsulting.com>
Libre Tech Consulting <https://libretechconsulting.com>
___
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
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 <https://libretechconsulting.com>
Libre Tech Consulting <https://libretechconsulting.com>
___
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: error reading private key file, ddns_update update failed not found
Good Morning, No surprise I'm sure, but this was user error. I had enabled inline signing but was manually running dns-signzone as I always had. Admittedly I didn't understand how inline signing worked, but this KB article made it obvious: https://kb.isc.org/article/AA-00626/0/Inline-S igning-in-ISC-BIND-9.9.0-Examples.html. Updates are working perfectly now. I'm not sure if there is a way to implement a log message if inline signing is enabled for a zone but a manually signed zone file is referenced or present, but it would be very helpful should someone stuck [very far] in the past like I was run into this scenario. There is no end to the outdated and inaccurate blogs and tutorials for bind that can cause this to happen. Regards, -Ryan On Sat, 2018-03-31 at 18:25 -0400, rmcgu...@libretechconsulting.com wrote: > Hi Kim, > Thank you for your email. I'll give this a shot. I did run dns- > signzone on both zones again but I didn't remove the signed zones > first. > Regards, > -Ryan > > > Original Message > From: Kim Culhan <w8hd...@gmail.com> > Sent: Friday, March 30, 2018 06:32 PM > To: bind-users@lists.isc.org > Subject: Re: error reading private key file, ddns_update update > failed not found > > On Fri, March 30, 2018 4:57 pm, Ryan McGuire wrote: > > > Mar 29 15:50:39 bind named[99]: dns_dnssec_findzonekeys2: error > > reading private key file mcguire.local/RSASHA256/43356: file not > > > found > > Mar 29 15:50:39 bind named[99]: dns_dnssec_findzonekeys2: error > > reading private key file mcguire.local/RSASHA256/43345: file not > >found > > Recent experience has been that the 'key file not found' problem an > result from > replacing the key files in the key directory. > > When the zone is signed, bind retains the key files which existed at > that time > by including them in the signed zone files. > > There may be a better way to fix this, but I found it necessary to > re-sign the zone > after removing the existing signed zones files: > > As in: rm domain.zone.* then resign the zone. > > In the process of Googling for a solution to this problem for days I > found only one > more 'sophisticated' approach to this problem. > > This is probably not the best way to do this, but it gets the server > up and running > again in a few minutes. > > Maybe someone will followup to this 'solution' with the correct way > and it may be > you didn't make the mistake I did and re-generate the keys. > > thanks > -kim > > ___ > 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___ 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
error reading private key file, ddns_update update failed not found
Good Afternoon,
I have a newly configured bind9 server with two dynamic zones that I
cannot seem to get working. I've ensured I have a key-directory
configured and I've confirmed that the keys exist and are readable by
bind but I'm unable to resolve the issue. The zones themselves work
fine, but dynamic updates are failing. If it's relevant, bind is
running inside an LXD container.
Logs:
Mar 29 15:50:39 bind named[99]: client 192.168.0.3#2093/key
ddns_update: signer "ddns_update" approved
Mar 29 15:50:39 bind named[99]: client 192.168.0.3#2093/key
ddns_update: updating zone 'mcguire.local/IN': adding an RR at 'am335x-
opt.mcguire.local' A 192.168.0.165
Mar 29 15:50:39 bind named[99]: client 192.168.0.3#2093/key
ddns_update: updating zone 'mcguire.local/IN': adding an RR at 'am335x-
opt.mcguire.local' TXT "3154a902d1b045a4064274c0d6b5
Mar 29 15:50:39 bind named[99]: dns_dnssec_findzonekeys2: error reading
private key file mcguire.local/RSASHA256/43356: file not found
Mar 29 15:50:39 bind named[99]: dns_dnssec_findzonekeys2: error reading
private key file mcguire.local/RSASHA256/43345: file not found
Mar 29 15:50:39 bind named[99]: client 192.168.0.3#2093/key
ddns_update: updating zone 'mcguire.local/IN': found no active private
keys, unable to generate any signatures
Mar 29 15:50:39 bind named[99]: client 192.168.0.3#2093/key
ddns_update: updating zone 'mcguire.local/IN': RRSIG/NSEC/NSEC3 update
failed: not found
Zone config:
zone "0.168.192.in-addr.arpa" IN {
type master;
file "/etc/bind/zones/db.0.168.192.in-addr.arpa.signed";
auto-dnssec maintain;
key-directory "/etc/bind/keys";
inline-signing yes;
allow-update { key DDNS_UPDATE; };
};
zone "mcguire.local" IN {
type master;
file "/etc/bind/zones/db.mcguire.local.signed";
auto-dnssec maintain;
key-directory "/etc/bind/keys";
inline-signing yes;
allow-update { key DDNS_UPDATE; };
};
Key directory and relevant keys:
File: /etc/bind/keys/
[...]
Access: (0755/drwxr-xr-x) Uid: (0/root) Gid:
( 112/bind)
-rw-r--r-- 1 bind bind 627 Mar 28 12:11 K0.168.192.in-
addr.arpa.+008+04239.key
-rw-r- 1 bind bind 1776 Mar 28 12:11 K0.168.192.in-
addr.arpa.+008+04239.private
-rw-r--r-- 1 bind bind 972 Mar 28 12:12 K0.168.192.in-
addr.arpa.+008+05959.key
-rw-r- 1 bind bind 3316 Mar 28 12:12 K0.168.192.in-
addr.arpa.+008+05959.private
-rw-r--r-- 1 bind bind 955 Mar 28 12:11 Kmcguire.local.+008+43345.key
-rw-r- 1 bind bind 3316 Mar 28 12:11
Kmcguire.local.+008+43345.private
-rw-r--r-- 1 bind bind 610 Mar 28 12:11 Kmcguire.local.+008+43356.key
-rw-r- 1 bind bind 1776 Mar 28 12:11
Kmcguire.local.+008+43356.private
Any ideas?
Regards,
-Ryan___
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
