[RSSAC Caucus] Rogue Operator Work Party: Source of zone data

[Paul Vixie]

On Wed, Oct 07, 2020 at 06:12:02PM +0530, Mukund Sivaraman wrote:
> On Wed, Oct 07, 2020 at 01:11:13AM +0000, P Vixie wrote:
> > Mukund Sivaraman writes:
> > 
> > > On Tue, Oct 06, 2020 at 02:15:21PM -0700, P Vixie wrote:
> > > > ... that's the underlying meaning of dnssec.
> > > 
> > > The root zone is not entirely signed by DNSSEC (NS records at zonecuts
> > > and address glue have no signatures, which could be changed to deny
> > > service to specific TLDs).
> > 
> > this never mattered, and doesn't matter now. if the subzone isn't signed,
> > all hell will break loose, regardless of what's in the root zone. if it is
> > signed, then the DS RRs in the root zone must match the DNSKEY in the
> > subzone. ...
> 
> Sorry Paul, but I wrote that it could be used to deny service to
> specific TLDs. A resolver can be made to go down a rabbit hole with
> this.

i hope you can do some game theory here. a bad NS record set is a problem,
regardless of dnssec status. but, the problem itself is different without
dnssec vs. with dnssec. we (the entire internet technical and governance
community) no longer make extra effort for the non-dnssec problem, either
with an unsigned tld, or a nonvalidating resolver.

> > icann knows they cannot make zone changes of this kind with short
> > turnaround. if this is a bigger problem then they know about, then the dns
> > technical community should document it in an RFC and bring it to icann's
> > attention.
> 
> This scenario isn't limited just to the root zone. 

our work on this committee, however, is thusly limited. broader concerns
(such as your icann.org example) should go to the DNSOP WG.

> From section 6.1 in:
> https://tools.ietf.org/html/draft-ietf-dnsop-dns-zone-digest-11
> 
> >   The zone digest allows the recipient of a zone to verify its
> >   integrity.  In conjunction with DNSSEC, the recipient can
> >   authenticate that it is as published by the zone originator.
> 
> From the abstract:
> 
> > This provides assurance that received zone data matches published
> > data, regardless of how the zone data has been transmitted and
> > received.
> 
> It doesn't say it's limited to AXFR or zone transfers, but then again,
> even if it is limited to transfers, it is typically the way nameservers
> receive zone contents from a "source".

one can only verify that the signed zonemd record has a correct checksum
if one is in possession of the full zone. that means transfer initiators.

-- 
Paul Vixie