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