On 31.7.2018 16:58, Tony Finch wrote: > Petr Špaček <petr.spa...@nic.cz> wrote: >> On 30.7.2018 15:32, Tony Finch wrote: >>> >>> I keep thinking it might make sense to sign non-authoritative delegation >>> records, though it's really hard to see how we could get there from here. >>> For instance, there isn't a flags field in RRSIG so you can't explicitly >>> mark an RRset as being non-authoritative. >> >> It is! RRSIG has signer name field which points to node with particular >> DNSKEY. If signer name is shorter than zone apex name the signature was >> created by someone up the tree. > > It would be nice if that is enough :-) For NS records the RRSIG signer > will either be the same as the owner (apex RRset) or shorter (delegation > RRset). For glue it's not so clear-cut if you don't have any > apex/delegation records to hand. But maybe the other context is enough - > the section that the records appear in, the RFC 2181 priority order. > > The other question I can't answer is whether existing validators will be > discombobulated by an RRSIG of unknown algorithm on a delegation NS > RRset...
Well, there is a posibility not to send out these RRSIGs for normal queries. Auth server has to have special code to handle delegations anyway so I can imagine that these parent-side RRSIGs are present only in zone transfer. One problem I can see is that these additional RRSIGs effectively prevent modification of data but not removal of glue (or NS in out-out intervals) ... -- Petr Špaček @ CZ.NIC _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
