Domain: nominum.com
Stories and comments across the archive that link to nominum.com.
Comments · 18
-
Hmm. What's Vixie say?
I predict some pacing up and down the halls and maybe a bit of hand waving in the near future.
http://www.nominum.com/company/advisory_board_vixie.php
"Today, Paul is considered the primary modern author and technical architect of BINDv8 the Berkeley Internet Name Domain Version 8, the open source reference implementation of the Domain Name System (DNS). He formed the Internet Software Consortium (ISC) in 1994, and now acts as Chairman of its Board of Directors. The ISC reflects Paul's commitment to developing and maintaining production quality open source reference implementations of core Internet protocols."https://www.isc.org/about/leadership
President Paul Vixie
"Internet Systems Consortium, Inc. (ISC) is proud to be the producer and distributor of commercial quality Open Source software for the Internet Community" (read: BIND, among other things.) -
These incompetents...
... are giving lectures about security but can't even configure properly their own webserver (notice the Notice). What a bunch of losers...
-
Re:NLnet Labs software
Let's just compare the performance, reliability, scalability, and security between Nominum's products and NSD and Unbound. For the moment, have a look specifically at Wouter's presentation from RIPE a year and a half ago for a beta version of Unbound, which show it handling double the number of queries per second of PowerDNS and Bind9 (start at page 11). We're now at version 1.3.3, and I've got an entry-level 1u Xeon server that will handle about 10kqps before slowing down with an Unbound config that took me all of an hour to learn, configure, and tune for optimum performance.
BTW, credit where credit is due, I've got to say thanks to Nominum for open-sourcing their DNS performance testing tools, which was what I used to test my Unbound setup. I think this marking campaign is a result of the right hand not knowing what the left hand is doing, as PowerDNS et. al. were not created in a vacuum and certainly rely on open-source libraries for various things.
This is a troll? The cluefulness ratio here has gone down so far...
-
Re:BIND is past it's sell-by date.
The issue at hand is not how well BIND performs or how easy it is to use, but how SECURE it is.
IME, older software that has been battered by attackers (like BIND or sendmail) is a lot less likely to have critical unpatched vulnerabilities because it's been around so long. The biggest problem is using an old version, and Nomium wouldn't solve that problem. Sure, you could replace the old legacy system with their new crap, but if you just built a NEW system using new version you'd accomplish the same thing.
I do not think that either open source or commercial software has a clear advantage in terms of security, generally speaking. Having said that, I think in this case they'd have a very tough time arguing that their commercial product with FAR fewer eyes on it is inherently more secure. Nomium is not Microsoft, they do not have hundreds of QA staff.
This is assuming that SKYE isn't just a knockoff of BIND, which is likely since the staff at Nomium are all BIND veterans. They are actually complaining about their own software here.
http://www.nominum.com/news/press/2000/nominum_releases_bind_9.php -
NLnet Labs software
Let's just compare the performance, reliability, scalability, and security between Nominum's products and NSD and Unbound. For the moment, have a look specifically at Wouter's presentation from RIPE a year and a half ago for a beta version of Unbound, which show it handling double the number of queries per second of PowerDNS and Bind9 (start at page 11). We're now at version 1.3.3, and I've got an entry-level 1u Xeon server that will handle about 10kqps before slowing down with an Unbound config that took me all of an hour to learn, configure, and tune for optimum performance.
BTW, credit where credit is due, I've got to say thanks to Nominum for open-sourcing their DNS performance testing tools, which was what I used to test my Unbound setup. I think this marking campaign is a result of the right hand not knowing what the left hand is doing, as PowerDNS et. al. were not created in a vacuum and certainly rely on open-source libraries for various things.
-
Nominum ANS
I know your post was asking more about hosted DNS solutions, but if you have a budget to do it right, take a look at Nominum ANS. Has a great SOAP API and supports zone templates.
-
DNS is a big problem and it's getting biggerHi,
DNS is one of the bottlenecks to come. For nearly every ISP, DNS traffic grows faster than the overall traffic.
i'm doing a lot of consulting for large ISPs on DNS problems. BIND is good for small and medium ISPs but bad for large ones (as resolver, as primary or secondary nameserver).
It doesn't work very well with Cache above 1GB and the multithreading is not very efficent. Startup (for servers with 100K zones) is very slow, restart (after changing the configuration) is risky if you decreased the number of masters for a secondary zone (core dump). The readability of the code is far from perfect and it doesn't seperate different functions very well (e.g. you cannot easily replace the caching algorithm). The handling of slow or dead servers could be improved too...
So, i personaly welcome the new contender in the OSS nameserver arena
;-). Let the games begin...The best results (up today) i got with Nominum ANS and CNS. It's neither FOSS nor cheap but really, really fast. We replaced at one customer 4 overloaded BIND systems (3 Ghz Dual Xeon, 4GB RAM, 2 BIND processes per system) with CNS on the same hardware (but only 2 systems) and the load barely reached 10%.
Sincerely yours, Martin
-
Re:which BIND do you mean?
But do not tar all versions of BIND with a single brush. They weren't created equal, and they're not equal now. (Paul Vixie, ISC who has to sign his
/. posts because some people might not know what the l33t mibh account name means)
Instead, you should tar BIND9 separately and even more so than the previous versions. Why?
Because the commercial company that developed "BIND9" immediately turned around and wrote a better performing and more secure closed source commercial server after learning from the mistakes they made writing BIND versions X.Y-9.Z (despite what Vixie says about it being _all_ different developers for BIND9).
One of the most telling and hilariously ironic things about the better-than-BIND server written by the guys who wrote "the bestest newest" BIND server is that they use completely separate programs for authoritative and caching DNS servers - you know just like DJB was designed from the start (and BIND people have bashed incessantly) Why didn't they do that when they did the uber rewrite of BIND for v9?
Paul Vixie is Marc Fluery - he just hides it better, but be assured everything he does is about money, power and control - how about full disclosure of the money flow to/from Vixie/Nominum/ISC? Yeah, I thought not.
http://www.nominum.com/getFile.php?file=nominum_ds_cns.pdf
[these guys have balls, talking shit about code they wrote themselves on contract for ISC]
Attacks exploiting BIND's well-known weaknesses
don't affect any of Nominum's DNS servers, which
are based on completely separate source code.
With many times the throughput of BIND-based
name servers, Nominum's Foundation Caching
Name Servers are significantly more robust than
BIND servers and are able to withstand the
increased query loads generated by denial of service
attacks or virus-infected systems.
A Response Validation feature screens out
malformed or malicious DNS packets, protecting
systems from attacks directed at DNS resolver
libraries.
Nominum's Foundation Caching Name Server
operates within predefined memory constraints
regardless of the number of requests it
receives, thus eliminating a common source
of name-server outages. -
Re:Nice in theory...
-
Re:BIND "okay"?
"Not connected to the internet", then? BIND is notorious for remote root exploits. This by you is "okay"?
Do you mean BIND 8 or BIND 9? Looking at your google query, I see about four different hits that actually have to do with BIND, and they're all about BIND 8, and they are all the same root exploit, not four different root exploits. Along with them is a root exploit for tcpdump - are you proposing that we stop using tcpdump as well?
Seriously, if you want an open source name server, BIND 9 is an amazingly high-quality piece of software. I've never used djb's software, because I hate managing patch trees, and because I like BIND 9's automatic, secure zone transfers, which aren't supported by djbdns. Perhaps there is some value in it, but it's not worth it to me. Also, the cult of personality implicit in naming a product after yourself upsets my stomach. Should I have called the ISC DHCP server tedhcp?
If you are running BIND 8 because BIND 9 doesn't perform as well, first of all, the difference probably isn't as great as you've been led to believe. Secondly, you can probably afford a high-quality commercial name server, such as the one my employer makes. Personally I don't think running BIND 8 is worth the headaches - it was a credible piece of software in the early days, but by the time version 8 rolled around, it was due for a rewrite, and that's why the ISC in fact completely rewrote it from scratch for version 9. -
http://66.35.250.150 anyone?
Many thanks to Paul Vixie, who's biography can be found here , and accomplishments include:
- technical architect of DNS/BIND
- founder of the ISC (Internet Software Consortium)
- cofounder of MAPS (blackhole)
- CIX router ace & CIX-W maintainer
and many others.
-
Re:Why is a profit-company in such a central role?
I've long since wondered why a non-profit like the FSF or ISC didn't create an alternate CA.
I don't know if I trust Paul Vixie much more than Verisign - create *BL's have tons of people freely contribute, then turn it pay only access. You want BIND support, contract with these people who aren't us ;) ISC == Nominum What about the "pay to get security updates about BIND before the general public fiasco". one blurb hereUse our buddies/related companies for mailing list management or we mark you as a spammer.
Accussations and some evidence that they were blackholing routes from the antispammers down under. Alot of questionable stuff, but its bured because of the "good will" from BIND... He seems very dictatorial from what I have seen.
No thanks...
RMS on the other hand, would probably just want it to be called the GNU/DNS system :) -
Re:Did ISS tell bind maintainers?
Actually, no. ISC has known about this for nearly a month. The patches have been available to subscribers of their commercial front, Nominum, for some time now.
-
Re:The alternative is obvious...
Are you completely fucking insane? starting your own DNS based on a DSL line? do you have ANY idea how busy the root servers are?
They AVERAGE 3000 queries per SECOND.
Read RFC 2870 about root nameservers - it'll cost you a lot of money to do something like that. You are talking about a fully loaded clustered pair of 4 processor boxes, HA networking engineering, HA firewalls, etc, etc, and a team of top admins. None of this comes cheap, and don't even think of using linux, you'll want something you can get top tier integrated OS/Hardware support for.
Have a look at the levels of redundancy nominum use for GNS - their DNS service.
Alex -
Re:Why still running on BIND?Post your code. Let people rip it apart. BIND has gotten where it is today because it is still the best open-source solution for the job.
Yes, there are independantly coded closed-source solutions which perform better and presumably are better all around (Nominum has written a program that they use as the basis for their Global Name Service, which does not contain any code from BIND).
However, these are closed-source implementations, and the folks who operate the various root servers are doing so on a volunteer basis, and are not interested in just handing everything over to some company who operates a "black box" -- regardless of who that company is.
Indeed, it's the root server operators that have really spared us from the worst of the damage that ICANN has tried to inflict upon us. For the stupidest things, the root server operators simply said "Not only NO, but HELL NO!", and ICANN was forced to back down.
-
Nominum Global Name Service?Folks,
At this point, I wouldn't consider doing anything without checking with Nominum (the company responsible for writing and maintaining BIND version 9).
These guys offer a service whereby they provide either primary or secondary nameservice for your domain, across their distributed cluster of redundant, fault-tolerant servers. Heck, the secondary service is even free (in all the various senses of the word).
I just wish they had a Dynamic DNS service, so that we could all kiss DynDNS.org and GraniteCanyon.com farewell for their incredibly crappy service.
--
Brad Knowles -
Re:Release notes?
Found 'em - ISC has the release notes up now. They also have the BIND 9 Administrator's Reference available as a pdf; though it looks like the same docs come with the distribution in html & man format.
-
DNS DoS - the need for scalabilityA poster asks:
Just from a theretical point of view, how difficult do you think it would be to take those servers down from terrorist activity. I mean could the internet be taken down if 12 explosions at the right time/place where detonated?Stripes starts his reply:
Assuming you can figure out where they all are form the IP addresses in the root.cache file, and traceroute, or other similar tools, and maybe a bit of social engenering, it shouldn't be any harder then any other 12 randomly selected machines.Define "explosions"
Stripes, The poster to which you responded did not specify what type of explosions were available to them. If they're nuclear explosions, they'd probably need only 8-10 strategically placed explosions to wipe out all of the current neameservers (with or without social engineering). If they're lucky, they might take out the "shadow root servers" as well. Given the location of some of the root servers, they'd probably cripple alot more than just DNS. They'd effectively take out a good deal of infrastructure as well as the Internet engineers necessary to repair it, not to mention start a worldwide panic.
The Internet would still recover though, much as you described in your post. Anyone can setup a redundant server cluster within a matter of minutes given a set of pre-staged root and first level zone data.
The more interesting problems are due to corrupted data rather than doing denial of service attacks on nameservers. Some bad data in Network Solution's database can make various interesting parts of the Internet suck really bad. When one root server has data corruption, the whole net feels it. Imagine if some NSOL staffer garbled the nameserver data for "Yahoo.COM." or "IN-ADDR.ARPA." to point to 255.255.255.255 instead of the real servers?
For anyone else interested in DNS DoS...
An easier method
One of the easiest way to kill DNS is to try a coordinated DoS attack against all of the nameservers. Each of the world hundreds of thousands of resolvers is configured to use any of 13 root nameservers. Just like a 15-year-old kid did with HTTP requests, one could probably start a distributed DoS attack against DNS. The "heftiest" root nameserver is rumored somewhere in this discussion to be able to handle 6000-8000 hits a second. With 13 published nameservers, one needs only about 100000 hits per second to saturate the current capacity of all of the servers. Let's say that I was a bright hacker (which I'm not) that I could find my way into 1000 machines around the world that each had a T1 connection or better. Can we agree that this is a difficult but not unreasonably impossible thing to do? If one were not smart enough to do it themselves, one could perhaps go to a hacker convention or local user group and bribe a script kiddie seeking infamy and fortune to go forth an find 1000 machines to hack. Another way is to unleash a time-dated virus onto the net that will do your bidding at a specific time. Each machine would gather a list of 100 addresses, perhaps starting with the history file of a user's browser to get a list of second-level domains. It could also look for addresses using a popular portal directory or search engine and interpret results to get domain names. With 100 domain names, it would query 100 names per second (less than one megabit) from each of the few registered root nmeservers. While the traffic isn't overwhelming, it will overload the root servers fo rthe number of transactions per second, and nothing short of hunting and killing half of the query servers would reduce the effectiveness of the attack. To make the attack harder to stop, one could double or quadruple the number of query servers or use methods of masquerading your attack (I won't go into detail here) to keep network administrators from being able to shut down query servers. Another way to scale the attack is to use they heavier TCP protocol for most of the queries instead of the lightweight UDP.
fin.
The technology needed to exponentially increase the ability of the root servers to perform is not out of reach. With the proper motivation (a DoS like I described), one million dollars of capital (compare $1m to the current valuation of NSOL), and perhaps 30 man-weeks of time, one can make a farm of servers able to handle two orders of magnitude more requests than the current set of servers.
The IBM server announcement by Network Solutions disappoints me. It's sad.
Any of the following are good candidates that I know about for scalably solving root DNS infrastructure problems...
- UltraDNS - DNS service provider with an interesting spin on distributed scalability
- Nominum - the knowledge and knowhow to make fast scalable DNS servers and software
- Akamai/Sandpiper - a distributed operations infrastructure onto which one can install root clusters.
One can also implement interesting filters on such a proxy server to reduce the effect of stupider resolvers or lame DoS attacks.
--
Eric ZiegastPS: Slashdot probably isn't the best forum for this, but if you know a better forum, feel free to point them toward this post.