Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

Keith Moore <moore@network-heretics.com> Mon, 07 February 2022 02:56 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C453A1224 for <behave@ietfa.amsl.com>; Sun, 6 Feb 2022 18:56:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level:
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.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 9jPMpB6OpSmg for <behave@ietfa.amsl.com>; Sun, 6 Feb 2022 18:56:00 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E5D3A121A for <behave@ietf.org>; Sun, 6 Feb 2022 18:55:58 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 980835C00E9; Sun, 6 Feb 2022 21:55:57 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 06 Feb 2022 21:55:57 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=qdI0+WgU+CTkgvFpsvWT5bkhq5Uzj2GWlFkHlzzgC1c=; b=ABcYjM+9 tNYRwrahgE+RQWS+r+d6rrHZydXThADMcaWSkPEUIPS9Ouk4DS1OZqtgsYTOM7uB TSxDdIifMsF6prmlKHt4p9b43ukXvcd73pbCi8FYa8Z5vEIX5Kj/80RAh2qa1JTX UjOvGZab2J5yegwu1jUANgmZWjB5fHXYsvqgAC2fQjGtjepdPU3USyYWS36Dx54Q GhGGnSS7+/9kZCZNwCHrPgQAYzeBKvn5St1zha8iSAsi1SezIVP2DktveLEEjEWa sxZIHwyIThZm+WCSSImUxaRfZz/SGmhM7StKOh82owzDeEOrnn3CG5hiPVB7RBb5 M/bvGxsr9iR9Bw==
X-ME-Sender: <xms:PYoAYjxm6ff34g2N-RC551PbZLpPy9tCiFD9o7OTI4XkdYg09ylqAw> <xme:PYoAYrSLgM8qwzlGT775nNSvyLEIDI6GutJP8O9c0VxKko3MBSheD9n0IAdVgzZB4 nBcyM8MNx2jUg>
X-ME-Received: <xmr:PYoAYtWLj7BkRLWGZq00ADSGzvKPP1v_pLYfQo4w4xMi4dBOfpmrE-Y3js18c0edtu5NMMBfcNkK2wFLr18YDBwjxTHRhFevKweF>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrheeggdeglecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfhfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpefmvghithhh ucfoohhorhgvuceomhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhmqe enucggtffrrghtthgvrhhnpeeftddvleeijeevkeejhfeuudehveeihfejfedvgfduhfff hfduuddufeeggfetveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:PYoAYthT_wclrDkhXkxWxdlgsQZzScKrEU_JGDJu4ADJ8D8P2rDzfw> <xmx:PYoAYlCHbqR5Ab9IGrsSgGUb8l6EgGZw00LZhrjYogmJAF-CqhJwbA> <xmx:PYoAYmIZSO8RTDoG0XsRbwdiKjxp9ka-r7PhOv0JQ5aS_AVewqAeVA> <xmx:PYoAYopucJPiRgl0kc69cPZT-xIQOD2gelRQTXNg8FwJHDZE4IQKgQ>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 6 Feb 2022 21:55:56 -0500 (EST)
Message-ID: <f2aee64b-658f-7d12-6409-cff2c8a0df3e@network-heretics.com>
Date: Sun, 06 Feb 2022 21:55:55 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-US
To: Klaus Frank <klaus.frank@posteo.de>, Christian Huitema <huitema@huitema.net>, behave@ietf.org
References: <45e423cc-4095-cca2-bf8c-aa15e977b19c@posteo.de> <ff858dee-a21a-a50d-72a5-da7915ac2de4@network-heretics.com> <71b5cdb0-78af-0f77-debc-84e178fe5e3a@posteo.de> <7a008cc2-e8a3-f91d-c782-96866c36a9db@network-heretics.com> <ee760818-a3c4-3755-6bdf-afcec6fcaaad@posteo.de> <B7DFC369-E7B7-4171-9C85-F75986B5AEF6@gmail.com> <6123a322-e9a7-7f90-391f-9b4c4461ce45@network-heretics.com> <e95993e4-4166-4b3d-1637-8ca451b093b6@huitema.net> <7b7cf541-3387-6d0b-0fbe-273a08fd37ed@posteo.de> <0d18c171-f713-4590-d9a6-3c5729a3384c@huitema.net> <a4dbfa8c-abb4-e4e7-e53c-d7f54a2e5bf9@posteo.de>
From: Keith Moore <moore@network-heretics.com>
In-Reply-To: <a4dbfa8c-abb4-e4e7-e53c-d7f54a2e5bf9@posteo.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/V_QV4pL_US3sgyhRd1ShAAjccq4>
Subject: Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/behave/>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Feb 2022 02:56:06 -0000

On 2/6/22 21:48, Klaus Frank wrote:

> Also the noted "smtp server and DNS may not be under the same 
> management" is also one of the reasons why it should be within DNS64. 

Disagree.  One of the general problem with DNS, BTW, is that the people 
who operate the DNS servers and the people who operate the applications 
that require correct DNS configuration are often not the same people, 
and often don't even work with the same company. So DNS already gets 
out-of-sync with reality too often as it is.

If a NAT takes it upon itself to alter DNS records in flight, there's 
even more potential for the DNS to get out-of-sync with reality, and 
three different parties that have to potentially be reconciled to fix 
the problem.

Of course this is a big reason that applications are increasingly using 
DoH or DoT to query a trusted server whenever possible - to minimize the 
potential for some third party to have screwed things up.

Keith