IETF Logo Mail Archive

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

Mark Alley <mark.alley@tekmarc.com> Thu, 14 March 2024 21:05 UTC

Return-Path: <mark.alley@tekmarc.com>
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 54E35C14CE31 for <dmarc@ietfa.amsl.com>; Thu, 14 Mar 2024 14:05:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=pass (2048-bit key) header.d=tekmarc.com
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 xsQLjr6vfIS7 for <dmarc@ietfa.amsl.com>; Thu, 14 Mar 2024 14:05:21 -0700 (PDT)
Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B65C14F5EB for <dmarc@ietf.org>; Thu, 14 Mar 2024 14:05:20 -0700 (PDT)
Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-dd14d8e7026so1267342276.2 for <dmarc@ietf.org>; Thu, 14 Mar 2024 14:05:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tekmarc.com; s=google; t=1710450319; x=1711055119; darn=ietf.org; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=UrX8HevdfCytMFaIgVXxtFrcGrDLeHMMgR1QjJ3yEcg=; b=FB3m9TcmnNnwK7dCQlHnRgVVy1xZSrQHMzZhAvCA8t84aHGR1h1Sgw6WPYOC9Dp7uc c+aw3sQVuf6OitFV33lplS/fHC3jroExu7OsazyZZCMRsW5fFEe/7qZnPeK0C66rpUzf UiXPuzyhlyHu2hNIKPlKqCFgQ3CLeDheQoj9Fxe1M0LWro1WNcBGZZzkfZ385lNoV5MP 4/gGb/PhzW/uNbpxOFcCOgPkChoFYDL0/ivUsE4kgMV8CTvtELfw2I9dBNJrIfp6y5OR UNfPlvHEZlx9YTCjHjTLGJSvLPf1SRt+Y+BQ2BFKSyRgXqCAfou/u8wEcbG7VSfMtOtJ NTqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710450319; x=1711055119; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=UrX8HevdfCytMFaIgVXxtFrcGrDLeHMMgR1QjJ3yEcg=; b=IWvY8DUeOJDfe1kTBOFpy8LfNQJ0cj1QCvXdFoP9Z2k8WMS75Y1RShan6dHuk4hSQV 5GH+Fkd31LWP02t1sc2ScEp8cR8SLL4Ry/+ClN6SvcvzINTPo0r6m4+o0o1j/AaF7rUs Okns7Mqh/hqMUQ0g9pDqIT23XULRwIhcviUgR+ihbc7bZhHVb0WQF8R8+mYXu4rOjGXE pe2YOMMq+6k0ORgWWWYZiIxfN1HP5Pk+OYLbTFwpF6cwbdMbKn3oum3Y1qObPQUZbKof YDa8vE4slFQyQpEyP6EVzcGVg3NFPejnxCz/Y3IYCRvtH372W3gPa8cKDy2EhEyt0zHD 4tzw==
X-Gm-Message-State: AOJu0YzdhV9LPstNkBAY/4aD536/TcW3sGfgHhwfsVNICjasN3afWDlj lMT4iCBp52+wh2QWbhXDQbFzFLaGJ/RX2r4ujzMFTf3hQb6qtRCFJe700dLTQ8+ny5lE6Hh4Uqd s
X-Google-Smtp-Source: AGHT+IEPfATCjMu1PC6pZ9/SqIoxTJxr3y4eL005PreSJGvZ3JSXP21GFvAmgTFfctRgjf2tHSqavA==
X-Received: by 2002:a25:8489:0:b0:dcc:f2a4:153e with SMTP id v9-20020a258489000000b00dccf2a4153emr2976941ybk.46.1710450319203; Thu, 14 Mar 2024 14:05:19 -0700 (PDT)
Received: from [192.168.2.20] (162-238-103-217.lightspeed.brhmal.sbcglobal.net. [162.238.103.217]) by smtp.gmail.com with ESMTPSA id b11-20020a25ae8b000000b00dce0a67ac8bsm419959ybj.23.2024.03.14.14.05.18 for <dmarc@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Mar 2024 14:05:18 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------0H49kTD2JsKzerKuTPZ1Ra4u"
Message-ID: <d87d4fd3-2a28-49a9-b427-b11e2f14b984@tekmarc.com>
Date: Thu, 14 Mar 2024 16:05:18 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: dmarc@ietf.org
References: <CAHej_8kip_p+n56=Y5WuVG2M_+HXHj51fyY3k6dx-itJRZkCpQ@mail.gmail.com> <B18FD596-D342-4569-8A23-3E01B137DDDA@kitterman.com> <CAHej_8=+fHDstBHCzS54cr5dmGo=XfyXy0wzaS6gY6WokpF_Lg@mail.gmail.com> <791cdf24-011d-4cd1-83cd-79d438f3020d@tekmarc.com> <CAHej_8my0_2y5NqsqawiH3x1S5Xn14eGXGYDNfHmPOWu585TKw@mail.gmail.com>
From: Mark Alley <mark.alley@tekmarc.com>
In-Reply-To: <CAHej_8my0_2y5NqsqawiH3x1S5Xn14eGXGYDNfHmPOWu585TKw@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/IKfLeESHOyIDBZlrpKyS7crv-z0>
Subject: Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs
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: Thu, 14 Mar 2024 21:05:25 -0000

On 3/14/2024 3:49 PM, Todd Herr wrote:

> On Thu, Mar 14, 2024 at 4:43 PM Mark Alley 
> <mark.alley=40tekmarc.com@dmarc.ietf.org> wrote:
>
>     On 3/14/2024 3:38 PM, Todd Herr wrote:
>>     On Thu, Mar 14, 2024 at 4:34 PM Scott Kitterman
>>     <sklist@kitterman.com> wrote:
>>
>>
>>         I think this is correct.  I think it's obviously enough
>>         correct that I'm surprised anyone was confused.
>>
>>         Do we know what the theory was that led people to think
>>         otherwise?
>>
>>         Seems to me we don't really need this, but maybe there's a
>>         reason.
>>
>>
>>     The reasons given were:
>>
>>      1. https://www.rfc-editor.org/rfc/rfc5863#section-4.1
>>      2. https://datatracker.ietf.org/doc/html/rfc6376#section-7.5
>>      3. Neither RFC 7489 nor DMARCbis contain the phrase "CNAME", so
>>         if it's not explicitly mentioned...
>>
>>     Granted, the first two citations are in regards to DKIM records,
>>     not DMARC records, but those were the reasons given.
>
>     Couldn't hurt to clarify explicitly, I'm for it. Domain owners
>     have been using CNAMEs with DMARC TXT RRs pretty much since its
>     inception.
>
> I agree that clarifying it can't hurt, obviously, but I was quite 
> surprised to hear that CNAMEs were being published for DMARC records, 
> as I'd never seen one. On the other hand, I've seen *lots* of DKIM 
> public keys published as CNAMEs, which I'm sure just wrecks the person 
> citing DKIM RFCs as a reason that DMARC records can't be CNAMEs.

Domain owner use cases with DMARC CNAMEs boils down to really either of 
2 things:

  * Single point of policy management for orgs with dozens, hundreds, or
    thousands of domains to manage DMARC on, and also applicable to
    RUA/RUF addresses.
  * Delegation to a third-party for management, similar to DKIM CNAMEs
    as you noted that are popularly in use by many ESPs for
    vendor-managed key rotation.

- Mark Alley

v2.23.0 | Report a Bug | By Email