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