IETF Logo Mail Archive

Re: [dmarc-ietf] what to document about the tree walk

Alessandro Vesely <vesely@tana.it> Wed, 13 July 2022 10:05 UTC

Return-Path: <vesely@tana.it>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA31DC14CF0B for <dmarc@ietfa.amsl.com>; Wed, 13 Jul 2022 03:05:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.128
X-Spam-Level:
X-Spam-Status: No, score=-2.128 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=A6CUOOS+; dkim=pass (1152-bit key) header.d=tana.it header.b=CTIrGhGR
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zQtfpMvmt7q for <dmarc@ietfa.amsl.com>; Wed, 13 Jul 2022 03:05:08 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61EC9C16ECB7 for <dmarc@ietf.org>; Wed, 13 Jul 2022 03:05:06 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1657706705; bh=pEkBftEEqwPNilkouc9o9dUtfMENdjLOMCji/xDpBzE=; h=Date:Subject:To:References:From:In-Reply-To; b=A6CUOOS+OB+jSVuJHXkpvxRRx/fTmqMAHwWalZ2A2kJixSjr+duBfIvrGicubIqLI 18pGbrCPkX6tOS3ST3FAw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1657706705; bh=pEkBftEEqwPNilkouc9o9dUtfMENdjLOMCji/xDpBzE=; h=Date:To:References:From:In-Reply-To; b=CTIrGhGRACPNat15BgPqG4Hvkwkj4yiBW5wECMccTNqDTj6lMS0JYf1IljDKEeXCU VxsxOSejEXxDIjF0UUooijPcN3OzFS68SQegQyNtKbA5xRL+lBqtF9KtMw4+FMFEbz nLgQwlRE0GOqWH3wqzmeadtxaGo0U0uDob72vXuYJ95wqSFgHgedlUO+BffW5
Author: Alessandro Vesely <vesely@tana.it>
Received: from [192.168.1.108] (host-82-56-132-47.retail.telecomitalia.it [82.56.132.47]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0C3.0000000062CE98D1.000073F7; Wed, 13 Jul 2022 12:05:05 +0200
Message-ID: <ff0d6007-e5a5-f9eb-dd8a-d57ca68f35f4@tana.it>
Date: Wed, 13 Jul 2022 12:05:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
To: dmarc@ietf.org
References: <20220710010547.DB3B04532F40@ary.qy> <d8716435-8a52-dac4-ede2-6c27fced7f0f@tana.it> <84DDA91C-26E2-4803-8C6C-0369ED67298F@kitterman.com> <c4a7fd03-eae8-497f-3133-73523a9c1ca2@tana.it> <5197ba5f-9de4-d838-1579-eae67683e2d4@taugh.com> <650cadee-db8f-a54a-4d14-082c2d0bed02@tana.it> <0f3a343b-e7ea-7509-ceab-e5670aac8616@taugh.com> <CAH48ZfxHgxZwu3zLh99pc1JS4s==9bxU-0nS78O=7UAnZ=DtUQ@mail.gmail.com> <CAHej_8nkpGo30b9-ZkRc_wokymJ2ry_hsMgzaB2m4EH-WWG_zw@mail.gmail.com> <CAH48ZfzoVocPRKeVTqf6AE6Z48AWKFObm7X5oDa1ic1sQ5V1zg@mail.gmail.com> <CAL0qLwZFO_KK3+RUdzMLyjW0uOnzi4mXcVww1Mqx8tmhe-x2hA@mail.gmail.com>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
In-Reply-To: <CAL0qLwZFO_KK3+RUdzMLyjW0uOnzi4mXcVww1Mqx8tmhe-x2hA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/DgJTTiQJuF2ZvRkLxAoVgcWRSf0>
Subject: Re: [dmarc-ietf] what to document about the tree walk
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jul 2022 10:05:15 -0000

On Wed 13/Jul/2022 07:12:25 +0200 Murray S. Kucherawy wrote:
> If we want a migration period, some kind of hybrid model might work: 
> Do the DNS tree walk, but at each step, if you find you've hit a name 
> that's present in the PSL, you can stop and pretend you found a marker 
> you're looking for.  When those markers are all (or mostly) actually 
> published, then stop doing that.  For bonus points, find some non-DoS 
> way to notify those operators that they really should be publishing 
> the missing markers.  (The 1990s DNS "lame delegation" stuff comes to 
> mind.)  We just need to remember that SPF had a not-so-great 
> transition plan, so we need to be careful how we craft this one.


Uh?  manuals recommend to look up WHOIS to determine the owner of 
domains reported to suffer lame delegation and contact them... 
Nowadays, contacts for domain names are not available that way.

We could hijack reporting addresses, though.


Best
Ale
--

v2.23.0 | Report a Bug | By Email