Re: djbdns: An alternative to BIND
> You need only count the lines of code needed by the daemon/s > servicing requests. That is, IMO, bind's only major failing. Too > much code, too many little used features (nobody I know needs or > wants rndc), and no way to compile without them. If you read Bruce > Schneier, as every developer should, you know how important that > "Amount of code" is. Ah, but how do you know what are the little used features? We use rndc a lot, just as we used ndc with BIND 8. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Call for Track Chairs - APRICOT 2006
APRICOT 2006 CALL FOR TECHNICAL CONFERENCE TRACK CHAIRS Asia Pacific Regional Internet Conference on Operational Technologies Perth, Australia Feb 22 - Mar 3, 2006 The APRICOT 2006 Program Committee is seeking interested and qualified Track Chairs to actively assist the Committee in recruiting speakers and organizing technical tracks for the 2006 Asia Pacific Regional Internet Conference on Operational Technologies. The main responsibility of the Track Chair is to identify, recruit high quality speakers to share their expertise on operationally relevent topics. As in past years, the APRICOT Program Committee will issue a general call for presentations, which typically elicits a large number of submissions. These proposals will be provided to the Track Chairs for consideration, but it is expected that the Track Chairs will primarily use their own personal networks to recruit speakers who may not have participated in past APRICOT events. Specific Track Chair responsibilities include: * Identifying and describing a track topic and relevant potential track components (panel discussions, pro/con debates, etc.) within the track that will be interesting and valuable to the APRICOT audience. Preliminary Track descriptions are due at the time of nomination, or by June 15, 2005. * Helping to publicize and recruit speakers, session moderators, and participants for their track and the conference in general. * Vetting and recommending speakers and their subjects for their Track to the Program Committee. Detailed Track content recommendations are due on August 29, 2005. * Requiring and confirming that speakers submit their proposed materials in a timely manner. Track chairs should submit speaker recommendations and abstracts to the Program Committee by September 26, 2005. Selected speakers will be announced by the Program Committee on or before October 10, 2005. * Evaluating submitted materials for content and quality suitable for an international technical/operations conference. Track chairs should submit full/detailed presentation outlines to the Program Committee by November 7, 2005. * Serving as a liaison between the Program Committee and the selected participants in your Track. Track chairs should submit all complete presentation materials to the Program Committee by January 9, 2006. * This year we will require that speakers must supply their program material in advance so that we can confirm operational content and that there is not inappropriate sales material. * Track Chairs are members of the Apricot Program Committee and will share the responsibility of determining overall program issues and planning. Track Chairs are encouraged to help find speakers for other tracks and tutorials as well. Workshop Chair and Tutorial Chair These positions are similar to the Track Chairs described above, but will be responsible for recruiting and facilitating instructors for five-day and half-day/full day instructional tutorials, respectively. A total of 5-6 Track Chairs will be selected by the Program Committee, along with a Tutorial Chair and Workshop Chair, with the expectation that 4-6 Tracks will ultimately be scheduled for presentation. Please feel free to nominate yourself or someone other than yourself who might be appropriate for either of these positions. The deadline for receiving Conference Track and Tutorial Track Chair nominations is May 2, 2005. Results of the selection process will be announced by May 18, 2005. ABOUT THE APRICOT AUDIENCE The APRICOT audience is mainly comprised of technical network operators and professional engineers with experience levels ranging from (almost) newbie to seasoned, senior technical management. APRICOT audiences always include native speakers of a dozen or more languages, so written materials and presentations should be tuned appropriately. Each year, the majority of APRICOT attendees travel internationally and commit considerable sums relative to their local economies to participate in APRICOT; they expect the highest possible quality in presentation content and delivery. APRICOT CONFERENCE TRACKS, SESSIONS, & TUTORIALS Historically, tutorials have focused on core operational skills and basic protocol knowledge, with conference sessions highlighting day-to-day operations and recent/emerging issues within a 12-18 month time horizon. APRICOT Conference Tracks are full-day events. Each Track typically encompasses three 90-minute Sessions composed of 3-4 presenters (speakers) per session; accordingly each presentation should be designed to be approximately 20-30 minutes in duration. On the recommendation of the Track Chair, individual Sessions may be moderated by persons with expertise appropriate to the subject matter of the session. Session Moderators may assist in managing speaker time and soliciting questions from the audience. APRICOT Tutorials are half or full day workshops which focus on a particular
Re: djbdns: An alternative to BIND
At 07:32 PM 4/9/2005, you wrote: David Conrad wrote: - Amount of code Again, what should be counted? Should you include rsync? Should you include utility programs like check-namedconf, axfr-get, rbldns, walldns, walldns-conf, etc.? You need only count the lines of code needed by the daemon/s servicing requests. That is, IMO, bind's only major failing. Too much code, too many little used features (nobody I know needs or wants rndc), and no way to compile without them. If you read Bruce Schneier, as every developer should, you know how important that "Amount of code" is. How do you add zones to your servers? We certainly don't connect to a shell on all of them for simple configuration tasks. Network shares and rndc make short work of most DNS tasks. rndc -s ns1 reconfig and rndc -s ns1 reload zone.com are the two most frequently used DNS tools used by our support staff. For automated tasks, writing a zone file to disk from the database on change and issuing an rndc reload is very useful. On the djb vs. BIND debate, for database driven zones, just output BIND format files (or djb if that floats your boat) from your database. Calling the actual zone files the "database" doesn't make sense anyway. If you manage your information well, the file format of the server application doesn't really matter. The security, performance and standards compliance matter most - to us anyway. -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin
Re: djbdns: An alternative to BIND
On Sat, Apr 09, 2005 at 04:32:12PM -0700, Roger Marquis wrote: > You need only count the lines of code needed by the daemon/s > servicing requests. That is, IMO, bind's only major failing. Too > much code, too many little used features (nobody I know needs or > wants rndc), and no way to compile without them. If you read Bruce > Schneier, as every developer should, you know how important that > "Amount of code" is. Ok, just came from the pub so i'm making this a short and simple one: I need&&want rndc! > Using bind 8 and 9 but still looking for something better, Doing that too, we could as well just kill ourselves if we were not ever looking for something better than we already have. Thats called life. ;) Stefan -- [Reading Elliot the contract] The Devil : Paragraph one states that I, the Devil, a not-for-profit organization, with offices in Purgatory, Hell, and Los Angles, will give you seven wishes to use as you see fit. - Bedazzled (2000)
Re: djbdns: An alternative to BIND
Roger Marquis wrote:
> You need only count the lines of code needed by the daemon/s
> servicing requests. That is, IMO, bind's only major failing. Too
> much code, too many little used features (nobody I know needs or
> wants rndc), and no way to compile without them. If you read Bruce
> Schneier, as every developer should, you know how important that
> "Amount of code" is.
While I don't disagree about lines of code, in general, I will remind you
that "nobody" and "everyone" are not sets that you may speak for. I like
rndc (although I preferred ndc). I've been using BIND since BIND 4.{mumble}
(currently at BIND 9 for those machines I retain responsibility for), and
I'd surely rather have all of BIND's little idiosyncrasies that to deal
with AD (now *there's* a nightmare).
--
Open source should be about giving away things voluntarily. When
you force someone to give you something, it's no longer giving, it's
stealing. Persons of leisurely moral growth often confuse giving with
taking.-- Larry Wall
Re: books every network operator should read?
Janet Sullivan wrote: I'd like to make a list for the BGP4.net wiki of books that are thought highly of by the network community. What books stand out for you as being excellent? If you could only own 5 network related books, what would they be? One of my favorites from years back though not BGP-related, probably out of date and out of print, a very good read none the less: A Guide to Fractional T1 James E. Trulove, 1992 Artech House, ISBN 0-89006-524-1 -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: djbdns: An alternative to BIND
David Conrad wrote: - Amount of code Again, what should be counted? Should you include rsync? Should you include utility programs like check-namedconf, axfr-get, rbldns, walldns, walldns-conf, etc.? You need only count the lines of code needed by the daemon/s servicing requests. That is, IMO, bind's only major failing. Too much code, too many little used features (nobody I know needs or wants rndc), and no way to compile without them. If you read Bruce Schneier, as every developer should, you know how important that "Amount of code" is. All I really want is to "configure --minimal && make && make install" and not have to fix ISC's ill thought-out defaults (like /usr/local/etc on Solaris...). Using bind 8 and 9 but still looking for something better, -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: djbdns: An alternative to BIND
On Sat, 9 Apr 2005, Stephane Bortzmeyer wrote: Just wondering how many have transitioned to djbdns from bind If transitioning from BIND, why go to the non-free and non-compliant djbdns instead of nsd (http://www.nlnetlabs.nl/nsd/)? I couldn't agree more. At least BIND9 and NSD both support RFC 4035, and I am getting tired of hearing about these cache poisoning hypes lately. Last one to secure his zone is a luser :) Paul
Re: AS prepending
On Fri, 8 Apr 2005, Patrick W Gilmore wrote: > > On Apr 8, 2005, at 10:28 AM, Philip Lavine wrote: > > > I am using AS prepending to favor one ISP over > > another, in a BGP multihomed/multiISP scenario. Why > > does the ISP receiving the prepends fail to add my > > network into their routing table? Is this a "feature" > > of BGP, or have I gone too far with 3 prepend > > statements. > > If they are both transit providers, then they are broken. I have found at least one major ISP did check the amount of prepends and did not accept the announcement if it did not match exactly what was coded in their as-path filter. They had to code special as-path filters that allowed an undetermined number of prepends so we could "play". Why not just ask your upstream ISP if they filter prepends? -Hank > > If they are peers, the second ISP is probably preferring the route it > hears through your transit provider because there are fewer AS hops.
Re: djbdns: An alternative to BIND
On Apr 9, 2005, at 9:35 AM, Will Yardley wrote: On Sat, Apr 09, 2005 at 01:14:14AM -0700, David Conrad wrote: Fortunately, if it is a religion, I am agnostic in the BIND vs. DJB war since I work for a company that has created a product that could be argued competes with both... :-). Didn't Nominum write BIND9, Yes, up to 9.2.0, under contract to ISC. and doesn't / didn't it provide commercial support for it? Yep. A commercial necessity if your market is ISPs/telcos. I'd think / hope that would give you a slight slant in one direction. I have my preferences, however I'm not religious about it. DJBDNS is better than BIND in some scenarios, BIND is better in others. Neither is perfect and since our customers use both, I'm interested in objective measures as opposed to subjective, emotion laden value judgments. Rgds, -drc
Re: djbdns: An alternative to BIND
> > Fortunately, if it is a religion, I am agnostic in the BIND vs. DJB war > > since I work for a company that has created a product that could be > > argued competes with both... :-). and from what i've heard, everyone who has tested nominum's ANS and/or CNS has been impressed with the performance, protocol compliance, and usability. (only the fact that it's commercial software, possessing a price tag, keeps it from being even more popular than it already is.) > Didn't Nominum write BIND9, and doesn't / didn't it provide commercial > support for it? I'd think / hope that would give you a slight slant in > one direction. all of the developers who worked on BIND9 worked at nominum or its predecessor (internet engines), and most of them are still at nominum. note, though, that this work was done under contract to ISC, who owns the copyright and who is BIND9's current developer and publisher. nominum and isc now both offer "commercial" (for a fee) support for BIND9, but i suspect nominum would prefer to sell and support ANS/CNS than just support BIND9. > And he's obsessed with the idea of "The BIND Company" > http://cr.yp.to/djbdns/blurb/bindmoney.html apparently, every political sphere needs an axis of evil to keep it focused. -- Paul Vixie
Re: Blog...
Thanks for the kind words. - ferg -- Bill Woodcock <[EMAIL PROTECTED]> wrote: I have to agree... Paul's been doing an excellent job of picking out the one or two things that really matter each day, and I've found it quite valuable. I think that unlike much of the administrivial chatter on the list lately, and the usual kids-ranting-at-each-other, this has been improving the signal-to-noise ratio quite a bit. -Bill -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://spaces.msn.com/members/fergdawg/
Re: djbdns: An alternative to BIND
On Sat, Apr 09, 2005 at 01:14:14AM -0700, David Conrad wrote: > > Fortunately, if it is a religion, I am agnostic in the BIND vs. DJB war > since I work for a company that has created a product that could be > argued competes with both... :-). Didn't Nominum write BIND9, and doesn't / didn't it provide commercial support for it? I'd think / hope that would give you a slight slant in one direction. My favorite thing about djb is that while he seldom has time to help people who are using his own software (claiming he's too busy or they're too stupid), he seems to have infinite time and patience to troll in forums for the makers of other software (comp.protocols.dns.bind, postfix-users mailing list, etc.). I also think his "my way or the highway" / "doesn't play nice with others" approach affects not just his personal interactions, but his software as well. And he's obsessed with the idea of "The BIND Company" http://cr.yp.to/djbdns/blurb/bindmoney.html w
Re: djbdns: An alternative to BIND
* [EMAIL PROTECTED] (David Conrad) [Sat 09 Apr 2005, 10:14 CEST]: [..] > PowerDNS: Yes (authoritative only) [..] > (I might have gotten some of these wrong) You are - PowerDNS has pdns_recursor and has for quite a while. Uses less memory than BIND and is faster too. Potential conflict of interest: I know the author personally (and he's a truly nice guy). -- Niels. -- The idle mind is the devil's playground
Re: books every network operator should read?
Blueprints for High Availability Ewan Stern & Hal Marcus John Wiley & Sons . High Availability Network Fundamentals Chris Oggerino Cisco Press Fundamental readings for those 24x7 guys. Abraços, Marlon Borba, CISSP. "Você prefere sua estabilidade hoje ou sua felicidade amanhã?" --Max Gehringer, na CBN. >>> Kim Onnel <[EMAIL PROTECTED]> 04/09/05 6:55 AM >>> Internet Routing Arch. [...]
Re: books every network operator should read?
Internet Routing Arch. Routing TCP/IP vol.1 Cisco LAN Switching or Any other LAN switching book Troubleshooting Routing Protocols by Zaheer Aziz Cisco ISP essentials Some chapters of "IOS software Arch" On Apr 9, 2005 6:36 AM, Janet Sullivan <[EMAIL PROTECTED]> wrote: > > I'd like to make a list for the BGP4.net wiki of books that are thought > highly of by the network community. What books stand out for you as > being excellent? If you could only own 5 network related books, what > would they be? > > Feel free to reply to me offlist - I'll post a summary after a few days. > > Thanks! > > Janet >
Re: djbdns: An alternative to BIND
On Apr 8, 2005, at 5:43 PM, Niek wrote: On 4/9/2005 1:50 AM +0100, Paul Vixie wrote: Count Server Software [snip some list] One could also put together a list based on: This actually would be an interesting list. Unfortunately, the criteria you provide are a bit hard to come up with reasonable answers for. Specifically: - Security holes. What do you count as a "security hole"? BINDv9 is a completely different code base than BINDv4 or BINDv8. Should security holes in earlier versions of BIND count against BINDv9? Since tinyDNS requires the use of rsync (or similar) to transfer zone data to secondaries, should security issues in that package count against tinyDNS? How about syslog? - Amount of code Again, what should be counted? Should you include rsync? Should you include utility programs like check-namedconf, axfr-get, rbldns, walldns, walldns-conf, etc.? - Bloatness What's one person's bloat is another's fundamental requirement. BIND, since it tries to be a reference implementation of the DNS protocols, includes pretty much everything the IETF standardizes on. DJBDNS doesn't attempt to be a reference implementation, so many of the features and/or functionality available in BIND are simply not there. BIND has a very long history of features and functionality that have been added as a result of operational experience, e.g., BIND's logging system, blackhole functionality, views, etc. DJBDNS relies on external programs to meet these operational requirements (of some). - Seperation of functionality An easy and objectively verifiable one: BIND4, 8, 9: No. DJBDNS: Yes. To add some others: Microsoft DNS: No. MaraDNS: No. NSD: Yes (authoritative only) PowerDNS: Yes (authoritative only) Posadis: No. MyDNS: Yes (authoritative only) (I might have gotten some of these wrong) - # of seconds it takes to load huge amounts of zones Another easy and objectively verifiable criteria. DJBDNS is faster in loading huge amounts of zones. Of course, one could argue that loading huge amounts of data is not something you'd typically want to do, so optimization should be spent in what a DNS server does do frequently (i.e., answer DNS queries) but that could be a value judgment. In the end, it all comes down to religion: Bind people don't ack djb points and vice versa. Actually, I don't believe this is true. There are a wide variety of objectively verifiable metrics folks can use to determine which DNS server best meets their needs. Throughput (queries per second), latency, forwarding time, standards compliance, data load times (many zones, big zones), stability/reliability (how often does it crash), availability (how often does it takes naps), memory consumption, CPU consumption, etc. Fortunately, if it is a religion, I am agnostic in the BIND vs. DJB war since I work for a company that has created a product that could be argued competes with both... :-). Rgds, -drc
Re: djbdns: An alternative to BIND
On Fri, Apr 08, 2005 at 03:55:15PM -0700, Vicky Rode <[EMAIL PROTECTED]> wrote a message of 20 lines which said: > Just wondering how many have transitioned to djbdns from bind If transitioning from BIND, why go to the non-free and non-compliant djbdns instead of nsd (http://www.nlnetlabs.nl/nsd/)? One of the (many, many) annoying things about djbware is the constant claim that djbware is the only challenger to "reference" software.
Re: djbdns: An alternative to BIND
> > > I had a play with DJBDNS after using BIND for years. Here's why I > > > switched back: > > > - No AXFR support > > It supports this. > > No IXFR, no automatic notification of bind slaves (you get to run a > separate notify script) ... > > But yes, it is far easier to use, consumes very low amounts of memory > and makes an excellent local resolver cache e&oe no roundrobin DNS > without a patch (as in it returns all the A records in the same order > every time, whereas bind does this in a different order ...) A contrary view from the trenches: Around a year ago we tested DJB dnscache as the recursive DNS server in a high-volume ISP environment - mostly because we were not happy with BIND 9 performance at the time. Our conclusions were: - dnscache used *more* CPU than BIND 9 in our environment, effectively ruling it out - Not possible to get dnscache to listen to more than one IP address unless you introduce hacks/patches - Weird failures reported from users - Annoying installation process with lots of small programs that we don't want or need We then used BIND 8 for a while, due to its better performance than BIND 9. Earlier this year we finally found a BIND 9 configuration and version that worked well for us (but still too low performance). We finally switched to Nominum CNS (two servers) and one BIND 9 server as backup. We really like Nominum CNS, and we're happy. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
