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

[Tim Wicinski <[e-mail]>]

On Fri, Nov 23, 2018 at 7:17 AM Alessandro Vesely <[e-mail]> 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
> SOA
> 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
ARC and DNS
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
query
usage around our SPF records as an example (since we do layered SPF), and
those
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
are
fine in doing them.

Tim