IETF Logo Mail Archive

Re: [Add] discovery of DNS server privacy policy

tirumal reddy <kondtir@gmail.com> Mon, 07 September 2020 11:52 UTC

Return-Path: <kondtir@gmail.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B75F3A0C5F for <add@ietfa.amsl.com>; Mon, 7 Sep 2020 04:52:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 hp2uB9lYQfqZ for <add@ietfa.amsl.com>; Mon, 7 Sep 2020 04:52:57 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 84F8A3A0C59 for <add@ietf.org>; Mon, 7 Sep 2020 04:52:57 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id j2so13650486ioj.7 for <add@ietf.org>; Mon, 07 Sep 2020 04:52: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=BGMgm94/BeIOnBq6YXVRNM1ZmOwS31NLz8rGDaWeE8k=; b=u3qO6FOatVv4ILIZnxUjd3Vw5gOo9+TPT8Tm8edhu9p0HtAnvDZwVoX1PxY0NqR+NZ ewclKQ0DRm0WsGVFDTv26jTXjIPpG8jJfoUkmfvl8f+4XsK1wr2jQ3JfQSXAMzCDZR1P opwSs/WW3QIm7MYNQXzpt+44RRqYrCkoXy4RZtRp/eQI8QtVrbGNcjZ0/zyeiG34JC3S m52aXbGh5zWbP7aEUvrbzZTPFmWP4iFJ9OeYWC6C1JtpUBDWCmnsUaG1BR46u0b43qrz Q4viPtNaR7vYb9TplKk328izSmEeND62Yv20p1l43LKYOO4WZEs2BkMYTEKAdMxQEZ42 NmSA==
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=BGMgm94/BeIOnBq6YXVRNM1ZmOwS31NLz8rGDaWeE8k=; b=VMM+1DpeXrkXG1Fz77xjySVfdhE69wuf+mFosXZGmJc+5paofgl2bbzmyTBHhlkRqJ hFVniZzrZ/xud2D6z9IEdUTPLVS/6/vXSpYKFA4lB+JN+mkBTa9iHI1KaXWGS7WxrWh6 5Sm+i9x2iCCF3gxTMwS4Hber6XKhsVgSt69ty/8z0uynZmHDIUNvU2MOGhvoVWOkeovE P5TJzSOboZB1Nuy1D2GTNwdlkCMBqbdKNppXdRu0iSdB2Sa6CrxE0sRoW14/DwaRLHeZ DjPrG9ootdzJDT4njv0PDXMnPBKdAOf2Id9b0Js9nVmK4JfG0+utzlmGNg6MSLZvKZPH 3Rpw==
X-Gm-Message-State: AOAM533I/cYTAy1rr2eTyIVVQeh2r/OWlOPLxAC+T7m1Ra+nVtGkbpGD r+WXSk5wXSdelNaLvFo/3E3NLXepSNEs6kbTmqraPEjaSNIt9g==
X-Google-Smtp-Source: ABdhPJxe232rNo6xobm2dtjfuYMujOInjyxnlQG9xsAwc6jTQpUbQgOKHutufCV5s0gvCQ0bCeK/pFrA4LH1BeSKktg=
X-Received: by 2002:a02:6607:: with SMTP id k7mr19296215jac.91.1599479576814; Mon, 07 Sep 2020 04:52:56 -0700 (PDT)
MIME-Version: 1.0
References: <31194C90-6C0B-470C-8B14-79C12D2C5C0D@comcast.com> <CACJ6M14gXmEHc_fX8=GpKwRDn6C=R7LR06JG_Qg-cWR5agU9Hw@mail.gmail.com> <391E15D2-9208-4BA9-B01E-3673982DA6CE@apple.com> <CABcZeBMXvcF6PJWE+EkGVx1c9RXzO1XuB3xhrVKUJvUb=aus8A@mail.gmail.com> <4cd8a8c6-3516-4ad6-877c-9460d8096773@www.fastmail.com> <CAFpG3gfkrKGiuPRH1QvH+-w2H=N1ijtDpk5Oh=D2JOp-L4Q1+w@mail.gmail.com> <CABcZeBNhHcNAkVm=PNUvV8_vGVvDvJbaMVHB_w9zu63+ebQwpQ@mail.gmail.com> <CAFpG3gcAjHkh7boDwLq+sHpGtfB2WT0NbuuFqqBQs2M6BZkAOQ@mail.gmail.com> <CABcZeBMi-B7LKB6ipt6vLSZcF9OMLga8f+qydpZVOhOGQrttuQ@mail.gmail.com> <CAFpG3geQefT0=fN-6UFwDqLLqbb1XthHA=np4HPS2NfSO77csA@mail.gmail.com> <CABcZeBPmfe8Um38xFHoxw+26-YQxFUPN+p4aW9uzbPKGy1xz4g@mail.gmail.com> <CAFpG3gefyTcibzfQ-dzXKv5fKE=vwUktux0dz25wNL7_+tf7MA@mail.gmail.com> <CABcZeBMVcH74RYXZrLRNtHLi-xZgGxRHA2CsH6nbiz+5uGM32g@mail.gmail.com> <CAFpG3gcJeXyuJ4n8N6wyDvVJGkO1toVC4hUXjL6ACWg+sent+w@mail.gmail.com> <CABcZeBNS7EEw+zX-rgOJpiBbqw6jn80uXSR60Mj-oCRwEnTAjQ@mail.gmail.com> <CABcZeBOQ-LgXAFGYtz3t791qj12jUkkksxpNz3600MeT-bXn-A@mail.gmail.com> <8722.1599146928@localhost> <CH2PR00MB0778D8E58C79869ABE456131FA2C1@CH2PR00MB0778.namprd00.prod.outlook.com> <CAFpG3gey0AmFEak91suodhbdtH1A6pCc6KwZ7RLEU6rX6u9k8w@mail.gmail.com> <BY5PR00MB07734E7DC1F6788C5CA8917EFA2D1@BY5PR00MB0773.namprd00.prod.outlook.com> <0D8D408A-1210-441B-8321-5087A4E9E9C3@rfc1035.com>
In-Reply-To: <0D8D408A-1210-441B-8321-5087A4E9E9C3@rfc1035.com>
From: tirumal reddy <kondtir@gmail.com>
Date: Mon, 07 Sep 2020 17:22:45 +0530
Message-ID: <CAFpG3gfG00+RP2KFeLeNvmAzbvbeJ567X=3=6sFLaNBwmw8ALw@mail.gmail.com>
To: Jim Reid <jim@rfc1035.com>
Cc: Tommy Jensen <Jensen.Thomas=40microsoft.com@dmarc.ietf.org>, ADD Mailing list <add@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000068ee05aeb7dc11"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/a4p_60TIyexEdge_qrr46AOQOls>
Subject: Re: [Add] discovery of DNS server privacy policy
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Sep 2020 11:52:59 -0000

On Fri, 4 Sep 2020 at 21:30, Jim Reid <jim@rfc1035.com> wrote:

> On 4 Sep 2020, at 16:19, Tommy Jensen <Jensen.Thomas=
> 40microsoft.com@dmarc.ietf.org> wrote:
> >
> > It's not that I object to users being shown the privacy policy of their
> DNS servers. I object to a protocol making it a mandatory part of somehow
> approving a server at the protocol level.
>
> Nobody’s suggesting such a thing - at least I hope not.
>

Yes, the resolver information (e.g., DNS server identity, cryptographically
asserted DNS server identity, filtering capability, privacy statement URL)
are provided in RESINFO RRTYPE defined in
https://tools.ietf.org/html/draft-pp-add-resinfo-02 to convey the resolver
information in a JSON object.

The client can use any of the mechanisms (DHCP/RA, PvD and SUDN) to
discover and connect to the Encrypted DNS server, it can then use
https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-05 to
learn the discovered DNS server resolver information to help in the
selection decision.

-Tiru


>
> What could/should be part of this WG’s discovery efforts is a way for a
> DNS server to signal to its clients what privacy options, if any, it
> offers. Or perhaps for clients to signal to the server what privacy options
> it will/won’t accept. This could (handwave) be something comparable to the
> extended EDNS error codes, albeit dressed up in XML or JSON syntactic sugar
> or whatever else the WG ultimately agrees as the way of publishing that
> info.
>


>
> > Whether the user/admin trusts example.com and whether the server
> sending me bits is indeed example.com need to be separated, whether the
> connection's content is HTML, DNS, or anything else. Once I acquire the
> address to connect to, decisions about whether I should connect have
> already been made at a layer above me.
>
> How can that be made to work for DNS discovery? Who/what is making the
> decision at that higher level about the DNS server you “connect” to? How?
> Isn’t this the problem that this WG is meant to address?
>
> PS: apologies for a meaningful and relevant Subject: header. :-)
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>

v2.23.0 | Report a Bug | By Email