[ietf-dkim] domain existence check

[Steve Atkins]

On May 22, 2008, at 9:03 AM, John Levine wrote:

> We don't seem to have resolved the question of whether the ADSP should
> define a specific existence check, or just say that you should check
> but leave the definition for other places.
>
> Personally, I think it's severe mission creep to try to define an
> existence check.  It's straightforward to check for a NXDOMAIN or
> NODATA result, but I see no reason to think that such a check has the
> semantics an ADSP user would want.

The reason for the existence check is simply to make it possible
for an ADSP user to specify consistent policy across all their
space in the DNS tree. A simple check for NXDOMAIN is
sufficient to fill that need. Any semantics beyond that are moving
beyond the reason that the check is needed.

>
>
> To touch on some of the issues (and try not to rehash them all), the
> majority of A and AAAA records don't name domains used in mail and you
> can't check short of sending a test message and waiting a week to see
> if it bounces, there's many ways a name can exist but again not for
> mail (what if there's just a TXT record), and any check we defined
> would just be wrong if, e.g., next year we make MX . the no-mail
> standard.
>
> So I like Arvel and Wietse's approach, say to do it but don't try to
> define it since any definition would be wrong.  Other thoughts?

If you don't define it then the sender has to assume the most
pessimistic implementation, in order for their wishes to be communicated
reliably to all checkers who implement their own form of check
for existence.

That most pessimistic implementation is to assume that the sender
checks only for NXDOMAIN, so the sender will need to explicitly
publish ADSP records for anything that's syntactically valid for
use in email and does not return an NXDOMAIN.

So, that's exactly the same operationally as specifying checking
just for NXDOMAIN, but less clearly communicated, as it replaces
a simple hard rule with unclear language that implies
exactly the same behavior for senders but is more likely to be
misunderstood and misimplemented.

Cheers,
   Steve