Re: [DNSOP] TA signal - suggestion to enhance signal

[Brian Dickson <[e-mail]>]

On Mon, May 13, 2019 at 11:21 AM Wessels, Duane <[e-mail]>
wrote:

>
>
> > On May 13, 2019, at 10:17 AM, Brian Dickson <
> [e-mail]> 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