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

[Paul Ebersman <[e-mail]>]

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.

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.

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.