On Mon, Jul 22, 2019 at 2:00 PM Dan Mahoney <dmaho...@isc.org> wrote:
> After a hallway conversation with Evan yesterday, I wanted to clarify a
> few things that I came across when working on this. Point one is the
> use-case of NOTE. Point two is an argument for the general usefulness of
> a COVERT record.
>
> On NOTE:
>
> I am an admin who uses my zone files as a source of truth -- which
> include comments, versioning, and formatting. (I also commit to version
> control, and there's a $Id: $ tag in my zonefiles.)
>
> I'd like the ability to have some degree of human-intended metadata
> survive an AXFR, to be able to promote a slave copy of a zone to being
> master, promote versioning, and keep my zonefiles readable within my
> processes. I am not suggesting NOTE be anything but exactly what its name
> implies: not a hook for some kind of inter-server transfers or private
> keys, just things like "remove after 1/1/2020" or "allocated to group foo"
> or even "generated from config DB on $date". I especially intend to
> state, perhaps with stronger language, that NOTE SHOULD NOT used for
> things intended to be machine-parsed the way we've overloaded TXT.
>
> I'm an operator. Among my credentials: I operate personal infrastructure,
> ISC's infrastructure, and a nontrivial amount of the infrastructure for
> the root zone. This is the operational input I'm told the IETF community
> craves and suggests an issue of not getting until after a standard passes..
>
>
Dan,
I think all of this makes sense, what does not make sense is to stuff this
into old "AXFR/IXFR" semantics.
The draft is already changing how "upstream" deals with "downstream" in
this proposal.
My suggestion is to take a step back and say we have outgrown AXFR and we
need better mechanism to sync
various servers.
Lets start work on a new "SYNC Name servers" protocol that can meet modern
requirements
My list of features that I would like to see:
-- DNSSEC awareness (MIXFR)
-- Long lived TLS connections that allow
--- updates of multiple zones
-- adding and removing of zones
-- Configuring service parameters: online-keys, ACL's, logging
status ......
-- even send back logging information
This would allow us to get rid of Notify, catalog zones, and few other
warts that have been added on over the years.
Olafur
> Best,
>
> -Dan
>
> On Sat, 6 Jul 2019, Evan Hunt wrote:
>
> > Colleages,
> >
> > Some years ago, Dan Mahoney and I submitted a draft describing a proposed
> > mechanism for storing confidential zone comments alongside normal zone
> > data - a NOTE RR, which would be transferrable from primary to secondary
> > servers, but not accessible to ordinary DNS queries. It generated some
> > iniital interest, but not much momentum, and we let the proposal lapse.
> >
> > More recently, Witold Krecicki had a very similar idea for a mechanism to
> > disseminate private key data between primary and secondary servers. We
> > talked it over and decided to expand the NOTE record semantics into a
> > generic method for storing and transferring covert in-band zone data.
> >
> > The generic mechanism is described in draft-krecicki-dns-covert-00. It
> > calls for the allocation of a range of "Covert-RR" type code values,
> > which would have restrictions on their dissemenination. A primary server
> > implementing Covert-RR types must not allow them to queried, nor to be
> > transerred to a secondary server unless that server indicates via an EDNS
> > option that it *also* understands Covert record semantics and will not
> > transfer the data to any peer that doesn't.
> >
> > The original NOTE RR draft has been shrunk down and rewritten as a
> > proposed use case for Covert RR's. Additional use cases will be coming
> > in the future; in particular, draft-pusateri-dnsop-update-timeout seems
> > like it might be a good candidate.
> >
> > Details are below. Please have a look. Thanks!
> >
> > --------
> > Name: draft-krecicki-dns-covert
> > Revision: 00
> > Title: Domain Name System (DNS) Resource Record types for
> transferring covert information from primary to secondaries
> > Document date: 2019-07-06
> > Group: Individual Submission
> > Pages: 6
> > URL:
> https://www.ietf.org/internet-drafts/draft-krecicki-dns-covert-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-krecicki-dns-covert/
> > Htmlized: https://tools.ietf.org/html/draft-krecicki-dns-covert-00
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-krecicki-dns-covert
> >
> >
> > Abstract:
> > The Domain Name System (DNS) Resource Record TYPEs IANA registry
> > reserves the range 128-255 for Q-TYPEs and Meta-TYPEs [RFC6895] -
> > Resource Records that can only be queried for or contain transient
> > data associated with a particular DNS message.
> >
> > This document reserves a range of RR TYPE numbers for Covert-TYPEs -
> > types that are an integral part of the zone but cannot be accessed
> > via a normal QUERY operation.
> >
> > Uses for such records could include zone comments that are
> > transferrable with the zone, expiry times for dynamically updated
> > records, or Zone Signing Keys for inline signing. This document,
> > however, does not define any specific Covert RR types.
> >
> > --------
> > Name: draft-hunt-note-rr
> > Revision: 02
> > Title: A DNS Resource Record for Confidential Comments
> (NOTE RR)
> > Document date: 2019-07-06
> > Group: Individual Submission
> > Pages: 4
> > URL:
> https://www.ietf.org/internet-drafts/draft-hunt-note-rr-02.txt
> > Status: https://datatracker.ietf.org/doc/draft-hunt-note-rr/
> > Htmlized: https://tools.ietf.org/html/draft-hunt-note-rr-02
> > Htmlized: https://datatracker.ietf.org/doc/html/draft-hunt-note-rr
> > Diff: https://www.ietf.org/rfcdiff?url2=draft-hunt-note-rr-02
> >
> > Abstract:
> > While the DNS zone master file format has always allowed comments,
> > there is no existing mechanism to preserve comments once the zone has
> > been loaded into memory or converted to a binary representation.
> > This note proposes a new RR type "NOTE", to be allocated from the
> > Covert-RR type range proposed in [I-D.krecicki-dns-covert], so that
> > confidential comments can be stored alongside zone data, and included
> > in zone transfers when Covert semantics are supported by the
> > secondary.
> >
> > _______________________________________________
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> >
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
--
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
