Re: [OPSAWG] [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt

tirumal reddy <> Sat, 26 September 2020 07:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 328913A10FA; Sat, 26 Sep 2020 00:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 m7Zn-YwzGGBc; Sat, 26 Sep 2020 00:39:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92A7D3A10E8; Sat, 26 Sep 2020 00:39:33 -0700 (PDT)
Received: by with SMTP id g7so5851145iov.13; Sat, 26 Sep 2020 00:39:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NOffToEETWiKgflvWxwiOcpJyBIACIW1P+zA6yyCaao=; b=jEowS07KO7hgWSUVLfJDHEq7IVtVGzbQrhxYK+Ea67lKqydTz8HzdRB81CD9nim4PL i93vLc8lh+O1C4QzKvnmrVrZljG4nNwpn06gcXd1PJBLdyUCNjbemV/54eKvq631/U1c S4U4QGX/N1seF6x29jaU9PXey+epN/qLlqNo/QOahY2VO8GBujLvCeETJB0dThacjflT t9zmkt+ZBnKyCmHk7ccFAWK4+Q5oG3bJGxKuwOrdlHh0HonMqP4Q7VqfuTN6xjROoll+ yIqIAT7dYr99Zo7eRR0z1gKpKQbBFPkvFBkoszJgoY0x4dQIL1vY/SGspU2xcSIY7pGB D/dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NOffToEETWiKgflvWxwiOcpJyBIACIW1P+zA6yyCaao=; b=hiX0tVjLNDMySl4kd7VGKGy/IIRuZHi0CP4DQihbEA/Yccg5Mj2S4OhRzKS9AdcSKY 4pVXL4MbCKZT7/EesDy/t7LlylPNg8ihsl3mp31bVGAjRbjD0ktzTcg+qrCaAtSMW3Nn P14Y7xeakkORaJGvkhC+4nNPEwLWhKUebABraplNJN5Ag7cCn+qO09ZZciDuFOuEvmx4 rFDSt90dsvcbn236KUzeuQKdutmCEovOgn/O+F1Ns7/ANR0F61EZeZFYAZ5JAxO//ahC Sqg5SfVccWJrWUdPqmQ29fVH8KLvmmisag1N19BXl4kaaonU+duxEl73vwgo7t2H3xSg JiUQ==
X-Gm-Message-State: AOAM531D3xlD7ymE7C4Crwmxm9P59sJtfNgunzqHlnRauAy7iNeGF97F CZAI20l+pfgA9EkQvkV6pkVF35yQve2BZxCJyvF35VZjbkF+innN
X-Google-Smtp-Source: ABdhPJydXO8gGMRytX/HAeVAycqZhgB58pgJWJlnPHz7afgDH6GZ31zpVeSPLUh0l8zJv3D9FQcCpFuZLeb7aX1/DoI=
X-Received: by 2002:a6b:d908:: with SMTP id r8mr1577747ioc.21.1601105972764; Sat, 26 Sep 2020 00:39:32 -0700 (PDT)
MIME-Version: 1.0
References: <> <15779.1600960819@localhost> <> <> <15491.1601055706@localhost>
In-Reply-To: <15491.1601055706@localhost>
From: tirumal reddy <>
Date: Sat, 26 Sep 2020 13:09:21 +0530
Message-ID: <>
To: Michael Richardson <>
Cc: Eliot Lear <>, opsawg <>,
Content-Type: multipart/alternative; boundary="000000000000c1271f05b032885e"
Archived-At: <>
Subject: Re: [OPSAWG] [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 26 Sep 2020 07:39:35 -0000

On Fri, 25 Sep 2020 at 23:11, Michael Richardson <>

> tirumal reddy <> wrote:
>     > +1.  The problem is not just with public resolvers but also with
>     > designated resolvers. The IoT device supporting MUD must use the
>     > encrypted DNS server discovered in the attached network.
> Yes-ish.
> I don't think that we have to mandate use of encrypted DNS servers,
> as long as it's the ones on the attached network.

In the home network use case, if the CPE does not support an encrypted DNS
forwarder, endpoint will discover and use the ISP encrypted DNS recursive
server. The CPE will no longer be able to enforce MUD rules. For instance,
Firefox can discover and use Comcast Encrypted DNS recursive server, see

> My take is that it is better to use Do53 across the local LAN than public
> DoH
> server.   If the IoT device can be convinced to use the local DoT server,
> great.
> But, your documents in ADD are clearly trying to get there, but we aren't
> there yet.

In the interim ADD session 2, the consensus is to use DHCP/RA to discover
the local encrypted DNS server. extends DHCP/RA and it
also discusses hosting a DoH/DoT forwarder on the home router.


> I've been looking for a YANG module that would allow for explicit
> management
> of "/etc/resolv.conf" on a device.  If there is one, I don't know where it
> would be.
> --
> Michael Richardson <>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide