Subject: [DNSOP] proposal: Covert in-band zone data

From: Evan Hunt <[email-masked]>
Date: Sat, 6 Jul 2019 21:30:24 +0000

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.

---

From: Joe Abley <[email-masked]>
Date: Sat, 6 Jul 2019 15:39:53 -0700

Hi Evan!

> generic method for storing and transferring covert in-band zone data.

What's the use-case for using the DNS to transfer private key data?

At first glance it seems to me that there are a lot of alternative
mechanisms, many of which seem less likely to leak confidential data
than using a protocol that has only really ever been deployed to make
information public.

If there's a good reason to use the DNS for this your proposal seems
like a plausible way to do it (I haven't read it in detail, but you
know what you're doing and I'm sure it's good stuff). It's that first
if that gives me pause.

Joe

---

From: Evan Hunt <[email-masked]>
Date: Sat, 6 Jul 2019 23:00:22 +0000

> What's the use-case for using the DNS to transfer private key data?

Inline signing, I believe.  Witold should be the one to discuss that one,
not me.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Witold Krecicki <[email-masked]>
Date: Sun, 7 Jul 2019 01:05:28 +0200

W dniu 07.07.2019 o 00:39, Joe Abley pisze:
> What's the use-case for using the DNS to transfer private key data?All of those methods require configuring an external, out-of-band
mechanism to transfer the ZSK - using covert records is something that'd
work 'out of the box'.
The primary use case I'm thinking about is to give secondaries the
ability to do online NSEC signing to provide white lies. Proposed NSEC5
also requires a method to transfer the private key to the slave.
And, again - this is just one of the proposed uses of covert RRs, this
document is showing it just as an example.
-- 
Witold

---

From: Joe Abley <[email-masked]>
Date: Sat, 6 Jul 2019 16:09:36 -0700

Hi Witold,

> On Jul 6, 2019, at 19:05, Witold Krecicki <[email-masked]> wrote:
>

Interesting, thanks!

There's an argument, I suppose, that an out-of-band mechanism to
exchange metadata is already required to agree things like DNS NOTIFY
targets, master servers andTSIG shared secrets. Those things already
need to be exchanged securely, so presumably you're not talking about
just setup time, but rather over time to manage automated ZSK rolls,
etc?

Joe

---

From: Witold Krecicki <[email-masked]>
Date: Sat, 6 Jul 2019 23:28:05 +0000 (UTC)

----- Oryginalna wiadomość -----
Od: "Joe Abley" <[email-masked]>
Do: "Witold Krecicki" <[email-masked]>
DW: [email-masked]
Wysłane: niedziela, 7 lipiec 2019 1:09:36
Temat: Re: [DNSOP] proposal: Covert in-band zone data

>just setup time, but rather over time to manage automated ZSK rolls,

Exactly - while the things you mentioned are configuration options that
are 'human generated', the ZSK rollover should be, in the ideal case,
something that happens automatically, without any human intervention. 

-- 
Witold

---

From: Joe Abley <[email-masked]>
Date: Sat, 6 Jul 2019 16:46:36 -0700

> something that happens automatically, without any human intervention.

It wouldn't necessarily be harmful to be able to update those other
things automatically, too. Things like master servers and NOTIFY
targets perhaps change less frequently or predictably than a ZSK, but
in times of emergency all could benefit from a well-designed,
automated and secure mechanism to handle changes.

TSIG secrets are rarely rolled in practice, in my experience, and
being able to improve upon that also seems useful.

I still wonder whether what you're proposing really only solves one of
a wider set of problems, and whether doing it in the DNS really makes
sense. Perhaps a standardised, out-of-band provisioning protocol would
be better.

We might have a need to exchange some other kind of metadata between
authoritative servers for a zone in the future, eg relating to secure
transports or privacy. The idea of being able to provide a general
solution to solve future such problems seems attractive.

None of this is commentary directly about your draft, of course.

Joe

---

From: Witold Krecicki <[email-masked]>
Date: Sun, 7 Jul 2019 01:59:50 +0200

W dniu 07.07.2019 o 01:46, Joe Abley pisze:
> But why put it out-of-band when it can be in-band? This draft is just an
'umbrella' - you can put whatever you want there, and you can be sure it
won't be leaked. There can be a special RR type for master servers - in
COVERT range, there can be a special RR type for TSIG keys - in COVERT
range. It can be used for any type of metadata.
Note: I'm considering adding a 'private' covert range, for
implementation-specific things (just like we have a general 'private' RR
types range).

-- 
Witold

---

From: Joe Abley <[email-masked]>
Date: Mon, 8 Jul 2019 12:20:02 -0400

Hey,

On 6 Jul 2019, at 19:59, Witold Krecicki <[email-masked]> wrote:

> But why put it out-of-band when it can be in-band?

I don't think there's a good general answer to this. Sometimes in-band signalling is good; other times out-of-band signalling has proved to be safer. I'm talking very generally, here, not directly about your proposal.

As far as this particular idea goes, I mentioned before what had given me pause: we're talking about taking a protocol where every RRSet in a zone to date has been public and is made available in DNS responses. Any server that doesn't implement this new mechanism would presumably treat the new covert RRTypes as they would any other unknown/opaque type and make the data public.

There is hence an operational risk that data will leak (e.g. by configuration changes, software downgrades that are pragmatic necessities, side systems that publish zone data in ways other than the DNS).

By keeping data that is already exchanged over a (manual) out-of-band channel separate, and not packaging them up with zone data, the existing segregation of private vs. public is preserved and the task is simply to automate a process that is currently manual.

This might sound like a very high-level concern, but I suspect there are ramifications of changing the security model of the data published in a zone that extend beyond the operation to the wider architecture, e.g. what to do with PII that is published in a covert record, and what extra work results from the changed risk profile of that data? In a segmented security architecture, what are the implications of sensitive material being mixed with public information?

Joe

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 8 Jul 2019 17:20:31 +0000

> On Jul 8, 2019, at 9:20 AM, Joe Abley <[email-masked]> wrote:
> 
> 

I share this concern raised by Joe.  I agree that it can be useful to exchange configuration/provisioning data this way, but leaks seem almost inevitable as proposed.

I'll probably regret this, but what about a COVERT class, instead type RR type?

With respect to 2.6. Interaction with ZONEMD, I'd think it should follow handling of DNSSEC.  That is, covert types should not be included in a zone digest.

DW

---

From: Witold Krecicki <[email-masked]>
Date: Mon, 8 Jul 2019 20:46:42 +0200

W dniu 08.07.2019 o 19:20, Wessels, Duane pisze:>> On Jul 8, 2019, at
> I share this concern raised by Joe.  I agree that it can be useful to exchange configuration/provisioning data this way, but leaks seem almost inevitable as proposed.
We tried to include as many safeguards as possible, but I don't think
we'd ever be able to avoid footie-shootie. I'd just add a section in
"Security consideration" with summary of the issues stated above.

> I'll probably regret this, but what about a COVERT class, instead type RR type?But then a) we'll end up with a dual-class zones b) nobody would
implement it, as I don't think anything but BIND supports classes other
than IN (correct me if I'm wrong?)

Witold

---

From: Brian Dickson <[email-masked]>
Date: Mon, 8 Jul 2019 12:01:46 -0700

On Mon, Jul 8, 2019 at 11:47 AM Witold Krecicki <[email-masked]> wrote:

> >> As far as this particular idea goes, I mentioned before what had given
> me pause: we're talking about taking a protocol where every RRSet in a zone
> to date has been public and is made available in DNS responses. Any server
> that doesn't implement this new mechanism would presumably treat the new
> covert RRTypes as they would any other unknown/opaque type and make the
> data public.
> >>
> >> There is hence an operational risk that data will leak (e.g. by
> configuration changes, software downgrades that are pragmatic necessities,
> side systems that publish zone data in ways other than the DNS).
> >>
> >> By keeping data that is already exchanged over a (manual) out-of-band
> channel separate, and not packaging them up with zone data, the existing
> segregation of private vs. public is preserved and the task is simply to
> automate a process that is currently manual.
> >
> > I share this concern raised by Joe.  I agree that it can be useful to
> exchange configuration/provisioning data this way, but leaks seem almost
> inevitable as proposed.
> > I'll probably regret this, but what about a COVERT class, instead type
> RR type?But then a) we'll end up with a dual-class zones b) nobody would
What about using namespace instead of class or rrtype, or perhaps in
addition to that?
By making it an in-band thing but out-of-name-space, it makes it a little
more difficult to achieve self-immolation.
The namespace could be specified as having local-only significance, and
putting it under a single parent name lets you manage it all however you
want, including potentially in a single zone.
E.g. zone "my.example.com.cover.t", or "example.com.covert.", or even
"covert.". Protect *that* with TSIG etc., or possibly also use DNSSEC
and/or ZONEMD for extra goodness.
Maybe add it to the registry of special purpose names? Basically, if a
query is seen on it, drop it, unless the query is AXFR/IXFR.

Using the namespace allows you to break it up into subzones, e.g. to
correspond to delegated or managed zones, where the transfer tree differs.
Or not, if you don't have that particular use case to handle.

Put it in a reserved TLD that is not delegated, and you should not expect
any queries even by accident.
Add whatever other magic your flavor of authoritative servers supports for
limiting queries etc., and you're golden.

Brian

---

From: Richard Gibson <[email-masked]>
Date: Mon, 8 Jul 2019 15:02:46 -0400

Class is a bad idea for a few reasons, but principal among them in my 
mind is the fact that per section 4.2 of RFC 1034, the concept of zone 
is subordinate to the concept of class—even if zone cuts were in the 
same places, example. in a new class would still be a distinct zone from 
example. in the Internet class.

On 7/8/19 13:20, Wessels, Duane wrote:
> RR type?

---

From: Witold Krecicki <[email-masked]>
Date: Mon, 8 Jul 2019 22:05:08 +0200

> I share this concern raised by Joe.  I agree that it can be useful to exchange configuration/provisioning data this way, but leaks seem almost inevitable as proposed.

One more thing - this feature is intended for operators, not for regular
users. We should have more tolerance for shootfooting features there.

> With respect to 2.6. Interaction with ZONEMD, I'd think it should follow handling of DNSSEC.  That is, covert types should not be included in a zone digest.

As I understand ZONEMD main purpose is to verify the full content of the
zone, mainly for zone transfer. In that case, I'd include COVERT records
- as the clients who can transfer the zone using XFR will also be able
to transfer COVERT records. (but I'm not stuck to that opinion).

Witold

---

From: Witold Krecicki <[email-masked]>
Date: Mon, 8 Jul 2019 22:08:35 +0200

W dniu 08.07.2019 o 21:01, Brian Dickson pisze:
> By making it an in-band thing but out-of-name-space, it makes it a
> little more difficult to achieve self-immolation.
> correspond to delegated or managed zones, where the transfer tree
> differs. Or not, if you don't have that particular use case to handle.
> 
> Put it in a reserved TLD that is not delegated, and you should not
> expect any queries even by accident.
> Add whatever other magic your flavor of authoritative servers supports
> for limiting queries etc., and you're golden.

That breaks hierarchicality of DNS - you have two completely unrelated
(in terms of 'classical' DNS) zones stored in one file. Also - the draft
includes the way to query for those records (useful for example for NOTE
RR), moving them to a different hierarchy somehow breaks that.

Witold

---

From: Bill Woodcock <[email-masked]>
Date: Mon, 8 Jul 2019 13:28:33 -0700

> On Jul 6, 2019, at 4:46 PM, Joe Abley <[email-masked]> wrote:

Very much agreed, whether using this mechanism or other.

                                -Bill

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 8 Jul 2019 20:30:16 +0000

> On Jul 8, 2019, at 1:05 PM, Witold Krecicki <[email-masked]> wrote:
> 

If the primary server is allowed to transmit two versions of the zone -- one with covert RRs and one without -- then it only makes sense to omit covert RRs from the digest.  It would be unfortunate, but necessary.

Actually I think the last paragraph of 2.2 would be better with only this:

   If the primary server receives a zone transfer request for a zone with
   Covert RRs, but without the COVERT-OK option, it MUST NOT transfer the zone.

That is, don't allow AXFR of a zone with Covert RRs to an unaware secondary.  Then leaks are much less likely and you can include the covert RRs in the zone digest.  You would need to specify what the server should do in this case.  REFUSED I guess.

DW

---

From: [email-masked]
Date: Mon, 8 Jul 2019 16:40:34 -0400

Hi Witold,

On Jul 8, 2019, at 16:05, Witold Krecicki <[email-masked]> wrote:

> users. We should have more tolerance for shootfooting features there.

I don't have anything extra to add to my earlier observations and I understand in general the points you are making.

One small thing though, on your text above -- I'm not sure precisely what you mean by those words, but it seems possible that you're distinguishing between large, commercial DNS service operators and others who might be smaller, non-commercial, hobbyist, amateur, or something.

I think we should be careful about specifications that appear to promote centralisation or otherwise make assumptions about what particular kinds of operators can or will do. I think our audience includes the full spectrum. (I also don't think small, hobbyist operators have any kind of monopoly on operational accidents, having been involved in more than a couple large-scale events in my time.)

If we can design protocols that can fail in a safe way, I think we should, regardless of whether we imagine safety shoes are being worn.

Joe

---

From: Witold Krecicki <[email-masked]>
Date: Mon, 8 Jul 2019 22:57:17 +0200

> One small thing though, on your text above -- I'm not sure precisely what you mean by those words, but it seems possible that you're distinguishing between large, commercial DNS service operators a…

People querying DNS servers vs people operating DNS servers that are
queried, it's just that.

Witold

---

From: Witold Krecicki <[email-masked]>
Date: Mon, 8 Jul 2019 23:02:02 +0200

> That is, don't allow AXFR of a zone with Covert RRs to an unaware secondary.  Then leaks are much less likely and you can include the covert RRs in the zone digest.  You would need to specify what…

The alternative is to transfer the zone without COVERT RR's if (and only
if) a configuration option is set - this is to make it easier during
'transition period' where primary supports Covert and secondary doesn't
- e.g. for NOTE RRs which are not critical to functioning of the zone.
The default behaviour is to refuse the transfer.

You're definitely right about specifying an exact response (REFUSED) if
a zone  transfer request without COVERT-OK is received for a zone with
COVERT RR's and without the configuration option, I'm adding it to my
TODO list.

Witold

---

From: Tony Finch <[email-masked]>
Date: Tue, 9 Jul 2019 14:24:14 +0100

Joe Abley <[email-masked]> wrote:
> configuration changes, software downgrades that are pragmatic
> necessities, side systems that publish zone data in ways other than the
> DNS).
>

Yes. It might make sense to put secret keys in catalog zones.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Cromarty, Forth, Tyne: South 3 to 5, becoming variable 3 or less. Smooth or
slight. Occasional rain, fog patches. Moderate, occasionally very poor.

---

From: Joe Abley <[email-masked]>
Date: Tue, 9 Jul 2019 09:41:09 -0400

Hi Tony,

> Yes. It might make sense to put secret keys in catalog zones.

My sense is that there are far more examples today of people using REST interfaces to provision DNS services than there are people using catalogue zones, but I agree, catalogue zones are a category of the kind of out-of-zone signalling I'm suggesting.

(I'm agreeing to your agreement \ to make the point that just because catalogue zones use the DNS as a substrate, they're not in-band in the sense of the original proposal.)

Joe

---

From: Dan Mahoney <[email-masked]>
Date: Mon, 22 Jul 2019 17:59:37 +0000 (UTC)

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:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 23 Jul 2019 09:17:49 -0400

> enough time patching my DNS servers without having to patch an IPAM.

"Just use DDNS" is actually harmful advice in many situations, for exactly
the reasons you've raised.  Maintaining versioning and "blame" (who made
what change when) is overly complex when trying to use DDNS-based zone
maintenance.  Not to mention I can put together a fairly decent zone change
management process using version control and zone files with off-the-shelf
software that any small enterprise can make use of ... there just aren't
any good OSS zone editors based on DDNS that I'm aware of, and small
enterprises can't afford to do a ton of in-house software development to
make something purpose built.

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 25 Jul 2019 10:53:29 -0400 (EDT)

Both docs in this set should say something more about authenticity and 
integrity, particularly since DNSSEC cannot be used to establish the 
same.  (The security considerations sections mention confidentiality. 
Authenticity and integrity are likely important for most use cases.)

On the whole, I'm not a fan of this overall approach, though I'm 
willing to wait and see.

-- Sam

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 25 Jul 2019 13:25:52 -0400

> 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

> > Title:                Domain Name System (DNS) Resource Record types for
> transferring covert information from primary to secondaries
> > 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://datatracker.ietf.org/doc/html/draft-krecicki-dns-covert
> >
> >
> > Abstract:
> > URL:
> https://www.ietf.org/internet-drafts/draft-hunt-note-rr-02.txt

-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com

---

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Jul 2019 13:32:32 -0400 (EDT)

On Thu, 25 Jul 2019, Ólafur Guðmundsson wrote:

> 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 

+1

Paul

---

From: Evan Hunt <[email-masked]>
Date: Thu, 25 Jul 2019 17:42:21 +0000

On Thu, Jul 25, 2019 at 01:25:52PM -0400, Ólafur Guðmundsson wrote:
> [...]

We're running out of bar bof opportunities in Montreal, but I'd be happy
to discuss this further.

---

From: Tim Wattenberg <[email-masked]>
Date: Thu, 25 Jul 2019 14:24:56 -0400

> Am 25.07.2019 um 13:25 schrieb Ólafur Guðmundsson <olafur=[email-masked]>:
> 

+1

	– Tim

---

From: Paul Ebersman <[email-masked]>
Date: Thu, 25 Jul 2019 14:30:51 -0400

olafur> My suggestion is to take a step back and say we have outgrown
olafur> AXFR and we need better mechanism to sync various servers.

olafur> Lets start work on a new "SYNC Name servers" protocol that can
olafur> meet modern requirements

paulw> +1

+1.

I think we're allowed to replace something after 20+ years ;)

Things that might go in:

  - AXFR/IXFR/*XFR
  - zone meta data (create/modify/delete/digital-sigs)
  - "covert" data

My only hesitation is we seem to slow logarithmically as we increase
scope but this sure seems like the right direction.

---

From: Dan Mahoney <[email-masked]>
Date: Tue, 30 Jul 2019 19:39:00 +0000 (UTC)

> scope but this sure seems like the right direction.

As far as extending/replacing the AXFR protocol, this is great, however, I 
still see an orthogonal need for the thing I'm asking for: Parseable 
metadata.  For humans.  Not as a gateway to some sort of clever signaling 
or key-transfer protocol.  Analagous more to HINFO than TXT.

I'd be fine with this data ONLY living on the master, but having it 
survive things like named-compilezone or rndc freeze/thaw, or the slew of 
DDNS updates that things like ACME DNS-01 requires.

Effectively, this would be an internal-only DNS record that had a database 
representation but NO defined wire-format, so there'd be little chance of 
snooping over the wire (absent some kind of memory leak in the DNS 
implementation).

I also envision the "presentation format" looking like a regular 
comment so non-compatible implementations that tried to load a zone with 
these simply ignored them as they do regular comments.  Similar, perhaps 
to how server-side includes work in the web world.

-Dan

---

From: Paul Ebersman <[email-masked]>
Date: Tue, 30 Jul 2019 14:08:59 -0600

I was also one of those folks that put things in txt zone files for
years. My whole IP address management was comments in the in-addr.arpa
zones. While I went to dynamic zones to make DNSSEC easy and lost that,
I still see value in things that should be attachable to a zone but not
zone data and not something you wanted to "publish" in the open DNS.

ebersman> I think we're allowed to replace something after 20+ years ;)

ebersman> Things that might go in:

ebersman> - AXFR/IXFR/*XFR
ebersman> - zone meta data (create/modify/delete/digital-sigs)
ebersman> - "covert" data

dmahoney> As far as extending/replacing the AXFR protocol, this is
dmahoney> great, however, I still see an orthogonal need for the thing
dmahoney> I'm asking for: Parseable metadata.  For humans.  Not as a
dmahoney> gateway to some sort of clever signaling or key-transfer
dmahoney> protocol.  Analagous more to HINFO than TXT.

Actually, I think this moves your goal nicely. If we could have things
marked as "not zone data, sensitive" and dealt with only over a covert
channel after various auth/acl checks are done, it would be easy enough
to have metadata that won't leak.

Then we define some of these things we consider "private"/non-zone.

dmahoney> I also envision the "presentation format" looking like a
dmahoney> regular comment so non-compatible implementations that tried
dmahoney> to load a zone with these simply ignored them as they do
dmahoney> regular comments.  Similar, perhaps to how server-side
dmahoney> includes work in the web world.

Legacy/non-compatible would fall out because they wouldn't ever see this
because they'd fail whatever auth/negotiation was necessary to believe
that sending covert/metadata was OK and they'd never get it.

---

From: Dan Mahoney <[email-masked]>
Date: Tue, 30 Jul 2019 20:11:36 +0000 (UTC)

> that sending covert/metadata was OK and they'd never get it.

Right, my argument was more in the case of the "without covert".  I.e. 
you've dumped your zone on bind and loaded it into NSD.  On disk, not 
wire.

-Dan

---

From: Paul Ebersman <[email-masked]>
Date: Tue, 30 Jul 2019 14:16:27 -0600

ebersman> Actually, I think this moves your goal nicely. If we could
ebersman> have things marked as "not zone data, sensitive" and dealt
ebersman> with only over a covert channel after various auth/acl checks
ebersman> are done, it would be easy enough to have metadata that won't
ebersman> leak.

ebersman> Then we define some of these things we consider
ebersman> "private"/non-zone.

ebersman> Legacy/non-compatible would fall out because they wouldn't
ebersman> ever see this because they'd fail whatever auth/negotiation
ebersman> was necessary to believe that sending covert/metadata was OK
ebersman> and they'd never get it.

dmahoney> Right, my argument was more in the case of the "without
dmahoney> covert".  I.e. you've dumped your zone on bind and loaded it
dmahoney> into NSD.  On disk, not wire.

If what you're arguing for is something that's actually mixed into the
zone data, how do you handle non-compatible/legacy and avoid leakage?

Doing it as separate meta-data not part of the zone data and not needing
to be DNS wire format solves that but, again, without some covert or
non-AXFR transfer method, how do you get it around?

If you don't care about backward compatibility, this is a more easily
solvable problem.

---

From: Bob Harold <[email-masked]>
Date: Tue, 30 Jul 2019 16:24:04 -0400

> If you don't care about backward compatibility, this is a more easily

If you are looking at putting it outside the zone, it occurs to me that any
of the IPAM solutions have a database where you can attach information to
records, zones, IP addresses, etc.  Even Active Directory can probably do
that.

-- 
Bob Harold

---

From: Paul Ebersman <[email-masked]>
Date: Tue, 30 Jul 2019 14:33:14 -0600

rharolde> If you are looking at putting it outside the zone, it occurs
rharolde> to me that any of the IPAM solutions have a database where you
rharolde> can attach information to records, zones, IP addresses,
rharolde> etc. Even Active Directory can probably do that.

"Buy a commercial IPAM" isn't an open standards based solution. Nor are
any of those extra compatible between different implementations.

Not being send in the AXFR or stored as zone data doesn't mean separate
database either. That's assuming an implementation before we even have a
protocol design/extension.

---

From: Paul Ebersman <[email-masked]>
Date: Tue, 30 Jul 2019 14:36:34 -0600

dmahoney> I'd be fine with this data ONLY living on the master, but
dmahoney> having it survive things like named-compilezone or rndc
dmahoney> freeze/thaw, or the slew of DDNS updates that things like ACME
dmahoney> DNS-01 requires.

dmahoney> Effectively, this would be an internal-only DNS record that
dmahoney> had a database representation but NO defined wire-format, so
dmahoney> there'd be little chance of snooping over the wire (absent
dmahoney> some kind of memory leak in the DNS implementation).

Gotcha. So presumably also only on hidden master if that's the
architecture.

And transfer of data with these super-comments would be done by file
copy, not any DNS standard method?

---

From: Dan Mahoney <[email-masked]>
Date: Tue, 30 Jul 2019 20:51:44 +0000 (UTC)

> copy, not any DNS standard method?

Correct.  I do also envision a limited use-case for this feature where 
BIND might also add a note indicating the source/time of a DDNS update.  
But again, purely for humans, not for any action by the nameserver.

One possible format might be:

;NOTE	foo.bar.	NOTE	"pauls workstation"

-Dan