Date: Thu, 05 Dec 2013 08:09:50 +1100 From: Mark Andrews <marka@isc.org> To: Erwin Lansing <erwin@FreeBSD.org> Cc: stable@freebsd.org, freebsd-stable@freebsd.org Subject: Re: BIND chroot environment in 10-RELEASE...gone? Message-ID: <20131204210950.7917AB276B4@rock.dv.isc.org> In-Reply-To: Your message of "Wed, 04 Dec 2013 10:47:31 %2B0100." <20131204094730.GX29825@droso.dk> References: <529D9CC5.8060709@rancid.berkeley.edu> <529DF7FA.7050207@passap.ru> <529E179D.7030701@rancid.berkeley.edu> <20131203211606.F2E17B100EB@rock.dv.isc.org> <20131204094730.GX29825@droso.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20131204094730.GX29825@droso.dk>, Erwin Lansing writes: > On Wed, Dec 04, 2013 at 08:16:06AM +1100, Mark Andrews wrote: > > > > As for 9.9.x ESV it will be support for to at least June 2017, which > > is 5+ years from BIND 9.9.0, and 4 years after 9.9.x was announced > > as the ESV series with BIND 9.9.3. > > > > BIND 9.6 went ESV in Mar 2010 and will be EoL in Jan 2014. > > > > BIND 9.10 in is alpha at the moment. > > > > BIND 10 is still in development. > > > > Thanks for chiming in Mark. As you can see, there's some confusion > about BIND9's lifetime, so getting this straight from the horse's mouth > is good. > > I did a presentation at the recent ICANN meeting about why BIND was > removed from base, slides are at > http://people.freebsd.org/~erwin/presentations/20131118-ICANN-FreeBSD-DNS.pdf > > Note that most of the reasons all fall back to reducing code base and > complexity, and some of the other bullets all follow from that. It has > more to do with how BIND was integrated into FreeBSD than BIND itself > and unbound just has the advantage that it does not have an authoritatve > part (and key management etc), with associated options and potential > security vulnerabilities, and thus hopefully will be easier to maintain > in the base system. Yet you need the authoritative part for supplying addresses in the home which it is named vs Casper. B.T.W. It is don't be a recursive server if you are a authoritative server for a zone (i.e. listed in the NS records). Not staight split of rolls. Recursive server expect to be talking to authoritative servers. Stub resolvers don't care if some of the answers they get are from a authoritative zone or from a cache. They do care if they are not offered a recursive service. As with many things in the DNS there are lots of caveats and exceptions to any "rule". As for key management you only need to worry about that if you are signing the zones. As for potential bugs. Having authoritative support in the server adds very little additional code overall. You still need to parse queries. You still need code to assemble responses to the client. You still need code to parse responses from authoritative servers. About the only thing you do extra is read some zone content from disk or transfer it from other authoritative servers and write zone content out to disk. The arguements don't stack up for anyone truly aware of how nameservers work. Mark > Erwin > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131204210950.7917AB276B4>