About a month ago, I posted this: http://mailman.archlinux.org/pipermail/arch-dev-public/2012-February/022548.html
Your input would have been welcome then...

Also, I do not really see the point of your PKGBUILD: downloading the PGP key from ICANN and using it to verify the root-anchors.xml file is no more secure than just checking the hash of that file, since your PGP client has no means to know whether or no this key should be trusted.

But more importantly, what trusted-key.key file does your package propose to ship? root-anchors.key? Running "dig +sigchase icann.org" with that file as /etc/trusted-key.key yields "No trusted keys present" when it works perfectly with the /etc/trusted-key.key shipped by the current dnsutils.

To sum things up: as per the post I linked to above, I will release a dnssec-anchors package in [core] when OpenSSH-6.0 is released. Useful feedback is welcome, but not merely "it needs more cryptography" (I would retort that the hash function used to verify the integrity of the source files *is* a cryptographic hash function).

To be honest, I completely forgot about the source file integrity checks. However, these checks will only be meaningful when the key infrastructure is complete and present in Pacman. My understanding of Pacman's approach to package verification is basic (feel free to correct me), but as I see it currently, without Pacman's package signing fully working and actively checking PGP signatures, the source integrity check does nothing but verify that the files have not changed since they were packaged. They don't verify that you were the one who packaged them. If a rogue mirror decided to modify the trusted-key.key and release a modified package, the user would have no way of knowing. I'm not sure this is a big risk, but it is something to think about.

As for the trusted-key.key, it's actually in a different format than your supplied /etc/trusted-key.key. It contains the digest supplied by the ICANN/IANA when they released the root-anchors which it uses to verify the result of a DNSKEY query, whereas yours supplies the actual DNSKEY records (which I assume you got from a dig query on the root zone). We're essentially using two different approaches. The trust anchors as I distribute them are intended to be used by drill (from [community]/ldns) and not dig. The version of dig supplied in the main repositories likely did not have DNSSEC support when the dnssec-root-zone-trust-anchors package was created, hence why trusted-key.key is in this format. The original author's rational for this was that the DS format was usable to most applications. This may no longer be true.

It appears that packaging /etc/trusted-key.key in DNSKEY format is the way things are moving now, so here's what I am going to do. I'll keep the dnssec-root-zone-trust-anchors package from symlinking /etc/trusted-key.key to /usr/share/dnssec-trust-anchors/root-anchors.key and will instead add a post_install() hook that verifies that your supplied key works with the digest supplied by the IANA. I'll look into the dnssec-tools package and other related packages that I maintain and make sure that they're not expecting root anchors in DS format.

When time comes for your dnssec-anchors package to hit [core], I'll deprecate dnssec-root-zone-trust-anchors and changes dependencies on aur/dnssec-tools, etc.

EDIT: The first part about Pacman really only applies to people that have not enabled signature checking on Pacman yet.

Nearly all packages in [core] and [extra] are signed, and pacman has the ability to verify them, although it's not currently enabled by default as we are still working on a keyring package. Unless you enabled it yourself, indeed, you need to trust the package mirror you use. If you don't, your gnupg itself might be compromised so there is little point in verifying anything.

Anyway, if you found a way to verify the trusted-key.key file from my package using the IANA-published data I would be very interested in integrating it to the dnssec-anchors package.

I'll let this bug report open until dnssec-anchors goes to [testing] so we can keep discussing it.

Please see if you have any suggestions to improve what I just pushed to [testing].