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.)
Moving to the DNS-vendor standard answers of "just use DDNS" or "put it in
an IPAM" add additional complexity, and additional attack surfaces. DNS
servers have a tenuous relationship with database backends, and I spend
enough time patching my DNS servers without having to patch an IPAM.
Doing those things aso loses me my full history, which I may need when
going back over what the state of the zone was months or years ago.
Doing inline-signing allows me to keep my data as mine, in a backend
format that's understood and can be agreed-upon in an organization. A
person managing RDNS for a couple of forward zones and a couple of /24
address blocks doesn't have the need for that complexity.
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.
On COVERT:
ISC, a while ago, did that thing we're all guilty of a while ago. Our
DHCP (classic) server puts DDNS things in a TXT record without ("v=foo;")
qualification. Later, we gained the option to use a DHCID record, which
at least doesn't overload TXT, but suffers the same problem that COVERT
attempts to fix.
This isn't particularly secret data (an internal hash), but it's also not
particularly public data either. This data *could* be construed to be
some sort of key into what is personally identifiable information -- not
on its own, but as part of a larger footprint, or by looking at
rate-of-change in a PDNS DB. To those who would ask "what would we use a
covert record type for?", this is one possible candidate. If COVERT is
adopted for consideration, I could see the DDNS component of DHCP servers
being made COVERT-aware, day one.
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
