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

[Bob Harold <[e-mail]>]

On Tue, Jul 30, 2019 at 4:16 PM Paul Ebersman <[e-mail]> wrote:

> 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.
>

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