[dmarc-ietf] Performance and reliability concerns

Douglas Foster <dougfoster.emailstandards@gmail.com> Wed, 10 April 2024 21:31 UTC

Return-Path: <dougfoster.emailstandards@gmail.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 8E752C14F60D for <dmarc@ietfa.amsl.com>; Wed, 10 Apr 2024 14:31:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vjbmh8YCg-F0 for <dmarc@ietfa.amsl.com>; Wed, 10 Apr 2024 14:31:29 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 1E35AC14F601 for <dmarc@ietf.org>; Wed, 10 Apr 2024 14:31:29 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2d6fc3adaacso89029581fa.2 for <dmarc@ietf.org>; Wed, 10 Apr 2024 14:31:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712784686; x=1713389486; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=H4Snl/NtLseMq7JTSrwlV8ivTWc8Tz7qpP+tagxeCPc=; b=h3lv2abFy+qt7hFYb7IIwout52VDrzZzkczN680HFb0ciqf1HOdErvdgCUQReMecQX gLqRaWJmkG/OlaDc2d8Io7ozby1XIulooLoK6Cd1eeAvGKaH5SUSU2eVYfMiASAQIATN L+ZsNdE/AXciNagjBhmfaqAxuEQ78oMWvcH0RpnV3xGBMQWopfas6OEM0IamcS5SXK0z X8yEHv29j3iMSnj4LLx8p6Jgzcp1+yk6eAWQUVr9kmDFgzEF1iSBQTsGVI6ZfwEWb4zg mXbLJ5cT7p9PVKNkQnC5hlMBI0QaJLsYVlnDNeVmgxlDhfC3bzWpFALsvQ8XUF9cG19z oTSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712784686; x=1713389486; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=H4Snl/NtLseMq7JTSrwlV8ivTWc8Tz7qpP+tagxeCPc=; b=EXUkLpSTaLsNIlxIQyFvIXbaHLglxhvPLr8J79hpCy+nrMyRIY2mANRiP8qLmteata IHGtfVX7b02h5veIWuIMmFLlNwYtnIfJ6DfTtGHI3TBfaa8uGRaNCI1A5c21agR9YsjJ tWPTmAgg7gi5Qhqi1XWQeOLUvwMcBP7etOuqpOZ3nat7/nGxEf1qRK71cMYFnjQmGU68 Kiu98dZoTJgykQY+dGE1ylE+ZRBhV2HG2o6/I4Qj2wPHUfWDILGfiSkWSji1q7XTBpzb XBsa5Ybv5Q5t4ci8Vdc7bSxmKM6RWC2OZSzLtVGp4+If9PFA5vCrxvMIv/16ofGBArNP /Bnw==
X-Gm-Message-State: AOJu0YxoevSOuAYutL2wRKzVRaddFoSnPzLmBTBzLKXOxNZVrNrpa894 v7cnY6X71Km0nBRDeOrLrmFeMHZlHpnorvbJnlQ547sTnfLb/eV34PMAyFJo3+E7nD/c5vJPyJo ONr9tbW/EM896oLfVaBwq8FQ6Khq/6Wup
X-Google-Smtp-Source: AGHT+IGBxCkLsdp79/JgtndlJBS0r24L7C3aJEi6wI3h2Hvl+soT7KZJFXQjEh4p/dPeWVoqhdf5fuBUWNICqBhxQU0=
X-Received: by 2002:a05:651c:4c7:b0:2d4:7829:4d11 with SMTP id e7-20020a05651c04c700b002d478294d11mr3099684lji.39.1712784686318; Wed, 10 Apr 2024 14:31:26 -0700 (PDT)
MIME-Version: 1.0
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Wed, 10 Apr 2024 17:31:14 -0400
Message-ID: <CAH48ZfyvsAMuZ-JFzqMjo1pJ9Ax==Kgi3c7hQ+1TECZCqCpPVg@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ce0dfb0615c4c2d2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/PWYvzeUVIrtSwyUQmpU-78ZJZLY>
Subject: [dmarc-ietf] Performance and reliability concerns
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, 10 Apr 2024 21:31:29 -0000

I am concerned that the Tree Walk will have poorer performance and poorer
reliability than implementations based on RFC 7489

The boundary between organizational domains and their registries is very
stable, which is why it is highly suitable for a static reference like a
locally-implemented PSL.   Database lookups are fast and reliable.

The Tree Walk calls for the organizational domain to be recomputed on every
message, for every identifier of interest.  This means that the volume of
DNS queries will increase, although the percentage increase will be highly
dependent upon the optimizations built into a Tree Walk implementation.
 Overall, any Tree Walk implementation is expected to be a net increase in
workload to both the evaluation server and the DNS environment.

These extra DNS queries also hurt reliability.   A walk result is uncertain
if any query along the path produces a timeout error.   When a path result
becomes uncertain, the overall DMARC result may become uncertain.  This
risk exists in PSL implementations, since the evaluator still needs to
retrieve DMARC policy, SPF policy, and DKIM keys, but the Tree Walk is at
greater risk because it performs so many more DNS queries, and these extra
queries will be adding to any congestion that may be causing timeout
results.

The magnitude of this concern depends on the frequency of DNS Timeout
problems.   Upon reviewing my DMARC aggregate reports and my own data, I
was surprised that both sources indicate TempError results occur at a much
higher rate than my expectations.

One way to minimize this problem risk is to store error-free results in a
cache structure outside of DNS.  The already-existing PSL database provides
a starting point for this cache.   Once a cache is available, the Tree Walk
process can be moved offline, and used as a tool for validating and
updating the PSL, while continuing to use the fast and reliable PSL
database for real-time queries.  This addresses both the performance
problem and the consistency problem.

For those who don’t implement something similar, I expect them to be
frustrated when they discover that the extra overhead required by the Tree
Walk is coupled with reduced consistency of computed DMARC results.


Doug