Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains

Tim Wicinski <> Fri, 23 November 2018 16:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8CCD9130DFF for <>; Fri, 23 Nov 2018 08:57:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DGpYM5uJX6bc for <>; Fri, 23 Nov 2018 08:57:29 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 80F1212F1A6 for <>; Fri, 23 Nov 2018 08:57:29 -0800 (PST)
Received: by with SMTP id x19so19255976itl.1 for <>; Fri, 23 Nov 2018 08:57:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=67lXZyrYLn9/R7b7Ms6T1Tdaui9QPv4jt9kHlDJxG44=; b=J9wKM2FHW9k4C55t6rt2wlHM3u6zmU8Qn2ACx6OjqJlZC0VtI+ae6AXFpPz1BxuEF+ /kULMT1BAnLeTte9JO9UlP/XSEHHvLyriP9rh06u6igRIxIyh11nKHjm2BH9Y6zodSKZ hx9NIkBV9CZ6D5nopT63F5R3lMFajYIUneU+TaQKR1DrQFlyO5q7pqsFQvYb392QlXC7 xl47EeEkE++znc39QbAFqYY73U6mpmzzTlkCAX9mRdiH0NegSYN3/zMiQcRdzzugIFJ8 wpZZFz9XfFfdPsVQuqQdEEm+iWsbvzaMN9H8Ii025LITyPjWAhJ+buCAx2C3RetekKjL HGpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=67lXZyrYLn9/R7b7Ms6T1Tdaui9QPv4jt9kHlDJxG44=; b=Nz8mRW+yAg39UYnICqPORakS5GHBHz3QLVpaLIh4kRDSnxxP6YbMJbkU4f25CFNYzC b5S9QJ7dcPR5SWmsrQm/ozXdhNYX3TBuC4++aDR1FKEQQkiF1jaLqUrBT/z7OL1/uIMA 4beZm3UDjxU/qaHo1ISAyWp2UsyEEDqBDwdgEYHjLtELAKJXZDAcsbNxr/95dR5TXmmP DRaCBa98efh5BDo9vlmqxWTd8w3WCrVuXhXtcrMMg550O3kgBhon30pOH4xA/H+v3cli Ol30I7lqZ9CcubUFoiUVKo7XrebVar0glV9h8RY+HvoNO0GDMbuTUA0G6uosfe0ZlhpA ZizA==
X-Gm-Message-State: AA+aEWZq2cW1kG/oQT67KDAMB2fJpUmxe7uZKfQDs2cALyU3Av1pwR0d KgDYUDs6YxoCnG0iQ5FGdH6taodDgZ+9v4nkK218Sw==
X-Google-Smtp-Source: AFSGD/Vj7wfUntVifMJZX0M+q+6G5FjAlfLJGq+DxGdSor1pdSvJ5yqfC2woS/UlgWnG6as7bLT1ctp2obuxDc5iyZg=
X-Received: by 2002:a24:301:: with SMTP id e1mr1253583ite.109.1542992248831; Fri, 23 Nov 2018 08:57:28 -0800 (PST)
MIME-Version: 1.0
References: <3881693.rR9BVk4Dlq@kitterma-e6430> <> <4277375.HHtkFxoYCE@kitterma-e6430> <>
In-Reply-To: <>
From: Tim Wicinski <>
Date: Fri, 23 Nov 2018 11:57:20 -0500
Message-ID: <>
To: Alessandro Vesely <>
Content-Type: multipart/alternative; boundary="000000000000e201fb057b57e006"
Archived-At: <>
Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Nov 2018 16:57:32 -0000

On Fri, Nov 23, 2018 at 7:17 AM Alessandro Vesely <> wrote:

> On Fri 23/Nov/2018 08:20:50 +0100 Scott Kitterman wrote:
> >
> > [...]  There's nothing in the draft about walking up a tree.  The draft
> looks
> > one label higher in the tree than the organizational domain, that's it.
> One
> > and only one is the maximum additional number of lookups in the current
> draft.
> That sounds acceptable to me.  I don't think one extra query is going to
> have a
> tremendous impact:
> DMARC mechanics entails keeping tracks of A-Rs, indexed by domain, since
> that
> is required for sending aggregate reports.  The availability of such a
> database
> makes it handy to store parsed policies as well.  That is to say, a well
> designed mail filter can cache DNS data directly.  Hence, given a decent
> TTL, that extra lookup can probably be skipped on most messages.  Compared
> to
> the amount of per-message DNS queries, it doesn't seem to hurt.
> DMARC could have a better say on implied TTLs, since data seen at lookup
> time
> is going to be reported at end-of-day time.
I remember chatting with John Levine about this maybe six month ago about
lookups and he said "the extra DNS lookups should not be an issue" which I
agreed with.
Since I do DNS Operations for a mid-sized SaaS vendor, and we play lots of
SOA/TTL games
(10s NXTTL, 300s TTLs for most records, etc)  I went and looked at our DNS
usage around our SPF records as an example (since we do layered SPF), and
queries barely scratch the top 25, but the DMARC/DKIM queries are way down
in the noise.
I can't see where a second query is an issue, as long as the applications
fine in doing them.