On Mon, May 13, 2019 at 11:21 AM Wessels, Duane <[email protected]> wrote:
> > > > On May 13, 2019, at 10:17 AM, Brian Dickson < > [email protected]> wrote: > > > > The original RFC 8145 gives the ability to gather trust anchor signal > data. > > > > There are limitations related to inferring either reasons for behavior > observed on the aggregate volumes, or identifying originating > resolvers/forwarders versus upstream resolvers/forwarders (which could > include both NAT and forwarder root causes). > > > > I believe the additional information that would be operationally useful > as well as helpful for being able filter or otherwise drill down within the > collected data. > > > > The extra information I believe would be useful includes software > (package and version), and some unique identifier for each host, plus an > identifier derived from (possibly non-unique due to RFC 1918) host's IP > address. > > > > Putting this information underneath the _ta-* label, would allow the > high-level signal (the _ta itself) to be aggregated as easily as currently, > while also enable drilling down and/or aggregating/filtering to address any > PII issues. > > > > Suggestion for software id: whatever software currently puts into > version.bind or equivalent name, in the CH TXT class and type. > > > > Suggestion for host id: some UUID generated either at software install > time, or at software launch time, > > > > Suggestion for IP-based ID: hash of IP, where IP is "live", so changing > the IP results in change to the hash. This has the added benefit of > validating that the IP address of the incoming _ta query is the originating > system, versus NAT IP (possibly folding multiple hosts onto fewer/different > IP addresses) or forwarders who forward queries for clients. > > > > I believe these will be useful in analyzing the 8145 data, to extract > better signal data, and to filter data that is effectively "noise", and/or > track sources and changes better across event boundaries. > > > > Thoughts? > > > Hi Brian, > > Thanks for the suggestions. I think the first discussion needs to be > whether there is support for better signals at the expense of possibly less > privacy. My sense of the way things are today is that "privacy is king." > Good point; probably configurable and either opt-out or opt-in, possibly with defaults selected by e.g. whoever is "packaging" a particular open source project (where philosophies on privacy may differ significantly). Brian
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
