I'm against this.
ISC software has a long and troubling history of security vulnerabilties
and other issues. Indeed, there are a plethora of DNS implemenations as
a result of widespread dissatisfaction with ISC DNS software.
ISC BIND is also part of an AXFR-clarify scam, whereby ISC exploited an
ambiguity in the AXFR specification. Numerous other DNS implementations
performed the AXFR protocol the same way, including prior versions of
BIND. A clarification would therefore be expected to document the
prevailing assumptions used by implementations.
Instead, ISC changed BIND to use a different AXFR wire protocol, added
code to detect the "original protocol", and proposed a "clarification"
standard for the new protocol. ISC told operators and other implmentors
that the "clarification" did not change the wire protocol. Operators
who merely tried zone transfers with BIND 9 didn't perceive any change
due to the protocol detection code in BIND 9.
Had the "clarification" been approved, it would then only remain for ISC
and the so-called BIND companies (ISC, Nomimum, UltraDNS) to remove the
old-protocol detection, and then claim that other implementations
weren't compliant with the standards. The scheme failed when it was
pointed out that the "clarification" was in fact a wire protocol change
promoted almost exclusively by BIND people. (See message by Dr. Dan
Bernstein on Namedroppers, 2/14/2003)
Vixie just recently claimed that he never supported the "clarification"
document, though the Namedroppers archives refute that claim.
So, as a result, I'm trying to remove all ISC software from my systems.
I don't know of any specific issues with the ISC DHCP software, except
that I think the problems with ISC BIND are systemic in nature, and
therefore the other ISC software must suffer similarly.
Indeed, I'd much rather prefer a GPL or BSD copyright on the Sun DHCP
server.
--Dean
On Fri, 10 Aug 2007, David Pickens wrote:
> After struggling with some issues recently around the current DHCP
> server daemon, I am opening a discussion thread to garner support to
> replace the current DHCP server daemon in Solaris.
>
> Specifically, I proposed that the current daemon be replaced with
> ISC's implementation of the DHCP server. I've outlined the reasons
> after my signature.
>
> Please post your comments and suggestions. If you would, please
> indicate your support for this initiative by including "YES" in the
> Subject line or within the first couple of lines of your posting.
>
> Thank you,
>
> Dave Pickens, Principal Engineer
> US Government, Education and Heathcare (GEH)
> Sun Microsystems, Inc.
>
> ---
>
> The following outlines some of the reasons gathered from Solaris admins and
> other sources (these may or may not be 100% factual -- however perception is
> reality in some cases):
>
> 1) Old code
>
> The Solaris DHCP is older code and not actively updated -- no one wants to
> accept responsibility within Sun for the maintenance, updating of the code
> since it's not new and exciting. Realistically it needs a re-write and
> re-architecture.
>
> Much of it hasn't changed since Dave Miner rewrote the code for the initial
> release of Solaris 9 (or earlier).
>
> 2) GUI
>
> The current Solaris DHCP Admin GUI is slow and considered non-standard in the
> industry. Does not work with large #'s of scopes or IP addresses. While ISC's
> DHCP server does not offer an admin GUI, 3rd party open source options that
> can be bundled or added to do the equivalent of the current Solaris DHCP
> Admin GUI.
>
> http://www.debianhelp.co.uk/dhcpweb.htm
>
> 3) Scalability and Performance
>
> ISC DHCP daemon being a more modern code base scales and performs better than
> Solaris' out-of-date DHCP daemon even when ISC is using a text file for IP
> information vs. Solaris' SUNWbin format. When the Solaris DHCP daemon is
> configured to use SUNWtext format, performance and scalability is even more
> noticeable.
>
> 4) Availability
>
> ISC DHCP daemon can be made completely redundant using the IETF Draft
> standard for DHCP Failover. The current Solaris DHCP daemon requires
> significant more effort including the use of a shared filesystem and the
> requirement to maintain the IP scope data in text file format, a known
> performance issue.
>
> 5) Supportability
>
> DHCP escalations often aren't done when necessary and customers feel like the
> current Solaris DHCP daemon isn't supported that well. (First level support
> at Sun can't even spell DHCP sometimes). The OpenSolaris community is no
> different. While there is significant work being done within the Networking
> area here, none is around the DHCP server.
>
> 6) Not core competency
>
> While some parts of IP networking are sexy and definitely a core competency,
> DHCP along with DNS are not. Other outside 3rd party open source packages for
> DNS (BIND) for example are integrated into Solaris rather than being
> maintained by Sun or the OpenSolaris community. So if it's not a core
> competency, why are we playing like we should keep maintaining our own code?
>
> In fact the BIND code is largely, if not wholly, ISC's code base for BIND in
> Solaris... why this and not DHCP server?
>
> 7) Not aligned with direction
>
> If the direction is innovation where it matters most, why again are we not
> admitting that DHCP just isn't a place where Sun and the OpenSolaris can
> actually provide innovation... and that with the direction of being
> compatible or more linux-like (a la Project Indiana) then keeping our own
> DHCP daemon is not in line with this direction
>
> 8) Not aligned with other linux distros
>
> Ubuntu, Redhat, Suse and Debian distros all use ISC by default
>
> 9) Most DHCP appliances (eg. BlueCat) don't use Sun Solaris
>
> They use the DHCP daemon from ISC... along with their own wrappers and
> management tools...
>
> 10) More articles on the Sun's own website BigAdmin about ISC available than
> Sun's DHCP
>
> Sun's own BigAdmin website for Solaris admins has more information around ISC
> than Sun's DHCP product.
>
> 11) More articles on ISC's product on the internet
>
> There's a larger community out there around ISC's DHCP daemon than the
> Solaris' DHCP daemon... this goes back the number of distros using it as
> their default DHCP server and is evidenced by the amount of articles on the
> internet around ISC's daemon vs. the current Solaris' DHCP daemon.
>
> >From this, it confirms that ISC is *the* reference DHCP server and a de
> >facto standard.
>
> 12) Lagging functionality
>
> The shear number and frequency of updates and new features introduced by ISC
> is an order of magnitude higher than that of Solaris' current DHCP server.
>
> In a recent update, ISC now offers new functionality not available in the
> Solaris DHCP daemon:
>
> a) A significantly enhanced Failover protocol implementation, which:
> i) Implements MAC Address Affinity to reduce the frequency of
> clients
> being assigned new IP addresses;
> ii) Supports the assignment of failover-protected addresses to
> legacy BOOTP clients;
> iii) Implements a dynamic lease reservation system that
> provides improved
> accounting of the use of fixed address assignments, by
> allocating fixed
> addresses out of the pool of dynamic leases; and
> iv) Further improves tools and reduces operator oversight
> necessary for
> maintaining a functioning system.
> b) Support for DHCP Leasequery, and the VIVCO/VIVSO options, which makes
> easy and comfortable integration with DOCSIS devices and the
> environment
> in which they are used.
> c) Management of class and subclass statements via OMAPI.
> d) Several server configuration options related to dynamic DNS behavior
>
> The current DHCP code base just isn't keeping up with these features and
> advances.
>
> 13) IPv6 / DHCPv6
>
> The current code will require significant effort and revision to support IPv6
> / DHCPv6. The resources within Sun and within the OpenSolaris community just
> haven't rallied around doing this. Migrating the DHCP server to ISC's code
> base will allow for IPv6 / DHCPv6 and other new features to be more easily
> integrated and supported.
>
>
> This message posted from opensolaris.org
> _______________________________________________
> networking-discuss mailing list
> [email protected]
>
>
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
networking-discuss mailing list
[email protected]
