[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
- [dmarc-ietf] Performance and reliability concerns Douglas Foster
- Re: [dmarc-ietf] Performance and reliability conc… Seth Blank