Isn't "weapons" just a category that can be blocked or not, depending on whose controlling the software? Thus I think it is fairly accurate to include pro-gun sites under "weapons." If a parents wants to block weapons-related information, then they can use this category. If not, they won't.
But how is the NRA's ILA more of a "weapons" site than "The Brady Campaign" ?
Neither site contains much in the way of weapons, there is actually more "gun porn" on the Brady web site than on the ILA web site.
Listing only the sites that take a stance for "weapons ownership rights" and against restrictive gun laws under the "weapons" category, while not listing the sites that take a stance against these rights and for more restrictive gun laws, does appear to reflect a political agenda.
The last real startup job I worked at, we received a cash bonus...
On the last full workday before the holidays, as we walked out the door the boss handed out envelopes each containing ten crisp new $100 bills.
The amount never showed up on our W-2s, either.
That said, a thoughtful gift is also appreciated. One of my big corporate gigs gave everybody an expensive fruit basket -- unlike a ham, even the vegetarian employees could enjoy that.
I suppose it would still have offended the hardcore organic vegans, who would find fault in the use of pesticides and such, but I'm not going to complain when I see oranges bigger than most grapefruits, and yet also sweet and juicy...
Hardly nobody on here knows shit technically speaking yourself excluded Nonesuch/GRIN/, and are ready to slit your throat if you say one wrong (read: probably true) thing about Apple.
I won't try to argue with that.
But where do the people who *do* know shit technically hanging out now? Certainly not K5...
Sure, there might be a few actual cipherpunks hanging out chatting on SILC, but I'm more interested in message boards than in realtime chat. I'm on BOFHnet, but that's devolved to a social clique of bitten unemployed sysadmins.
As a matter of a fact it sounds an awful lot like the anti-blast worm some jackass wrote. That bit of well meaning cyber-carpentry got on my network despite being prepared for blast and it did very similar damage. The honey pot project should look for useful things to the community not to an individual.
The key difference here is that the honeypot is passive, it does not go out looking for vulnerable hosts, it waits until after the three-way TCP handshake on TCP/135 is complete, and only then does it react.
Spoofing complete TCP sessions is non-trivial, making false-positives (especially for a two-stage worm like Blaster and Nachia, using two different sessions to complete the infection) highly unlikely.
Secondly, while I agree that vigilante entrapment on the wild Internet is a dangerous direction, the basic concept is a sound approach to handling worm propagation within an ISP, corporate WAN, or other "private" (Internet-connected or otherwise) network where the honeypot operator has the legal and moral right to act.
In my experience, corporate and large ISP outbound mail gateways do not move around much, if at all.
Also, the AT&T whitelist effort appears to be targeted at their current existing IP connectivity customers, which is a much smaller pool of addresses and servers than the Internet as a whole.
Public key cryptography (PGP, GPG, etc) can address many of these concerns -- simply refuse to accept mail unless it is either:
Encrypted with your public key -or-
Signed by one of your "trusted signers" using their private key.
The first requirement allows any random stranger to send email to you, if they are willing to put in the extra work and CPU cycles to obtain your published key and encrypt with it. This knocks out the broadcast mass spam mailings.
The second requirement provides a workaround for legitimate mailing lists and other broadcast messages -- when you sign up for a mailing list or sign up for Aunt Martha's christmas letter, you can add them to your list of trusted signers.
The major problem remaining is how to get the Aunt Martha's of the world to start using PGP/GPG...
There are an estimated 10 million mail servers in operation right now.
The average life time of an IP for a server is approximately 1 year.
Please provide a source for your numbers.I find the above to be rather questionable.
In my experience, corporate and large ISP outbound mail gateways do not move around much, if at all.
Also, the AT&T whitelist effort appears to be targeted at their current existing IP connectivity customers, which is a much smaller pool of addresses and servers than the Internet as a whole.
Sorry, I still don't get how certificates would make anything better. It is either the same kind of capitulation like this whitelisting is if you manage the certificates you trust yourself, or mostly useless if you depend on some root CAs - given that about 85% of the spam I get comes from machines that are technically allowed to send mail to me, but are an open proxy or relay or simply cracked, certificate validation buys you nothing.
Encapsulating SMTP in SSL has other benefits (Carnivore-proofing, etc), the primary benefit of requiring a SMTP client present a valid certificate signed for that client source IP by a trusted CA is that the average open proxy or cracked desktop PC would not normally have a signed certificate available.
The use of certificates give a number of options -- you could trust the usual root CAs, and you could also choose to trust certificates that you yourself sign, or signed by some other trusted third party. Somebody like MAPS or SpamCop or AT&T could provide signing services, offering to sign for a fee, for a bond, or (getting back onto the current AT&T topic) only sign for their customers and partners.
It would be a useful defense if spammers would routinely try to impersonate legitimate hosts by IP spoofing or something, but alas, they don't.
However, spammers routinely do try to turn ordinary personal broadband-connected PC's into spam-transmitting SMTP clients, and these would be machines that would not normally have a valid "SMTP Certificate" assigned to a static IP (if they have a static IP at all), and thus would not pass even the most basic trusted client certificate check.
Hackers who build up a zombie army of hundreds or thousands of compromised Windows hosts are not likely to go out spend $$ to purchase a signed certificate for the (short-lived) IP address of each zombie.
Corporations who manage a couple (or a couple dozen, in the case of AOL) separate outbound SMTP gateways would likely not have a problem with paying a few bucks per server to have them "bonded" by one or more CAs. Abuse the privilege and you forfeit your bond.
Could anyone tell me if this letter also went out
to customers that manage their own IP nets but buy upstream connections from AT&T. For example, ISPs that are LIRs for their own nets.
I believe that AT&T customers who only use AT&T for transit (have their own AS and portable IP blocks) also received the letter. Only other way I could have gotten it is based on some old DNS registrations delegated to AT&T...
Took me a bit to figure out what "LIR" (Local Internet Registry.) refers to, since I've been out of the retail ISP game for many years. Turns out, "LIR" is not very clearly defined, it just means an ISP to which IP space has been allocated?
I can't believe they aren't going to do a black list instead of a white list.
AT&T has had their own private blacklist running for months, I hear it doesn't work too well. Too many false positives and false negatives.
Another thought is that perhaps AT&T EMS is planning to subscribe to Vixie's RBL+, and want to first whitelist all of their customers, to prevent legitimate customer email from getting blocked by an overly broad stroke of the dynamic blacklist...
Hopefully RMX will get off the ground soon, so we can all do this automaticaly.
That's what I was thinking, but it looks like RMX is dead in the water, the link to the memo from the IETF ASRG website goes 404.
Looks like TLS (SMTP over SSL with client and server certificates) is our only hope. I was at a recent Open Group messaging conference (formerly X.org) where the main topic was spam, and there is definitely interest in this approach.
I'm not sure that this is stupid -- my own Fortune 500 employer has been considering implementing a similar "whitelist" for incoming mail, giving preference to known vendors and customers.
Only real difference is that most companies don't have the balls to send this kind of broadcast mail message...
AT&T cannot be this stupid. I have to think that this is a hoax. The long message vouching for the credibility of the earlier, terse message supports this idea.
I've received both the original short message and the longer followup message. The long message includes contact information at the end, names and a 800 number. The names given are actual AT&T employees.
It looks legitimate to me, the reply email address is given as rm-antiattspam at ems dot att dot com (bot-proofing added by me). I haven't actually responded yet, but other role accounts at AT&T also take the form of rm-something@ems.att.com.
In large mta deployments the mx is hardly ever the sending mta.
Yes, Morelife is exactly correct. My "outbound" mail firewalls have no TCP listeners on them at all, only a PF rules to return RST for TCP/113 (to avoid the AUTH query delay), so listing them as MX hosts for inbound mail would be a bad idea.
There *was* a IETF draft for "RMX" (Reverse MX) published by the IETF's Anti-Spam Research Group (ASRG), but it's not really ready for prime time.
Yes snail mail is private, to both businesses and private individuals. Now think about the anaology, I do not expect anyone to open my mail at home, but the office is different,...
So to compare, many businesses do open and read snail mail addressed to another person in the company. There is even a word for them, Gatekeepers. It is chapter 1 materical in a business communication class to know that people other than the person you address a letter to are going to read that letter.
Exactly, a business has the right to open any mail delivered to their business address, even if marked "personal". The USPS is very clear on this, see When does federal protection of mail terminate?
I think the real issue is that any snail mail that arrives at a business is property of the business, and that any email that arrives at a business mail server could be considered the same.
Of course if you want to get your personally mail at work, then you could use one of those fabulous web based services, but then that goes back to the issue of surfing/emailing on company time.
One area that is less clear, is can your employer intercept email that you read via a webmail service, when you access the service on company time using company resources?'
What's to stop you from pointing a dyndns address at one of anonymizer.com's IPs?
For starters, even the cheapest web filtering solution will resolve hostnames and check against a list of blocked IP addresses. Actually, for the cheapest web filtering solution, that's all it does.
Your best option to "get away with" (for a little while) browsing stuff at work that they don't want you browsing is to proxy your requests through a HTTPS TCP/443 proxy of your own construction, and keep the connections short and the traffic low-volume.
Or better yet, when you are at work, do your job, and save the NSFW web browsing for when you are off the clock, on your own time, your own bandwidth, and your own equipment.
My company uses Websense, which is extremely irritating as it blocks many useful and interesting sites. It doesn't alter them; it just blocks them.
Therefore, I have circumvented it by tunneling most of my traffic through SSH to external machines running the squid http proxy and socks (for IM).
All they will see is intermittent encrypted traffic on port 22 (or whatever port your SSH server is on). Of course it would help if you have an excuse for needing an SSH connection. I'm covered as several servers under my control are co-located.
Keep in mind that they can still catch you (high traffic to unusual destinations, should surfing, keystroke sniffer, etc), and the fact that you went to such extremes shows intent, so activity that might have resulted in a warning instead leads to termination, or even (in extreme cases, with a paranoid boss) prosecution.
Keep in mind, that for the BOFH, actions like yours scream "I've got something to hide! Investigate me!"
Using ssh and rz (or scp) is a good way to copy all your sourcecode/company docs & secrets out without them really knowing.:)
Until they block 22.
Easy enough to set up your SSH software to listen on another port, or even tunnel through HTTPS, etc.
Another thing I hated in my old company was that it looked like they only allowed 2 concurrent http connections, so you couldnt download from >2 http sites.
But I bet you all the CEOs and high ups have unrestricted access, thats why all viruss are spread by managers not engineers.
Restricting concurrent TCP sessions is an interesting approach, has some neat implications.
In my experience, most viruses and worms get in through webmail sites, VPN, or laptops. I've even seen SQL-Slammer (aka sapphire, a memory resident worm that goes away when you reboot) show up inside a secure LAN when somebody brought in a suspend'ed laptop from home.
hey just throw up a huge "THIS PAGE IS RESTRICTED BY COMPANY POLICY" page complete with little flashing red lights and sirens. that last bit is funny because you can hear them going off every so often as someone in the office tries a "restricted" page and has the sound turned on and up.
Yeah, I'm the guy that wrote the one at my employer -- the standard "Coaching" page from Websense wasn't glaring enough, so I added a bright orange background and garish red and black "police tape" style borders. No chance to mistake what happened when you see that page come up.
Flashing lights and sirens would be a bit over the top for our button down management, but I did manage to sneak in a stealthy little "shutter click" camera sound effect as the OnClick for the "I accept that visiting this page may be in violation." button.
Amazing how may people get the In-Your-Face warning page and see it as a personal challenge, and waste the next half hour hunting for the one obscure pr0n site that Websense doesn't yet know about...
Before leaving a job, I'd work extra hard for the last few weeks. When a new potential employer calls to ask about past job performance, your boss will likely give them a good review of you [like 'He has been finishing projects ahead of schedule.'], rather than the 'legal requirement' version [such as 'he works here and was hired on @date@, and he does his work.']
Keep in mind that for many employers, policy forbids giving any information beyond the 'legal requirement', good or bad, so there is no incentive to kiss up instead of just telling them to kiss your ass goodbye.
But you can burn your bridges if you want to...
Agreed. Leaving on good terms might hurt your ego, but it can pay off in the long term.
I haven't done the investigation as to why, but SSG (and by extension, scp/sftp) doesn't approach the throughput of FTP.
Most likely culprit is the general protocol overhead of SSH, even when compression and strong encryption are both disabled.
For example, across a 100Mbps switch between two machines, transferring large (700MB ISO images) files with FTP or even NFS gives an average throughput of 70Mbps, while using 'scp' (blowfish, no compression) tops out at 10Mbps for the exact same file.
Oddly, even using 'scp' on loopback on a 1.4Ghz FreeBSD machine hits the same hard limit of ten megabits?
even if you had the.COM zone, i believe you'd need a system capable of handling a process of something like 2-4GB in memory - 64bit, and a customized bind most likely.
Using tinydns, serving the.COM zone from a 32-bit OS with just 2Gb RAM (total, not image) is entirely feasible.
It's not so much that DJB and the CDB file format is so tiny and efficient (though it is) as it is that BIND and BIND zones are huge and bloated.
I agree, take back the roots. I notice that the.ORG zone removed the Verisign nameservers earlier this month. Any connection to SiteFinder?
Skapare writes:
Why not just take back the roots? The only reason Verisign can do what they do is because the GTLD servers they control are delegated to by the root servers (not sure who controls those anymore, but it can't be good). And those root servers are configured in the hint file of name servers all over the internet. So who controls those? We (who have our own name servers) do.
I run my own root on most of my networks and employers' networks -- it's easy to implement and more efficient. (That said, we do it for security, to keep lookups for bogus TLDs from going out over the internet.)
It's a little harder, but not a lot harder, to just run your own root zone. The biggest thing is to gather up all the NS records and associated A records for each TLD. That's a small list (relatively speaking), so it could be done via a few hundred dig commands to the root servers. Or it can be downloaded. Now once you have that data, you replace the.com and.net zones with your own. Of course that begs the question, replace it with what?
Overriding "." on your own nameserver is easy, as the delegation information for BIZ/INFO/COM/NET/ORG/UK/TV/etc is easy to obtain and doesn't change very often. Overriding the TLDs themselves, going from serving "." to serving ".COM", is a much more difficult project.
Unlike the "." root zone, the.COM zone changes twice a day, is HUGE, and the zone file itself is not readily available to the general public.
Verisign can break Vixie's patch. All they have to do is set up a separate name server which pretends to be a.com and.net server, with the very same wildcarded A-record.
...
Then we'll have to make DNS servers filter out specific delegations
IIRC, there is already a BIND feature to not query certain nameservers (by IP or subnet), it's one of the effects of BLACKHOLE.
I agree, Verisign could make things difficult for DNS administrators who want to "go back to the way things were" before Verisign decided that they wanted to turn.COM and.NET back into being their own little private profit center.
Hopefully Verisign realizes that this could evolve into a nasty little war, resulting in perhaps the establishment of a new form of RBL.
If there's two things Vixie knows, they are DNS and RBL...
My guess is that Verisign does log the requests received, but does not normally go to the effort to correlate the DNS requests with hits to SiteFinder, and that if you want to mess with their marketing data, you would want to send bogus requests to the SiteFinder HTTP, not just bogus DNS queries.
Does anyone know if you can directly ask a root server about a domain? I didn't think mere mortals could
Yes you can.
Any host can make non-recursive requests to the root servers.
Technically, if a query for whatever.com arrives at a root server, it should only return the list of NS records for.COM, and if a query for whatever.com arrives at an authoritative server for.COM (many roots are also.COM servers), it should only return the registered NS records for whatever.com.
In fact, that is exactly the problem -- the Verisign roots should return only NS or NXDOMAIN records, but for names in.COM.or.NET, they instead "synthesize" an A record, pointing to sitefinder, with a 15 minute TTL (cache lifetime).
The various hacks either ignore the specific A record, or ignore records from root servers other than NS. The latter is a cleaner approach, IMHO.
Anyway, why fit a mouse with leather? Your hand gets very warm and sweaty from playing games and sometimes just doing regular work on the computer so why would you want a leather covered mouse? I'm sure it'll be a lot of fun having your hand stick to your mouse when it's too hot. And wouldn't the sweat really wear down the leather and like ruin it? Won't whatever dye they use bleed onto your hand? I dunno it just doesn't seem like a good idea.
Sounds like you haven't had experience with good quality leather.
Good italian leather or suede does not have any issues with the dye bleeding or the leather suffering from contact wear.
Luxury cars are using a perforated leather with a fan under the seat to address the heat/sweat/stickiness problem. I know there are game controllers using a similar technique with perforated plastic.
I want a leather mouse covered in real mouse leather, even if does require skinning a half-dozen fieldmice to get full coverage.
Slashdot Mirror
Neither site contains much in the way of weapons, there is actually more "gun porn" on the Brady web site than on the ILA web site.
Listing only the sites that take a stance for "weapons ownership rights" and against restrictive gun laws under the "weapons" category, while not listing the sites that take a stance against these rights and for more restrictive gun laws, does appear to reflect a political agenda.
On the last full workday before the holidays, as we walked out the door the boss handed out envelopes each containing ten crisp new $100 bills.
The amount never showed up on our W-2s, either.
That said, a thoughtful gift is also appreciated. One of my big corporate gigs gave everybody an expensive fruit basket -- unlike a ham, even the vegetarian employees could enjoy that.
I suppose it would still have offended the hardcore organic vegans, who would find fault in the use of pesticides and such, but I'm not going to complain when I see oranges bigger than most grapefruits, and yet also sweet and juicy...
I won't try to argue with that.
But where do the people who *do* know shit technically hanging out now? Certainly not K5...
Sure, there might be a few actual cipherpunks hanging out chatting on SILC, but I'm more interested in message boards than in realtime chat. I'm on BOFHnet, but that's devolved to a social clique of bitten unemployed sysadmins.
Suggestions?
The key difference here is that the honeypot is passive, it does not go out looking for vulnerable hosts, it waits until after the three-way TCP handshake on TCP/135 is complete, and only then does it react.
Spoofing complete TCP sessions is non-trivial, making false-positives (especially for a two-stage worm like Blaster and Nachia, using two different sessions to complete the infection) highly unlikely.
Secondly, while I agree that vigilante entrapment on the wild Internet is a dangerous direction, the basic concept is a sound approach to handling worm propagation within an ISP, corporate WAN, or other "private" (Internet-connected or otherwise) network where the honeypot operator has the legal and moral right to act.
Also, the AT&T whitelist effort appears to be targeted at their current existing IP connectivity customers, which is a much smaller pool of addresses and servers than the Internet as a whole.
- Encrypted with your public key
- Signed by one of your "trusted signers" using their private key.
The first requirement allows any random stranger to send email to you, if they are willing to put in the extra work and CPU cycles to obtain your published key and encrypt with it. This knocks out the broadcast mass spam mailings.-or-
The second requirement provides a workaround for legitimate mailing lists and other broadcast messages -- when you sign up for a mailing list or sign up for Aunt Martha's christmas letter, you can add them to your list of trusted signers.
The major problem remaining is how to get the Aunt Martha's of the world to start using PGP/GPG...
In my experience, corporate and large ISP outbound mail gateways do not move around much, if at all.
Also, the AT&T whitelist effort appears to be targeted at their current existing IP connectivity customers, which is a much smaller pool of addresses and servers than the Internet as a whole.
The use of certificates give a number of options -- you could trust the usual root CAs, and you could also choose to trust certificates that you yourself sign, or signed by some other trusted third party. Somebody like MAPS or SpamCop or AT&T could provide signing services, offering to sign for a fee, for a bond, or (getting back onto the current AT&T topic) only sign for their customers and partners.
However, spammers routinely do try to turn ordinary personal broadband-connected PC's into spam-transmitting SMTP clients, and these would be machines that would not normally have a valid "SMTP Certificate" assigned to a static IP (if they have a static IP at all), and thus would not pass even the most basic trusted client certificate check.Hackers who build up a zombie army of hundreds or thousands of compromised Windows hosts are not likely to go out spend $$ to purchase a signed certificate for the (short-lived) IP address of each zombie.
Corporations who manage a couple (or a couple dozen, in the case of AOL) separate outbound SMTP gateways would likely not have a problem with paying a few bucks per server to have them "bonded" by one or more CAs. Abuse the privilege and you forfeit your bond.
I believe that AT&T customers who only use AT&T for transit (have their own AS and portable IP blocks) also received the letter. Only other way I could have gotten it is based on some old DNS registrations delegated to AT&T...
Took me a bit to figure out what "LIR" (Local Internet Registry.) refers to, since I've been out of the retail ISP game for many years. Turns out, "LIR" is not very clearly defined, it just means an ISP to which IP space has been allocated?
Another thought is that perhaps AT&T EMS is planning to subscribe to Vixie's RBL+, and want to first whitelist all of their customers, to prevent legitimate customer email from getting blocked by an overly broad stroke of the dynamic blacklist...
That's what I was thinking, but it looks like RMX is dead in the water, the link to the memo from the IETF ASRG website goes 404.
Looks like TLS (SMTP over SSL with client and server certificates) is our only hope. I was at a recent Open Group messaging conference (formerly X.org) where the main topic was spam, and there is definitely interest in this approach.
Only real difference is that most companies don't have the balls to send this kind of broadcast mail message...
I've received both the original short message and the longer followup message. The long message includes contact information at the end, names and a 800 number. The names given are actual AT&T employees.It looks legitimate to me, the reply email address is given as rm-antiattspam at ems dot att dot com (bot-proofing added by me). I haven't actually responded yet, but other role accounts at AT&T also take the form of rm-something@ems.att.com.
There *was* a IETF draft for "RMX" (Reverse MX) published by the IETF's Anti-Spam Research Group (ASRG), but it's not really ready for prime time.
Your best option to "get away with" (for a little while) browsing stuff at work that they don't want you browsing is to proxy your requests through a HTTPS TCP/443 proxy of your own construction, and keep the connections short and the traffic low-volume.
Or better yet, when you are at work, do your job, and save the NSFW web browsing for when you are off the clock, on your own time, your own bandwidth, and your own equipment.
Keep in mind, that for the BOFH, actions like yours scream "I've got something to hide! Investigate me!"
In my experience, most viruses and worms get in through webmail sites, VPN, or laptops. I've even seen SQL-Slammer (aka sapphire, a memory resident worm that goes away when you reboot) show up inside a secure LAN when somebody brought in a suspend'ed laptop from home.
Flashing lights and sirens would be a bit over the top for our button down management, but I did manage to sneak in a stealthy little "shutter click" camera sound effect as the OnClick for the "I accept that visiting this page may be in violation." button.
Amazing how may people get the In-Your-Face warning page and see it as a personal challenge, and waste the next half hour hunting for the one obscure pr0n site that Websense doesn't yet know about...
Keep in mind that for many employers, policy forbids giving any information beyond the 'legal requirement', good or bad, so there is no incentive to kiss up instead of just telling them to kiss your ass goodbye. Agreed. Leaving on good terms might hurt your ego, but it can pay off in the long term.
Most likely culprit is the general protocol overhead of SSH, even when compression and strong encryption are both disabled.
For example, across a 100Mbps switch between two machines, transferring large (700MB ISO images) files with FTP or even NFS gives an average throughput of 70Mbps, while using 'scp' (blowfish, no compression) tops out at 10Mbps for the exact same file.
Oddly, even using 'scp' on loopback on a 1.4Ghz FreeBSD machine hits the same hard limit of ten megabits?
It's not so much that DJB and the CDB file format is so tiny and efficient (though it is) as it is that BIND and BIND zones are huge and bloated.
Skapare writes:
I run my own root on most of my networks and employers' networks -- it's easy to implement and more efficient. (That said, we do it for security, to keep lookups for bogus TLDs from going out over the internet.) Overriding "." on your own nameserver is easy, as the delegation information for BIZ/INFO/COM/NET/ORG/UK/TV/etc is easy to obtain and doesn't change very often. Overriding the TLDs themselves, going from serving "." to serving ".COM", is a much more difficult project.Unlike the "." root zone, the .COM zone changes twice a day, is HUGE, and the zone file itself is not readily available to the general public.
I agree, Verisign could make things difficult for DNS administrators who want to "go back to the way things were" before Verisign decided that they wanted to turn .COM and .NET back into being their own little private profit center.
Hopefully Verisign realizes that this could evolve into a nasty little war, resulting in perhaps the establishment of a new form of RBL.
If there's two things Vixie knows, they are DNS and RBL...
Any host can make non-recursive requests to the root servers.
Technically, if a query for whatever.com arrives at a root server, it should only return the list of NS records for .COM, and if a query for whatever.com arrives at an authoritative server for .COM (many roots are also .COM servers), it should only return the registered NS records for whatever.com.
In fact, that is exactly the problem -- the Verisign roots should return only NS or NXDOMAIN records, but for names in .COM .or .NET, they instead "synthesize" an A record, pointing to sitefinder, with a 15 minute TTL (cache lifetime).
The various hacks either ignore the specific A record, or ignore records from root servers other than NS. The latter is a cleaner approach, IMHO.
Good italian leather or suede does not have any issues with the dye bleeding or the leather suffering from contact wear.
Luxury cars are using a perforated leather with a fan under the seat to address the heat/sweat/stickiness problem. I know there are game controllers using a similar technique with perforated plastic.
I want a leather mouse covered in real mouse leather, even if does require skinning a half-dozen fieldmice to get full coverage.