Hi Francis
On Tue, Jul 18, 2017 at 01:17:58PM +0200, Francis Dupont wrote:
> In your previous mail you wrote:
>
> > There are still many popular unsigned zones, many of which don't look
> > like they will be signed soon due to operational and other reasons.
> >
> > Will you give some thought and reply with your opinion on NSEC/NSEC3 for
> > unsigned zones requiring the DNS COOKIE option in transmission, that can
> > be used with draft-ietf-dnsop-nsec-aggressiveuse?
>
> => I can't parse your message:
> - unsigned zones have no zone keys
NSEC needs no keys, only their RRSIGs would which wouldn't exist in
unsigned zones. In this case the unsigned NSEC would also not be part of
the zone (it would have to be synthesized and maintained outside the
zone).
> - DNS cookie was designed to give a return routability proof for the client,
> not the server
> - there is no NSEC/NSEC3 in an unsigned zone
> Perhaps you mean to return a synthesized NSEC/NSEC3 and the DNS COOKIE is
> as usual required to avoid amplification DoS.
This was discussed during the ISC 2017 all-hands; I don't remember if
you were in the meeting when we discussed it (I think the meeting topic
was about DoS mitigation measures).
Because an unsigned/unauthenticated NSEC/NSEC3 has the potential to nix
entire zones, when it was discussed, Mark Andrews suggested that
requiring DNS COOKIE to further reduce the chance of cache poisoning
(more than source port randomization and random message ID) could be a
reasonable idea to think about.
> But what will be the signing key (including on the client side) and
> what to put in the NSEC/NSEC3? Perhaps this applies only to authoritative
> servers of the (unsigned) zone?
> It seems easier to remember that DNSSEC offers proofs for denial of existence.
Mukund
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
