Re: [DNSOP] private-use in-meeting chat comments
Eric Orth wrote: > On Tue, Nov 17, 2020 at 4:46 PM Tony Finch wrote: > > > > There's also a privacy leak: if you assign a unique subdomain then when a > > device roams and leaks queries for the private domain, the device can be > > tracked and correlated with other devices that use the same private > > domain. > > > > What if, in whatever hypothetical solution is using this, it is reasonable > for devices to always regenerate the names they are using on changing > networks? At least in such hypothetical cases, it seems the privacy danger > would be significantly mitigated, right? (Maybe we're getting too far into > unknown hypotheticals without finding actual usecases or implementors that > want this.) Ah, oops, I need to clarify: the private domain might be a per-CPE domain or an enterprise internal domain; the device is someone's phone or laptop which roams between multiple networks. The private domain is handed to the roaming device, and the device doesn't know (isn't told, and can't be told with current protocols) that the domain name is supposed to be private to the network. So the device is likely to keep asking about names of services in the private domain regardless of the network it is connected to, and thereby leak private information. Tony. -- f.anthony.n.finchhttp://dotat.at/ Southeast Iceland: Southeasterly 6 to gale 8, decreasing 4 or 5, then becoming cyclonic 7 to severe gale 9, occasionally storm 10 later in south. Rough or very rough, becoming high or very high later in south. Rain, squally showers later. Moderate or good, becoming moderate or poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Meeting feedbacks/summary on draft-bretelle-dnsop-recursive-iprange-location
I support the resolver IP range discovery function. I don't think it will
be hard to come up with a reasonable format for that. An APL record with
standard address families would seem fine. A URI record pointed at a JSON
blob or a flat text file would be fine too.
I do not support the geolocation function. I think the right solution here
is ECS. Even bad IP-geolocation from ECS will be better than using the
recursive resolver's country-code; at least it will be estimating the
location of the right entity.
If ECS is not widely deployed enough for your purposes, I would focus on
ways to increase support for ECS. For example, we could work on ways
to use shorter prefixes for improved privacy where appropriate, or provide
guidance on how to use ECS for geo-based responses.
On Wed, Nov 18, 2020 at 8:28 PM Manu Bretelle wrote:
> Hey all,
>
> Thanks a lot for providing feedback on the resolver IP ranges and location
> distribution draft [0] during the dnsop meeting.
>
> I gathered the feedbacks below as follow-ups, but, based on some of the
> comments made at the "mic" or over Jabber, I would also to provide some
> clarifications as to the intent of the draft.
>
> The primary intent of this draft is for resolver DNS providers to be able
> to share the list of IP ranges they operate under in a standardized way so
> consumers of such list can rely on 1 consistent format to access and parse.
> As mentioned in the draft introduction, currently this is a bit all over
> the place.
> RFC8805 [1] does provide this format (CSV)/medium (HTTPS).
>
> Amongst the use cases:
> * Being able to access/distribute IP ranges is mostly useful for
> network/DDoS/Response Rate Limit policies.
> * Location (optional in RFC8805) can be useful for Geo based DNS answers.
>
> While there is work on finding geofeed in the OPSAWG [2], this would
> defeat the original purpose of sharing resolver-only IP ranges. One could
> possibly say that only ip ranges are distributed and geolocation would be
> fetched from inetnum object but it seems to be adding more complexity in
> both term of consuming and generating the data as we now deal with multiple
> data-sources in different operational areas (DNS vs Network).
>
> Addressing the feedback category received during the meeting.
>
> # Geo location is not a good mechanism for providing customized answers
>
> Ben Schwartz and others on Jabber commented that Geo location is not the
> right thing to use.
>
> This draft is in no-way recommanding use of country/region... as the way
> to do so called "geotargeting" DNS, neither does it tries to solve this
> problem. I do agree that
> geolocation is different from network topology, latency. DNS targeting is
> even more complex than that and would take into consideration capacity of
> the destination (compute, backbone to origin), drain ratio, overall health
> of the system, (paid) peering vs transit... and more.
>
> The thing though, is that not everybody can build this type of
> metric/feedback loop and instead a lot are relying on the location of the
> resolver (based on its IP) as a proxy for where to send an end user. This
> is pretty much all you can get at DNS level. If you are lucky enough to
> receive and support ECS then you can go a step deeper. Eventually your most
> granular level of traffic steering (for the web) is going to be once the
> end user connects to your service and you can generate pages with customize
> domain to send them to a specific POP, or Alt-SVC.
>
> Route53 [3], NS1 [4], DynDNS [5], Akamai [6] to name a few, provide such
> type of targeting.
>
> Opensource authoritative name servers also support GeoIP answers: Bind
> [7], PowerDNS [8], Knot DNS [9]. Typically based on a DB in MaxmindDB
> format.
>
> Resolver IP could also be used by people implementing Geo targeted answers
> to generate ipv{4,6}hint SvcParamsKey.
>
>
> So, while using a resolver "location" may not be optimal, there is real
> use-cases and needs that can be served by standardizing this which gives a
> decent amount of bang for the buck.
>
> # TXT record, no, please no.
>
> I hear you and provided this as a potential mechanism knowing that it
> would be controversial.
> To "facilitate" discovery, the idea would be to have this behind a special
> underscore label.
>
> Ben Schwartz mentioned that HTTPS would not be a good candidate, SVCB
> probably more [10].
> I had originally thought of URI [11] but favors HTTPS for its potential
> extensibility (ip hints, ech, alpn...), even though most of those may not
> be strictly needed for this use case.
>
> Mark Andrews commented that APL [12] could probably be a fit with new
> custom address family. It would mean that the family needs to be registered
> in IANA's address family numbers registry for something that does not feel
> close an actual address family.
> Also, this record could quickly grow in size. Unless the intent was to use
> it in reverse lookup?
>
> Alex Mayrhofer mentioned geo URI. Thanks
[DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Interoperable Domain Name System (DNS) Server Cookies Authors : Ondrej Sury Willem Toorop Donald E. Eastlake 3rd Mark Andrews Filename: draft-ietf-dnsop-server-cookies-04.txt Pages : 16 Date: 2020-11-19 Abstract: DNS Cookies, as specified in [RFC7873], are a lightweight DNS transaction security mechanism that provide limited protection to DNS servers and clients against a variety of denial-of-service and amplification, forgery, or cache poisoning attacks by off-path attackers. This document provides precise directions for creating Server Cookies so that an anycast server set including diverse implementations will interoperate with standard clients. This document updates [RFC7873] with * suggestions for constructing Client Cookies in a privacy preserving fashion, * precise instructions for constructing Server Cookies deprecating the methods described in [RFC7873], and * suggestions on how to update a server secret. An IANA registry listing the methods and associated pseudo random function suitable for creating DNS Server cookies is created, with the method described in this document as the first and as of yet only entry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-server-cookies-04.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-server-cookies-04 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'Message Digest for DNS Zones' to Proposed Standard (draft-ietf-dnsop-dns-zone-digest-14.txt)
The IESG has approved the following document: - 'Message Digest for DNS Zones' (draft-ietf-dnsop-dns-zone-digest-14.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari, Robert Wilton and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/ Technical Summary: This document describes a protocol and new DNS Resource Record that can be used to provide a cryptographic message digest over DNS zone data. The ZONEMD Resource Record conveys the digest data in the zone itself. When a zone publisher includes an ZONEMD record, recipients can verify the zone contents for accuracy and completeness. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. Working Group Summary: There were several discussions during the working group process, but they were all resolved. The only other point raised was with the intended document status (currently Standards Track). Please see comments in Section 6 Document Quality: There have been implementations of the DNS record in several public domain DNS servers. However, because of the narrow use for this resource record, the shepherd does not feel that vendors will see the need to implement. More than one managed DNS vendor has indicated they see no need to implement. Personnel: Document Shepherd: Tim Wicinski Responsible Area Director: Barry Leiba ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] private-use in-meeting chat comments
On Tue, Nov 17, 2020 at 4:46 PM Tony Finch wrote: > Brian Dickson wrote: > > > One potential approach is to say (in the RFC) that one of the two-letter > > reserved codes should avoid name collision by putting a > collision-resistant > > second-level label, below .zz and above the private use usage (and use > that > > particular two-letter code in that manner exclusively). > > This kind of thing, or guidspace.arpa, is not that different in terms of > usability / ugliness from assigning a unique subdomain under a domain that > has been registered in the normal way. > Confirming that I understand your point: You're discussing the case of some local-network technology using $guid.guidspace.technology-vendor.com? 3 possible advantages I can think of of standardizing a .arpa subdomain: 1) More universally trustworthy that *.guidspace.arpa names will never be globally resolvable, which would be unexpected behavior. If using a normally registered domain, you have to rely on whoever owns that domain, and I could see usecases where the domain owner and the tech owner creating a name are not one and the same. 2) In cases different technology vendors have created some standard relying on guid-generated unique names (not necessarily an IETF standard), it may be desirable for the generated names to fall under some neutral third-party domain (in this case .arpa) rather than everyone involved relying on somebody maintaining a domain. 3) In more general cases where different parties aren't trying to interconnect, I don't quite understand why everyone can't just register domains for their uses. But one of the reasons we keep discussing potential solutions for local domains is that many people keep refusing to register names. This would be a good alternative to hopefully convince them to stop squatting unowned names. (Although from a practical perspective, I have no illusions that this would actually end the practice of squatting.) > > There's also a privacy leak: if you assign a unique subdomain then when a > device roams and leaks queries for the private domain, the device can be > tracked and correlated with other devices that use the same private > domain. > What if, in whatever hypothetical solution is using this, it is reasonable for devices to always regenerate the names they are using on changing networks? At least in such hypothetical cases, it seems the privacy danger would be significantly mitigated, right? (Maybe we're getting too far into unknown hypotheticals without finding actual usecases or implementors that want this.) > > I have a terrible mental conflict trying to weigh this privacy issue > against the horrible consequences of encouraging people to squat on > unassigned domains and use colliding hostnames. The privacy leak probably > needs to be fixed regardless, and if it is fixed then there would be a bit > less pressure in favour of unwise squatting. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Biscay: Southerly 3 to 5, veering westerly 5 or 6 later in northwest. > Moderate, occasionally rough in northwest. Rain later. Good, occasionally > moderate. > > ___ > 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
