All of his info on DNS is valuable but not relevant to my problem as it happens<br>when I'm not connected to the net. To show how serious this is, I did a few timings.<br>boot-up to login prompt: 4 minutes, 5 seconds<br>
login till ready to use: 4 minutes<br>shutdow: 1 minute plus<br>when connected to the net<br>boot-up to login prompt: 42 seconds<br>login till ready to use: 15 seconds<br>shutdown: 15 seconds<br><br>These long delays use up 10 percent of my battery before I can even start<br>
to work!<br><br>That it happens during boot-up exonerates gnome but seems to mean the<br>problem is in some very fundemental part of the system.<br><br>I tried to upgrade to "lenny" with apt-get upgrade but this did not change the<br>
kernel and the problem remained. I finally did a full, new install of lenny<br>and he problem is gone. As a side benefit, it appears my built-in<br>broadcom wi-fi may now work.<br><br>Richard<br><br><div class="gmail_quote">
On Thu, Oct 29, 2009 at 4:47 PM, Bill Broadley <span dir="ltr"><<a href="mailto:bill@broadley.org">bill@broadley.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<div class="im"><br>
Rick Moen wrote:<br>
> Quoting Bill Broadley (<a href="mailto:bill@broadley.org">bill@broadley.org</a>):<br>
><br>
>> I'd suggest adding caching in there somewhere, probably assumed.<br>
><br>
> I've yet to find a nameserver package of any sort, recursive,<br>
> authoritative, or even merely forwarding, that doesn't do caching.<br>
<br>
</div>Right, you know that, I know that, figured someone else might not.<br>
<div class="im"><br>
>> Agreed. Large ISPs (like pacbell) often have overloaded DNS, not to mention<br>
>> the DNS is often on the wrong end of a busy network.<br>
><br>
> That's only the beginning of their problems. To the predominant<br>
> dog-slow performance would add pervasive cache poisoning, e.g., the<br>
> quality of being a security menace, as the next obvious problem to<br>
> mention. But better to just skip them.<br>
<br>
</div>Agreed.<br>
<div class="im"><br>
>> I suggest unbound.<br>
><br>
> I like Unbound, despite its relative youth. PowerDNS Recursor is also<br>
> good, and perhaps a bit better tested. I would also consider MaraDNS.<br>
><br>
> I'm extremely happy with the authoritative-only server published for<br>
> quite a while by the same .nl TLD people who've more recently followed<br>
> up with Unbound, FWIW.<br>
<br>
</div>Good to know.<br>
<div class="im"><br>
>>> It'll also improve performance over using OpenDNS,<br>
>> Sort of. For cache hits, yes. For cache misses, not to much.<br>
><br>
> Obviously, I was talking about cache hits -- which predominate if you<br>
> run a recursive nameserver for a long while.<br>
<br>
</div>Sure. But that doesn't mean that fairly often some random site gets popular,<br>
over loaded even, and then is not in your cache.<br>
<div class="im"><br>
>> Sure, so only your ISP instead of opendns and your ISP knowing everywhere you<br>
>> visit.<br>
><br>
> The problem of your upstream link(s) being able to traffic analysis on<br>
> where your packets are sent to, and inspection in cases where you don't<br>
> bother to encrypt them, is a separate problem. But you knew that.<br>
> Also, unlike OpenDNS, they have fiduciary obligations to you under<br>
> contract. But you knew that, too.<br>
<br>
</div>Both good points. Opendns does try to give you protection against various<br>
other things, depending on your choices you get any collection of:<br>
* no protection/blocking<br>
* protection/blocking against phishing<br>
* protection/blocking against porn<br>
* protection/blocking against illegal activity<br>
* protection/blocking against social networking sites.<br>
<div class="im"><br>
> Use OpenDNS, and a party who owes you no loyalty whatsoever has a<br>
> central record of all DNS queries your IP has attempted.<br>
<br>
</div>Yup.<br>
<div class="im"><br>
>> NXDOMAIN does bug me, I believe that optional if you login/create an account.<br>
><br>
> That deliberate RFC violation _should_ bug you. It's essentially saying<br>
> "Nothing but the Web counts. Correct DNS information for SMTP mail<br>
> doesn't matter, because it's not the Web."<br>
<br>
</div>Yup. Although I'd expect that the IP they give you for a typo'd domain<br>
doesn't have an SMTP port open. There is the option to select:<br>
* Enable typo correction (and NX Domain redirection)<br>
<br>
So it's up to you, I agree I wish the default was the other way.<br>
<div class="im"><br>
> I'm not clear on why a login would remove that misfeature. They use the<br>
> ads on their "Site not found" Web pages to generate the revenue stream<br>
> that underwrites the service.<br>
<br>
</div>They seem pretty friendly and well implemented.<br>
<div class="im"><br>
>> Oh, almost forgot. I'd recommend unbound as a local caching recursive<br>
>> server. It's DNSSEC and DLV aware....<br>
><br>
> I'm no DJB fan, but I think he's right about the reasons why DNSSEC is<br>
> never going to be used on any significant enough scale to matter. The DLV<br>
> lookaside kludge (that partially works around lack of a signed root<br>
> zone) to an overengineered and impractical based spec strikes me as just<br>
> another deck-chair on the sinking ship.<br>
<br>
</div>Dunno, seems to be gaining significant ground lately. .gov and .org are in<br>
the dlv, as well as a bunch of others top level domains (granted none as<br>
popular as .com.) DNS is really important and many people place much more<br>
trust in it than they should.<br>
<br>
I agree that DNSSEC is scarily useless today, a shared key means you have to<br>
control both client and server.... rare. The DLV fixes this, with just a 1-2<br>
line change to your local DNS you can take advantage of anyone using DLV. Say<br>
even to verify the contents of this email from paypal, gmail, or an even from me.<br>
<div class="im"><br>
> I don't know why I should trust DLV repositories (Trust Anchor<br>
> repositories), and the largest one that makes something like a<br>
> meaningful effort to validate that they belong to whom they claim to<br>
> (ISC's) had a whopping total of 25 DLV records in it a year ago, when I<br>
> last looked into this. (SecSpidor collects DLVs, but doesn't validate<br>
> them.)<br>
<br>
</div>I don't have any numbers, but my domains have the serial number around 850.<br>
Seems reasonable to trust <a href="http://dlv.isc.org" target="_blank">dlv.isc.org</a> if you trust <a href="http://isc.org" target="_blank">isc.org</a>. Nothing stops you<br>
from running your own dlv if you so choose, I've seen a couple collections of<br>
dlv records that could easily be downloaded as needed. If anyone has a good<br>
idea of how many domains are using DLV please speak up.<br>
<div class="im"><br>
> So, good luck making that stuff practical and useful. Do send a<br>
> postcard. ;-><br>
<br>
</div>The cost of adding 1-2 lines to a local dns config is IMO worth the cost of<br>
admission. If you trust iana/itar you can grab their anchors with a handy<br>
script that grabs <a href="ftp://iana.org/itar/anchors.mf" target="_blank">ftp://iana.org/itar/anchors.mf</a> and checks a pgp signature.<br>
Much easier if you can trust the .org's DNS response ;-).<br>
<br>
I've added the server side support to DLV to a few domains, seems worth it<br>
just so I can be sure I'm talking to them when I'm accessing them remotely.<br>
Sure my most important communications happen via ssl or openssh, but it's nice<br>
to have extra protection for dns lookups as well.<br>
<br>
So basically I recommend unbound for your laptop/desktop and enabling dlv with<br>
someone you trust (I trust <a href="http://isc.org" target="_blank">isc.org</a>).<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.9 (GNU/Linux)<br>
Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/" target="_blank">http://enigmail.mozdev.org/</a><br>
<br>
iEYEARECAAYFAkrqN6AACgkQBmOBO0n4EFWkRQCfQJr2fUb2d0R13pPrY9mSz2by<br>
Da4Ani3H6+65xdNk3st8RVYj79l6sZdo<br>
=oC/2<br>
-----END PGP SIGNATURE-----<br>
<div><div></div><div class="h5">_______________________________________________<br>
vox-tech mailing list<br>
<a href="mailto:vox-tech@lists.lugod.org">vox-tech@lists.lugod.org</a><br>
<a href="http://lists.lugod.org/mailman/listinfo/vox-tech" target="_blank">http://lists.lugod.org/mailman/listinfo/vox-tech</a><br>
</div></div></blockquote></div><br>