bind 9.18.7, fbsd13.1: crash with signed/signing zone
Hello,
I have a zone definition like this:
zone "myzone" in {
type master;file "signed/myzone";
allow-transfer { "myacl"; };
inline-signing yes;
dnssec-policy default;
};
and starting bind9.18.7 on FreeBSD 13.1 (self-compiled ports version)
leads to this crash, according to syslog, see below.
Does anyone have an idea on how to debug/fix this ?
Oct 15 16:48:08 sec named[39818]: rbtdb.c:6762: REQUIRE(((rbtnode->nsec ==
DNS_RBT_NSEC_NSEC3 && (rdataset->type == ((dns_rdatatype_t)dns_rdatatype_nsec3)
|| rdataset->covers == ((dns_rdatatype_t)dns_rdatatype_nsec3))) ||
(rbtnode->nsec != DNS_RBT_NSEC_NSEC3 && rdataset->type !=
((dns_rdatatype_t)dns_rdatatype_nsec3) && rdataset->covers !=
((dns_rdatatype_t)dns_rdatatype_nsec3 failed, back trace
Oct 15 16:48:08 sec named[39818]: 0x23ffd8 at
/usr/local/sbin/named
Oct 15 16:48:08 sec named[39818]: 0x80031613a at
/usr/local/lib/libisc-9.18.7.so
Oct 15 16:48:08 sec named[39818]: 0x800979411 at
/usr/local/lib/libdns-9.18.7.so
Oct 15 16:48:08 sec named[39818]: 0x800a53d16
at /usr/local/lib/libdns-9.18.7.so
Oct 15 16:48:08 sec named[39818]: 0x800334e33 at
/usr/local/lib/libisc-9.18.7.so
Oct 15 16:48:08 sec named[39818]: 0x800305e62
at /usr/local/lib/libisc-9.18.7.so
Oct 15 16:48:08 sec named[39818]: 0x800300823
at /usr/local/lib/libisc-9.18.7.so
Oct 15 16:48:08 sec named[39818]: 0x800305d26
at /usr/local/lib/libisc-9.18.7.so
Oct 15 16:48:08 sec named[39818]: 0x8002fc8ad at
/usr/local/lib/libisc-9.18.7.so
Oct 15 16:48:08 sec named[39818]: 0x800b72eea at
/usr/local/lib/libuv.so.1
Oct 15 16:48:08 sec named[39818]: 0x800b84555 at
/usr/local/lib/libuv.so.1
Oct 15 16:48:08 sec named[39818]: 0x800b73438 at
/usr/local/lib/libuv.so.1
Oct 15 16:48:08 sec named[39818]: 0x8002fc9ab at
/usr/local/lib/libisc-9.18.7.so
Oct 15 16:48:08 sec named[39818]: 0x80033d2c6 at
/usr/local/lib/libisc-9.18.7.so
Oct 15 16:48:08 sec named[39818]: exiting (due to assertion failure)
--
p...@opsec.eu+49 171 3101372Now what ?
--
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 9.18.7, fbsd13.1: crash with signed/signing zone
Hi!
> I have a zone definition like this:
>
> zone "myzone" in {
> type master;file "signed/myzone";
Aha, this file path was wrong. Fixed, at least it crashes no longer.
--
p...@opsec.eu+49 171 3101372Now what ?
--
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: Question About Internal Recursive Resolvers
>>I'm thinking about redesigning an internal DNS environment. To begin >>with, all internal DNS zones would reside on non-recursive servers >>only. >why? My understanding has always been that the recommendation is/was to separate recursive and non-recursive servers. Now I understand I'm talking about an INTERNAL environment and the rules have over the years become somewhat lax... In this case I also believe this would provide a more granular approach to using security features such as tsig keys to control updates. >> That said, all clients would connect to recursive resolvers. >don't they now? They do. I'm talking about a situation where an edge layer can be eliminated. Each recursive server would have access out to the internet. No forwarding would be required. >>The question is this; do I use an internal root with pointers to the >>internal zones (as well as the outside DNS world) or do I include stub >>zones to point at the non-recursive internal servers? >stub zones, forward zones (forward with recursion bit set) or static-stub zones (send iterative queries to configured servers)> Again, my understanding is that forwarding would require recursion. Thanks for the info about stub zones etc. >>Access to the internal DNS zones would be controlled by location. >if you have recursive servers in internal network, you don't need control >access on auth-only servers If a non-secure client (read the next sentence...) accesses the same recursive server as a regular client, it will have access to the internal zones by default.. Therefore we need to have some sort of access controls in place. >>(e.g. guest WiFi devices would NOT have access to internal DNS >>zones...) >> >>Recursive resolvers would allow implementation of features such as RPZ, etc. >do you need RPZ for internal zones? Since ALL recursive servers have access out to the internet, yes. Please forgive me if my post was confusing, arrogant, or naive. I'm simply trying to seek the wisdom of those on the list that have more experience or different experience than myself. Hopefully, I can gain from that wisdom and we can provide a kind environment where those less educated feel mentored. Bob -- 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: Question About Internal Recursive Resolvers
I'm thinking about redesigning an internal DNS environment. To begin with, all internal DNS zones would reside on non-recursive servers only. why? On 15.10.22 12:03, Bob McDonald wrote: My understanding has always been that the recommendation is/was to separate recursive and non-recursive servers. Now I understand I'm talking about an INTERNAL environment and the rules have over the years become somewhat lax... In this case I also believe this would provide a more granular approach to using security features such as tsig keys to control updates. This is a common misconception. Yes, it's a good idea to separate recursive servers accessed/used by your clients from authoritative servers accessed/used by whole internet. But this does NOT mean that internal/recursive servers must not, nor should not containt your internal zones, nor it means you should put your internal zones to your publicly accessible authoritative servers. If you have own zones for your own usage, exactly the same way you have recursive servers, it makes rarely sense to put them to other servers than your internal/recursive servers, just put internal zones to internal servers. If you are an ISP/registry/DNS provider, it makes sense to separate authoritative zones for your clients' domains, for all those cases your client move their domains somewhere else without notifying you (hell, they do that too often), or to be able to prepare moving domains to your servers. The question is this; do I use an internal root with pointers to the internal zones (as well as the outside DNS world) or do I include stub zones to point at the non-recursive internal servers? stub zones, forward zones (forward with recursion bit set) or static-stub zones (send iterative queries to configured servers)> Again, my understanding is that forwarding would require recursion. Thanks for the info about stub zones etc. forward zones - named sends recursive query to the primary servers stub zones - named fetches NS records from primary servers and uses them for resolution static-stub zones - named forwards iterative (non-recursive) requests to primary servers clients accessing any of these zones must have recursion allowed and recursion must be enabled in BIND. Access to the internal DNS zones would be controlled by location. if you have recursive servers in internal network, you don't need control access on auth-only servers If a non-secure client (read the next sentence...) accesses the same recursive server as a regular client, it will have access to the internal zones by default.. Therefore we need to have some sort of access controls in place. and THIS is exactly the reason you SHOULD put your internal zones on your internal server. Please forgive me if my post was confusing, arrogant, or naive. neither one. I'm simply trying to seek the wisdom of those on the list that have more experience or different experience than myself. Hopefully, I can gain from that wisdom and we can provide a kind environment where those less educated feel mentored. that's why we are here. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95 -- 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: Question About Internal Recursive Resolvers
On 10/15/22 10:03 AM, Bob McDonald wrote: My understanding has always been that the recommendation is/was to separate recursive and non-recursive servers. I too (had) long shared -- what I'm going to retroactively call -- that over simplification. Now I understand I'm talking about an INTERNAL environment and the rules have over the years become somewhat lax... In this case I also believe this would provide a more granular approach to using security features such as tsig keys to control updates. I don't know if the rules have become more lax so much as been clarified to indicate internal / private vs external / (semi)public servers. Semi-public in things like an ISP allows it's IP space to perform recursive queries. If a non-secure client (read the next sentence...) accesses the same recursive server as a regular client, it will have access to the internal zones by default.. Therefore we need to have some sort of access controls in place. I think the emphasis is on "by default". I also believe there are many ways to alter this default behavior. Please forgive me if my post was confusing, arrogant, or naive. I'm simply trying to seek the wisdom of those on the list that have more experience or different experience than myself. Hopefully, I can gain from that wisdom and we can provide a kind environment where those less educated feel mentored. I've found that almost everyone, myself included, tends to get invested and energetic in discussions. Sometimes even animated. But as long as we don't make anything personal and keep things at arms length, we can almost always see through the fog and help / learn from each other. By all means, feel free to dislike / disagree with things I say / do. Please ask why I do things. Please share why you think / do what you do as I'd like to learn from you. But please, for the love of $DEITY please do not perpetuate ad hominem attacks. -- Not that anyone has in this thread. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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: Question About Internal Recursive Resolvers
On 10/15/22 10:34 AM, Matus UHLAR - fantomas wrote: If you are an ISP/registry/DNS provider, it makes sense to separate authoritative zones for your clients' domains, for all those cases your client move their domains somewhere else without notifying you (hell, they do that too often), or to be able to prepare moving domains to your servers. #truth forward zones - named sends recursive query to the primary servers stub zones- named fetches NS records from primary servers and uses them for resolution static-stub zones - named forwards iterative (non-recursive) requests to primary servers clients accessing any of these zones must have recursion allowed and recursion must be enabled in BIND. Please clarify where recursion needs to be allowed; the BIND server clients are talking to and / or the back end server that BIND is talking to on the client's behalf. I'm not completely clear and I think it's better to ask than to assume incorrectly. On 10/15/22 10:03 AM, Bob McDonald wrote: If a non-secure client (read the next sentence...) accesses the same recursive server as a regular client, it will have access to the internal zones by default.. Therefore we need to have some sort of access controls in place. and THIS is exactly the reason you SHOULD put your internal zones on your internal server. Sorry if I'm being particularly dense this morning, but I'm not following ~> understanding Bob's and Matus's statements like I want to. How does hosting the zone on an internal server provide any additional security? Or are you simply relying on other security mechanisms to prevent non-secure clients -- as Bob described them -- from accessing the server ~> zone? I feel like, by default -- as Bob described, any hosted zone is going to be accessible by any client that can query the server. With this in mind, I feel like the type of zone; primary / secondary / mirror / stub / static-stub / forward, makes little difference in and of itself. Rather, it would be dependent on global and / or per-zone allow-* statements to protect the server / zone(s) at the BIND application level. Does that make sense? What am I missing / misunderstanding? that's why we are here. :-) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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: Question About Internal Recursive Resolvers
If you are an ISP/registry/DNS provider, it makes sense to separate authoritative zones for your clients' domains, for all those cases your client move their domains somewhere else without notifying you (hell, they do that too often), or to be able to prepare moving domains to your servers. #truth On 10/15/22 10:34 AM, Matus UHLAR - fantomas wrote: forward zones - named sends recursive query to the primary servers stub zones- named fetches NS records from primary servers and uses them for resolution static-stub zones - named forwards iterative (non-recursive) requests to primary servers clients accessing any of these zones must have recursion allowed and recursion must be enabled in BIND. On 15.10.22 11:50, Grant Taylor via bind-users wrote: Please clarify where recursion needs to be allowed; the BIND server clients are talking to and / or the back end server that BIND is talking to on the client's behalf. I'm not completely clear and I think it's better to ask than to assume incorrectly. recursion must be allowed on the BIND server that is supposed to forward queries from clients, and those clients need to have recursion enabled on that BIND server. the Bob mentions copnfiguring recursive server so I assume everything is already allowed, I just noted that recursion is needed for zone types above. On 10/15/22 10:03 AM, Bob McDonald wrote: If a non-secure client (read the next sentence...) accesses the same recursive server as a regular client, it will have access to the internal zones by default.. Therefore we need to have some sort of access controls in place. and THIS is exactly the reason you SHOULD put your internal zones on your internal server. Sorry if I'm being particularly dense this morning, but I'm not following ~> understanding Bob's and Matus's statements like I want to. How does hosting the zone on an internal server provide any additional security? Or are you simply relying on other security mechanisms to prevent non-secure clients -- as Bob described them -- from accessing the server ~> zone? Company has internal/recursive servers only accessible by internal clients. If you configure internal zones on these servers, all internal clients will immediately have access to these zones, no measures needed (though possible) If you configure internal zones on separate servers, you must: - configure recursive servers to direct lookups to authoritative servers - control access to those zones on authoritative servers. so, you must take two more measures. I feel like, by default -- as Bob described, any hosted zone is going to be accessible by any client that can query the server. Bob describes moving internal zones to non-recursive servers. https://lists.isc.org/pipermail/bind-users/2022-October/106756.html Which requires those measures above, without obvious need, except the misunderstood principle "separate recursive and authoritative servers". With this in mind, I feel like the type of zone; primary / secondary / mirror / stub / static-stub / forward, makes little difference in and of itself. Rather, it would be dependent on global and / or per-zone allow-* statements to protect the server / zone(s) at the BIND application level. Does that make sense? What am I missing / misunderstanding? the point is to make the system simple and robust. separating DNS servers may make DNS more robust and it may make DNS less robust. Bob describes access to different zones from different clients (internal, wi-fi, ...) configured on recursive server. There's no visible gain if Bob moves internal zones to another server. However there are still some questions to this https://lists.isc.org/pipermail/bind-users/2022-October/106764.html - where/how/why is TSIG used - how is the DNS configured now, don't internal recursive servers have access to the internet now? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Fighting for peace is like fucking for virginity... -- 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: Question About Internal Recursive Resolvers
People do the funniest things with DNS. It's a pretty good key-value store, especially for read-heavy workloads. Maybe you update counters for "what clients in this OT environment are posting telemetry to this web server"? DNS wouldn't be a good choice for that, but Redis is. But maybe you want to query for the info with the DNS; as a bonus, DNS can offload / cache reads. On Sat, 15 Oct 2022, Grant Taylor via bind-users wrote: [...] How does hosting the zone on an internal server provide any additional security? Or are you simply relying on other security mechanisms to prevent non-secure clients -- as Bob described them -- from accessing the server ~> zone? I feel like, by default -- as Bob described, any hosted zone is going to be accessible by any client that can query the server. DNS is federated, meaning that a server can be both a service and a client, which means in the use case given above that the Redis instances can be distributed close to where the counters are updated; the DNS will go out and collect those counters when you query them, no need to send a constant stream of telemetry to a central location. You probably don't want those counters accessible to every dog on the internet. Some thought is necessary in deploying DNS servers so that intended clients get access. (We don't usually expect DNS clients to issue hundreds of requests per second either, but it works; you just need to give it some thought.) I assume that people have been doing variations on this sort of thing since PDPs were as common as LSD in Berkely. The usual suspects arrive: TSIG, allowed addresses, firewall rules; site-to-site VPNs; that sort of thing. Turns out RPZ is useful as a WAF equivalent, limiting the Redis keys which can be queried as well as the types of allowed queries. Here is my contribution to ensuring employment for DNS subject matter experts: * https://github.com/m3047/rkvdns -- DNS proxy for Redis * https://github.com/m3047/rkvdns_examples -- examples -- Fred Morris, internet plumber -- 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: Question About Internal Recursive Resolvers
Hi Grant.
My understanding is this, which is almost identical to what I did in a
former life:
client ---recursive_query---> recursive_DNS_server
---non_recursive_query---> internal_auth/Internet
where:
client == laptop/phone/server running stub resolver code
recursive_DNS_server == what Bob is asking about, a recursive-only DNS
server
internal_auth == the other component, an authoritative-only DNS server
Separation of internal and external clients - preventing external ones from
accessing internal names - is easily achieved with a couple of views, such
as this:
view "external" {
match-clients { address_match_list }; # the set of all possible
addresses that external clients may be given.
match-destinations { address_match_list }; # the address(es) given to
external clients for their DNS service.
...
};
view "internal" {
# there is no `match clients`. Any client not already match by the
"external" view potentially has access to this view, if they target the
correct service address(es).
match-destinations { address_match_list }; # the address(es) given to
internal clients for their DNS service. Different from the one(s) given to
external clients.
attach-cache "external"; # internal clients have access to records that
have already been cached due to queries made by external clients.
...
};
Greg
On Sat, 15 Oct 2022 at 18:52, Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:
> On 10/15/22 10:34 AM, Matus UHLAR - fantomas wrote:
> > If you are an ISP/registry/DNS provider, it makes sense to separate
> > authoritative zones for your clients' domains, for all those cases your
> > client move their domains somewhere else without notifying you (hell,
> > they do that too often), or to be able to prepare moving domains to your
> > servers.
>
> #truth
>
> > forward zones - named sends recursive query to the primary servers
> > stub zones- named fetches NS records from primary servers and
> > uses them for resolution
> > static-stub zones - named forwards iterative (non-recursive) requests to
> > primary servers
> >
> > clients accessing any of these zones must have recursion allowed and
> > recursion must be enabled in BIND.
>
> Please clarify where recursion needs to be allowed; the BIND server
> clients are talking to and / or the back end server that BIND is talking
> to on the client's behalf.
>
> I'm not completely clear and I think it's better to ask than to assume
> incorrectly.
>
> > On 10/15/22 10:03 AM, Bob McDonald wrote:
> >> If a non-secure client (read the next sentence...) accesses the same
> >> recursive server as a regular client, it will have access to the
> >> internal zones by default.. Therefore we need to have some sort of
> >> access controls in place.
> > and THIS is exactly the reason you SHOULD put your internal zones on
> > your internal server.
>
> Sorry if I'm being particularly dense this morning, but I'm not
> following ~> understanding Bob's and Matus's statements like I want to.
>
> How does hosting the zone on an internal server provide any additional
> security? Or are you simply relying on other security mechanisms to
> prevent non-secure clients -- as Bob described them -- from accessing
> the server ~> zone?
>
> I feel like, by default -- as Bob described, any hosted zone is going to
> be accessible by any client that can query the server.
>
> With this in mind, I feel like the type of zone; primary / secondary /
> mirror / stub / static-stub / forward, makes little difference in and of
> itself. Rather, it would be dependent on global and / or per-zone
> allow-* statements to protect the server / zone(s) at the BIND
> application level.
>
> Does that make sense?
>
> What am I missing / misunderstanding?
>
> > that's why we are here.
>
> :-)
>
>
>
> --
> Grant. . . .
> unix || die
>
> --
> 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
>
--
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: Question About Internal Recursive Resolvers
OK, if a known client accesses DNS on the internal network, that client is pointed at a recursive resolver (e.g by DHCP). That resolver either provides access to the internal DNS zones (e.g. via stub zones) or sends the client query to the root servers on the internet. An unknown client (e.g. guest WiFi) will be given the same resolver address for its DNS server. At this point it would require ACLs to prevent that unknown client from accessing the internal DNS zones. All DNS traffic from that client would be sent to the internet. Another way to achieve that would be to have a separate set of DNS resolvers for unknown clients (resolver addresses handed out via DHCP). That's my current view of how to get things done in this case. What I'm discerning from the discussion so far is that this isn't strictly necessary. The internal DNS zones can/should reside on the recursive resolvers. The question of unknown client access to internal DNS zones is resolved (no pun intended...). RPZ COULD be implemented on ANY of the recursive DNS resolvers. The tsig key discussion is around its use as a method of allowing updates to internal DNS zones. Strictly hypothetical. Don't get hung up on it. Thank you all for the information. You've provided answers to my questions and have renewed my faith in geekdom. If anyone is still confused, I'd be glad to discuss this offline until we have a final solution. Then we can publish if necessary. Bob -- 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: Question About Internal Recursive Resolvers
On 10/15/22 1:51 PM, Greg Choules via bind-users wrote: Hi Grant. Hi Gred, I'm quickly replying to your message. I'll reply to Matus & Fred later when I have more time for a proper reply. My understanding is this, which is almost identical to what I did in a former life: client ---recursive_query---> recursive_DNS_server ---non_recursive_query---> internal_auth/Internet where: client == laptop/phone/server running stub resolver code recursive_DNS_server == what Bob is asking about, a recursive-only DNS server internal_auth == the other component, an authoritative-only DNS server ACK I that's the topology I had in my mental map. Separation of internal and external clients - preventing external ones from accessing internal names - is easily achieved with a couple of views, such as this: I /absolutely/ agree with you. However "views" is /non-default/. -- To reflect Bob's original message. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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
