Re: [DNG] Clarification please
Quoting Simon Walter (si...@gikaku.com): > Thanks for the bits of wisdom. > > Do you know any papers/articles/sites that discuss and explain this more? As Steve says, the crusty enfant-terrible of software, Prof. D.J. Bernstein, had some useful things to say about this, so, sure, start there. I swear I've come across other pieces elaborating on why separating recursive from authoritative nameservice is a recommended precaution, but I failed to bookmark/save those, sorry. -- Cheers, "2020 is pulling out more plot devices than Rick Moen a TV series on the brink of being canceled." r...@linuxmafia.com (Seen on Reddit, Oct. 2, 2020.) McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
Quoting Dimitris via Dng (dng@lists.dyne.org): > depends on the role... > bind as a local caching dns for PCs might be overhead. some people > would want something minimal/light for recursion, not the whole bind > "beast"... > unbound is very light in that perspective, and also found dqcache > (packaged) a pretty nice alternative. For a local recursive nameserver[1], I would urge consideration of PowerDNS Recursor, Deadwood, Knot Resolver, or (patched) dnscache, all of which are small, fast, and have reasonable security prospects and history. I'll not be critical of people like Mason choosing to still run BIND9 in that role -- if only because I still do that myself in places out of inertia -- but for that application consider it overfeatured, slow, ponderous, and a bit security-risky. [1] Calling such software 'caching' doesn't really clarify what the core functionality is, since every subvariety of DNS nameserver software except for authoritative-only daemons includes caching. -- Cheers, "2020 is pulling out more plot devices than Rick Moen a TV series on the brink of being canceled." r...@linuxmafia.com (Seen on Reddit, Oct. 2, 2020.) McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
Quoting Olaf Meeuwissen (paddy-h...@member.fsf.org):
> I have a dnsmasq instance that does *authorative* resolution for an
> internal domain.
Well, pseudo-authoritative.
> Anything not in that domain is forwarded to the corporate DNS servers.
> Works fine for me so I think dnsmasq can be more than _just_ a
> forwarder (which is all I wanted to point out).
Yes, dnsmasq does do _stub_ (local-only) authoritative service, as
is mentioned in my DNS software bestiary's entry.
http://linuxmafia.com/faq/Network_Other/dns-servers.html#dnsmasq
When I said '_just_ a forwarder', I meant that it doesn't do (real)
authoritative service or recursive resolving. It cannot even
independently resolve RRs without processing the recursive flag
('iteratively'), i.e., it cannot resolve anything outside its
local-private-domain zonefile except by forwarding the query to a
separate recusive daemon elsewhere.
Naturally, the ability to have a stub zone is also useful.
My point is that dnsmasq is in _no way_ an adequate substitute for
having a locally based recursive nameserver. However, it can be a nice
adjunct to one.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
On 11/3/20 8:44 PM, Olaf Meeuwissen via Dng wrote: Hi Rick, Rick Moen writes: Quoting g4sra via Dng (dng@lists.dyne.org): Can anybody suggest a suitable authoritative/recursive DNSSEC supporting name server for SOHO domain use on embedded systems. What I am looking for is something like dnsmasq. dnsmasq, it should be noted, is _just_ a forwarder. It forwards outbound queries to one or more IP-identified recursive servers you specify. Those recursive servers do the actual work. I have a dnsmasq instance that does *authorative* resolution for an internal domain. Anything not in that domain is forwarded to the corporate DNS servers. Works fine for me so I think dnsmasq can be more than _just_ a forwarder (which is all I wanted to point out). Personally, I really like OPNsense. It uses Unbound these days. I don't use it for everything. However, for most of my clients needs, it handles their DNS needs very well. Specifically "overrides" provide a local authority. If they need a true authoritative server, I am familiar with BIND. So BIND it is. OPNsense is a BSD. So the PID "bug", I guess, is not relevant. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
On 11/3/20 4:36 PM, Steve Litt wrote: On Sat, 31 Oct 2020 09:08:50 +0900 Simon Walter wrote: On 10/30/20 7:29 AM, Rick Moen wrote: ... FWIW, I am no longer comfortable with the idea of a combined authoritative/recursive server on a publicly exposed static IP. That has been deprecated for long decades as bad security, particularly because it increases the risk of cache poisoning of the recursive server. IMO, a LAN connected to public networks, even a small one, ought to have the authoritative service on a separate, public-facing host, and the recursive service on a protected, internal-network machine that is as shielded from public networks as possible. Thanks for the bits of wisdom. Do you know any papers/articles/sites that discuss and explain this more? I have not updated my IT knowledge in years and am a bit thirsty. When it comes to separation of authoritative and resolver parts of DNS, the documentation from the old djbdns makes it very clear, and is an excellent starting point. I'll have to check that out. Thanks! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
*sighs* PIDfiles are not the right way to communicate with daemons. I stopped there. Bernard (Beer) Rosset https://rosset.net/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
On Tue, 3 Nov 2020 14:55:40 -0500 Mason Loring Bliss wrote: > On Tue, Nov 03, 2020 at 12:24:35PM +0900, Simon Walter wrote: > But yes. I'd found an issue where Unbound wasn't obeying service > management in Devuan, and then that spiraled out into it being > CVE-worthy. But for our purposes, unbound changes ownership if its > PIDfile, PIDfiles are not the right way to communicate with daemons. So all that need be done is to install daemontools-encore, runit or s6, and start Unbound from daemontools-encore, runit, or s6. Once you do that once, you can start shifting more and more daemons to the superior method of exec-based supervision rather than PIDfiles. SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
On 11/3/20 9:55 PM, Mason Loring Bliss wrote: For my part, I've stopped using unbound at all. I've been using BIND for many years, and it works just fine in this role too. depends on the role... bind as a local caching dns for PCs might be overhead. some people would want something minimal/light for recursion, not the whole bind "beast"... unbound is very light in that perspective, and also found dqcache (packaged) a pretty nice alternative. OpenPGP_signature Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
On Tue, Nov 03, 2020 at 12:24:35PM +0900, Simon Walter wrote: > > Could it be related to this? > > > > https://github.com/NLnetLabs/unbound/issues/303 > > I don't think so - unless you are paranoid about anything that RH employees > contribute to. Hah, if you're paranoid about projects RH employees contribute to, then you're all in trouble. :P But yes. I'd found an issue where Unbound wasn't obeying service management in Devuan, and then that spiraled out into it being CVE-worthy. But for our purposes, unbound changes ownership if its PIDfile, and this means that our start-stop-daemon refuses to operate on it - if the process can be subverted, it can write any PID in there, for instance, and cause us to kill an arbitrary daemon. If the process can make the PIDfile into a symlink, it can maybe cause us to overwrite arbitrary files, and so forth. It's not yet wholly clear how upstream will fix it. Depending on that, we might end up needing to fork it - Debian will be unaffected since they don't insist on sysvinit compatibility any more. For my part, I've stopped using unbound at all. I've been using BIND for many years, and it works just fine in this role too. -- Mason Loring Bliss ma...@blisses.orghttp://blisses.org/ For more enjoyment and greater efficiency, consumption is being standardized. signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
On Tue, 3 Nov 2020 02:50:37 -0500 Steve Litt wrote: > On Thu, 29 Oct 2020 16:53:43 + > g4sra via Dng wrote: > > > On 29/10/2020 13:44, Michael Neuffer wrote: > > > On 10/29/20 2:27 PM, d...@d404.nl wrote: > > --snip-- > > >> To ease the maintenance of those servers i intend to migrate them > > >> to docker containers. I wonder people on this list have > > >> experience on this subject? > > > > > > > > > You might want to take a look at this project: > > > > > > https://github.com/mailserver2/mailserver > > > > Please correct me if I am mistaken, I thought 'unbound' was tied to > > 'systemd creep' nowadays and have been avoiding it for that reason > > alone. I want to avoid creating a dependency on something I don't > > already have only to need to purge it next year ... > > I'm as anti-systemd as the next guy, but I use unbound on a constant, > everyday basis. Let me explain... > > Here are two lines from my unbound.conf: > > == > # Guard against future default changes: no systemd ever! > use-systemd: no > == > > As far as I can see, if I had set use-systemd to "yes", unbound would > have reported its success in starting in the systemd approved way, and > would not have backgrounded itself. So if you use sysvinit, you just > say use-systemd: no and whatever option that makes it background > itself. If you use runit or s6, say systemd: no and whatever makes it > NOT background itself. > > So basically, there's a little, probably completely separate part of > unbound with minimal linkage, that if told to, will send out a > systemd-approved "I am functional now" message. But as far as I know, > unbound uses no systemd facilities and would only require or suggest > systemd as a result of a systemd-infected distro configuring unbound > that way. Not sure if it is relevant or not, but during a dist-upgrade to ceres today, got the following notification: unbound (1.11.0-1) unstable; urgency=medium The default Debian config file shipped in the unbound package has changed from using the "include:" directive to using the "include-toplevel:" directive in order to include the config file fragments in /etc/unbound/unbound.conf.d/*.conf into the unbound configuration. The "include-toplevel:" directive has been newly introduced in unbound 1.11.0 and it requires that any included config file fragment begin its own clause (e.g., "server:"). The existing "include:" directive that was used in previous Debian releases of the unbound package only performed textual inclusion, and it was possible to construct a set of config file fragments that depended on the presence or ordering of specific config file fragments in order to parse correctly. For instance, a config file fragment could have specified an option that can only appear in the "server:" clause, and rely on a previously included config file fragment to begin that clause. This behavior is no longer allowed by the use of the "include-toplevel:" directive because it is not robust against config file fragments being added, removed, or reordered. If you are upgrading the unbound package and you have installed any config file fragments into /etc/unbound/unbound.conf.d/ you should check that each config file fragment begins its own clause (e.g., "server:") and update each config file fragment as necessary to be compatible with the behavior of the "include-toplevel:" directive. If needed, the previous behavior can be restored by changing the following line in /etc/unbound/unbound.conf: include-toplevel: "/etc/unbound/unbound.conf.d/*.conf" to its previous setting: include: "/etc/unbound/unbound.conf.d/*.conf" -- Robert Edmonds Sun, 09 Aug 2020 19:39:01 -0400 Best fraser ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
Hi Rick, Rick Moen writes: > Quoting g4sra via Dng (dng@lists.dyne.org): > >> Can anybody suggest a suitable authoritative/recursive DNSSEC >> supporting name server for SOHO domain use on embedded systems. What >> I am looking for is something like dnsmasq. > > dnsmasq, it should be noted, is _just_ a forwarder. It forwards > outbound queries to one or more IP-identified recursive servers you > specify. Those recursive servers do the actual work. I have a dnsmasq instance that does *authorative* resolution for an internal domain. Anything not in that domain is forwarded to the corporate DNS servers. Works fine for me so I think dnsmasq can be more than _just_ a forwarder (which is all I wanted to point out). Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
On Thu, 29 Oct 2020 16:53:43 + g4sra via Dng wrote: > On 29/10/2020 13:44, Michael Neuffer wrote: > > On 10/29/20 2:27 PM, d...@d404.nl wrote: > --snip-- > >> To ease the maintenance of those servers i intend to migrate them > >> to docker containers. I wonder people on this list have experience > >> on this subject? > > > > > > You might want to take a look at this project: > > > > https://github.com/mailserver2/mailserver > > Please correct me if I am mistaken, I thought 'unbound' was tied to > 'systemd creep' nowadays and have been avoiding it for that reason > alone. I want to avoid creating a dependency on something I don't > already have only to need to purge it next year ... I'm as anti-systemd as the next guy, but I use unbound on a constant, everyday basis. Let me explain... Here are two lines from my unbound.conf: == # Guard against future default changes: no systemd ever! use-systemd: no == As far as I can see, if I had set use-systemd to "yes", unbound would have reported its success in starting in the systemd approved way, and would not have backgrounded itself. So if you use sysvinit, you just say use-systemd: no and whatever option that makes it background itself. If you use runit or s6, say systemd: no and whatever makes it NOT background itself. So basically, there's a little, probably completely separate part of unbound with minimal linkage, that if told to, will send out a systemd-approved "I am functional now" message. But as far as I know, unbound uses no systemd facilities and would only require or suggest systemd as a result of a systemd-infected distro configuring unbound that way. I have a lot of confidence in unbound. SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
On Sat, 31 Oct 2020 13:18:56 +1100 wirelessduck--- via Dng wrote: > > On 31 Oct 2020, at 10:52, Simon Walter wrote: > > > > On 10/30/20 3:19 AM, Bernard Rosset via Dng wrote: > >>> That said, I've stopped using unbound and I'm using straight BIND > >>> as my local resolver lately. It's pleasant. > >> From what we discovered about unbound during one of the meetings, > >> I clearly do not trust that technology. > > > > What meetings? Is it possible to divulge some more info WRT what > > you discovered? I am curious. > > Could it be related to this? > > https://github.com/NLnetLabs/unbound/issues/303 If that's all it is, it applies only to sysvinit. One can install runit, supervise runit as a case-by-case supervisor from sysvinit's /etc/inittab, and start and stop unbound from runit. I was doing this ten years ago with djbdns. There's no shame in having some of your daemons started by sysvinit, and others started by daemontools, daemontools-encore, runit, or s6. SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
On Sat, 31 Oct 2020 09:08:50 +0900 Simon Walter wrote: > On 10/30/20 7:29 AM, Rick Moen wrote: > ... > > FWIW, I am no longer comfortable with the idea of a combined > > authoritative/recursive server on a publicly exposed static IP. > > That has been deprecated for long decades as bad security, > > particularly because it increases the risk of cache poisoning of > > the recursive server. IMO, a LAN connected to public networks, > > even a small one, ought to have the authoritative service on a > > separate, public-facing host, and the recursive service on a > > protected, internal-network machine that is as shielded from public > > networks as possible. > > Thanks for the bits of wisdom. > > Do you know any papers/articles/sites that discuss and explain this > more? > > I have not updated my IT knowledge in years and am a bit thirsty. When it comes to separation of authoritative and resolver parts of DNS, the documentation from the old djbdns makes it very clear, and is an excellent starting point. SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
On 10/31/20 11:18 AM, wirelessduck--- via Dng wrote: On 31 Oct 2020, at 10:52, Simon Walter wrote: On 10/30/20 3:19 AM, Bernard Rosset via Dng wrote: That said, I've stopped using unbound and I'm using straight BIND as my local resolver lately. It's pleasant. From what we discovered about unbound during one of the meetings, I clearly do not trust that technology. What meetings? Is it possible to divulge some more info WRT what you discovered? I am curious. Could it be related to this? https://github.com/NLnetLabs/unbound/issues/303 I don't think so - unless you are paranoid about anything that RH employees contribute to. IMHO, that is a very civil and sane discussion, ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
Simon Walter wrote: > On 10/30/20 3:19 AM, Bernard Rosset via Dng wrote: >>> That said, I've stopped using unbound and I'm using straight BIND as my >>> local resolver lately. It's pleasant. >> >> From what we discovered about unbound during one of the meetings, I >> clearly do not trust that technology. > > What meetings? Is it possible to divulge some more info WRT what you > discovered? I am curious. curious here too, unbound has always been considered somewhat secure. there's also an recent independent security audit (link from unbound site), so this would be interesting to know, please share.. :) using bind mainly as authoritative in servers, although it seems really heavy and tbh don't like the fact that bind's almost a monopoly... also heard nice things about knot - will probably give it a try sometime soon... anyway, using almost exclusively unbound in pcs, as local caching dns.. seems to me lighter/easier to configure than dnsmasq. and iirc, most linux distros have moved to unbound as well.. 2c. d. signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
> On 31 Oct 2020, at 10:52, Simon Walter wrote: > > On 10/30/20 3:19 AM, Bernard Rosset via Dng wrote: >>> That said, I've stopped using unbound and I'm using straight BIND as my >>> local resolver lately. It's pleasant. >> From what we discovered about unbound during one of the meetings, I clearly >> do not trust that technology. > > What meetings? Is it possible to divulge some more info WRT what you > discovered? I am curious. Could it be related to this? https://github.com/NLnetLabs/unbound/issues/303___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
On 10/30/20 7:29 AM, Rick Moen wrote: ... FWIW, I am no longer comfortable with the idea of a combined authoritative/recursive server on a publicly exposed static IP. That has been deprecated for long decades as bad security, particularly because it increases the risk of cache poisoning of the recursive server. IMO, a LAN connected to public networks, even a small one, ought to have the authoritative service on a separate, public-facing host, and the recursive service on a protected, internal-network machine that is as shielded from public networks as possible. Thanks for the bits of wisdom. Do you know any papers/articles/sites that discuss and explain this more? I have not updated my IT knowledge in years and am a bit thirsty. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
On 10/30/20 3:19 AM, Bernard Rosset via Dng wrote: That said, I've stopped using unbound and I'm using straight BIND as my local resolver lately. It's pleasant. From what we discovered about unbound during one of the meetings, I clearly do not trust that technology. What meetings? Is it possible to divulge some more info WRT what you discovered? I am curious. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
my vote is for pdns-recursor. i’ve been using it for all sorts of different types of networks since version 1.n days. it can handle thousands of queries per second. it’s the first thing i install on any new system. coupled with dns-dist, it can handle recursive dns-over-https queries as well. Sent from my iPhone > On Oct 30, 2020, at 1:23 PM, Michael Neuffer wrote: > > > >> On 10/29/20 5:53 PM, g4sra via Dng wrote: >>> On 29/10/2020 13:44, Michael Neuffer wrote: >>> On 10/29/20 2:27 PM, d...@d404.nl wrote: >> --snip-- To ease the maintenance of those servers i intend to migrate them to docker containers. I wonder people on this list have experience on this subject? >>> >>> >>> You might want to take a look at this project: >>> >>> https://github.com/mailserver2/mailserver >> Please correct me if I am mistaken, I thought 'unbound' was tied to 'systemd >> creep' nowadays and have been avoiding it for that reason alone. >> I want to avoid creating a dependency on something I don't already have only >> to need to purge it next year ... > > If you can provide them with a better option, PLEASE go ahead and help out. > My impression of the people working on this was that they are not exactly > fans of systemd either. > > Cheers > Mike > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
On 10/29/20 5:53 PM, g4sra via Dng wrote: On 29/10/2020 13:44, Michael Neuffer wrote: On 10/29/20 2:27 PM, d...@d404.nl wrote: --snip-- To ease the maintenance of those servers i intend to migrate them to docker containers. I wonder people on this list have experience on this subject? You might want to take a look at this project: https://github.com/mailserver2/mailserver Please correct me if I am mistaken, I thought 'unbound' was tied to 'systemd creep' nowadays and have been avoiding it for that reason alone. I want to avoid creating a dependency on something I don't already have only to need to purge it next year ... If you can provide them with a better option, PLEASE go ahead and help out. My impression of the people working on this was that they are not exactly fans of systemd either. Cheers Mike ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
Quoting g4sra via Dng (dng@lists.dyne.org): > Can anybody suggest a suitable authoritative/recursive DNSSEC > supporting name server for SOHO domain use on embedded systems. What > I am looking for is something like dnsmasq. dnsmasq, it should be noted, is _just_ a forwarder. It forwards outbound queries to one or more IP-identified recursive servers you specify. Those recursive servers do the actual work. Respectable recursive(-only) nameserver packages (that are open source): o Unbound o PowerDNS-recursor o dnscache (from the djbdns suite), if patched to modern standards o Deadwood o Knot Resolver o Bundy recursive portion (but it's probably scary betaware) Respectable authoritative(-only) nameserver packages (that are open source): o NSD o PowerDNS Authoritative Server o MaraDNS authoritative portion o rbldnsd o YADIFA o MyDNS-NG (which also does forwarding of out-of-bailiwick queries) o ldapdns o Knot DNS o gndsd o dnsjava o tinydns (from the djbdns suite), if patched to modern standards o Bundy authoritative portion (but it's probably scary betaware) (Something that becomes apparent as one studies this field is that writing an authoritative daemon is relatively easy and many folks have done it. Writing a recursive daemon without messing up is difficult, so there are far fewer successful examples.) I maintain a bestiary of all known DNS software for Linux, here: http://linuxmafia.com/faq/Network_Other/dns-servers.html The above list is extracted from it. The page is still missing one peculiar^W innovative package, called Ironsides. Coverage is coming, Real Soon Now. I _hope_ the page is reasonably clear and complete about DNSSEC support, but: Errare humanum est, sed perseverare autem diabolicum. FWIW, I am no longer comfortable with the idea of a combined authoritative/recursive server on a publicly exposed static IP. That has been deprecated for long decades as bad security, particularly because it increases the risk of cache poisoning of the recursive server. IMO, a LAN connected to public networks, even a small one, ought to have the authoritative service on a separate, public-facing host, and the recursive service on a protected, internal-network machine that is as shielded from public networks as possible. I have personal experience with: BIND9 (and predecessors), NSD, Unbound, PowerDNS Recursor, PowerDNS Authoritative Server, dnscache, tinydns. I can enthusiastically recommend NSD and PowerDNS Server. Before a recent troubling thing with Unbound where the developers made a dumb decision to accomodate containerising, I was a huge Unbound cheerleader and might be again. Necessary disclaimer: I'm personal friends with Deadwood/MaraDNS author Sam Trenholme (but have yet to substantially deploy his software). As an administrator whose experience with BIND goes all the way back to BIND4 days, I know well that it's the path of least resistance to just deploy a do-it-all nameserver package like BIND9, but that's been known to be a bad idea for a long time, and it's past time to stop doing that. -- Cheers,"Rand Paul being patient zero for a Senate Rick Moen viral outbreak is a sign of a writers' room r...@linuxmafia.comdropping too much acid, late in the season." McQ! (4x80)-- @owillis (Oliver Willis) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
On 29/10/2020 18:19, Bernard Rosset via Dng wrote: >> That said, I've stopped using unbound and I'm using straight BIND as my >> local resolver lately. It's pleasant. > > From what we discovered about unbound during one of the meetings, I clearly > do not trust that technology. Too bad: it was on my to-test list. > > However, unbound is recursive-only IIRC. > > Since I am most interested in authoritative NS technology, I have yet to test > knot, of which I read good stuff. > > BIND is ol' do-it-all grand-daddy. A bit messy & overcomplicated to properly > set up & manage to my taste. Used it for ages, I like what I am used to, and after battling with Micro$oft's offering but it is not appropriate for my current project. Can anybody suggest a suitable authoritative/recursive DNSSEC supporting name server for SOHO domain use on embedded systems. What I am looking for is something like dnsmasq. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
That said, I've stopped using unbound and I'm using straight BIND as my local resolver lately. It's pleasant. From what we discovered about unbound during one of the meetings, I clearly do not trust that technology. Too bad: it was on my to-test list. However, unbound is recursive-only IIRC. Since I am most interested in authoritative NS technology, I have yet to test knot, of which I read good stuff. BIND is ol' do-it-all grand-daddy. A bit messy & overcomplicated to properly set up & manage to my taste. Bernard (Beer) Rosset https://rosset.net/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
On Thu, Oct 29, 2020 at 04:53:43PM +, g4sra via Dng wrote: > Please correct me if I am mistaken, I thought 'unbound' was tied to > 'systemd creep' nowadays and have been avoiding it for that reason alone. No, that's systemd-resolved. Unbound is unrelated. That said, I've stopped using unbound and I'm using straight BIND as my local resolver lately. It's pleasant. -- Mason Loring Bliss (( If I have not seen as far as others, it is because ma...@blisses.org )) giants were standing on my shoulders. - Hal Abelson signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
You're wrong, unbound worked and still works fine without systemd. Στις 29 Οκτωβρίου 2020 6:53:43 μ.μ. EET, ο/η g4sra via Dng έγραψε: >On 29/10/2020 13:44, Michael Neuffer wrote: >> On 10/29/20 2:27 PM, d...@d404.nl wrote: >--snip-- >>> To ease the maintenance of those servers i intend to migrate them to >>> docker containers. I wonder people on this list have experience on >this >>> subject? >> >> >> You might want to take a look at this project: >> >> https://github.com/mailserver2/mailserver > >Please correct me if I am mistaken, I thought 'unbound' was tied to >'systemd creep' nowadays and have been avoiding it for that reason >alone. >I want to avoid creating a dependency on something I don't already have >only to need to purge it next year ... > >___ >Dng mailing list >Dng@lists.dyne.org >https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Clarification please
On 29/10/2020 13:44, Michael Neuffer wrote: > On 10/29/20 2:27 PM, d...@d404.nl wrote: --snip-- >> To ease the maintenance of those servers i intend to migrate them to >> docker containers. I wonder people on this list have experience on this >> subject? > > > You might want to take a look at this project: > > https://github.com/mailserver2/mailserver Please correct me if I am mistaken, I thought 'unbound' was tied to 'systemd creep' nowadays and have been avoiding it for that reason alone. I want to avoid creating a dependency on something I don't already have only to need to purge it next year ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
