Thursday August 07, 2008 PGP: Signing policy update / Please sign my photo UID
Couple of PGP things:
It's not terribly consistent though, and I'm still not quite sure where I stand on signing keys on nothing more than a cursory examination of governmental ID (i.e. people at key-signing events whom I don't know personally), so I'm not very happy with it. I'm much more comfortable signing keys of people I've known and interacted with over a period of time, and even more so when I know others who've done same - even if I've not seen an ID.
Some may wonder why I would sign keys on the basis of my level-1/Low policy, but the concept of "web of trust" implies additive trust (potential for at least), so even a "not much confidence" signature ought to be of value to the WoT.
).
If you can attest to that being a good likeness of me and have good reason to believe it's my key, please do sign that new UID. (Also, what's with people who sign only one UID on a key? I've no control over the order of UIDs, I think, so its always a less favoured UID that gets signed in such cases - arg!
).
Weird BIND9 AXFR error? Remove stray A6 records..
Some release after BIND 9.2.1, its parser for A6 records appears to have broken. If you've ever experimented with A6, you might to go check you've expunged all occurrences from your zone files. Resultant symptoms include:
Background: For many years, as I saw it only between a master behind a sub-1500 MTU (PPPoE, sigh) and certain servers, I assumed it was an MTU-blackhole problem with some upstream sneakily doing firewalling. However, recently the problem started to afflict another server, after an upgrade of their BIND software, and affected AXFRs even over paths that were perfectly fine. Some brute-force testing ruled out obvious problems like size issues (not like my zones are big) or relatively new records like SSHFP, leading to some head-scratching, but eventually pinned it down to a couple of stray A6 records.
( Aug 07 2008, 06:59:24 PM IST ) Permalink Comments [0]