Re: bind -> unbound/nsd, Re: bind -> unbound/nsd
On Aug 22, 4:02am, r...@marples.name (Roy Marples) wrote: -- Subject: Re: bind -> unbound/nsd, Re: bind -> unbound/nsd | OK, I'll bite. | | Please describe how nsd has a "tighter integration" or (i assume | better?) "out of the box usability" | when in -base vs pkgsrc. When I wrote this I had 2 things in mind: - making it work with blacklistd like bind does - having easier configuration for DDNS (which I use). christos
Re: bind -> unbound/nsd, Re: bind -> unbound/nsd
| On Aug 22, 4:02am, r...@marples.name (Roy Marples) wrote: | -- Subject: Re: bind -> unbound/nsd, Re: bind -> unbound/nsd | | | Please describe how nsd has a "tighter integration" or (i assume | | better?) "out of the box usability" when in -base vs pkgsrc. Aside from what Christos said, anything in base can be installed from a (downloaded and burned) CD/DVD and work without any kind of network connection. In this context, that's particularly relevant if you're setting up a DNS zone signing system - one of those wants to be 100% isolated from the Internet (from day 1) (unless you have one of the fancy, costly, hadware, signing boxes) so that the safety of the key used is ensured (particularly relevant if you're running one of the upper level domains.) Of course, it is possible to get everything needed, and burn it on extra CDs (or USB sticks) and install it that way - but that's not nearly as tightly integrated (nor nearly as well tested.) Of course, it isn't just DNS servers & tools for which this is relevant, NTP, HTTP, ssh (probably more) servers in base also make things easier, and more likely to work, if included in base - and allow systems to work in environments where there is no internet connectivity (either by design, of just happenstance) - and of course, lack of intenet, does not mean lack of any networking, so all of these servers are still useful in some cases. kre
Re: bind -> unbound/nsd
chris...@zoulas.com (Christos Zoulas) writes: > The recent change of ISC/bind licensing from BSD to MPL for the > next release has provided us with an opportunity to re-evaluate > the preferred daemon status for NetBSD and DNS resolution. Board/Core > have decided not to import the next version of bind, and instead > import the current version of unbound/nsd. > > If you feel that this creates problems for you, let us know. > Also you should be able to use newer versions of bind from pkgsrc. > We are not planning to de-support or remove bind for NetBSD-8. I don't see any real problems, but I think there should have been public discussion rather than announcing a decision. signature.asc Description: PGP signature
Re: bind -> unbound/nsd
In article , Greg Troxel wrote: > >I don't see any real problems, but I think there should have been public >discussion rather than announcing a decision. We can have it now... christos
Re: bind -> unbound/nsd
On Thu, 18 Aug 2016, Christos Zoulas wrote: > The recent change of ISC/bind licensing from BSD to MPL for the next > release has provided us with an opportunity to re-evaluate the preferred > daemon status for NetBSD and DNS resolution. Wouldn't the license change result in some kind of status change in the main NetBSD CVS code repo for bind? I thought there was some kind of penalty box for not having a BSD license, anyhow. > If you feel that this creates problems for you, let us know. Also you > should be able to use newer versions of bind from pkgsrc. I have used Bind since the 1990s. I worked as a DNS admin for a (very) large corporation in the mid-2k-naughts's. We used bind in that environment, too. So, I have a lot of administration experience with Bind (so my minor critiques are coming from many years of exposure). That said, I'm not a fan of bind. I have a lot of respect for ISC and the folks who've maintained Bind over the years. However, I see it in a similar light as Sendmail. I could care less how "old" something is. That has about zero bearing on it's quality. However, if there *are* parts of UNIX history that aren't pretty. Sendmail and Bind both have had way-too-many security issues. It got so bad with Sendmail that folks finally wrote it off (thank $deity). Sendmail and Bind both have ridiculously over-complicated configuration formats due to their scope creep and inferior initial designs vis-a-vis later competing projects who were able to learn from their missteps. I'm not trying to be overly critical. Folks got a lot of milage out of Bind and Sendmail and a good sysadmin can set them up relatively safely. I know, because I'm in that category. However, it's just WAY more pain than is necessary when much more Unixy (to everyone's horror, I don't consider Sendmail to be Unix-like much at all due to it's overuse of M4 macros, in fact, it's a bit heretical, IMHO). Bind is not as heinous in it's own space as Sendmail has been over the years, but it doesn't change the fact that it's over-complicated and nasty in light of competing projects. That's just my impression, though. YMMV. > We are not planning to de-support or remove bind for NetBSD-8 I'd welcome it's removal since, as you say, it's in pkgsrc and folks can still fetch it easily and keep trucking with it. IMHO, Unixy first-principles (as well as volunteer energy) should determine what stays and goes in the code tree, not "backwards compatibility". That's M$-like thinking, to me. One major reason to be "open source" is that you *can* recompile the source if you want to change your ABI or other breakable bits. Also, one of TNF's stated goals for NetBSD is "correctness". I'm sure we could all debate what that means, but I'd assert that if you have several choices, you should pick the one most coherent with your own goals (licenses, design, simplicity, etc..). Again, I do realize how incredibly subjective all that is. So, I'm only stating my own opinion. Having worked with Unbound a bit, I have to say that it seems like a much more secure and easier to manage choice than Bind at this point. To ISC folks changing the license my feeling is "Thanks for years of service, but we've got to part ways now." Bind has picked up a lot of features over the years. I wouldn't be surprised if it could do a few things that Unbound cannot do. However, those are definitely going to be edge cases. 99% of folks running DNS servers are going to be just fine. Those that aren't, well, you can go to pkgsrc and still get bind. So, that's not really a big deal. That's my $0.02. -Swift
Re: bind -> unbound/nsd
chris...@astron.com (Christos Zoulas) writes: > In article , > Greg Troxel wrote: >> >>I don't see any real problems, but I think there should have been public >>discussion rather than announcing a decision. > > We can have it now... Well, it's not really the same when the decision has been made. But how about posting the analysis of why the change? Is it really about MPL (and presumably the patent terms)? Is it about security track record? Is unbound/nsd feature complete relative to everything that can be done with bind? Specifically, serving authoritative zones, DNSSEC, dynamic updates, and (for others) split dns? Please note that I'm not objecting; I'm just asking for the rationale to be articulated. signature.asc Description: PGP signature
Re: bind -> unbound/nsd
On Thu, 18 Aug 2016, Greg Troxel wrote: > Is it about security track record? I'm not wanting to get into the discussion of fiat versus consensus decision making. However, I'd like to give my own personal answer on some of the questions you raise, as a heavy DNS user/sysadmin. Bind's security track record has been somewhere between "horrible" and "really bad" depending on the version. http://www.cvedetails.com/product/144/ISC-Bind.html?vendor_id=64 Bind 9 was released in 2000, IIRC. So, that is mostly just for the 9.x code stream. Lots of folks still preferred the 4.x code base since 9.x added so much that it became a huge mess. 4.x had terrible security, but exhibited less inertia for getting started and maintaining the zones. So, Bind 4.x was maintained for quite a while. The trend is also not in decline. Note that in 2016 there were eight vulnerabilities and that's the largest number since 2002. However, to be fair, Bind has also had the maximum amount of beatings from every high-profile hacking team you can imagine. Perhaps if competing projects had the same amount of scrutiny they wouldn't fair well, either. > Is unbound/nsd feature complete relative to everything that can be done > with bind? Not even close if you consider the whole list. Unbound can only function as a recursive resolver. It has *no* ability to serve PTR and A records directly. It does, however, have some DNSSEC functionality. > Specifically, serving authoritative zones, DNSSEC, dynamic updates, and > (for others) split dns? It does not do split horizon because it can't be authoritative (same for dynamic DNS). YADIFA, MaraDNS, Knot DNS, or Djbdns would all be better choices than Unbound if you want a "real" server. The idea behind Unbound is to provide a secure and fast client resolver. Here's how the other's would break down in a nutshell: YADIFA Pros: BSD licensed. Fast. Full featured Cons: Newer. Not even in pkgsrc yet. No recursion. No split horizon MaraDNS: Pros: Good security record, stable, most features available Cons: Zany "Mara-DNS" license and weird layout / config Knot DNS: Pros: Very full featured. Fast. Awesome YAML config setup Cons: GPL'd, won't act as a recursive resolver Djbdns: Pros: Very secure. Fast. Public domain (no license) Cons: Missing features, spotty maintenance > Please note that I'm not objecting; I'm just asking for the rationale to > be articulated. In my mind the rationalization would be that most folks would probably have a secure resolver than a full-featured (potential) authoritative server. My guess is that a recursive server is what most folks want. The trade-off is essentially that you lose a bunch of features, but you also create a much smaller attack surface and gain Unbound's (slightly) more clear syntax. If authoritative DNS is seen as indispensable for distribution in NetBSD, it might be expedient to track YADIFA (since it's got a compatible license). However, the trouble it's about 8 years behind Bind's feature set. -Swift PS: It's sad that ISC decided to move to the MPL but I don't blame them much. It sucks to work on something for years that's "insanely popular" but nobody will contribute to or support. I'm sure folks know the feeling. I've read similar complaints from the OpenSSH team. I don't blame them a bit. Our 19[90|80]'s ideas about software freedom have been put to the test, and I'm not sure they've come out unblemished by the big-B-Billions of Internet ab^H^Husers.
Re: bind -> unbound/nsd
> On Aug 18, 2016, at 4:53 PM, Swift Griggs wrote: > >> On Thu, 18 Aug 2016, Greg Troxel wrote: >> Is it about security track record? > > I'm not wanting to get into the discussion of fiat versus consensus > decision making. However, I'd like to give my own personal answer on some > of the questions you raise, as a heavy DNS user/sysadmin. > > Bind's security track record has been somewhere between "horrible" and > "really bad" depending on the version. > > http://www.cvedetails.com/product/144/ISC-Bind.html?vendor_id=64 > > Bind 9 was released in 2000, IIRC. So, that is mostly just for the 9.x > code stream. Lots of folks still preferred the 4.x code base since 9.x > added so much that it became a huge mess. 4.x had terrible security, but > exhibited less inertia for getting started and maintaining the zones. So, > Bind 4.x was maintained for quite a while. > > The trend is also not in decline. Note that in 2016 there were eight > vulnerabilities and that's the largest number since 2002. However, to be > fair, Bind has also had the maximum amount of beatings from every > high-profile hacking team you can imagine. Perhaps if competing projects > had the same amount of scrutiny they wouldn't fair well, either. > >> Is unbound/nsd feature complete relative to everything that can be done >> with bind? > > Not even close if you consider the whole list. Unbound can only function > as a recursive resolver. It has *no* ability to serve PTR and A records > directly. It does, however, have some DNSSEC functionality. > >> Specifically, serving authoritative zones, DNSSEC, dynamic updates, and >> (for others) split dns? > > It does not do split horizon because it can't be authoritative (same for > dynamic DNS). > > Don't ignore the NSD part of the subject.
Re: bind -> unbound/nsd
On Thu, Aug 18, 2016 at 02:53:38PM -0600, Swift Griggs wrote: > On Thu, 18 Aug 2016, Greg Troxel wrote: > > Is it about security track record? > > I'm not wanting to get into the discussion of fiat versus consensus > decision making. However, I'd like to give my own personal answer on some > of the questions you raise, as a heavy DNS user/sysadmin. > > Bind's security track record has been somewhere between "horrible" and > "really bad" depending on the version. > > http://www.cvedetails.com/product/144/ISC-Bind.html?vendor_id=64 > > Bind 9 was released in 2000, IIRC. So, that is mostly just for the 9.x > code stream. Lots of folks still preferred the 4.x code base since 9.x > added so much that it became a huge mess. 4.x had terrible security, but > exhibited less inertia for getting started and maintaining the zones. So, > Bind 4.x was maintained for quite a while. > > The trend is also not in decline. Note that in 2016 there were eight > vulnerabilities and that's the largest number since 2002. However, to be > fair, Bind has also had the maximum amount of beatings from every > high-profile hacking team you can imagine. Perhaps if competing projects > had the same amount of scrutiny they wouldn't fair well, either. > > > Is unbound/nsd feature complete relative to everything that can be done > > with bind? > > Not even close if you consider the whole list. Unbound can only function > as a recursive resolver. It has *no* ability to serve PTR and A records > directly. It does, however, have some DNSSEC functionality. > > > Specifically, serving authoritative zones, DNSSEC, dynamic updates, and > > (for others) split dns? > > It does not do split horizon because it can't be authoritative (same for > dynamic DNS). > > YADIFA, MaraDNS, Knot DNS, or Djbdns would all be better choices than > Unbound if you want a "real" server. The idea behind Unbound is to provide > a secure and fast client resolver. Here's how the other's would break down > in a nutshell: > > YADIFA > Pros: BSD licensed. Fast. Full featured > Cons: Newer. Not even in pkgsrc yet. No recursion. No split horizon > > MaraDNS: > Pros: Good security record, stable, most features available > Cons: Zany "Mara-DNS" license and weird layout / config > > Knot DNS: > Pros: Very full featured. Fast. Awesome YAML config setup > Cons: GPL'd, won't act as a recursive resolver > > Djbdns: > Pros: Very secure. Fast. Public domain (no license) > Cons: Missing features, spotty maintenance > > > Please note that I'm not objecting; I'm just asking for the rationale to > > be articulated. > > In my mind the rationalization would be that most folks would probably > have a secure resolver than a full-featured (potential) authoritative > server. My guess is that a recursive server is what most folks want. The > trade-off is essentially that you lose a bunch of features, but you also > create a much smaller attack surface and gain Unbound's (slightly) more > clear syntax. Totally agree. Not only this, but in general... Bind I think is really horrible in terms of security - have only this, I see no reason to keep it in the base system nowadays. And also because there is a decent alternatives.(besides, I'm also think that most users don't need more than unbound). Bind configuration in my point of view(I really did not mean to offend anyone of it's developers) is a nightmare, unfortunately, too. Except unbound, at least djbdns looks like a good choise. > > If authoritative DNS is seen as indispensable for distribution in NetBSD, > it might be expedient to track YADIFA (since it's got a compatible > license). However, the trouble it's about 8 years behind Bind's feature > set. > > -Swift > > > PS: It's sad that ISC decided to move to the MPL but I don't blame them > much. It sucks to work on something for years that's "insanely popular" > but nobody will contribute to or support. I'm sure folks know the feeling. > I've read similar complaints from the OpenSSH team. I don't blame them a > bit. Our 19[90|80]'s ideas about software freedom have been put to the > test, and I'm not sure they've come out unblemished by the big-B-Billions > of Internet ab^H^Husers. >
Re: bind -> unbound/nsd
On Aug 18, 1:27pm, g...@ir.bbn.com (Greg Troxel) wrote: -- Subject: Re: bind -> unbound/nsd | Please note that I'm not objecting; I'm just asking for the rationale to | be articulated. There are many analyses on the web comparing bind and unbound, here are 3: http://info.menandmice.com/blog/bid/37244/10-Reasons-to-use-Unbound-DNS https://forums.freebsd.org/threads/53924/ https://en.wikipedia.org/wiki/Comparison_of_DNS_server_software For us though the particular reasons are: - License change would require us to copy the software and reapply patches. - We don't have other MPL software in base; this would mean another license. - Fewer security issues - Smaller memory footprint for most people, easier to administer. - New resolver API's (asynchronous etc) - Modular, simpler, smaller, better auditable - BSD licensed And some negatives: - Crypto is integrated, not optional (although we can fix that) - Bind libraries are still used by dhcpd - Needs additional components nsd, openDNSSEC, ldns to match bind's functionality christos
Re: bind -> unbound/nsd
On 19/08/2016 07:16, Christos Zoulas wrote: > - Needs additional components nsd, openDNSSEC, ldns to match bind's > functionality Maybe we should take a step back and consider what functionality we need rather than trying to match bind. For example, I would use nsd on exactly one machine in my environment, my public facing DNS server which is exactly where it belongs. On the other hand, all my other BSD machines run unbound as a local caching resolver. I'm all for stripping out bind and putting unbound in its place, but I would suggest to keep nsd in pkgsrc along with bind (even though it would make my task of updating my ERLITE easier as compiling on it for pkgsrc blows chunks). Roy
Re: bind -> unbound/nsd
On Fri, Aug 19, 2016 at 09:55:48AM +0100, Roy Marples wrote: > For example, I would use nsd on exactly one machine in my environment, > my public facing DNS server which is exactly where it belongs. > > On the other hand, all my other BSD machines run unbound as a local > caching resolver. To slightly expand that. You don't need nsd if you just want to serve a few local host names for a local network. You only need nsd if you want to provide an authoritive DNS server. IMO that is a decently small use case that it doesn't justify the incluse into the base system. Joerg
Re: bind -> unbound/nsd
On Fri, 19 Aug 2016, Joerg Sonnenberger wrote: > To slightly expand that. You don't need nsd if you just want to serve a > few local host names for a local network. You only need nsd if you want > to provide an authoritive DNS server. IMO that is a decently small use > case that it doesn't justify the incluse into the base system. I'd agree. It highlights the fact that you're better off picking a feature list and seeing who matches. On the basis of license/features Bind is hard to beat. On the basis of license && security it's hard to accept. Bind basically looks like this: [ ] Recursive resolution [ ] Caching only [ ] Authoritative server support [ ] DNSSEC [ ] Split horizon [ ] Response rate limiting (RRL) [ ] Clustering/replication [ ] Dynamic reloadability [ ] NXDOMAIN redirection [ ] BSD or acceptable License [ ] GeoIP [ ] Response policy zones [ ] Database support [ ] Written in C -Swift
Re: bind -> unbound/nsd
On Fri, Aug 19, 2016 at 06:13:13PM +0200, Joerg Sonnenberger wrote: > On Fri, Aug 19, 2016 at 09:55:48AM +0100, Roy Marples wrote: > > For example, I would use nsd on exactly one machine in my environment, > > my public facing DNS server which is exactly where it belongs. > > > > On the other hand, all my other BSD machines run unbound as a local > > caching resolver. > > To slightly expand that. You don't need nsd if you just want to serve a > few local host names for a local network. You only need nsd if you want > to provide an authoritive DNS server. IMO that is a decently small use > case that it doesn't justify the incluse into the base system. I am strongly opposed to removing basic server functionality present in BSD Unix for over 30 years -- and still in widespread use -- from NetBSD. I don't mind replacing BIND but all its functionality should be replacd. If you want to have to guess which version of basic Internet server software might happen to be on the system you're working on today, Linux is -->over there. Thor
Re: bind -> unbound/nsd
On Aug 21, 10:28am, t...@panix.com (Thor Lancelot Simon) wrote: -- Subject: Re: bind -> unbound/nsd | I am strongly opposed to removing basic server functionality present | in BSD Unix for over 30 years -- and still in widespread use -- from NetBSD. | I don't mind replacing BIND but all its functionality should be replacd. | | If you want to have to guess which version of basic Internet server | software might happen to be on the system you're working on today, Linux | is -->over there. I agree with that; yes, pkgsrc is there, but it does not provide the tight integration and the "out of the box" usability. I am also running authoritative servers on NetBSD so I am biased :-) I am also the one who is doing the work... christos
Re: bind -> unbound/nsd
On Sun, Aug 21, 2016 at 10:38:44AM -0400, Christos Zoulas wrote: > On Aug 21, 10:28am, t...@panix.com (Thor Lancelot Simon) wrote: > -- Subject: Re: bind -> unbound/nsd > | I am strongly opposed to removing basic server functionality present > | in BSD Unix for over 30 years -- and still in widespread use -- from NetBSD. > | I don't mind replacing BIND but all its functionality should be replacd. > > I agree with that; yes, pkgsrc is there, but it does not provide the > tight integration and the "out of the box" usability. I agree strongly with Thor about the basic functionality and Christos about the integration and usability. Dave -- David Young //\ Trestle Technology Consulting (217) 721-9981 Urbana, IL http://trestle.tech/
Re: bind -> unbound/nsd
On Sun, Aug 21, 2016 at 10:28:39AM -0400, Thor Lancelot Simon wrote: > On Fri, Aug 19, 2016 at 06:13:13PM +0200, Joerg Sonnenberger wrote: > > On Fri, Aug 19, 2016 at 09:55:48AM +0100, Roy Marples wrote: > > > For example, I would use nsd on exactly one machine in my environment, > > > my public facing DNS server which is exactly where it belongs. > > > > > > On the other hand, all my other BSD machines run unbound as a local > > > caching resolver. > > > > To slightly expand that. You don't need nsd if you just want to serve a > > few local host names for a local network. You only need nsd if you want > > to provide an authoritive DNS server. IMO that is a decently small use > > case that it doesn't justify the incluse into the base system. > > I am strongly opposed to removing basic server functionality present > in BSD Unix for over 30 years -- and still in widespread use -- from NetBSD. > I don't mind replacing BIND but all its functionality should be replacd. I find it quite dishonest to call authoritive DNS a basic server functionality. Joerg
Re: bind -> unbound/nsd
On Aug 21, 10:28am, Thor Lancelot Simon wrote: } On Fri, Aug 19, 2016 at 06:13:13PM +0200, Joerg Sonnenberger wrote: } > On Fri, Aug 19, 2016 at 09:55:48AM +0100, Roy Marples wrote: } > > For example, I would use nsd on exactly one machine in my environment, } > > my public facing DNS server which is exactly where it belongs. } > > } > > On the other hand, all my other BSD machines run unbound as a local } > > caching resolver. } > } > To slightly expand that. You don't need nsd if you just want to serve a } > few local host names for a local network. You only need nsd if you want } > to provide an authoritive DNS server. IMO that is a decently small use } > case that it doesn't justify the incluse into the base system. } } I am strongly opposed to removing basic server functionality present } in BSD Unix for over 30 years -- and still in widespread use -- from NetBSD. } I don't mind replacing BIND but all its functionality should be replacd. } } If you want to have to guess which version of basic Internet server } software might happen to be on the system you're working on today, Linux } is -->over there. I find this comment quite confusing. Having to guess which software (and how to configure it) that provides a particular functionality isn't much different then guessing whether or not the functionality is provided by default. I use NetBSD to provide authoritative name service for a small service provider. I'm also in the camp that if you're going to remove BIND from base, then it is probably better not to bother with providing an authoritative name server, especially since very few systems are going to need one. People that do need one are either installing something from pkgsrc, or going through the hassle of converting to a different program. The latter is likely more troublesome. }-- End of excerpt from Thor Lancelot Simon
Re: bind -> unbound/nsd
On Thu, Aug 18, 2016 at 11:10:18AM -0400, Christos Zoulas wrote: > > Hello, > > The recent change of ISC/bind licensing from BSD to MPL for the > next release has provided us with an opportunity to re-evaluate > the preferred daemon status for NetBSD and DNS resolution. Board/Core > have decided not to import the next version of bind, and instead > import the current version of unbound/nsd. > > If you feel that this creates problems for you, let us know. > Also you should be able to use newer versions of bind from pkgsrc. > We are not planning to de-support or remove bind for NetBSD-8. > > Best, > > christos Hi, This may not be 100% factually correct (I'm trying my best, but not too familiar with BIND): NetBSD 6.0 was released in Oct 2012. If we had done such a decision several months before the release, the version of BIND we would have in base for 6.x is ~9.9.0. This is a list of the vulnerabilities that our 6.x base BIND would contain in this scenario, which would resemble what we will see towards the end of the 8.x supported life. # CVE Number Short Description 75 2016-2775 A query name which is too long can cause a segmentation fault in lwresd 73 2016-1286 A problem parsing resource record signatures for DNAME resource records can lead to an assertion failure in resolver.c or db.c 72 2016-1285 An error parsing input received by the rndc control channel can cause an assertion failure in sexpr.c or alist.c 69 2015-8704 Specific APL data could trigger an INSIST in apl_42.c 67 2015-8000 Responses with a malformed class attribute can trigger an assertion failure in db.c 65 2015-5722 Parsing malformed keys may cause BIND to exit due to a failed assertion in buffer.c 64 2015-5477 An error in handling TKEY queries can cause named to exit with a REQUIRE assertion failure 63 2015-4620 Specially Constructed Zone Data Can Cause a Resolver to Crash when Validating 62 2015-1349 A Problem with Trust Anchor Management Can Cause named to Crash 60 2014-8500 A Defect in Delegation Handling Can Be Exploited to Crash BIND 57 2014-0591 A Crafted Query Against an NSEC3-signed Zone Can Crash BIND 56 2013-6230 A Winsock API Bug can cause a side-effect affecting BIND ACLs 55 2013-4854 A specially crafted query can cause BIND to terminate abnormally 53 2013-2266 A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named 52 2012-5689 BIND 9 with DNS64 enabled can unexpectedly terminate when resolving domains in RPZ 51 2012-5688 BIND 9 servers using DNS64 can be crashed by a crafted query 50 2012-5166 Specially crafted DNS data can cause a lockup in named 49 2012-4244 A specially crafted Resource Record could cause named to terminate 48 2012-3868 High TCP query load can trigger a memory leak 47 2012-3817 Heavy DNSSEC validation load can cause a "bad cache" assertion failure 46 2012-1667 Handling of zero length rdata can cause named to terminate unexpectedly Obtained from https://kb.isc.org/article/AA-00913/0/BIND-9-Security-Vulnerability-Matrix.html
Re: bind -> unbound/nsd
On Aug 21, 9:47pm, co...@sdf.org wrote: } On Thu, Aug 18, 2016 at 11:10:18AM -0400, Christos Zoulas wrote: } > } > The recent change of ISC/bind licensing from BSD to MPL for the } > next release has provided us with an opportunity to re-evaluate } > the preferred daemon status for NetBSD and DNS resolution. Board/Core } > have decided not to import the next version of bind, and instead } > import the current version of unbound/nsd. } > } > If you feel that this creates problems for you, let us know. } > Also you should be able to use newer versions of bind from pkgsrc. } > We are not planning to de-support or remove bind for NetBSD-8. } } This may not be 100% factually correct (I'm trying my best, but not too } familiar with BIND): } } NetBSD 6.0 was released in Oct 2012. If we had done such a decision } several months before the release, the version of BIND we would have in } base for 6.x is ~9.9.0. } } This is a list of the vulnerabilities that our 6.x base BIND would } contain in this scenario, which would resemble what we will see towards } the end of the 8.x supported life. There are regular pullups for security issues. Thus your list would only be correct for 6.0 itself, and not for subsequent 6.x releases. And, if one didn't update from 6.0 at all, there would be plenty of other issues (both OpenSSL and OpenSSH regularly get CVEs for example). } # CVE Number Short Description } 752016-2775 A query name which is too long can cause a segmentation fault in lwresd } [list elided] } } Obtained from https://kb.isc.org/article/AA-00913/0/BIND-9-Security-Vulnerability-Matrix.html }-- End of excerpt from co...@sdf.org
Re: bind -> unbound/nsd
On Sun, Aug 21, 2016 at 03:07:18PM -0700, John Nemeth wrote: > There are regular pullups for security issues. Thus your list > would only be correct for 6.0 itself, and not for subsequent 6.x > releases. And, if one didn't update from 6.0 at all, there would > be plenty of other issues (both OpenSSL and OpenSSH regularly get > CVEs for example). > Would we update for security reasons despite the license change?
Re: bind -> unbound/nsd
On 2016-08-21 15:38, chris...@zoulas.com wrote: On Aug 21, 10:28am, t...@panix.com (Thor Lancelot Simon) wrote: -- Subject: Re: bind -> unbound/nsd | I am strongly opposed to removing basic server functionality present | in BSD Unix for over 30 years -- and still in widespread use -- from NetBSD. | I don't mind replacing BIND but all its functionality should be replacd. | | If you want to have to guess which version of basic Internet server | software might happen to be on the system you're working on today, Linux | is -->over there. I agree with that; yes, pkgsrc is there, but it does not provide the tight integration and the "out of the box" usability. I am also running authoritative servers on NetBSD so I am biased :-) OK, I'll bite. Please describe how nsd has a "tighter integration" or (i assume better?) "out of the box usability" when in -base vs pkgsrc. Roy
Re: bind -> unbound/nsd
On Fri, Aug 19, 2016 at 06:13:13PM +0200, Joerg Sonnenberger wrote: > On Fri, Aug 19, 2016 at 09:55:48AM +0100, Roy Marples wrote: > > For example, I would use nsd on exactly one machine in my environment, > > my public facing DNS server which is exactly where it belongs. > > > > On the other hand, all my other BSD machines run unbound as a local > > caching resolver. > > To slightly expand that. You don't need nsd if you just want to serve a > few local host names for a local network. You only need nsd if you want > to provide an authoritive DNS server. IMO that is a decently small use > case that it doesn't justify the incluse into the base system. I know nothing of bound / nsd - in bind I currently serve a local domain using zones fetched from the authoritative server, so it isn't authoritative, and it isn't only cacheing - how does that fit in the new world? Cheers, Patrick
Re: bind -> unbound/nsd
On Mon, Aug 22, 2016 at 12:21:00PM +0100, Patrick Welche wrote: > On Fri, Aug 19, 2016 at 06:13:13PM +0200, Joerg Sonnenberger wrote: > > On Fri, Aug 19, 2016 at 09:55:48AM +0100, Roy Marples wrote: > > > For example, I would use nsd on exactly one machine in my environment, > > > my public facing DNS server which is exactly where it belongs. > > > > > > On the other hand, all my other BSD machines run unbound as a local > > > caching resolver. > > > > To slightly expand that. You don't need nsd if you just want to serve a > > few local host names for a local network. You only need nsd if you want > > to provide an authoritive DNS server. IMO that is a decently small use > > case that it doesn't justify the incluse into the base system. > > I know nothing of bound / nsd - in bind I currently serve a local > domain using zones fetched from the authoritative server, so it > isn't authoritative, and it isn't only cacheing - how does that fit > in the new world? For unbound, there are essentially three different ways to answer a query: (1) Recursion to some upstream name server like the root servers. (2) Local (non-authoritive) entries (3) Stub zones, e.g. explicit redirect to an authoritive server. If you only care about A, , PTR, SOA and TXT for internal use, (2) is enough. The answers won't be authoritive, but you can easily specify the data in the config file and/or manipulate it via the control socket. The latter can also be used for some forms of Dynmic DNS. If you need authoritive answers or more control of the zone like DNSSEC, wildcards or CNAME, you can use stub zones to implement a split horizon. E.g. you tell unbound explicitly that example.com. should be resolved via 192.168.1.1 and not via whatever is found in com. One of the biggest the reason why unbound doesn't do authoritive is that it makes it a lot easier to avoid a large class of cache poisoning attacks. For typical local network uses in the SOHO style, it isn't needed either. Joerg
Re: bind -> unbound/nsd
On Sun, 21 Aug 2016, co...@sdf.org wrote: > Would we update for security reasons despite the license change? The upstream will continue to provide security fixes for the stable supported version that uses the old license for at least a couple years. (The license change is in the new feature release that is not out yet.)
Re: bind -> unbound/nsd
On Sun, Aug 21, 2016 at 10:28:39AM -0400, Thor Lancelot Simon wrote: > On Fri, Aug 19, 2016 at 06:13:13PM +0200, Joerg Sonnenberger wrote: > > On Fri, Aug 19, 2016 at 09:55:48AM +0100, Roy Marples wrote: > > > For example, I would use nsd on exactly one machine in my environment, > > > my public facing DNS server which is exactly where it belongs. > > > > > > On the other hand, all my other BSD machines run unbound as a local > > > caching resolver. > > > > To slightly expand that. You don't need nsd if you just want to serve a > > few local host names for a local network. You only need nsd if you want > > to provide an authoritive DNS server. IMO that is a decently small use > > case that it doesn't justify the incluse into the base system. > > I am strongly opposed to removing basic server functionality present > in BSD Unix for over 30 years -- and still in widespread use -- from NetBSD. > I don't mind replacing BIND but all its functionality should be replacd. > > If you want to have to guess which version of basic Internet server > software might happen to be on the system you're working on today, Linux > is -->over there. So for what it's worth: I don't see any need to have a DNS server in base. It may be traditional, but few people use it; the landscape's changed since the days where it was something you'd have on e.g. a department LAN along with a mail server and ftp server. And unlike e.g. removing the mailer daemon, there's nothing in base that depends on having local DNS service and also there's nothing that the DNS server gains from being in base. Plus, IMO, it's better to handle things that require frequent patching in pkgsrc because it's a lot easier to keep them up to date. (And yes, I serve some authoritative DNS from netbsd, so I have a stake in this game too.) -- David A. Holland dholl...@netbsd.org
Re: bind -> unbound/nsd
It would be good to be able to have local DNSSEC validation work (especially if we want to use TLSA). I also serve authoritative DNS using NetBSD currently and for over a decade. I am fine with installing an authoritative server via a package.
Re: bind -> unbound/nsd
On Sun, Aug 28, 2016 at 06:24:41AM +, David Holland wrote: > > So for what it's worth: I don't see any need to have a DNS server in > base. It may be traditional, but few people use it; the landscape's As a guy who spent the best part of a decade building embedded products out of NetBSD: I'll believe all this "you can just add a package" stuff when all this stuff I should supposedly be able to use from pkgsrc cross-compiles as cleanly as our base system does. I had to integrate *PHP* to our "base system" build. That sucked, but it sucked a lot less than the logistical and non-reproducibility issues which stemmed from building parts of our product outside the wonderful, clean, cross-compile-from-anywhere-to-anywhere NetBSD system build. Thor
Re: bind -> unbound/nsd
On August 29, 2016 at 8:36:23 PM, Thor Lancelot Simon (t...@panix.com) wrote: > On Sun, Aug 28, 2016 at 06:24:41AM +, David Holland wrote: > > > > So for what it's worth: I don't see any need to have a DNS server in > > base. It may be traditional, but few people use it; the landscape's > > As a guy who spent the best part of a decade building embedded products > out of NetBSD: I'll believe all this "you can just add a package" stuff > when all this stuff I should supposedly be able to use from pkgsrc > cross-compiles as cleanly as our base system does. Yes, we lost a lot of what was supposed to be the goal with pkgsrc in that area (cross-compiling). Work has been done, but, like many pkgsrc projects, it never really became a first class citizen. Not to disparage all the work the pkgsrc people do. Yes, the loss of cross compile *does* impact the decision on pkgsrc vs base. However, ARMs are getting faster, m68ks aren’t. ;) I firmly believe we need to have a stronger push into the embedded/appliance space. That said, yeah, we (image builders) are at a disadvantage until we can turn that ship. Maybe this is the impetus to start improvements on making pkgsrc more useful to cross environments? Right now we’re at the the original 4.3BSD/386BSD here’s a long list of instructions: https://ftp.netbsd.org/pub/pkgsrc/stable/pkgsrc/doc/HOWTO-use-crosscompile (Further described here: https://www.netbsd.org/gallery/presentations/riastradh/asiabsdcon2015/pkgsrc-cross-paper.pdf) We need to get here: https://wiki.netbsd.org/projects/project/cross_nb_pkgsrc/ > > I had to integrate *PHP* to our "base system" build. That sucked, > but it sucked a lot less than the logistical and non-reproducibility > issues which stemmed from building parts of our product outside the > wonderful, clean, cross-compile-from-anywhere-to-anywhere NetBSD > system build. > > Thor > -- Erik Berls
