Slashdot Mirror

There is a Firefox add-on, DNSSEC Validator, which appears to work for the pir.org zone, as well as my own roysdon.net zone. Both are DNSSEC signed, although my roysdon.net is found in the DLV.

You can point the tool to use Comcast's DNSSEC trial resolver which is DLV-enabled at 68.87.68.170.
You can trial Comcast's DNSSEC trial resolved which does not have DLV support at 68.87.64.154 and rely only on the Root signature and previously published ccTLDs like .SE.

pir.org is an example of a zone which you can verify just by having the root zone's key. The root signs .ORG, and .ORG has signed pir.org.
As opposed to DLV-enabled zones, like mine, which rely on dlv.isc.org until .NET is signed. Well, also until Registrars add a way so that .ORG owners can sign their zones.

I did a bit of digging, and all the data on host counts appear to be compiled from the ISC Domain Survey. According to the summary on that page, "The Domain Survey attempts to discover every host on the Internet by doing a complete search of the allocated address space and following links to domain names." This would seem to exclude hosts without reverse-DNS records, but I'd need to read the complete study methodology before I could comment intelligently.

I also looked to see if there were easily-available figures on the number of IP addresses allocated by country but couldn't find any.

Regardless of the method for counting hosts, it still seems quite likely that US hosts make up considerably more than 13% of all hosts worldwide.

Really? I'm pretty sure my favorite browser is immune.

You are kidding right?

Really? I'm pretty sure my favorite browser is immune.

Finally, YouTube for us Lynx users.

Are the ASCII images 7-bit clean?

Not all of us can afford 14.28% additional bits, you insensitive clods!

Just sayin'.

http://lynx.isc.org/

There is no "BIND 10 committee", but we do have weekly conference calls. Minutes from these are published on our Trac site:

https://bind10.isc.org/wiki/WeeklyConferenceCalls

[ disclaimer: I am the BIND 10 project manager ]

We wrote lots of tests. (How else would we know it has bugs in it?) This is a somewhat fair criticism of BIND 9, but read the link before you assume we didn't learn any lessons from the past. The unit tests are included in the tarball and coverage results are viewable online.

Is there any physical reason why a router couldn't do the following to transparently enable ipv6-oblivious software to effectively "inverse-NAT the rest of the world"?

No, there isn't. "NAT46" routers do just that, and one way or another they will become common in the next several years. Comcast is working with ISC to develop a NAT46 solution they call an address family transition router. Cisco has similar support in the works too.

Comcast figures people will be running one or more IPv4 only devices on residential networks for a long time, so the need for a NAT46 solution of some type will be nearly universal.

There is also NAT64 which works the other way - connecting IPv6 only clients to IPv4 only servers. It has the advantage of being much simpler and easier to implement than NAT46 is.

I reckon it depends on how much you trust your ISP (Is it Comcast? comes to mind), but you could roll your own DNS server.

Here you go.

Bind has Windows binaries for XP/2003/2008

https://www.isc.org/downloadables/11

Here, let me fix that for you.

obviously mean http://ftp.isc.org/www/bind/arm95/man.named-checkzone.html

Didn't they use something like this before reloading the zone? If the mistake was a missing '.' it should've given you big warnings ...

http://ftp.isc.org/www/bind/arm95/man.named-checkconf.html

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.)

http://en.wikipedia.org/wiki/Lynx_(web_browser)

http://lynx.isc.org/ ---home_page

Slightly off-topic, but just a reminder: have you patched the BIND security hole yet? If you're running BIND 9 and your server is the master for any domains (including localhost), and you haven't patched this week, one malicious packet can crash your server.

Crashing your server, now that's a bit extreme. It actually causes Bind9 to exit on the master server. Which whilst inconvenient, isn't worth being to histerical about. Any DNS admin worth his salt has geographically and network disperse slave servers to handle queries when the primary cannot be contacted.

I did an
apt-get update && apt-get install bind9
yesterday, so my master dns server is safe now

Am I the only one who doesn't see the multiplicity of real competition as a threat, but rather as the greatest success of the Mozilla Foundation?

Huh? Is there somebody out there yelling, "No! We need one browser! Competition is evil"? If so, I haven't run across them.

With browsers (as with any other software) there's always some obsessive fanboy who says that everybody should be using Firefox or Opera or even Lynx. But that just religious non-logic; it's not an argument against competition.

What about us Baptists? If the Roman Catholics can have a browser...
Oh, I forgot: "The GUI is a factory for idols, and that's why we have lynx."

Or two dhcp servers. Just in case the path to the first dhcp server is unavailable

http://www.madboa.com/geek/dhcp-failover/

Keep in mind that if you are using unnumbered interfaces, there is a standing bug in Cisco IOS that will make it impossible to make use of DHCP failover.

https://lists.isc.org/pipermail/dhcp-hackers/2007-April/001597.html

He's the president of the company that's doing the work.

This outperforms every browser on the planet, especially over dialup or flaky wifi. As for the Acid3 test, it passes provided you squint hard enough.

Yes but how do I implement it...

fast and easy.

And those that know howto properly use DNSSEC will find those to be invalid. This is not a self signed ``just accept it'' certificate.
You should probably read up on the idea a bit: https://dlv.isc.org/about/background

Yes, it is very straightforward: DNSSEC in 6 minutes

It took me a little longer to assimilate the 79 slides, but perhaps I am just slow.

Known as a Trust Anchor Repository, the alternative was announced by ICANN last week and has been in testing since October.

Ah, so the other alternative, look-aside validation, currently run by the ISC and something I've been using for ages isn't a solution? OK, I'll stop using it right now...

Clues. Isle nine. I'd get one, were I you. ICANN ain't the only game in town.

However much M$, Disney, RIAA, MPAA would like your to believe otherwise, the fact is that copying copyrighted material is perfectly legal in all Berne Convention countries, unless the copyright owner says otherwise. Even perfectly then it may be allowed but with restrictions.

The GPL, ISC, and CC licenses come to mind as overwhelmingly common examples. Act on the empirical facts not opinions, half-baked or otherwise.

I was able to get in before it was fully slashdotted (it was crawling when there were only two posts here).

Here are some US mirrors:
CA ftp://mirrors.isc.org/pub/DragonFly/
TX ftp://mirror.evilprojects.net/pub/DragonFlyBSD/
VA ftp://ftp.theshell.com/pub/DragonFly/iso-images/

And some EU ones:
UK ftp://ftp.as6911.net/pub/DragonFly/
Germany ftp://chlamydia.fs.ei.tum.de/pub/DragonFly/

Here's the Release Notes:
Release Improvements

* A new DVD ISO release image is now available, in addition to the CD release.
* The new DVD release has a full X environment ready-to-go and many packages pre-installed.
* A full pkgsrc tar is now available on the CD/DVD in /usr.
* Full sources tar now available on the DVD (kernel sources only on the CD), in /usr.
* The nrelease build now trivializes package selection for people creating customized releases.
* The installer is now able to create a HAMMER filesystem setup.

Kernel changes

* First step towards AMD64 support (done by Jordan Gordeev during the Google Summer of Code 2008).
* The system control intr_mpsafe is enabled by default.
* Move /kernel to /boot/kernel and /modules to /boot/modules.
* Add RFC3542 support (done by Dashu Huang during the Google Summer of Code 2008).
* Add HW checksum support to the loopback interface, which doubles performance.
* acpi_cpu(4) update. It's now possible to use higher (lower power usage) C states than C1 in modern (multicore) CPUs.
* First steps to use network threads without the Big Giant Lock (this feature is considered experimental).
* Fixed CVE-2008-2476 IPv6 security issue with modified patches from NetBSD.
* bridge_input works now in parallel.
* Fix bugs in dealing with low-memory situations when the system has run out of swap or has no swap.
* Major rewrite of usched_bsd4 and related support logic, plus additional improvements to the LWKT scheduler.
* Major revamping of the pageout and low-memory handling code.
* suser_* replaced with priv_* implementation from FreeBSD.

HAMMER changes

* HAMMER is now considered production-capable. Many bug fixes and other improvements have been made.
* It is now possible to boot from a HAMMER-only disk. No need for a single UFS partition for /boot. However, for production systems we still recommend a small UFS /boot followed by swap followed by one large HAMMER partition.
* Add HAMMER read support to the boot loader.
* Now uses per-mount kmalloc pools for bulk data structures, particularly for inodes and records.

Hardware changes

* Add ACPI support module for IBM/Lenovo Thinkpad laptops (from FreeBSD).
* Add ACPI support module Asus laptops (from FreeBSD).
* Add acpi_video(4) - a driver for ACPI video extensions (from FreeBSD).
* It is possible to power down PCI devices during

There are plenty of benchmarks out there showing Gentoo outperforming similar distributions, tho obviously with a distro as customizable as gentoo it's easy to misconfigure it and get abysmal performance...

Example:

http://new.isc.org/proj/dnsperf/OStest.html

There were some more, but i couldn't find the urls with a quick google search.

... computer manufacturers forced to install Firefox, Chrome, Opera and Safari by default alongside Internet Explorer on new Windows-based PCs.

And also Lynx, I would bring me great joy to see a video of an average Windows user trying to use Lynx.

It is *possible* to cache YouTube videos and the like, but you'd need some technical skill to pull it off. Basically, you'd write a Squid pre-filter that replaces embedded YouTube videos with an embedded call to a local cgi-script. On the first invocation, the cgi-script would download and cache the video while streaming it to the client. Subsequent calls would skip the download process.

Of course, this only saves bandwidth when you re-watch the same video over-and-over.

Even in the pre-YouTube days of the internet, Squid didn't help with bandwidth all that much. I once set up a Squid cache in transparent-proxy mode at an ISP with around 400 dial-up customers. I gave it 4 GB of cache space, which doesn't sound like much now, but our biggest drives were 500mb full-height SCSI bricks. I tuned every configurable option and pulled every trick in the book to maximize the caching. The experiment lasted around a month, during which time Squid saved us around 30% on our inbound bandwidth, according to log analysis. We finally had to shut it down because customers started to notice that they weren't seeing real-time data (like stock quotes) and some of them threatened to sue.

Bottom line: If you want low-bandwidth internet, use one of the these:

Lynx

Links

ELinks

w3m

http://lynx.isc.org/

Am the only one that thinks there were way too many links in that summary?

Personally, I am running bind. My ISP's DNS servers were rather slow to respond.

With most linux distros, all you have to do is install it with your package manager, and then set your machine to use itself, rather than the ISP, as the DNS server. The default configuration that gets installed will generally query the root servers. You will need to check your distros documentation just in case.

Bind packages can also be found for DD-WRT. I don't run them, so I cant say how well they work.
DD-WRT Bind DNS-slave server
http://www.dd-wrt.com/dd-wrtv2/downloads/others/packages

For M$ users, DNS server packages, (including bind), are available. I don't have experience with them, as I dumped M$ shortly after XP was released.
Google Search
ISC Bind

There is more than enough documentation on how to set-up and run DNS servers available on the net, it is pointless to do that here.

The biggest thing that I don't understand is why people who write such articles don't mention that there are solutions available. It would have simply been a 2 or 3 sentence paragraph in TFA to give links to a way around the censoring. TFAs that were linked to didn't even point out that it was DNS filtering, the link in my original post came from one of TFAs.

For DNSSEC to work, you need either:
1)Signed root
2)signed TLDs with out of band pre-verification
3)DLV.

1) is the future.
2) and 3) are what we are stuck with today, so I'll explain them.

DNSSEC can be rooted anywhere you like, but the lower down the tree you go from the root the more keys you have to manually verify. For .gov to be secure, for example, every recursive DNS server operator would have to manually verify and install the .gov key. And they'd have to update it periodically, probably about yearly. For 2) to work, every DNS op would have to be on top of key rotation, or an out of band verification tool could be written that would depend on GPG, SSL, or other established crypto for verification.

DLV is a solution where someone besides the actual DNS root is treated as the DNSSEC root for anyone who submits their key to the DLV. Right now ISC runs one of these, available here. Previously, VeriSign ran a pilot, but dropped it. Apparently they saw no good way to monetize the service.

Eventually the actual DNS root will be signed, and there is lots of talk about it at the moment, but little action.
St the moment .org, .arpa(reverse lookup), and .gov are moving to deploy DNSSEC themselves.

Note that the root signing issue is more political (i.e. Who holds the keys?) then technical at this point.

Would anybody need a browser like that?

I'd rather use Firefox or Lynx ftp://lynx.isc.org/current/

The only real fix available now for the fundamental vulnerability is DNSSEC. There's an excellent doc up on ISC's site called DNSSEC in Six Minutes for those who read bothered to read Kaminsky's actual presentation (especially the last 40 or so slides on subtle ways security systems like SSL break when you can't trust DNS), put that together with the ten hour exploit for patched servers, and realised we're not out of the woods yet by a long chalk...

Well, sort of. If you have a DNSSEC-aware resolver, and you are looking up a record in a signed zone, then the man-in-the-middle attack you're proposing doesn't work, because the signatures don't check out. So it is possible to prevent the problem you're describing.

The reason we have this problem is, very simply, that in many of the larger TLDs, the top-level zone is not signed. So there's no chain of trust, so even if you sign your zone, I have no way to get your key, because I have no chain of trust to follow.

There are solutions to this - register in a signed TLD, like .se, for example. Or use DNS Lookaside Validation. But ultimately the situation you describe will continue to be the default until the big zones are signed, and people who do transactions that require security start signing their zones.

It's a bit of a chicken-and-egg problem, unfortunately.

It's long past time for Secure DNS, which is a combination of TSIG+TKEY, SIG(0), and DNSSEC. End to end crypto authentication. Protects not just against off-path spoofed-source attacks like Kaminsky's, but also on-disk attacks against zone files, and provider-in-the-middle attackers who remap your NXDOMAIN responses into pointers to their advertising servers.

Sadly, it's a year away even if everybody started now, and most people want to be last not first, so very few people have started, and some of those people are saying "why bother, if it's not an instant solution there's no point to it, let's scrap the design and start over." (Had it not taken 12 years to get Secure DNS defined, then the prospect of doubling that time would not daunt me as much as it does.)

So, everybody please start already. NSD and Unbound from NLNetLabs supports DNSSEC. So does BIND, obviously. Sign your zones, and if your registrar won't accept keys from you, send them to a DLV registry while you wait for that. Turn on DNSSEC validation in your recursive nameservers. Write a letter to your congresscritter saying "please instruct US-DoC to give ICANN permission to sign the root DNS zone." In the time it would take for this Russian physicist's attack to work over your 512K DSL line (2.2 years, I heard?) we could completely secure the DNS or at least the parts of DNS whose operators gave a rat's ass about security (which is not the majority but it certainly includes your server, right?)

Which Microsoft license? Their "shared source" licenses? This is better than that -- you are free to modify the code and use it for any purpose, as long as the copyright notice remains. This is nothing like ANY Microsoft license (except for the one the University of California at Berkeley granted Microsoft)

http://www.isc.org/index.pl?/sw/dhcp/dhcp-copyright.php

I'm surprised that more folks here aren't running their own resolvers. It isn't that hard, especially if you don't need to act as an authoritative server for serving your own domains and just need a recursive resolver. One nice hack you can configure if you run your own resolver is dnssec - cryptographically secured dns lookup. While there aren't many dns zones that are cryptographically signed yet, there are a little over 10,000 (see http://secspider.cs.ucla.edu/ ). That is a start. Unless people start using dnssec and demanding that their websites be in secured dns zones, companies won't be bother to do the work needed to configure their dns zones with dnssec. A pdf with simple instructions for setting up dnssec can be found here. I set up my domains and resolvers this way, and it only took an afternoon to get acquainted enough with the concepts to bumble through the instructions. I've been running it for a few days now and it seems to be working just fine. http://www.isc.org/sw/bind/docs/DNSSEC_in_6_minutes.pdf

Once someone (anyone?) releases a DNS package that allows firewall-style rules (e.g. "client on this range of IPs may only resolve subdomains of the following domains..."

I think you might be able to do that with the "views" feature of ISC BIND v9 named, although I've never tried. I know you can define ACLs for clients and control how they see the DNS using the ACL. You should be able to define forwarding zones for the domains you want to work, and blackhole everything else. I think.

http://www.isc.org/sw/bind/arm93/Bv9ARM.ch06.html#view_statement_grammar

it's an acronym for "Berkeley Internet Name Daemon"

Actually, BIND stands for "Berkeley Internet Name Domain". Berkeley did the seminal work for the original DNS implementation, and that's what they called their idea. BIND is a suite which includes a stub resolver, some utilities, and named (name daemon). (Along with some other stuff, now.)

If you want to get fancy, "ISC BIND named" is the proper name of the software we're talking about. ISC is the company, BIND is the product, named is the program.

See: http://www.isc.org/sw/bind/index.php

How in the world did you manage to get hold of the patches, test them, and deploy a competing product on a 90,000+ zone installation in the two hours between the patch's public release and your post? That's... really fast work.

Out of curiosity, what version of BIND were you running prior to the change, and on what OS/hardware?

It is true--and we acknowledged in the release announcments--that the initial security patches (9.3.5-P1, 9.4.2-P1, 9.5.0-P1) cause a significant performance hit on heavily-loaded systems.

There are further code optimizations that get performance roughly back to baseline, but we felt they were too extensive to release without putting them through a beta cycle.

Two beta releases, with the enhanced performance code, were published at the same time as the patches: BIND 9.5.1b1 and BIND 9.4.3b2; you can grab them now (um, for values of "now" that include "very soon"; one of our 10G fiber links picked an unfortunate moment to fail).

The remaining beta, BIND 9.3.6b1, will be released in a few days, because five releases at one time was already enough to juggle.

How in the world did you manage to get hold of the patches, test them, and deploy a competing product on a 90,000+ zone installation in the two hours between the patch's public release and your post? That's... really fast work.

Out of curiosity, what version of BIND were you running prior to the change, and on what OS/hardware?

It is true--and we acknowledged in the release announcments--that the initial security patches (9.3.5-P1, 9.4.2-P1, 9.5.0-P1) cause a significant performance hit on heavily-loaded systems.

There are further code optimizations that get performance roughly back to baseline, but we felt they were too extensive to release without putting them through a beta cycle.

Two beta releases, with the enhanced performance code, were published at the same time as the patches: BIND 9.5.1b1 and BIND 9.4.3b2; you can grab them now (um, for values of "now" that include "very soon"; one of our 10G fiber links picked an unfortunate moment to fail).

The remaining beta, BIND 9.3.6b1, will be released in a few days, because five releases at one time was already enough to juggle.

Except your Unix/Linux server is probably using BIND , and ISC has released a patch (and lots more information): http://www.isc.org/index.pl?/sw/bind/bind-security.php

Lynx - it's what dialup connections were made for... ...and you didn't think there was any content on the interwebs...

I'm seeing RC3 for those links.

Check out the timestamp of binary:

http://mozilla.isc.org/pub/mozilla.org/firefox/releases/latest-3.0/win32/en-US/

Direct links to win32, en-US, from the official mirrors:

http://mozilla.isc.org/pub/mozilla.org/firefox/releases/latest-3.0/win32/en-US/Firefox%20Setup%203.0.exe
http://pv-mirror01.mozilla.org/pub/mozilla.org/firefox/releases/latest-3.0/win32/en-US/Firefox%20Setup%203.0.exe
http://mozilla2.mirrors.tds.net/pub/mozilla.org/firefox/releases/latest-3.0/win32/en-US/Firefox%20Setup%203.0.exe
http://pv-mirror02.mozilla.org/pub/mozilla.org/firefox/releases/latest-3.0/win32/en-US/Firefox%20Setup%203.0.exe
http://mozilla.mirrors.easynews.com/mozilla/firefox/releases/latest-3.0/win32/en-US/Firefox%20Setup%203.0.exe


Other international sites (navigate to appropriate OS and lang)
http://www.mirrorservice.org/sites/releases.mozilla.org/pub/mozilla.org/firefox/releases/latest-3.0/
http://mozilla.ftp.iij.ad.jp/pub/mozilla/mozilla.org/firefox/releases/latest-3.0/
http://mozmirror01.true.nl/pub/mozilla.org/firefox/releases/latest-3.0/

For more, see google cache of mirror list here:


http://209.85.141.104/search?q=cache:_PnqbgP1GpIJ:www.mozilla.org/mirrors.html+firefox+3+download+mirror&hl=en&ct=clnk&cd=1&gl=us