Re: [DNSOP] [hrpc] Proposal for a side-meeting on services centralization at IETF 104 Prague

"Vinicius Fortuna [vee-NEE-see.oos]" <fortuna@google.com> Thu, 14 March 2019 17:51 UTC

Return-Path: <fortuna@google.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F360130F43 for <dnsop@ietfa.amsl.com>; Thu, 14 Mar 2019 10:51:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 tt-6lbJ4ikdZ for <dnsop@ietfa.amsl.com>; Thu, 14 Mar 2019 10:51:02 -0700 (PDT)
Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 58A14130EF5 for <dnsop@ietf.org>; Thu, 14 Mar 2019 10:50:57 -0700 (PDT)
Received: by mail-vs1-xe2e.google.com with SMTP id h132so3800912vsd.5 for <dnsop@ietf.org>; Thu, 14 Mar 2019 10:50:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m3SYk4wKl+h3WmdMDap+i8XwvvrmCU50bpH/LPbNU5Q=; b=F2clig0lUm8QKg8baPjbbEWlTT4PrG5FZNpPtUJ8Et5h/sVG9IPydpO4HNWsRSsdtp xkYkYG5eIIXNGVyopqfFciMSFNm7qyTULtHdf9MxKr+JsdoiJv+hzzSc2/GaARX/tJrb XlBiPxpATbRZ0s6Br2B7g/EDgnRy0pnLIMegsAx9ALPkYdOm5TlLqJ9mvjkXQ/4s8MkT m92Co++VIBWNgj/IsXZ/6PESKvpK62+ykvcm9i/zJutkBfW6WNQvN3Crona7QtXoRMBJ 8b96Os8tvj/fLss6BW692YHw8GdNFpuHenQBsvjhYkJ8TvuTAK5hmYR/IcZSd6L0gZIE DPJw==
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=m3SYk4wKl+h3WmdMDap+i8XwvvrmCU50bpH/LPbNU5Q=; b=szmxrcYg6OgqZZDC40HIqMLyN7tn0SVKOfysVKYmIZ+YyhUZe8+aWxn3Qc82sT6BsE 1gb0L2vlr7QRH5XeYjsM/0DVodpwZf0W178psoZJPmPb2hr+MiTgCITXvHH/QS+Ee2tK D10qYyPb5+yUygl18+jpujuIHmcGGSK9jolSoM1p4/r4F3hi1odiWf1XZHwKV6J2LXxU y5u+i/iwzTnhHqyD5msTA6jzNWwIgDzaAMMwfoK+Cnzf8QyQdsFDzEOlVJRcFJBE1nU0 lKxwt8dqqlG5Ia1Z8nn7B3vlYxKkaEwxG2fVlnmLdS/j/UbUnPk0A244prdIYEluP52N 2AUQ==
X-Gm-Message-State: APjAAAUlspOYlV8xexFuj7oSwm0Z0LE7cC0Kmuhkwkf9/VKLGXGEzjdy IfgUtSXet4JOgsQsIRV9UMbOfLsbA1HAOi41Cc1CFQ==
X-Google-Smtp-Source: APXvYqyGe3H+EZaf97GikRSSMzyCp01stcsHy3bM3ykRXWdhoGMBNbmlSTp3HgFOL4Erdpnqtth+FEswk04asIH9FT0=
X-Received: by 2002:a67:ebcd:: with SMTP id y13mr4977870vso.152.1552585855991; Thu, 14 Mar 2019 10:50:55 -0700 (PDT)
MIME-Version: 1.0
References: <20190311170218.o5hitvysuefhjjxk@nic.fr> <2044747.4WdMZHU4Qz@linux-9daj> <D97261BB-1D62-400F-8EBD-886B5BA586BD@fugue.com> <4425132.CsHbCTgi9Z@linux-9daj>
In-Reply-To: <4425132.CsHbCTgi9Z@linux-9daj>
From: "Vinicius Fortuna [vee-NEE-see.oos]" <fortuna@google.com>
Date: Thu, 14 Mar 2019 13:50:44 -0400
Message-ID: <CAJVAGYg+AmaK4AgkrioMt1Z_UGVZdnsNuNasnouuxUzaU7kMxA@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: Ted Lemon <mellon@fugue.com>, dns-privacy@ietf.org, dnsop@ietf.org, doh@ietf.org, Vittorio Bertola <vittorio.bertola@open-xchange.com>, hrpc@irtf.org
Content-Type: multipart/alternative; boundary="0000000000006e760205841190d0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/RN9tMYs8Orq5fJAWbhTkAu6cx3s>
Subject: Re: [DNSOP] [hrpc] Proposal for a side-meeting on services centralization at IETF 104 Prague
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2019 17:51:17 -0000

Paul, I'm trying to understand your scenario.

If you ran your own DoH server in your network (doing RDNS or whatnot), and
the DoH server is distributed to clients via DHCP + a protocol upgrade
mechanism, would that address the concerns you are listing?

Vinicius Fortuna

On Thu, Mar 14, 2019 at 1:33 AM Paul Vixie <paul@redbarn.org>; wrote:

> On Thursday, 14 March 2019 00:48:53 UTC Ted Lemon wrote:
> > On Mar 12, 2019, at 2:52 PM, Paul Vixie <paul@redbarn.org>; wrote:
> > > please do not relegate discussions about the loss of operator control
> over
> > > the RDNS control plane
> >
> > Although it’s certainly true that DNS is used as a control plane by many
> > operators, there is no standard “RDNS control plane.”   ...
>
> i don't think lack of standardization is the same as not existing. devices
> which honour the dhcp-assigned rdns service, work as expected, and as
> intended. devices who ignore that setting and seek their own rdns by their
> own
> internal configuration, will often not work at all.
>
> because many of us amend our locally visible dns namespace with things
> like
> .corp or .home or .local, it's even more vital that devices respect the
> rdns
> assignment i make. the dns content i want to be visible on my network,
> have to
> be visible on my network.
>
> because many of us won't allow pirate or malware or otherwise undesired
> DNS
> lookups to succeed, either because we don't like the name, or we don't
> like
> the result of the query, or we don't like some name server that would be
> involved in resolving it. the dns content i don't want to be visible on my
> network, have to not be visible on my network.
>
> from the days before dhcp when we typed these numbers in by hand, until
> now,
> it has always been the expectation that rdns was part-and-parcel of local
> network service. no different in that regard from dhcp or arp, neither of
> which is standardized under the heading, "control plane", yet, are.
>
> so i think i'm not going to follow you down this terminological rabbit
> hole.
> the reason that internet creations of yours will work better on my network
> if
> you treat the rdns as part of my control plane is, because it's my network
> and
> that's how i operate it. you're not welcome to bypass it, nor answer dhcp
> requests when you're not my dhcp server, nor answer arp requests when you
> aren't the device i assigned that address to.
>
> you can call that tautological if you wish. but it's the life my networks
> lead. external DoH providers are explicitly not welcome to provide service
> to
> malware or intruders who get into my network -- because rdns is part of my
> control plane, and like arp and dhcp, i control it and i monitor it, for
> $reasons.
>
> > The problem with the discussion we’ve been having about DoH and how it
> > affects your “RDNS control plane” is that we’re talking past each other,
> > not that the discussion should be had elsewhere.   It’s fine for there to
> > be a discussion, but if there is going to be a discussion, participants
> > need to engage constructively, and not just fling slogans at each other.
>
> i think i've flung considerably more than slogans, and, it's been
> exhausting.
>
> vixie
>
>
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc
>