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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
