A driver for this card is included in the standard CentOS 5 kernel (tested with kernel-2.6.18-164.9.1.el5) under the name rt61pci, however to be able to function a binary firmware is needed. Some searching revealed that the firmware is available in Fedora's rt61pci-firmware package. I rebuilt the package and put it in my CentOS playground repository.

So, if you have such a card and want to make it work in CentOS5 you might want to try running rpm -ivh http://rpm.resare.com/centos5-playground/i386/rt61pci-firmware-1.2-6.el5.noarch.rpm as root. Once that is done, running modprobe rt61pci should do the trick.

DNSSEC protects the DNS system against a certain group of security problems such as the kaminskybug, where an attacker tricks a DNS server to return the wrong data to end users. If an attack against the DNS system is successful that means serious trouble, since we depend on it to work reliably in a vast number of online activities. An attacker that controls the DNS system can trick people to for example supply their account information to their online bank and use that to steal money. Whenever there is the potential for large scale fraud you can pretty much be sure that someone will try to break it, and that is why DNSSEC is important.

So, we need DNSSEC. What's stopping us from using it? A few things, but the most important obstacle in my opinion is that it is a complex set of standards and that it is difficult to understand. There are some presentations and HOWTO documents online that attempts to explain and help people get started, but the learning curve is steep. One thing that I ran into when experimenting with my own zones was that somehow I managed to corrupt the signatures of one zone and I couldn't easily pinpoint what the problem was.

When confronted with this I got the idea to build an online service that tries to answer a simple question. What data was used and what cryptographic operations was performed to actually verify one specific DNS record? The answer to that question can be thought of as a chain of operations and records where one link connects to the other from all the way from the record being verified down to the DLV root key.

I decided to write the service in Python and it was one of the most fun programming projects that I have worked on in years. In a way it was basic research but with a clear application and an end result that I think could be a useful contribution. I even wrote my own RSA signature verification functionality, with a lots of help from Python's excellent large integer support.

The service can be found at http://dnssec.resare.com Feel free to give it a spin. There are no doubt bugs and errors that will be fixed and other modifications that will be made, but the basic functionality is in place.

Thanks to Alex for the beautiful HTML design,  to the python dns library dnspython that I use extensively and the airspeed templating library.

I've been missing that functionality on my Mac, so I wrote a small wrapper to the openssl command that provide the same basic functionality using Python. Python is really handy when it comes to writing small scripts like that does some string handling and calls other programs and since the basic checksumming functionality already is available in the openssl package it simple, short and neat.

As usual, feel free to use this any way you want.

 
#!/usr/bin/python
 
import subprocess
import sys
 
def checksum_file(filename):
    sp = subprocess.Popen(["/usr/bin/openssl", "sha1", filename],
                          stdout=subprocess.PIPE)
    retval = sp.communicate()[0]
    return retval[retval.find("= ") + 2:-1]
 
def verify(checksumfile):
    f = open(checksumfile, "r")
    for line in f:
        line = line[:-1]
		(sha1, fn) = line.split("  ")
		calc = checksum_file(fn)
		if calc != sha1:
            print "%s: FAILED" % fn
            sys.exit(1)
        else:
            print "%s: OK" % fn
 
def usage():
    print "Usage: sha1sum [-c CHECKSUM_FILE] [FILE]..."
    sys.exit(1)
 
if __name__ == '__main__':
    if len(sys.argv) == 1:
        usage()
	if sys.argv[1] == '-c':
        if len(sys.argv) != 3:
            usage()
        verify(sys.argv[2])
    else:
        for f in sys.argv[1:]:
            print "%s  %s" % (checksum_file(f), f)
 

Unlike most of the internet i use Unbound instead of bind as my nameserver. It offers great DNSSEC support as well as a well maintained code base. One recent feature is the use of mixed case labels when sending queries to other nameservers, as outlined in the DNS0x20 document. This is one countermeasure to the DNS Spoofing attacks that is an increasing problem on the internet these days, and it depends on the fact that name servers should treat queries that only differs in the case as if they were equals. In other words, mobizoft.qbrick.com and MobiZoft.Qbrick.com should be treated as the same.

The exact wording of the specification can be found in RFC1035 section 2.3.1:

Note that while upper and lower case letters are allowed in domain
names, no significance is attached to the case.  That is, two names with
the same spelling but different case are to be treated as if identical.

Unfortunately, Qbrick's nameservers fail to implement this specification, and mixed case questions gets answered with the NXDOMAIN reply code, which means that there is no data for the given domain name. I hope that Qbrick will get their act together and fix this soon, but in the meantime it can be a good idea to use the use-caps-for-id: no directive if you are using unbound.

In summary it is a bit annoying that errors like these are so hard to find and correct. Most video displaying flash plugins will not report a meaningful error, and the fact that SVT uses an external provider for their streaming video solution puts the problem even further away from the end user.

Update 091104: I have now gotten in contact with Qbrick. They recognize the problem but state that they have an ongoing project to replace the DNS solution and they will not address this issue until the new solution is in place.

1. The text was encoded in UTF-8 in the old database, but mysql thought that it was what it calls latin1. What I had entered as å the database perceived as Ã¥, but the transformation was applied on both write to and read from the database, so the characters turned out to be correct when displayed in bugzilla again.
2. The default behavior of mysqldump is to treat data it knows to be latin1 into UTF-8 in the output file. Since my data was really UTF-8, but mysql was under the impression that it was latin1, it encoded the UTF-8 into UTF-8 once more.
3. To make matters even more complicated, what mysql calls 'latin1' is not actually ISO-8859-1 but rather a slightly modified variant of the Windows-1252 character encoding. A result of this is that in some instances the double application of the UTF-8 transformation a single input character results in 5 output characters.
4. The solution to this mess is a curiously named option to mysqldump named --default-character-set. It can be used to override the default behavior of encoding strings marked as latin1 into UTF-8. mysqldump --default-character-set latin1 outputs my UTF-8 correctly. Once the database is in a file, just search and replace default charset=latin1 with default charset=utf8 and import the data.
5. At this point, the data that was UTF-8 all along is now correctly understood by mysql to be UTF-8.
6. Next problem: when starting up bugzilla with UTF-8 settings the characters still gets mangled.
7. It turns out that the bridge between mysql and perl in CentOS 5, the perl-DBD-MySQL package, is too old to support the mysql_enable_utf8 connection parameter. As a result, strings coming out of perl-DBD-MySQL containing non-ascii is not marked as utf8 strings.
8. So, why didn't checksetup.pl tell me this when I ran it? It turns out that there is a patch in the bugzilla shipped with EPEL to remove the check for the proper perl-DBD-MySQL version to make it runnable on CentOS 5. Perhaps a reasonable tradeoff, but a bit annoying when trying to find out what fails.
9. So I compiled a recent perl-DBD-MySQL and put it in my playground repository and now my bugzilla displays all sorts of strange characters correctly.