> 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." DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
