« previous 1 2 3 4 5 6 7 next »

Key service

It appears that the authors of the DKIM RFC want their standard to spread as quickly as possible as they included many practical comments, which is not usually done in RFCs. One example is the openssl command for generating the private key: openssl genrsa -out mail200801.private 1024. Any desired name can be given to the key file. For clarity, however, it is advisable to keep the names of key files identical with their respective DNS entries; there are details about this further on. The key length of 1024 is the minimum requirement stipulated in the RFC but is very sufficient at present. Next thing is to extract the public key into the mail200801.public file. This is done by entering openssl rsa -in mail200801.private -out mail200801.public -pubout -outform PEM.

At present, the DKIM standard only provides for public keys to be distributed as TXT records via the DNS. A separate type of record is to be defined at a later stage. However, the content of the PEM file we just created can't be used as a DNS record. The grep -v -e "^-" mail200801.public | tr -d "\n" command removes the public key header and footer as well as the line feeds.

For the bind DNS server, the public key including options shown here in wrapped form needs to go into one line in the respective zone file.

The entire line for the zone file entry in the BIND DNS server will look like the example listed above. The record name consists of the name of the key and the "_domainkey " subdomain. It is advisable to incorporate a version number in the key name as shown. Signature keys should be replaced on a regular basis for security reasons. Keys that are no longer in active use should not, however, be deleted, but instead be recalled. For this purpose, the admin simply puts a record without a key into the DNS: mail200801._domainkey IN TXT "v=DKIM1\; p=" The version number makes it impossible for active and recalled keys to overlap. The "_domainkey" subdomain with its prefixed underscore as stipulated in the RFC prevents the key entry to collide with other names. Apart from the public key identified via p=, the DNS record also contains various parameters. They all share the same notation, separating parameters and values with equal signs without spaces and closing the expression with a semicolon protected by a backslash, "\;".

The v parameter denominates the version of the DKIM standard used. Although it is optional, the RFC explicitly recommends its use. The v= entry must be listed first if there is one. The next parameter to follow is k to specify the key type (key type). This parameter is also optional; the default is "rsa". The last parameter before the key is t, which specifies particular properties like whether it is a test run (t=y). In this case, verifiers can check the signature but are not allowed to rate the message accordingly. When the postmaster is sure about their DKIM installation, they should make a TXT record without t=y available online. For test purposes, the entry can be retrieved using the dig mail200801._domainkey.example.com TXT +short command. Under Windows, the nslookup -type=TXT mail200801._domainkey.example.com command does the same.

« previous 1 2 3 4 5 6 7 next »