Slashdot Mirror

... is what could result, because cnn.com is not compliant.

Testing completed:
cnn.com: Minor problems detected!

This domain is going to work after the 2019 DNS flag day BUT it does not support the latest DNS standards. As a consequence this domain cannot support the latest security features and might be an easier target for network attackers than necessary, and might face other issues later on. We recommend your domain administrator to fix issues listed in the following
technical report https://ednscomp.isc.org/ednsc...

https://ednscomp.isc.org/ednsc...

... is what could result, because cnn.com is not compliant.

Testing completed:
cnn.com: Minor problems detected!

This domain is going to work after the 2019 DNS flag day BUT it does not support the latest DNS standards. As a consequence this domain cannot support the latest security features and might be an easier target for network attackers than necessary, and might face other issues later on. We recommend your domain administrator to fix issues listed in the following
technical report https://ednscomp.isc.org/ednsc...

https://ednscomp.isc.org/ednsc...

Amazon can't do DNS (Amazon's Route 53 servers deliberately break EDNS version negotiation by not answering non EDNS version 0 queries), how do you expect them to do IPv6?

No it isn't.

DNS running locally is kept up to date in patches, it is not a security issue. DNS uses less resources and speeds your browsing, leading to more power savings. Why would you setup a separate system? https://www.isc.org/downloads/ The need for the locally setup DNS is the exact same need as the need for your terrible hosts file, so that argument is silly. Keep reaching and moving the goal posts.

due to your LIMITED MENTALLY DAMAGED GOOD ASSBURGERS BRAIN being only able to hold 1 of MANY variable factors in play @ a time

Stay classy.

(sub 4% of the time ONLY for me due to hardcoded favorites in hosts @ the TOP of it cached in RAM locally)? Adblocking gains me back lookup speeds if a total miss & I have to hit DNS remotely.

You mean the same ad blocking you gain with a local dns setup with the same entries? Or did your ability to hold onto only one variable catch you again?

It's unclear whether most of the FUD in this discussion is directed at the GPL itself or specifically v3. But it's entirely unfounded.

It's not FUD, and its about the GPL in general - although being GPL3 makes it worse. "GPL2 or later" would have been a better (but still flawed) choice.

You know why libraries aren't generally licensed GPL, right? Anything that links to them has to have the exact same license as the library. For instance, the GPL2 licensed Inkscape can't use this library.

That's the difference between the GPL and the LGPL. You can link to LGPL libraries from any software; you can only link to GPL licensed libraries from code with the same version of the GPL.

In RMS' ideal world, all software would move to the latest GPL and it wouldn't be a problem. Good luck convincing these guys of that.

This is the appropriate license for this image format.

The GPL is not the appropriate license for any general-purpose library. That's what the LGPL is for. Or, like most reference implementations, a non-copyleft license like the MIT license.

Look, I get it, you're a promoter of software freedom. So am I. But this is the real world, and this is a reference implementation. There are conventions to follow for reference implementations, and an OSS non-copyleft license is one of those conventions. This image format could outperform every other format on the planet and it will still see no adoption outside of academia unless there's a compatibly licensed library available. Unless it gets relicensed, or someone writes a non-GPL library, this will go down as just another interesting format that sees no adoption whatsoever.

There is a browser perfect for you!

http://lynx.isc.org/current/

Firefux will crash 10x as previous version so what little use Firefux had it will have none now and it is up there with Fuckle Chrap and Internet Exploder. Stick with Lynx as it is the most stable and lightweight browser there is plus there is no way a script-kiddie can break into it since it doesn't execute code at all.

And you evidence for this is what? That name runs sanity checks on the function arguments then dies if it finds that the contract is not met? If system integrators did what Apple did and run named from launchd or the equivalent, which restarts named on unexpected terminations, there would be almost no advisories as the availability impact would go from complete (7.8) to partial (5.0) with even the easiest denial of service flaws and drops down still further to 4.3 or 2.6 with the more complicated ones. However the assumption is that there is nothing restarting named so a advisory with a 7.8, 7.1 or 5.4 score is issued.

Please go read the descriptions in the advisories at BIND-9-Security-Vulnerability-Matrix then ask yourself do you want software written by people who know they are human so mistakes will be made and therefor check for them or software that assumes that everything will always be correct and continues of regardless of the garbage arguments it has been given.

bind reads /etc/hosts.

Are you sure about that?

The source code is available here.
As far as I can tell, all references to "/etc/hosts" are in comments, not code.

I truly dislike Web-based forums. They require the user to connect to a specific Web site, which is sometimes down. Although Facebook is rarely down, a forum based there requires users to have Facebook accounts; similar requirements exist for other forum hosting services. Threaded discussions are often difficult to follow on Web-based forums, and threads usually cannot be sorted (both are also problems with mailing lists). To find a specific topic or thread, the user must use the forum's own search capability, which is too often rudimentary and insufficient for real-world use. Then, there is the fact that some Web-based forums work well only with certain browsers.

I much prefer the newsgroups hosted by NNTP (network news transfer protocol) servers. There are several NNTP service providers (NSPs), both free and paid; users only have to use one NSP to participate even when other users use other NSPs. That is, users are not required to connect and login to any one specific site.

A number of different NNTP applications also exist, mostly freeware. Those applications generally handle threaded discussions quite well. Search capabilities are built into the applications and are not needed for the newsgroup itself. If spam, flame wars, trolls, and other problems are a concern, a moderated newsgroup is also possible.

If your topic is limited, I would suggest creating an alt.* newsgroup. See the text document at http://ftp.isc.org/pub/usenet/CONFIG/README. However, many NSPs no longer host alt.* newsgroups because so many of them contained child pornography.

If your topic might have broad public appeal, you might consider creating a newsgroup under one of comp.*, news.*, sci.*, humanities.*, rec.*, soc.*, talk.*, or misc.*. See http://www.big-8.org/wiki/Main_Page.

A moderated newsgroup can have more than a single moderator, which would be appropriate if your forum is not related to your own personal Web site. See http://www.eyrie.org/~eagle/faqs/mod-pitfalls.html for the negatives of moderated newsgroups. The "Moderator's Handbook" at http://www.eyrie.org/~eagle/usefor/other/moderators-handbook is quite old but still useful. See also http://www.big-8.org/wiki/Changing_Moderation_Status.

They are a non-profit organization whose sole purpose is to support the infrastructure of the Internet. They build open-source software (like BIND and implementations of DHCP). Sorry, but you really should research before you spout off.

Not to mention running the F root name server. They really know DNS.

Off the top of my head, I can think of only a few organizations in the world who have the know-how and ability to run a large-scale DNS system properly. ISC is at the top of that list. IMHO, the FBI chose wisely.

Exactly. We know we never have to worry about a private corporation using personal data for profit, right? And no company would ever play ball with the feds in return for a juicy government contract. And its a good things they have a good reputation. I mean, someday companies might even have to start hiring PR people and the like to try to hide the evil things they do behind a good reputation.

Who said anything about a private corporation. Do you know what ISC IS?

They are a non-profit organization whose sole purpose is to support the infrastructure of the Internet. They build open-source software (like BIND and implementations of DHCP). Sorry, but you really should research before you spout off.

"And browsing through the results pages is very much unlike a CLI."

I use Lynx, you insensitive clod.

The distillation of it is to use Google's DNS, or some other public DNS system.

Of course, the best answer if you are sensitive to this kind of thing is to run your own resolver, which isn't all that hard.

Since this is about BIND, let me start the inevitable thread about the BIND alternatives.

BIND is the swiss army knife of DNS servers. It has a lot of features and can do pretty much everything. It's also a big binary and sometimes difficult to configure. CVE

Unbound and NSD are a suite of DNS servers from the same people. One (NSD) puts your web page on the Internet; the other (Unbound) looks for web pages on the Internet. NSD CVE Unbound CVE

PowerDNS (which like Unbound/NSD, is two separate programs) has a lot of flexibility with connecting to databases or what not to resolve a DNS name. Used by Wikimedia, among others. CVE

MaraDNS. I think it's the best one, but my opinion is a little biased. It was once a single program, now two separate programs (like Unbound/BSD and PowerDNS) Easy-to-configure; tiny binary suitable for embedded systems. CVE

DjbDNS. Great tiny two-program DNS suite. Hasn't been updated since 2001 and yes, it has security problems (I'm already taking bets that a follow-up to this post will pretend DjbDNS is magically perfectly secure). Zinq is a currently maintained unofficial fork.

There are many many other DNS servers, both open source and non-open source. Rick Moen has a great list of the open-source ones

There has not been a single remote-root exploit in BIND9 since it was offered up to the world circa 2001. It was a complete rewrite with new goals, so taking BIND 4.x or BIND 8.x as examples isn't really relevant.

ISC is also completely open about security issues, listing them all on the web site and registering them with the CVE Registry.

As I stated in another post, the goal of BIND9 was use use various constructs (like assertions) to check data integrity, where possible on the fly and where not practical in a way that causes a core dump. That to fail safe was the best option, and crashing in a way the bug could be fixed was a positive. If you view the advisories against BIND9 you'll see that strategy has worked very well. Of course there's no reason not to lock any application in a VM, jail, chroot or whatever to get additional security, but I think the track record of BIND9 compared to most other major open source software is decent.

BIND is also "full featured". Many of the folks here reference alternatives like NSD, tinyDNS, or Unbound which provide limited functionality compared to BIND. Obviously if you're willing to limit the functionality you limit the bug exposure, but that's true both if you use software that doesn't include the functionality but also if you disable that functionality in BIND. For instance the bug in question affects recursive resolvers only, if your BIND9 instance is an authority only configuration there is no exposure.

I'm afraid most of BIND's bad reputation comes from BIND 4.x and BIND 8.x, both of which were quite bad (for different reasons). BIND9 was a departure, and now ISC is working on BIND 10, which should be yet another large leap forward.

There has not been a single remote-root exploit in BIND9 since it was offered up to the world circa 2001. It was a complete rewrite with new goals, so taking BIND 4.x or BIND 8.x as examples isn't really relevant.

ISC is also completely open about security issues, listing them all on the web site and registering them with the CVE Registry.

As I stated in another post, the goal of BIND9 was use use various constructs (like assertions) to check data integrity, where possible on the fly and where not practical in a way that causes a core dump. That to fail safe was the best option, and crashing in a way the bug could be fixed was a positive. If you view the advisories against BIND9 you'll see that strategy has worked very well. Of course there's no reason not to lock any application in a VM, jail, chroot or whatever to get additional security, but I think the track record of BIND9 compared to most other major open source software is decent.

BIND is also "full featured". Many of the folks here reference alternatives like NSD, tinyDNS, or Unbound which provide limited functionality compared to BIND. Obviously if you're willing to limit the functionality you limit the bug exposure, but that's true both if you use software that doesn't include the functionality but also if you disable that functionality in BIND. For instance the bug in question affects recursive resolvers only, if your BIND9 instance is an authority only configuration there is no exposure.

I'm afraid most of BIND's bad reputation comes from BIND 4.x and BIND 8.x, both of which were quite bad (for different reasons). BIND9 was a departure, and now ISC is working on BIND 10, which should be yet another large leap forward.

I also think the characterization as a "0-day" isn't quite right.

Download Bind by Specific Version shows 9 was released 2004-Jan-28 07:05:51.

0-day used to mean that the exploit was release the day of release. Verses 1-day or later cracks.

Now it's just another throwaway term for exploit. And a very silly one at that.

(To be fair, it could be a problem with the last release from November 9th, 2011. I did not regression test this.)

I'm not sure how to square large production name servers with "generalist deployments". Clearly the small admin can do without a support contract. However I've seen large ISP's, supplying service to millions of customers with no support, and I think that's insane.

If you go back to ISC's Software Support page you'll notice "Advance Security Notifications". Depending on the nature of the issue, ISC's support customers often receive notification before BIND-announce. I believe this particular issue went out in all forums pretty much at the same time due to the severity, but lesser issues may be released in a staged fashion.

I am 100% with you up until you say, "I'm amazed how many people run large, production name servers on BIND yet don't have a cheap support contract. If you run BIND, rather than getting your alerts via /. look into a support contract so you get them directly from the vendor." I have a couple issues with this. The first is simply that it's perfectly reasonable to expect a good UNIX admin to handle BIND without issue for generalist deployments. The other issue I have is that you don't need a support contract to get these alerts. Sign up for the bind-announce mailing list (link: https://lists.isc.org/mailman/listinfo/bind-announce). Again, I'm totally with you up until the end there.

BIND is written by Internet Systems Consortium aka ISC, a non-profit that does various public benefit things for the Internet. The summary links to an alert from the Internet Storm Center aka ISC, a project of the SANS Technology Institute. There is no relation between these two ISC's, in this case the first authors the software, and the second tracks vulnerabilities. I'm sure by using a link to SANS many people on /. who are not familiar with these two ISC's will get them confused.

The link in the summary also goes to a preliminary version of the advisory. The correct, full summary is available on Internet Systems Consortium's web site as CVE-2011-4313.

I also think the characterization as a "0-day" isn't quite right. To me at least a 0-day issue is a bug that can exploited to do something, and that is used by bad-actors before the vendor is aware and able to fix the issue. In this case the bug simply crashes the server; there's no remote root or other exploit, and at this time there is no evidence of bad-actors using this bug at all. Rather it appears something interesting (unusual, perhaps put there intentionally) appeared in the DNS, and it triggered a bug in the software.

Some historical context may help. BIND8, for those who used it, was a pile of poo. It had a huge number of security issues and other problems and was generally a nightmare for sysadmins. Many people stayed on BIND 4.9.x for a very long time because of the issues in BIND8. When ISC launched BIND9, they wanted to change this perception. The action relevant to this bug is that BIND9 was designed to be full of assertions and other checks in the code. The goal was to catch any badness early, and if it was uncorrectable crash in a predictable way. The thought was that crashing with a core dump where you can fix the problem is far better than running off with bad data that could eventually be used in some sort of remote-root exploit.

This issue is sort of the payoff of that philosophy. Rather than taking this bad data and giving a remote hacker access to the machine BIND9 caught it with an assert, logs a useful message and core dumps. This is a big part of why 0-day leaves the wrong impression with me, "denial of service vector" seems to perhaps be a more accurate description. Sure, we could have a lively debate about if crashing is preferred or not, but I think most of the administrators who lived through BIND8 prefer the BIND9 procedures.

Internet Software Consortium also offers support for BIND (and DHCP). I'm amazed how many people run large, production name servers on BIND yet don't have a cheap support contract. If you run BIND, rather than getting your alerts via /. look into a support contract so you get them directly from the vendor.

BIND is written by Internet Systems Consortium aka ISC, a non-profit that does various public benefit things for the Internet. The summary links to an alert from the Internet Storm Center aka ISC, a project of the SANS Technology Institute. There is no relation between these two ISC's, in this case the first authors the software, and the second tracks vulnerabilities. I'm sure by using a link to SANS many people on /. who are not familiar with these two ISC's will get them confused.

The link in the summary also goes to a preliminary version of the advisory. The correct, full summary is available on Internet Systems Consortium's web site as CVE-2011-4313.

I also think the characterization as a "0-day" isn't quite right. To me at least a 0-day issue is a bug that can exploited to do something, and that is used by bad-actors before the vendor is aware and able to fix the issue. In this case the bug simply crashes the server; there's no remote root or other exploit, and at this time there is no evidence of bad-actors using this bug at all. Rather it appears something interesting (unusual, perhaps put there intentionally) appeared in the DNS, and it triggered a bug in the software.

Some historical context may help. BIND8, for those who used it, was a pile of poo. It had a huge number of security issues and other problems and was generally a nightmare for sysadmins. Many people stayed on BIND 4.9.x for a very long time because of the issues in BIND8. When ISC launched BIND9, they wanted to change this perception. The action relevant to this bug is that BIND9 was designed to be full of assertions and other checks in the code. The goal was to catch any badness early, and if it was uncorrectable crash in a predictable way. The thought was that crashing with a core dump where you can fix the problem is far better than running off with bad data that could eventually be used in some sort of remote-root exploit.

This issue is sort of the payoff of that philosophy. Rather than taking this bad data and giving a remote hacker access to the machine BIND9 caught it with an assert, logs a useful message and core dumps. This is a big part of why 0-day leaves the wrong impression with me, "denial of service vector" seems to perhaps be a more accurate description. Sure, we could have a lively debate about if crashing is preferred or not, but I think most of the administrators who lived through BIND8 prefer the BIND9 procedures.

Internet Software Consortium also offers support for BIND (and DHCP). I'm amazed how many people run large, production name servers on BIND yet don't have a cheap support contract. If you run BIND, rather than getting your alerts via /. look into a support contract so you get them directly from the vendor.

BIND is written by Internet Systems Consortium aka ISC, a non-profit that does various public benefit things for the Internet. The summary links to an alert from the Internet Storm Center aka ISC, a project of the SANS Technology Institute. There is no relation between these two ISC's, in this case the first authors the software, and the second tracks vulnerabilities. I'm sure by using a link to SANS many people on /. who are not familiar with these two ISC's will get them confused.

The link in the summary also goes to a preliminary version of the advisory. The correct, full summary is available on Internet Systems Consortium's web site as CVE-2011-4313.

I also think the characterization as a "0-day" isn't quite right. To me at least a 0-day issue is a bug that can exploited to do something, and that is used by bad-actors before the vendor is aware and able to fix the issue. In this case the bug simply crashes the server; there's no remote root or other exploit, and at this time there is no evidence of bad-actors using this bug at all. Rather it appears something interesting (unusual, perhaps put there intentionally) appeared in the DNS, and it triggered a bug in the software.

Some historical context may help. BIND8, for those who used it, was a pile of poo. It had a huge number of security issues and other problems and was generally a nightmare for sysadmins. Many people stayed on BIND 4.9.x for a very long time because of the issues in BIND8. When ISC launched BIND9, they wanted to change this perception. The action relevant to this bug is that BIND9 was designed to be full of assertions and other checks in the code. The goal was to catch any badness early, and if it was uncorrectable crash in a predictable way. The thought was that crashing with a core dump where you can fix the problem is far better than running off with bad data that could eventually be used in some sort of remote-root exploit.

This issue is sort of the payoff of that philosophy. Rather than taking this bad data and giving a remote hacker access to the machine BIND9 caught it with an assert, logs a useful message and core dumps. This is a big part of why 0-day leaves the wrong impression with me, "denial of service vector" seems to perhaps be a more accurate description. Sure, we could have a lively debate about if crashing is preferred or not, but I think most of the administrators who lived through BIND8 prefer the BIND9 procedures.

Internet Software Consortium also offers support for BIND (and DHCP). I'm amazed how many people run large, production name servers on BIND yet don't have a cheap support contract. If you run BIND, rather than getting your alerts via /. look into a support contract so you get them directly from the vendor.

BIND is written by Internet Systems Consortium aka ISC, a non-profit that does various public benefit things for the Internet. The summary links to an alert from the Internet Storm Center aka ISC, a project of the SANS Technology Institute. There is no relation between these two ISC's, in this case the first authors the software, and the second tracks vulnerabilities. I'm sure by using a link to SANS many people on /. who are not familiar with these two ISC's will get them confused.

The link in the summary also goes to a preliminary version of the advisory. The correct, full summary is available on Internet Systems Consortium's web site as CVE-2011-4313.

I also think the characterization as a "0-day" isn't quite right. To me at least a 0-day issue is a bug that can exploited to do something, and that is used by bad-actors before the vendor is aware and able to fix the issue. In this case the bug simply crashes the server; there's no remote root or other exploit, and at this time there is no evidence of bad-actors using this bug at all. Rather it appears something interesting (unusual, perhaps put there intentionally) appeared in the DNS, and it triggered a bug in the software.

Some historical context may help. BIND8, for those who used it, was a pile of poo. It had a huge number of security issues and other problems and was generally a nightmare for sysadmins. Many people stayed on BIND 4.9.x for a very long time because of the issues in BIND8. When ISC launched BIND9, they wanted to change this perception. The action relevant to this bug is that BIND9 was designed to be full of assertions and other checks in the code. The goal was to catch any badness early, and if it was uncorrectable crash in a predictable way. The thought was that crashing with a core dump where you can fix the problem is far better than running off with bad data that could eventually be used in some sort of remote-root exploit.

This issue is sort of the payoff of that philosophy. Rather than taking this bad data and giving a remote hacker access to the machine BIND9 caught it with an assert, logs a useful message and core dumps. This is a big part of why 0-day leaves the wrong impression with me, "denial of service vector" seems to perhaps be a more accurate description. Sure, we could have a lively debate about if crashing is preferred or not, but I think most of the administrators who lived through BIND8 prefer the BIND9 procedures.

Internet Software Consortium also offers support for BIND (and DHCP). I'm amazed how many people run large, production name servers on BIND yet don't have a cheap support contract. If you run BIND, rather than getting your alerts via /. look into a support contract so you get them directly from the vendor.

DNSSEC-based domain validation is an exciting possibility. But I've heard concerns over it:

For the time being, we will make just one remark about this. Many people have been touting DNSSEC PKI as a solution to the problem. While DNSSEC could be an improvement, we do not believe it is the right solution to the TLS security problem. One reason is that the DNS hierarchy is not trustworthy. Countries like the UAE and Tunisia control certificate authorities, and have a history of compromising their citizens' computer security. But these countries also control top-level DNS domains, and could control the DNSSEC entries for those ccTLDs. And the emergence of DNS manipulation by the US government also raises many concerns about whether DNSSEC will be reliable in the future.

Could you address those?

Yeah, I'll give it a shot.

First off "the right solution to the TLS security problem" is a problem. "TLS security" is not a single (the) problem but a multifaceted problem. DNSsec addresses (doesn't totally solve - none do - but does address) one of those facets (tying the cert to the domain owner). The fact that a malicious state level actor controls both DNS (and their ccTLD DNSsec signing) and the certificate authorities just leaves you in almost the same spot except I would argue that DNSsec has a leg up there. Not perfect, but better and more verifiable.

Controlling the CA, they can spoof a MITM certificate claiming to be you. Now, you have to validate all your certificates from an outside point of view. Or they issue the certificate and key to you (bad BAD practice done by many CAs for TLS E-Mail certs - they should NEVER have possession of the private key) and you will never be able to tell if they are abusing your cert or not. That's bad. That's real bad.

With DNSsec, you give them your public key signing key (ksk). They either properly sign it and publish it or they don't. You can verify this in the public DNS (plenty of public query servers and looking glasses and historical sites for DNS - aot site certs where you're on you own). You use your private ksk to that public key to sign your zone signing public keys (zsk) and you publish that public key yourself, which you can then also verify. Then you sign your records with the private key of your zone signing key. All of this should be confirmable from the public DNS but, in the case of a malicious state actor, you may still have to confirm it from an outside view (a looking glass or secure remote server) but you only need to verify that THEY properly published YOUR ksk public key and that they are not blocking DNSsec. You never give them your private key (never underestimate the power of what Bruce Schneier calls "rubber hose cryptography" - they beat the bejesus out of you till you give them the bloody key).

Is it bullet proof? In the face of a malicious state actor, nothing is bullet proof. We can only try to make it tougher for them.

Here you go.

DNSSEC-based domain validation is an exciting possibility. But I've heard concerns over it:

For the time being, we will make just one remark about this. Many people have been touting DNSSEC PKI as a solution to the problem. While DNSSEC could be an improvement, we do not believe it is the right solution to the TLS security problem. One reason is that the DNS hierarchy is not trustworthy. Countries like the UAE and Tunisia control certificate authorities, and have a history of compromising their citizens' computer security. But these countries also control top-level DNS domains, and could control the DNSSEC entries for those ccTLDs. And the emergence of DNS manipulation by the US government also raises many concerns about whether DNSSEC will be reliable in the future.

Could you address those?

Firefox still has four more version until they catch up with Internet Explorer 9, and seven to even match the version might of Google Chrome 12.0.742.105 (not that you can even tell the Chrome version when you download it...). They have blown right by Lynx 2.8.7! The race is on!

Use Lynx, or just turn off Javascript and java. As far as I know, there is no automatic way to install MacDefender without user interaction, but there are ways to be safe if you want to be extra sure. For an extra layer of protection, use a VMWare install or Ubuntu-live cd.

You are absolutely correct. It would not be hard to add a new record type.

A thought for you: http://www.isc.org/software/bind10

ISC are wanting suggestions for what is needed in BIND10, the essentially de-facto DNS server. You might want to put your thoughts together as a single white paper on integrated security and send it to them. You aren't getting much mileage on Slashdot, but you might well provoke some excellent thinking by the people who actually develop DNSSEC and the servers that use it.

Links to other software dealing with the Internet Routing Registry system (some are also given elsewhere):

IRR Toolset: http://www.isc.org/software/irrtoolset
IRRd: http://www.irrd.net/
Routing Registry Consistency Check (a web form, not the source code - pity): http://www.ripe.net/data-tools/projects/current/rrcc

If you want to use this system to construct your own WHOIS database, please see:

ftp://ftp.ripe.net/ripe/dbase/software/

(This is the WHOIS server used by RIPE.)

The information is indeed communicated to leaf nodes.

http://www.isc.org/software/irrtoolset

The Internet Routing Registry Toolset will give you most of the answers you want and the tools to verify the answers the plugin gives.

If you're interested in knowing what it would take to spoof, the obvious place to start would be the Internet Routing Registry daemon. Though you could also look up RFC 2622 as RPSL seems to be the standard protocol.

http://www.irrd.net/

"I want a browser that gives me the most battery life possible."

You want to use Lynx, then.

http://www.kitchenlab.org/www/bmah/Software/pchar/
http://www.isc.org/software/irrtoolset
http://oss.oetiker.ch/mrtg/
http://www.caida.org/tools/

If you want transparency, you can always do it yourself. Why wait for Google? You've a list of tools right there that will tell you who is throttling, when, where, how, by how much, and maybe even what they had for breakfast.

http://www.internettrafficreport.com/main.htm
http://www.internettrafficreport.com/namerica.htm

Then there's the Weather Channel for geeks. That should give you a good indication of "unusual" packet losses, indicative of throttling.

http://www.noc.ucla.edu/weather.html
http://www.cgl.ucsf.edu/weather/weather.html

For more local weather on the tens, there's UCLA and UCSF.

There ya go, and it cost you rather less than the same information is costing Google.

What they are doing is re-inventing the Internet Weather stations that have existed for a decade or so. (Think MRTG but on a much larger scale and with rather more sophisticated output.)

Well, ok, they're maybe adding in the capabilities of the open-source pchar utility, which gives you the packet loss and maximum throughput of every hop between any two points on the net.

Throw in the Internet Routing Registry Toolset and you've a complete system.

Tell you what, if Google is going to give a million bucks for a better-packaged MRTG + pchar + IRRToolset, I'll take the contract. May take me a little while to produce a uniform look-and-feel, clean some of the cruft from pchar, produce useful statistics showing exactly what, where and by how much traffic is being throttled. A week, maybe two, add one more for documentation, and a final one so I can have some R&R in Hawaii...

It's not like Georgia will do any better. It'll probably do a lot worse, take longer to do it, and will likely take side-payments by ISPs to conceal any throttling detected.

(reference https://www.isc.org/software/bind/advisories/cve-2011-0414)

* As Larissa pointed out, this security advisory used ISC's phased disclosure process (see http://www.isc.org/security-vulnerability-disclosure-policy). The US CERT advisory stated they notified ISC on 2011-01-24. This is reversed. US CERT and all other National CSIRT Teams were notified at the same time (Feb 15th). We just recently added the step in our disclosure process to notify all National CSIRT Teams listed on first.org.

* US-CERT threw in the "2011-01-24" thinking the discovery of the vulnerability matched the time we asked for our next batch of CVE numbers. In this case, this vulnerability was discovered by Neustar, who found the initial defect, and JPRS, who built the feasible lab exploits. That was all in Feb 2011, not Jan 2011.

* The "high severity" is based on the CVSS _BASE_ Score of 7.1 (AV:N/AC:M/Au:N/C:N/I:N/A:C). Network operators would use this CVSS base score and then run the Environmental and Temporal Score to get a CVSS actionable score. This is why you saw a low score from US CERT so low. They used their proprietary full metric, which scored it lower. Vendors are encouraged to use CVSS so the operator then takes accountability to gauge the risk specific to their environment.

Check out http://www.first.org/cvss/ for more information on CVSS. ISC has recently started using CVSS for all our security advisories (see http://www.isc.org/announcement/iscs-has-adopted-cvss-our-security-advisories).

* DNS Operational Risk and Reaction to any DNS issue is best addressed via DNS-OARC. If your DNS is critical, I recommend, as a minimum, to sign on to the public BIND forums (see https://lists.isc.org/mailman/listinfo) and the public DNS-OARC forums (see https://www.dns-oarc.net/oarc/services).

(reference https://www.isc.org/software/bind/advisories/cve-2011-0414)

* As Larissa pointed out, this security advisory used ISC's phased disclosure process (see http://www.isc.org/security-vulnerability-disclosure-policy). The US CERT advisory stated they notified ISC on 2011-01-24. This is reversed. US CERT and all other National CSIRT Teams were notified at the same time (Feb 15th). We just recently added the step in our disclosure process to notify all National CSIRT Teams listed on first.org.

* US-CERT threw in the "2011-01-24" thinking the discovery of the vulnerability matched the time we asked for our next batch of CVE numbers. In this case, this vulnerability was discovered by Neustar, who found the initial defect, and JPRS, who built the feasible lab exploits. That was all in Feb 2011, not Jan 2011.

* The "high severity" is based on the CVSS _BASE_ Score of 7.1 (AV:N/AC:M/Au:N/C:N/I:N/A:C). Network operators would use this CVSS base score and then run the Environmental and Temporal Score to get a CVSS actionable score. This is why you saw a low score from US CERT so low. They used their proprietary full metric, which scored it lower. Vendors are encouraged to use CVSS so the operator then takes accountability to gauge the risk specific to their environment.

Check out http://www.first.org/cvss/ for more information on CVSS. ISC has recently started using CVSS for all our security advisories (see http://www.isc.org/announcement/iscs-has-adopted-cvss-our-security-advisories).

* DNS Operational Risk and Reaction to any DNS issue is best addressed via DNS-OARC. If your DNS is critical, I recommend, as a minimum, to sign on to the public BIND forums (see https://lists.isc.org/mailman/listinfo) and the public DNS-OARC forums (see https://www.dns-oarc.net/oarc/services).

(reference https://www.isc.org/software/bind/advisories/cve-2011-0414)

* As Larissa pointed out, this security advisory used ISC's phased disclosure process (see http://www.isc.org/security-vulnerability-disclosure-policy). The US CERT advisory stated they notified ISC on 2011-01-24. This is reversed. US CERT and all other National CSIRT Teams were notified at the same time (Feb 15th). We just recently added the step in our disclosure process to notify all National CSIRT Teams listed on first.org.

* US-CERT threw in the "2011-01-24" thinking the discovery of the vulnerability matched the time we asked for our next batch of CVE numbers. In this case, this vulnerability was discovered by Neustar, who found the initial defect, and JPRS, who built the feasible lab exploits. That was all in Feb 2011, not Jan 2011.

* The "high severity" is based on the CVSS _BASE_ Score of 7.1 (AV:N/AC:M/Au:N/C:N/I:N/A:C). Network operators would use this CVSS base score and then run the Environmental and Temporal Score to get a CVSS actionable score. This is why you saw a low score from US CERT so low. They used their proprietary full metric, which scored it lower. Vendors are encouraged to use CVSS so the operator then takes accountability to gauge the risk specific to their environment.

Check out http://www.first.org/cvss/ for more information on CVSS. ISC has recently started using CVSS for all our security advisories (see http://www.isc.org/announcement/iscs-has-adopted-cvss-our-security-advisories).

* DNS Operational Risk and Reaction to any DNS issue is best addressed via DNS-OARC. If your DNS is critical, I recommend, as a minimum, to sign on to the public BIND forums (see https://lists.isc.org/mailman/listinfo) and the public DNS-OARC forums (see https://www.dns-oarc.net/oarc/services).

(reference https://www.isc.org/software/bind/advisories/cve-2011-0414)

* As Larissa pointed out, this security advisory used ISC's phased disclosure process (see http://www.isc.org/security-vulnerability-disclosure-policy). The US CERT advisory stated they notified ISC on 2011-01-24. This is reversed. US CERT and all other National CSIRT Teams were notified at the same time (Feb 15th). We just recently added the step in our disclosure process to notify all National CSIRT Teams listed on first.org.

* US-CERT threw in the "2011-01-24" thinking the discovery of the vulnerability matched the time we asked for our next batch of CVE numbers. In this case, this vulnerability was discovered by Neustar, who found the initial defect, and JPRS, who built the feasible lab exploits. That was all in Feb 2011, not Jan 2011.

* The "high severity" is based on the CVSS _BASE_ Score of 7.1 (AV:N/AC:M/Au:N/C:N/I:N/A:C). Network operators would use this CVSS base score and then run the Environmental and Temporal Score to get a CVSS actionable score. This is why you saw a low score from US CERT so low. They used their proprietary full metric, which scored it lower. Vendors are encouraged to use CVSS so the operator then takes accountability to gauge the risk specific to their environment.

Check out http://www.first.org/cvss/ for more information on CVSS. ISC has recently started using CVSS for all our security advisories (see http://www.isc.org/announcement/iscs-has-adopted-cvss-our-security-advisories).

* DNS Operational Risk and Reaction to any DNS issue is best addressed via DNS-OARC. If your DNS is critical, I recommend, as a minimum, to sign on to the public BIND forums (see https://lists.isc.org/mailman/listinfo) and the public DNS-OARC forums (see https://www.dns-oarc.net/oarc/services).

Let me ask a question, when alerts come out like this that explain a vulnerability, do they always state the problem the way it happens?

Thankfully, yes, err, well, as far as they know at that time. I don't do IXFR on my authoritative or resolving bind servers so I simply don't care. Kind of hard to cause a deadlock during a tiny slice of a time in a process I don't run...

Like, if someone understood how to exploit this vulnerability, are they really going to shut down DNS services or could it be that there is a worse vulnerability underneath? For instance, could this actually be a call to patch something that allows for DNS spoof, where someone does not want the issue to have wide awareness?

Uh, no. At least not directly. According to

http://www.isc.org/software/bind/advisories/cve-2011-0414

the server simply stops responding. Usually deadlocks in any software freeze it up quite well rather than false data. Old data, maybe, at worst...

What happens to the rest of your security infrastructure when it stops getting DNS responses? Probably nothing, but someone whom tried really hard could make something like a syslog that wouldn't log if it cant log reverse DNS, so I guess you could brute force something while no one is watching, that is vulnerable to brute forcing (no rate limiting, weak enough to be brute forced, etc). Once they have access maybe they could set up some sort of spoofy thing.

I don't know why the article does not link to the original advisory but the ISC qualified this vulnerability with a severity level high.

That's because the latest BIND was released specifically to patch this vulnerability. They just didn't really tell anybody about the vulnerability until after 9.7.3 was released. Don't believe me?

CERT was notified at the end of January.
"Date Notified: 2011-01-24" [ http://www.kb.cert.org/vuls/id/559980 ]

The CVE was reserved in the middle of January.
"Assigned (20110111)" [ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0414 ]

Yet the release notes for 9.7.3 don't mention any fixes which would coincide with this vulnerability:
http://ftp.isc.org/isc/bind9/9.7.3/RELEASE-NOTES-BIND-9.7.3.html

Thanks, ISC, for patching a vulnerability a month after you found out about it and then telling us two weeks later that you did that. That's awesome security procedure there.

Really?

Randomize server selection on queries As a security improvement to make forgery a little more difficult, BIND 9.6 now attempts to make the order of the server selection for queries less predictable. Previously, BIND would prefer to query the server with the lowest round trip time (RTT). Now servers that haven't been tried yet have their RTT set to a random value between 0 ms and 7 ms. And the RTT values of servers which have been tried are now randomly changed up to 128 ms.

This algorithm also applies to DNS servers specified with the "forwarders" clause. A local bind installation with the ISP's and Google's DNS servers configured as forwarders would do what you want. The OS and applications would then be configured to use the local DNS server.

The best I can suggest off hand would be ftp://ftp.isc.org/isc/pubs/pres/NANOG/50/DNSSEC-NANOG50.pdf and other things linked from http://www.isc.org/software/bind/dnssec. That one presumes 9.7 which means they got to skip a lot of the nastiness other commonly referenced guides go over. I don't think I've seen a guide that doesn't present it as more complicated than it is, but that isn't too bad.

That all assumes ISC bind, and I particularly recommend BIND 9.7 or newer as a starting point (it had some *major* simplifications on DNSSEC).

The best I can suggest off hand would be ftp://ftp.isc.org/isc/pubs/pres/NANOG/50/DNSSEC-NANOG50.pdf and other things linked from http://www.isc.org/software/bind/dnssec. That one presumes 9.7 which means they got to skip a lot of the nastiness other commonly referenced guides go over. I don't think I've seen a guide that doesn't present it as more complicated than it is, but that isn't too bad.

That all assumes ISC bind, and I particularly recommend BIND 9.7 or newer as a starting point (it had some *major* simplifications on DNSSEC).

ICANN is really a perfect example of where a bunch of wise-beard Unix hacker types could do a better job than the corporate whores currently doing it could. Or better yet, a proper distributed alternative to DNS.

We can and are.

With enough Linux geeks, anything is possible.

lol You can try compiling from source, I think it will compile automatically for OSX; or you can look at Fink or DarwinPorts: I believe they both have Lynx available.

lynx does have bookmarks. I don't remember if it has something like history.

I'd like to invite you to check out the lynx and links web browsers.

The problem with MSIE6 is that it adds nonstandard extensions to HTML and CSS, does not (natively) support the full PNG spec, it is pathetically insecure, it adds padding to certain HTML elements in a lot of situations where everybody else assumes padding=0 so by making a web page in standard HTML/XHTML that looks gorgeous in every single other web browser will be horribly broken in MSIE6.

MSIE7 and MSIE8 have progressively gotten a TON better but they still don't handle broken pages gracefully (see the acid3 test) and will still degrade to MSIE6 compatibility mode, encouraging corporate web developers to be lazy and keep things as-is.

Now, as far as "fancy effects" go - those "fancy effects" led to the possibility of google docs, web-based photoshop elements replacements, online banking that doesn't take weeks to navigate (do you have an AmEx account? Log into your account on AmEx and you will see online commerce done right), and even legal free and low-cost on-demand video programming, and online classes. It also allowed for the building of "community" web sites that made the whole world a lot smaller, connecting people from nearly every nation.

It also allows us to research products better before we buy, so when companies post their products online they can post a LOT more detail than they ever did in printed brochures, and you can educate yourself so that salespeople who nothing about the product beyond what their commission is won't steer you wrong.

You can stick to the web as it was circa 1997. I'll take today's "web 2.0" (wait, did I just say web 2.0?), thankyouverymuch. And, I'll be very happy using non-Microsoft browsers.