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

[Paul Ebersman <[e-mail]>]

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.