Ebooks – Sometimes it’s a bit too hard

I recently updated my ereader from a Kindle 2 to a Kindle Touch. I actually like this device quite a lot. The first thing that got me liking it was the crisper screen. The other was obviously the touch capability.

But over the last few weeks I have begun thinking about just how hard Amazon and BN have made it to competitive shop for ebooks. Both companies have deliberately tied the books behind a DRM scheme. I don’t begrudge them that – much. What I do begrudge is the lack of effort by either side to make things interoperable.

Now granted, five of the top six book publishers have pretty much engaged in a price fixing scheme in order to enforce a minimum pricing for the ebooks that is above what the market would dictate but let’s assume for a moment that Amazon has a cheaper price an a particular ebook than BN. If this was a dead tree version I could easily just buy from the cheaper seller – Amazon. But with ebooks I now have a problem. I have to buy in the format of my ereader – in other words, I have to buy my ebooks from Amazon.

Now for part of this I have found a solution. I use Calibre and I can convert some of the books to the best format for my Kindle which is the MOBI format. But again, with Amazon and BN DRM’d books I have a problem. Likewise, What if I choose to get a Nook in the future? I now have to repurchase my personal library.

I know both companies have PC versions of their reader software. The problem there for me is that those versions are Windows. Neither offers a Linux version. In that case I have to hope that Wine will run the software.

It would be great if Amazon and BN would come out with either a conversion application or a plugin for Calibre. Unfortunately, that would involve breaking the very thing both companies are counting on – lock in. I think this is somewhat short-sighted. If I can buy from both locations why wouldn’t I? Competition would be great. At that point they could concentrate on building better ereader platforms.

Comments Off on Ebooks – Sometimes it’s a bit too hard Posted in Uncategorized


Today I’m going to discuss DNSSEC and some of its implications.


I’ve been doing some research on this subject and been thoroughly amazed at the lack of information available on the internet about it. What little I have managed to find has been lacking in consistency in terms of basic subject matter. As a result I’ve decided to pull what I was able to find together into one easy to understand article.


The principle behind DNSSEC is a simple one. DNS information is signed to ensure that when the information is transferred the receiver has gotten valid information from the sender. This is achieved by signing the zone.


The root servers on the internet use this technology to ensure that the zones being transferred are accurate, thereby preventing DNS poisoning between the root servers.


The basic procedure is this. On DNS server DNSA the zone is created. The zone is then signed and loaded in. DNS server DNSB then requests a zone transfer from DNSA. DNSA sends the information over with the transmission signed with the key. DNSB takes the key and verifies it against the key holding server. If a new entry needs to be made the zone is updated on DNSA, re-signed, and then uploaded into the cache on DNSA again.


Really quite simple sounding. The implementation is obviously harder but this is the basic idea.


At this point a lot of people start thinking this is a really good idea and want to implement it on their networks. This is where I really began to run into trouble trying to pull information on this.


The firs stumbling block is network infrastructure equipment : routers, switches, and of course firewalls. Unlike a normal DNS packet, a DNSSEC packet is much larger – 4000 bytes versus the more normal 512 bytes. Also, unlike normal DNS which can use just UDP, DNSSEC makes use o both UDP and TCP. As a result many pieces of equipment fail to properly process the packets, instead looking at them as corrupt and therefore dropping them. To avoid this problem you should stick to equipment that is at least aware of the EDNS0 protocol, if not EDNS3.


Let’s assume at this point that you do have equipment that is capable of handling this traffic. We now get into the piece that is the hardest to understand for a lot of people : this technology is only good for transferring information between systems on disparate networks. Big sentence and the best example of that it the internet root servers. These are on disparate networks and therefore need a technology for confirming the information is valid.


Moving to your business network DNSSEC offers value in one instance in particular. This is when you have public facing internet servers and want to add another check to ensure the integrity of the data being passed between them. An example of such a case would be where you have a hidden master DNS server and several secondary DNS servers accessible from the outside. Using DNSSEC you can now ensure that if the firewall is compromised and the master is impacted falsified DNS data will not be accepted.


Now comes the problems for moving your business network to DNSSEC. First comes devices on the network that rely on DNS information. I’m not referring to the previously mentioned routers, switches, and firewalls. I’m talking more generic equipment. If you have a device that is not DNSSEC capable it will potentially not operate correctly. This is true of some workstation operating systems as well. These devices and OSes are, like non-DNSSEC aware infrastructure equipment, expecting DNS replies to be a certain size. Due to the larger size of the packets these endpoints may simply drop the packets as corrupt, they may suffer overflows, or they may incorrectly interpret the replies.


Second, Active Directory relies on Dynamic DNS. DNSSEC is NOT dynamic – it is very much static in nature. When a domain controller is brought up it attempts to register several DNS records including at least two SRV type records. Since the zone is now static this fails. Someone has to move the zone to a flat file basis, insert the appropriate records, re-sign the zone, and then move it back. This is obviously sub-optimal.


Third, a lot of clients, and in particular Windows clients, do NOTHING with the DNSSEC portion of a DNS packet. You read that correctly – a Windows client will take the DNS reply and discard the DNSSEC portion of the reply without ever performing any validation of the data. DNSSEC is therefore worthless if your goal is to have clients talking only to specific servers on the network as a rogue DNS server can still be inserted and provide bogus DNS replies to the client (the client will never know the difference). The client end provides no mechanisms for encryption, authentication, or verification.


In short – if your intent is to prevent DNS spoofing on your internal network use the technology that will provide that protection. This is most easily achieved using SSL or IPSec to secure your network.