Re: [dmarc-ietf] DNS library queries for DKIM and DMARC records?

[Dave Crocker <[e-mail]>]

On 4/13/2019 8:51 PM, John R Levine wrote:
>>>  As I understand it, your design depends on putting NXDOMAIN signals
>>>  in the additional section to show that there aren't any boundaries
>>>  between the names it returns.  How do you plan to do that?
>>
>> John, I don't understand your note.
> 
> In draft-dcrocker-dns-perimeter-00, it says this:
> 
>     Another approach is use of the DNS Additional section in the server
>     response.  When there is a query for a Perimeter node, the server
>     would include the associated Perimeter BEGIN record from earlier in
>     the hierarchy, if the queried node is within that hierarchy -- that
>     is, is above the actual or virtual END record.
> 
> If you asked for _perim.a.b.c.example.com, and the perimeter is actually 
> at "c", there, you hope that modified DNS servers will return NXDOMAIN 
> and in the additional section add _perim.c.example.com.  

Good. That language seems about right.


> But since the 
> additional section info is just advisory, that doesn't tell you anything 
> about _perim.b.c.example.com, which might exist or might not.  To avoid 
> doing a tree walk, you'd need a signal that _perim.b.c.example.com does 
> not exist, and there's no way to do that in an additional section.

The rest of your paragraph, again, is confusing and probably misleading.

First, by definition, the fact that NXDomain is returned means that 
_perim.b.c.example.com does not exist.  There is no need or suggestion 
that the Additional section also indicate that that name doesn't exist.

Rather, a query to such a non-existent domain will provide information 
that it doesn't exist by using the usual NXdomain response, except that 
response will /also/ have an Additional section, containing information 
about the node up the branch that contains the Perimeter 'begin'.

My draft doesn't yet offer a detailed specification for this.  It's 
phrased to explore an approach.  So the details of exactly what would go 
into the Additional section for an NXDomain response are tbd.  Let's 
wait to criticize or improve those details until after they've been written.

As for the concern about 'advisory', that merely means that the client 
would need to confirm the information from the Additional section. 
That's one more direct query to the referenced _perim.c.example.com.

Doing exactly one more query is already demonstrated to be acceptable, 
at least for some applications.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net