Keys at apex problem

[Dan Massey <masseyd@isi.edu>]

Hi,

Looking back on the namedroppers discussion, it seemed like the
consensus was that non-zone keys shouldn't be present at the
apex (I agree) and that this problem could be resolved by adding 
a SHOULD to the spec (I don't agree).  

I'm currently facing this problem in practice and it is not clear
(at least to me) how to proceed.  The zone causing the problem is:

$ORIGIN east.isi.edu.
@   IN   SOA ....
    IN   NS @
    IN   NS ns.isi.edu.
    IN   MX 10 @
    IN   A 38.245.76.2	
bb  IN   A 38.245.76.99
...

In addition to becoming a secure zone, this zone wants to participate
in our ssh experiment.  In the ssh experiment, hosts store their ssh
key in the DNS and the ssh client has been modified to lookup host keys
from the DNS.   This all works fine except for that annoying A record
for east.isi.edu.  After adding the keys, the zone would look like:

$ORIGIN east.isi.edu.
@   IN   SOA ....
    IN   SIG (for SOA by east.isi.edu zone key)
    IN   NS @
    IN   NS ns.isi.edu.
    IN   SIG (for NS by east.isi.edu zone key)
    IN   MX 10 @
    IN   SIG (for MX by east.isi.edu zone key)
    IN   A 38.245.76.2	
    IN   SIG (for A by east.isi.edu zone key)
    IN   KEY (zone key for east.isi.edu) 
    IN   KEY (ssh host key for 38.245.76.2)
    IN   SIG (for KEY set by east.isi.edu zone key)*
bb  IN   A 38.245.76.99
    IN   SIG (for A by east.isi.edu zone key)
    IN   KEY (ssh host key for bb, 38.245.76.99)
    IN   SIG (for KEY by east.isi.edu zone key)

    *note that we are using the SIG@parent approach
     so the SIG by isi.edu is stored at isi.edu

Do I tell the administrator to:

1) Ignore the SHOULD and put the ssh key at the apex anyway.
       The isi.edu zone will have to store the ssh key
       and east.isi.edu must involve the parent in any ssh key change.
       The ssh client should accept the ssh key for east.isi.edu based on 
         the SIG from the isi.edu zone key?? (stored at isi.edu)
         the SIG from the east.isi.edu key?? (stored at easti.isi.edu)
         either SIG??
         both SIGs??

2) The A record is no longer allowed at the apex 
       Forrest (the administrator) will point to zones like slashdot, cnn,
       etc and say they do similar things.  He is not doing anything
       particularly unique and nothing in the specs say he is wrong... 

3) The SSH keys shouldn't be present in the zone file. 
       Replace SSH with IPSEC, SSL, etc, etc and you have the same problem.  
       If the KEY record is only for zone keys, let's make the spec say that.

Currently I'm using option 4 which is to avoid the east.isi.edu zone
administrator. :)

Dan