Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

Lanlan Pan <abbypan@gmail.com> Tue, 21 March 2017 05:29 UTC

Return-Path: <abbypan@gmail.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1C112947C; Mon, 20 Mar 2017 22:29:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Qfi0HrTe5Ly; Mon, 20 Mar 2017 22:28:57 -0700 (PDT)
Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74B95129471; Mon, 20 Mar 2017 22:28:57 -0700 (PDT)
Received: by mail-wr0-x232.google.com with SMTP id u48so104953311wrc.0; Mon, 20 Mar 2017 22:28:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YF740ceJ3Jkh/VF6a3GkV+RC4ICQQR/Vn3Hrp/y5V8w=; b=GW6/B4YLcJ2loE7GJGmRoNlk2+d/IGo/IEOgR0aRXhTtQkH6KCCEPKGH6fTWlNZlFb V7FUqJiXXND3neCizvYIEo2NUhTU21QIT8/HQeDsmNV2URjGMjbrawsyzgDMwEk7ibVQ kaddkm4idkBc4fC53ltx+63vDwUHeHJlmyREYCqIEpXZYoxAjVfTjHJj5ObGqsN75Bx5 ZYdHrj0/VHYTHgo1GF0TdEHtTHl5/X9fwEFAg8pnAON7dbIdlu1ii9TS/t3dO+qudter 7V1nCwI+wIQczGDhDHgssxeb4bC1N5XYYmBDgdvaKcvdAOxzHCYMIn4V+Hv0t8oTiyV/ eFCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YF740ceJ3Jkh/VF6a3GkV+RC4ICQQR/Vn3Hrp/y5V8w=; b=PogVcuzIGnwPjMBMeqFUh+MtOHXJe/fHh3HQMydrkrqtSloDlPBXOWubliBxG4yPHP cCTqPGcH1PtptfYbe97+BNH178225jJiR73w1NPqBEfkj/1jbSDbJdkO7O9gBtjeQ9MG yoTRxJb35riP35QZt7ZO3slE8GI6WkbwCPpK+w37/saWRKjg2FffqhvZiLNdHXOJz65V +Jwqt5b7paFgUXW+DoedW4/lJVKFxD2W7T0K+NErU1ubvpYsvZtx7nDaYHSWhHNZuZ9+ kggPxI0gUuTp49kaJYAW3eM43CxVRNRGBb0vtq78FaxHvBt166zBaNF2rwRew+ObD//B jxow==
X-Gm-Message-State: AFeK/H2YRFlox0VQ1pddresZEfJ1AbMH6qq25fEjnvLmX1FH3pLPl5/F1xVkzC+jP97vw0LjecPfqIDMg1jahw==
X-Received: by 10.223.160.115 with SMTP id l48mr31291536wrl.24.1490074135396; Mon, 20 Mar 2017 22:28:55 -0700 (PDT)
MIME-Version: 1.0
References: <000f01d29dfe$50b6b190$f22414b0$@cn> <CANLjSvXGO3rSpqb7hzwmV=vfm=UTHnQYqfBmt=uD9Mi8cL59Jg@mail.gmail.com> <16B293AD-27A2-4A6D-8A96-7CD847B59708@senki.org> <CANLjSvUJfU1cafGXHyg=DuCnhm09mBm5z4ve2_g6j2ONgt2tRQ@mail.gmail.com> <df8da203-6fbc-02d9-7876-e220f2bbe884@nic.cz> <48FEB26B-8B76-4548-8F72-F907C81C65A6@opendns.com>
In-Reply-To: <48FEB26B-8B76-4548-8F72-F907C81C65A6@opendns.com>
From: Lanlan Pan <abbypan@gmail.com>
Date: Tue, 21 Mar 2017 05:28:44 +0000
Message-ID: <CANLjSvUdvJNO8C=idVCAAUcgAGhLDym3pmj+brcPniKqXu+4Qg@mail.gmail.com>
To: Brian Hartvigsen <bhartvigsen@opendns.com>, Petr Špaček <petr.spacek@nic.cz>
Cc: Barry Raveendran Greene <bgreene@senki.org>, "fuyu@cnnic.cn" <fuyu@cnnic.cn>, dns-privacy@ietf.org, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c18513687866e054b36eb33"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/IedPBZgrngG-nlJ-GrqsqVo1SJo>
Subject: Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Mar 2017 05:29:00 -0000

Hi,

Thanks for Petr and Brian.

Brian Hartvigsen <bhartvigsen@opendns.com>于2017年3月21日周二 上午3:34写道:


>> For user privacy concern, we can revise  ECS(114.240.0.0/24
>> <http://114.240.0.0/24>) => EIL (CHINA, BEIJING, UNICOM),give a
>> tradeoff between privacy and precise.
>
> Nice, this sounds like appropriate tradeoff to me.
>
>
> Side-effect of this is that it removes need to maintain copies of
> various Geo-IP databases all over the place, which is an improvement to
> operational practice.

I disagree.  Unless you get the clients to implement EIL, then you’ve
simply just pushed the need for geo-ip mapping from CDN to DNS provider.
Of course one would assume that an ISP already has this mapping, but 3rd
party DNS would not.  So either they have to build the mappings,  maintain
a copy of some Geo-IP database, or hope that all the clients have it
implemented.  With 3rd party DNS carrying double digit percentages of
traffic (iirc ~15% total from 2015 OARC presentation), that’s not something
to just brush away.


*AUTH*
ECS needs AUTH to do geo-ip mapping to decide most satisfied response.
There is Geo-IP database on the AUTH which is supporting ECS.  (ECS example
figures: Which CDNs support edns-client-subnet? )
<https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/>
<https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/>
Therefore, if AUTH support ECS, the AUTH can support EIL too.

*RECUR*
<https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/>
Return to the origin smart-dns-resolution problem, there are two critical
factors that affect the response accuracy of authoritative server: (details
wrote in my *Paper
<https://drive.google.com/open?id=0B5gNT4RRJ0xPaG9nZ045VXRrZzg>*)
1) Is the resolver's IP address close to the client's IP address?
2) Is the IP geolocation database used by the authoritative server with
high quality?

Public recursive resolvers offer free DNS resolution services for global
users. But these servers are NOT CLOSE TO many users because the public
recursive service providers COULDN'T deploy servers in every country and
every ISP's network.
That is why public recursive service provider starved of ECS, which carried
client subnet to AUTH for geo-ip mapping.
Therefore, public recursive resolvers INCREASE the seperated distance of
client's IP and resolver's IP. Because on traditional ISP recurisve
resolver side, ISP are nearby the client's IP.

That is why I say the most recommend is P-Model, deploy EIL on public
recursive resolver, to partly lighten the burden of AUTH (as Petr pointed),
decrease the user privacy risk at PUB RECUR -> AUTH path.
EIL deploy on I-Model (ISP recursive resolver)  and L-Model (Local
forwarding resolver) is in long-term, the most realistic nowadays is the
P-Model (Public recursive resolver).

By the way,if 3rd party public recursive DNS are carrying double digit
percentages of traffic, there is a high probability that they have strong
technologies and rich resources to do geo-ip mapping for their client
queries.



— Brian

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan