Re: feature request for improving named-compilezone
We're using dynamic updates. Update files are generated mostly through scripts so you know exactly who did what and when. On February 11, 2024 6:31:38 PM GMT+01:00, Andrew Latham wrote: >If you are using a version control system like GIT then I would suggest you >have a zonefile.md next to the zone with any specific notes and maybe a >history/changelog. This may not answer your problem case but documentation >as markdown or even just a TXT next to the zone is handy. > >On Thu, Jan 18, 2024 at 11:17 AM Marco Davids (SIDN) via bind-users < >bind-users@lists.isc.org> wrote: > >> Hi, >> >> How hard would it be to let named-compilezone keep any remarks that are >> present in the source file? Because now it strips them and that is >> problematic. >> >> -- >> Marco >> -- >> 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 >> > > >-- >- Andrew "lathama" Latham - -- 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: I am provoked by ISC for the 10 years statement that ISC refuse to fulfill (Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?)
It's hilarious. Who says python3 is going to be a thing in 10y ... or 20 藍 On February 11, 2024 5:41:34 PM GMT+01:00, Tim Daneliuk via bind-users wrote: >On 2/11/24 02:07, Ole Aamot wrote: >> "This whole “we support everything for 10 years” is just a sales pitch, not >> a something that can be fulfilled." – Ondřej Surý — ISC >> > > >I realize that there was a whole kerfuffle here that I mercifully missed and >have absolutely no interest in. > >But it did "provoke" a question. Does anyone think not restarting *anything* >for 10 years >is a good idea? > >I realize there were all these fanbois back in the day that wanted to prove >*NIX could stay up longer and with greater stability than Windows. But best >practices >would suggest that you patch and restart monthly at a minimum and more often >for >zero-days and more immediate threats. I would include among this the OS itself >as well as key infrastructure services. > >Oh, and for the record, I think ISC does a very fine job ;) > >-- >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
Correct response to NS request in case of dual delegation when one delegation returns REFUSED
Hello, We are currently working with a product called Superna Eyeglass which can be used for DR purposes on Powerscale (Dell storages). Quick background: Powerscale leverages DNS to create redundant and load-balanced frontend access. Without going into many details, Powerscale replies to DNS requests on a service IP (SSIP) indicating which node of the cluster should be used for the incoming connection. To that end, it requires you to delegate one (or more) zones to that SSIP. Now Eyeglass (the DR product) recommends using "dual delegation" for failover purposes (there are two distinct clusters (active/passive) which are not necessarily in-sync at any given moment in time). What they tell you to do is: Create a service name with two delegations/NS records pointing to both storages' SSIPs, the one currently not active will return REFUSED. i.e. you have cluster IN NS storage1 cluster IN NS storage2 Now they have "readiness" checks where they try to determine if that dual delegation is set up correctly. However, Bind only seems to return one of those nameservers when asked for it. Example: 1) client asks Bind: what is NS for "cluster"? 2) Bind seems to issue requests to both "storage1" and "storage2" for "NS cluster", one of which always returns "REFUSED" 3) Answer of Bind to client does not contain the one that was "refused". Therefore that readiness check is not working. They claim this is normal and that they only support Windows DNS for that check. My conclusion is that Windows DNS is an abomination. And relying on an inherently faulty behavior leads straight to hell. Am I missing something? Is Bind behaving correctly? Thanks, Marki -- 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: Need Help with BIND9
A thing you probably missed is checking the log files. What do they contain when it "isn't working"? What is the actual problem anyway?___ 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: forwarding zone setup from a BIND slave (without recursion?)
On 4/14/2021 12:44 AM, Sebby, Brian A. via bind-users wrote: My situation is due to a security requirement. We have DNS servers at our site running BIND that allow recursion, but I’ve been requested to set up some additional DNS servers for another project that is expected to **only** access the data that we’re authoritative for. And of course …. there’s a chance that it might need to look up one or two external zones. Essentially, what I really need is a recursive whitelist that doesn’t tell BIND what clients are allowed to do recursive lookups, but to limit BIND to only allow recursive lookups on a very small list of allowed domains. I was trying to set up a forwarding zone to forward queries to our DNS servers that do allow recursion, but as I discovered (and as was discussed earlier in the thread), if recursion is not allowed, then forwarding is also not allowed. I had tried setting the “allow-recursion” field to “localhost” and setting up a forward zone to forward to 127.0.0.1, but that didn’t work either. Hello, So they do _not_ only look up internal/authoritative zones, but external ones as well. (It's always the exceptions that kill you.) I think we have previously established that there is not a good way to do whitelisting using Bind, see the thread "Authority and forwarding, but not recursion/iteration". If you can live with non-allowed zones returning SERVFAIL (instead of NXDOMAIN for example), then using a recursive service with a bogus global forwarder and static stubs pointing to the authoritative/non-recursive service might do the trick. You might also be able to leverage RPZ if there are no complex conditions associated to your rules (everyone will have the same white/blacklists). You configure passthrough for the allowed zones and deny the rest. Alternatively, there is dnsdist which, while being a load-balancer, could be considered the swiss army knife of DNS filtering. Finally, some firewalls like Fortigates provide a "DNS filter" that lets you define custom white and blacklists. Palo Altos currently are not able to whitelist AFAIK. Best regards, Marki ___ 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: forwarding zone setup from a BIND slave (without recursion?)
Hello, On 4/7/2021 10:35 AM, Matus UHLAR - fantomas wrote: On 06.04.21 22:47, RK K wrote: In this scenario, in-order for the secondary server to forward the DNS query to an external DNS server, is it required to enable the recursion in the global options on the secondary servers? yes. To elaborate a little bit on that... Indeed that is how it works, unfortunately. When you start using forwarders or stubs, recursion needs to be enabled because you're no longer looking for your own authoritative data only. What I've learned from this list is that you should split authoritative and recursive service. In other words, you need two types of servers: 1) A non-recursive one in the backend containing your authoritative zones only. This can be a hidden master setup, somewhat like what you are using now. 2) The one your users access has recursion enabled, and contains stubs to the authoritative service. Obviously, it can also contain stubs (or forwarders) to anywhere else. At the same time it is performing full recursive service unless you take authority for the root zone. May I ask what is the reasoning behind your current setup (pointing your users to the non-recursive service)? What would you like to achieve? What would you like to prevent? Bye, Marki ___ 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: Authority and forwarding, but not recursion/iteration
On 3/13/2021 12:11 AM, Tony Finch wrote: Marki wrote: But if you need granular filtering, that could become a lot of views... Yes, I think RPZ is really designed to be a ban hammer for dealing with abuse, rather than a general-purpose access control mechanism. If you need to get really fancy then you should look at dnsdist which can be programmed in Lua. Tony. Just posting this to give everyone my conclusions and how this turned out. Standard DNS server software (not only Bind) does not provide for easy whitelist filtering, only blacklists seem to be "en vogue". Like trusting nearly everyone, except, oh well, what did they teach in security class? Never mind, we're currently rolling out dnsdist. @Tony Your feedback has been very to the point, knowledgeable and fruitful. If you've got an Amazon wishlist (almost wrote whitelist lol) let me know :D ___ 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: Authority and forwarding, but not recursion/iteration
On 3/9/2021 10:21 PM, Tony Finch wrote: Marki wrote: I'm not sure about the flexibility of RPZ; it doesn't seem that I can have rules like "client 1.2.3.4 is allowed to look up example.com but client 1.2.3.5 is not". You can have multiple response-policy zones, which are matched in the order they are listed in the configuration. You could perhaps have a zone listed early that uses RPZ-CLIENT-IP triggers and a PASSTHRU policy for non-sandboxed clients, then have a zone containing QNAME triggers (with liberal use of wildcards) and PASSTHRU policy (again) for just the permitted internal names, and finally a catch-all zone (wildcard to match any qname) with an NXDOMAIN policy to deny external names for sandboxed clients. (You can equally well combine the first two into a single zone, depending on whether you want more single-purpose RPZs or fewer multi-purpose ones.) Probably the setup would be more straightforward if there was a view for sandboxed clients and one or more views for those that are not. Concerning the non-sandboxed (or less-sandboxed view), I still fail to see how RPZ would allow me to define conditionals like "Host 1.2.3.4 is allowed to resolve example.com" (and nothing else). AFAICS you can either trigger on the client ip and allow (or deny) all names, or trigger on the name to be resolved and allow (or deny) for all clients, but not a combination thereof. You could create a view that matches 1.2.3.4 and include an RPZ that allows to use example.com. But if you need granular filtering, that could become a lot of views... Marki ___ 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: Authority and forwarding, but not recursion/iteration
On 3/9/2021 6:03 PM, Tony Finch wrote:
Marki wrote:
I am seeking a combination of either a combined configuration on one, or a
config of several different DNS servers together to achieve the following:
* Some clients should be able to resolve authoritative local zones as well as
some forwarded zones.
* Other clients should be able to resolve all of that _plus_ be able to make
recursive queries to the internet (or use a global forwarder).
In my opinion, as a rule of thumb it's best to avoid per-zone forwarding
in BIND. (Microsoft DNS really encourages it, but be wary because it
doesn't mean the same thing there!)
It's helpful if you have a clear distinction between authoritative-only
nameservers on the one hand, and on the other hand recursive nameservers
that provide service to stub resolvers. It sounds like you want to provide
an internal-only sandbox to some recursive clients, but it's best to think
of it as a restricted recursive service, not a special kind of
authoritative service. Especially because stub clients expect to receive
fully-resolved answers, so if you point them at an authoritative-only
server you'll get obscure problems in cases like cross-zone CNAMEs.
[ The distinction is that auth-only servers expect to receive only RD=0
(recursion not desired) queries from recursive DNS servers and reply with
RA=0 (recursion not available), whereas recursive servers expect to
receive RD=1 (recursion desired) from stub resolvers and reply with RA=1
(recursion available). ]
When you need to tie authoritative zones together, use delegation records
pointing at your authoritative-only name servers. Then your recursive
servers can just follow delegations in the usual way without special
configuration. (If you are doing split DNS, this can get fiddly, which is
a good reason for keeping your split DNS as simple as possible.)
[ You can configure recursive servers to have their own authoritative
copies of your zones - it can be faster and more resilient - but you can
think of it as a shortcut or optimization, on top of the fundamental
auth/rec split. ]
Your question is now, how to provide a restricted recursive service?
The top-level setup is to have multiple views with match-clients clauses
to determine whether a client is in the sandbox view or not. Then the
question is how to configure the sandbox view.
I don't know of any particularly good ways in BIND :-) When you want
default-allow with a block list, then RPZ is ideal, but you are asking for
default-deny with an allow list.
You might be able to configure a dummy default forwarder, and tell BIND it
is bogus, something like this (which I have not tested!):
forwarders A.B.C.D;
server A.B.C.D {
bogus yes;
};
then have per-zone static-stub configuration for allowed zones, pointing
at working authoritative servers.
Alternatively it might be easier to make other software such as dnsdist do
what you want. Or, consider implementing the sandbox with firewalls at the
network level. (But are you sandboxing DNS because of worries about
data exfiltration?)
Tony.
You're right about the sandbox and exfiltration (C2 etc.). What can't go
out, can't hurt. We don't need public DNS resolution on most client
systems since all Internet access is filtered through an explicit proxy.
Thus, why not just turn it off instead of trying to protect it using
expensive appliances and whatnot.
Concerning static-stub: Using a (bogus) forwarder together with "forward
first" (default) seems to work (Note: using "forward only" gives
SERVFAIL). All outside requests get a SERVFAIL even with "forward first"
but that's an esthetic problem. Another approach might be to disable
forwarders altogether (make it fully recursive) and then use RPZ. This
would however mean that stubs/forwarded zones would need to be
whitelisted, which means one or two more lines of configuration (and a
nice reply from the server).
As you mentioned there would be other view(s) for clients that actually
need public DNS. Correctly firewalling means blocking everything unless
it is allowed (whitelisting principle). I'm not sure about the
flexibility of RPZ; it doesn't seem that I can have rules like "client
1.2.3.4 is allowed to look up example.com but client 1.2.3.5 is not".
Marki
___
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: Authority and forwarding, but not recursion/iteration
I tried that. When you configure no global forwarders it's going to recurse because recursion needs to be enabled for the individual forwarded zones to work. You'd have to specify a fake global forwarder which looks like a hack. On March 7, 2021 10:09:49 AM GMT+01:00, Crist Clark wrote: >Two views. The view that does not do internet DNS claims authority for >the >root and does not global forward. The entire DNS is just the zones >defined >in the view, which can be authoritative or forwarded. The other view >has >the global forward-only to upstream resolvers. > >On Sat, Mar 6, 2021 at 3:34 PM Marki wrote: > >> I'm not sure: >> >> > Some clients should be able to resolve authoritative local zones as >well >> as some forwarded zones. >> >> And only that. "forward only;" doesn't cut it, in case you mean the >global >> option. That would still forward everything else somewhere else. The >> requirement is to _only_ resolve local stuff for some clients. >> On 3/6/2021 8:48 PM, Crist Clark wrote: >> >> forward only; >> >> On Fri, Mar 5, 2021 at 5:19 PM Marki >wrote: >> >>> Hello, >>> >>> I am seeking a combination of either a combined configuration on >one, or >>> a config of several different DNS servers together to achieve the >>> following: >>> * Some clients should be able to resolve authoritative local zones >as >>> well as some forwarded zones. >>> * Other clients should be able to resolve all of that _plus_ be able >to >>> make recursive queries to the internet (or use a global forwarder). >>> All hosts use the same DNS servers, this should not be made about >the >>> clients but rather be configurable on the server. >>> >>> Now the problems are the following: >>> * Since I need forwarders I can't turn off recursion. >>> * Since I can't turn off recursion I can't prevent it to go and try >to >>> resolve from root DNS. >>> >>> How do I do one (local authority and forwarders) but not the other >>> (iterative lookups on the Internet)? >>> >>> Thanks, >>> >>> Marki >>> >>> ___ >>> 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: Authority and forwarding, but not recursion/iteration
I'm not sure: > Some clients should be able to resolve authoritative local zones as well as some forwarded zones. And only that. "forward only;" doesn't cut it, in case you mean the global option. That would still forward everything else somewhere else. The requirement is to _only_ resolve local stuff for some clients. On 3/6/2021 8:48 PM, Crist Clark wrote: forward only; On Fri, Mar 5, 2021 at 5:19 PM Marki <mailto:bind-us...@lists.roth.lu>> wrote: Hello, I am seeking a combination of either a combined configuration on one, or a config of several different DNS servers together to achieve the following: * Some clients should be able to resolve authoritative local zones as well as some forwarded zones. * Other clients should be able to resolve all of that _plus_ be able to make recursive queries to the internet (or use a global forwarder). All hosts use the same DNS servers, this should not be made about the clients but rather be configurable on the server. Now the problems are the following: * Since I need forwarders I can't turn off recursion. * Since I can't turn off recursion I can't prevent it to go and try to resolve from root DNS. How do I do one (local authority and forwarders) but not the other (iterative lookups on the Internet)? Thanks, Marki ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users <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/ <https://www.isc.org/contact/> for more information. bind-users mailing list bind-users@lists.isc.org <mailto:bind-users@lists.isc.org> https://lists.isc.org/mailman/listinfo/bind-users <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
Authority and forwarding, but not recursion/iteration
Hello, I am seeking a combination of either a combined configuration on one, or a config of several different DNS servers together to achieve the following: * Some clients should be able to resolve authoritative local zones as well as some forwarded zones. * Other clients should be able to resolve all of that _plus_ be able to make recursive queries to the internet (or use a global forwarder). All hosts use the same DNS servers, this should not be made about the clients but rather be configurable on the server. Now the problems are the following: * Since I need forwarders I can't turn off recursion. * Since I can't turn off recursion I can't prevent it to go and try to resolve from root DNS. How do I do one (local authority and forwarders) but not the other (iterative lookups on the Internet)? Thanks, Marki ___ 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
