Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Ted Lemon <> Sun, 19 August 2018 01:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 37E86130EA0 for <>; Sat, 18 Aug 2018 18:09:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id orGyG9WfDRvX for <>; Sat, 18 Aug 2018 18:09:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 99492130DD7 for <>; Sat, 18 Aug 2018 18:09:16 -0700 (PDT)
Received: by with SMTP id v71-v6so16345325itb.3 for <>; Sat, 18 Aug 2018 18:09:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9kXhqrA2zJej/mjs/tqQV7WGBUwbBDR2447XQD/OfzA=; b=Tr71NJv0K2DZy1B5GTaK505yhEI/13ihBXsbrQ5+DqenehsKnX4k45sMC0cMC9jyrF uWtiL+yL8t6rwrVIF7cuD5woZ4oCDafps352j2wlKrZHZZwN6/q/A2EI1+f+csQhLthC E8l3mm+SKx8DRj152yLEY2YhfItCYmDQ3zbhG99mtonM0yLYxcCD1TnW3op6TN9roC2R kxyCzdylMb+Ffb6uthixdtwsheifpsgrhIG9qTiUKwFxbiWOlxPp0dPQ4Szt9xlzu8Xh e7S4p0mWVtoPd19JLWE2Y2ZHkvXp26NLyDZu49yTNt/RIZLZlcNRnl0n7hRDkutB9OJu eLVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9kXhqrA2zJej/mjs/tqQV7WGBUwbBDR2447XQD/OfzA=; b=XX6KRI+QLRxLtd6wKiQo6zP91LnqsIStBdU0JFSDBv3FaTq3gIdD192+4Ao8JeJC5u oJ1fJ+zHJVoMcgDxUuQ5ixZGe5CXURUXflLupOGC6FDG+P0J+95U0WFgqiAGxJcmI6k3 DmvjWvp5iEa9Yfb/hkSGHm30VrSd4sXiO6ZxsfROD4U9fUkEMyqEFD3B1gw35mRQcoWP YT7UqHe6I0DSpkfJIJInu1feAJKLNMOEfTFRSQMLHLKaTdKkO4f2XFb74rxVzRIGg2LJ ZesNhWPZeEi/6huUVgKjzxqD27/UcSaxPYl2KVGI7NGBGQRoA/CdKKJpnsG2b6L6rziS WIlA==
X-Gm-Message-State: AOUpUlFAeBaESX4GFkDp1IfLIJnHMC5VUHeQFY3ueXb8Z3zsH7d2+WQT LUcto0GwQOhU1Y4UvlQdyMvrJBCerR+dRNGmVkpMxw==
X-Google-Smtp-Source: AA+uWPykj2OasQFw9KHAn7YJbxGS1nnz3wPLkAAk4/Wm9pj+OoI3gguooSLosIwUnGFXNrwSNkRTsH5vpRNAvFyvmOw=
X-Received: by 2002:a24:5f92:: with SMTP id r140-v6mr30406132itb.95.1534640955855; Sat, 18 Aug 2018 18:09:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Sat, 18 Aug 2018 18:08:35 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Ted Lemon <>
Date: Sat, 18 Aug 2018 21:08:35 -0400
Message-ID: <>
To: Paul Vixie <>
Cc: Marek Vavruša <>, dnsop <>
Content-Type: multipart/alternative; boundary="0000000000000831d10573bf71ae"
Archived-At: <>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 19 Aug 2018 01:09:20 -0000

The thing is that most devices don't connect to just one network.   So
while your devices on your network can certainly trust port 853 on your
network, when they roam to other networks, they have no reason to trust
it.   If you have devices that never roam to other networks, that's fine,
but we have to design for the more general case.   There's no way with DHCP
for the device to tell that it's connected to a particular network, other
than matching IP addresses, which isn't a great idea.

On Sat, Aug 18, 2018 at 8:54 PM, Paul Vixie <> wrote:

> my threat model is intruders or eavesdroppers on the path between me and
> my rdns. i'd like the dhcp announcement to include a tcp/853 signal along
> with a pre-shared key or the hash thereof. the benefit would be that if my
> rdns network path is less secure than my dhcp network path, i'll improve
> the former by not using traditional udp/53. does that help?