[Dnssec-deployment] RRSIG for arpa expired

[Eric Osterweil]

On Jun 7, 2010, at 9:58 AM, Casey Deccio wrote:

> On Mon, Jun 7, 2010 at 9:14 AM, Paul Vixie <vixie at isc.org> wrote:
> i think that right now dnssec is somewhat new and that we can still safely
> fall back to "no validation" when folks make mistakes. as we learn from those
> mistakes it'll become viable to fall back to "no data" when folks make
> mistakes. early adopters expect pain, but having gethostbyaddr() universally
> fail only because ISC DLV imported the IANA TAR is probably too much pain.
> 
> 
> I agree.  That's precisely why in my organization, for the time being, we're doing both: validation on our primary resolver and no validation on our secondary.  Stub resolvers fail over to the secondary if validation fails, so customers can still get their work done.  But alerts of failed validation by the primary are sent to DNS admins, so we can help identify the issues.
>  
> when the root and ARPA are signed, then the cost of signing with the wrong
> key or letting it expire will be universal failure of gethostbyaddr(). so, we
> need to stop making mistakes with our keys and signatures.
> 
> I think one of the big issues that has troubled deployment is that all the maintenance issues seem to be lumped together by administrators, with regard to priority.  Key rollovers, for example, have their place in DNSSEC deployment, but coming from the unsigned world they add a lot of maintenance overhead/concern/frustration for relatively little return on investment (IMHO).  Frankly, at this point in the game key rollovers are not at all important compared to signature freshness.  I'm not suggesting that we educate administrators to avoid key rollovers, but that there is an understanding that some things are more important than others, with regard to DNSSEC, and not everything needs to be deployed at once.

There is an operational tradeoff there, though.  Large keys are stronger and may be impractical to factor, but with middleboxes and PMTU issues, they may not reach resolvers without incurring large latencies for timeouts and possibly TCP fallback (or higher name server load, depending on your perspective).  On the other hand, smaller keys will be more likely to get through the network w/o trouble, but may cause some people to worry about factoring.  Thus, we have a tradeoff, and some look to rollovers to deal with it.

I think the biggest pitfall will be to prescribe a one-size-fits-all solution here.

Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20100607/4507a3ce/attachment-0001.bin