Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-01.txt
On 13 May 2019, at 11:06, Ondřej Surý wrote: > But I do have a question for the WG - should we add a text that would allow > the “Expert Review” to formally > DEPRECATE (as defined in this I-D) other RRTYPEs? This would make things > much simpler in the > future when we want to formally cleanup more obsoleted records (like NINFO > and RKEY, etc...). I don't know what experts could be expected to know enough about the entire ecosystem to make that call. I also don't know that there's any measurement that could be used in all cases to indicate that an RRTYPE is dead. These both seem like shortcuts that could have unintended consequences. I think it's better to rely upon a consensus process. Following the example you're setting here might mean that this is an exercise we repeat in the IETF every year or two. I think that's ok. Joe signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-01.txt
On 13 May 2019, at 05:06, Ondřej Surý wrote: > > But I do have a question for the WG - should we add a text that would allow > the “Expert Review” to formally DEPRECATE (as defined in this I-D) other > RRTYPEs? I'm not sure an expert reviewer could or should be in a position to make that determination Ondřej. They could probably put dead/dying RRtypes on a list that says something like "These RRtypes will be deprecated in N months time. Scream now if you disagree.". If nobody screams after a reasonable notice period, the RRtype(s) can then be killed. If there are complaints, we'd know if the RRtype(s) are still in use and/or if that use remains valid. > This would make things much simpler in the future when we want to formally > cleanup more obsoleted records (like NINFO and RKEY, etc...). NINFO and RKEY were specifically created for use in .tel. If they are used there -- I don't know or care -- they should mainly be seen by the Telnic-controlled name servers and apps that use .tel domain names. [Unless Telnic's T have changed, registrants can't delegate these names to arbitrary name servers.] Someone would need to contact Telnic to find out how often these RRypes are found or looked up. They're the only ones who could say for sure if the RRtypes are obsolete or not. An expert reviewer probably wouldn't know that unless they asked. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] TA signal - suggestion to enhance signal
On Mon, May 13, 2019 at 11:21 AM Wessels, Duane wrote: > > 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 I think this is an accurate characterisation of the situation. But having said that, I think the lack of capabilities signalling in DNS, compared to say SMTP or HTTP is a huge problem, and since we have it in those protocols, I feel we have a basis to suggest there is not a blanket ban on this kind of thing in the model. Because of the massive lack of information about elements of the system, the lack of signalling is actually causing a problem. Thats distinct from the hypothetical privacy breach which I acknowledge is a fear, but its a fear which has to be balanced by the problem space we're in. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] TA signal - suggestion to enhance signal
On Mon, May 13, 2019 at 11:21 AM Wessels, Duane wrote: > > > > On May 13, 2019, at 10:17 AM, Brian Dickson < > brian.peter.dick...@gmail.com> 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] TA signal - suggestion to enhance signal
> On May 13, 2019, at 10:17 AM, Brian Dickson > 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-01.txt
Hi, I still would like to continue with this and I still think it’s a no brainer and I know this is super uninteresting to anyone but the DNS software vendors. But I do have a question for the WG - should we add a text that would allow the “Expert Review” to formally DEPRECATE (as defined in this I-D) other RRTYPEs? This would make things much simpler in the future when we want to formally cleanup more obsoleted records (like NINFO and RKEY, etc...). Ondrej -- Ondřej Surý ond...@isc.org > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for > draft-sury-deprecate-obsolete-resource-records-01.txt > Date: 13 May 2019 at 10:58:27 GMT+7 > To: "Evan Hunt" , "Ondrej Sury" > > > A new version of I-D, draft-sury-deprecate-obsolete-resource-records-01.txt > has been successfully submitted by Ondrej Sury and posted to the > IETF repository. > > Name: draft-sury-deprecate-obsolete-resource-records > Revision: 01 > Title:Deprecating obsolete DNS Resource Records Types > Document date:2019-05-13 > Group:Individual Submission > Pages:5 > URL: > https://www.ietf.org/internet-drafts/draft-sury-deprecate-obsolete-resource-records-01.txt > Status: > https://datatracker.ietf.org/doc/draft-sury-deprecate-obsolete-resource-records/ > Htmlized: > https://tools.ietf.org/html/draft-sury-deprecate-obsolete-resource-records-01 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-sury-deprecate-obsolete-resource-records > Diff: > https://www.ietf.org/rfcdiff?url2=draft-sury-deprecate-obsolete-resource-records-01 > > Abstract: > This document deprecates Resource Records (RR) Types that are either > not being used for anything meaningful or were been already made > obsolete by other RFCs. This document updates [RFC1035], [RFC1035], > [RFC4034]. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] TA signal - suggestion to enhance signal
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
Re: [DNSOP] ANAME high-level benefit question
Also, I would argue that the ability to run ANAME at your own infrastructure might drive less people to the “managed DNS” land or allow them to migrate away without a significant loss of functionality. One way or another, ANAME-like behaviour became defacto industry standard and we need to have a solution on a protocol level. Ondrej -- Ondřej Surý ond...@isc.org > On 11 May 2019, at 16:34, Ray Bellis wrote: > > > > On 11/05/2019 15:54, Dave Lawrence wrote: > >> I have a related question ... is allowing only targets on their own >> infrastructure currently a limitation most such providers have? > > I don't know about "most", but certainly some. See e.g. the attached > message posted here 2018/06/25. > > Ray > > <[DNSOP] abandoning ANAME and standardizing CNAME at > apex.eml>___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
