[Dnssec-deployment] Something rotten in the state of itar.iana.org

[Michael Graff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2010-08-23 10:52 AM, Kim Davies wrote:
> We first observed this problem in the last few weeks, and our network staff have been working on it. The version with the out-of-date data is a luke-warm standby which should never normally be "online", but for some reason is occasionally being hit by about 5 unique remote IP addresses. The workflow daemon only operates on the active version, which is responsible for generating the export files, which is why you see old snapshots is behind if you hit the standby, even though the data is in sync if you browse the web listing.
> 
> I've passed on this additional data which I hope will help our engineers nail the cause.

Any luck with this?  Could someone just go to the broken machine and
'rm' the TAR or its signature?  DLV flip-flopped twice in the last 24
hours, as did another script which pulls from the ITAR and configures
trust anchors.

All times are in US Central time:

  Bad ITAR:  08-24 23:15
  Good ITAR: 08-25 00:15
  Bad ITAR:  08-25 04:15
  Good ITAR: 08-25 05:15

The zones affected by this:  na, se (replaces key), and all the xn-*
zones.  cz was affected as well in DLV, and likely still is in scripts
which pull the trust anchors as DS records and use them directly.  The
BIND 9 script has to do a DNS fetch of the DNSKEYs, compare it to the
DS, and then add it as an anchor, and the bad-ITAR cz key isn't in DNS
anymore, so isn't added.  However, DS-using servers are likely affected
if they use a script like this.

- --Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx1N5oACgkQ+NNi0s9NRJ0+MwCeJ9+w/o4FiHPeEU647SruLA9v
cd0An20Zy/RpQ7aeIjoif2TyaBquZIwi
=m8iE
-----END PGP SIGNATURE-----