Subject: [DNSOP] Over on the dbound list: draft-dcrocker-dns-perimeter-00

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Apr 2019 12:06:57 -0700

Howdy. I've posted a draft that might be of interest to folk in this 
group.

It's best venue is almost certainly the dbound mailing list, where it is 
already starting to get discussion (and cross-posted to the dmarc list.)

Discussing it here, on a third list, doesn't seem advisable, but it's 
already been noted on the dbound discussion that the draft raises issues 
that might be of concern to the dnsop community.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 3 Apr 2019 21:20:09 -0400

>that might be of concern to the dnsop community.

The part of interest to DNSOP would be section 7 on pages 12 and 13
where it discusses tree walks and potential new additional section
processing to find the closest perimeter record above a name being
checked.

Other than that it's just another TXT record with a _prefix name.

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 14 Apr 2019 11:13:48 -0400

> processing to find the closest perimeter record above a name being

This draft proposes to publish TXT records to mark logical (not zone) 
boundaries, sort of like what the Mozilla PSL does.

Let's say there's a boundary between d.example and example.  Then the 
domain owner would publish _perim.example to show that's where a boundary 
(perimiter in the draft's language) is.  But what if the names go deeper 
and a client is wondering where the boundary is in a.b.c.d.example?  The 
proposal is that the client asks for _perim.a.b.c.d.example, and the DNS 
server returns NXDOMAIN but also puts the _perim.example in the additional 
section, so the client knows that's where the boundary is and doesn't have 
to do a tree walk.

It seems to me that this can't work.  Additional section entries are only 
hints, and just because it returns _perim.example, that doesn't mean that 
_perim.c.d.example doesn't exist.  In a DNS cache, there's no promise that 
additional section records will be remembered for the same time as the 
main answer, or for that matter remembered at all.  The client still has 
to probe all of the intermediate names to check that they don't exist.

Another issue is that qname minimzation breaks this, since the 
authoritative server often won't see the full query.  Or if the boundary 
is above a zone cut, the authoritative server won't have the additional 
record to return.

Although it is legal to put an additional section in an NXDOMAIN response, 
it's uncommon and I don't know how the bailiwick checks would work.

It seems unlikely that any DNS servers or caches would implement a feature 
that triggers TXT record additional section records based on the qname.

Am I missing anything here?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

PS: for a different design that (ab)uses wildcards to do the same thing 
and avoids tree walks see draft-levine-dbound-dns-02.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 14 Apr 2019 11:29:55 -0400

On Apr 14, 2019, at 11:13 AM, John R Levine <[email-masked]> wrote:
> Although it is legal to put an additional section in an NXDOMAIN response, it's uncommon and I don't know how the bailiwick checks would work.

We already do something like this when looking for the zone apex, and it potentially has the same problem.   If I look for the zone apex of a nonexistent name under a zone that does exist, I’ll get back an SOA record in the authority section.   How do I know that that’s the real zone apex?   If I look up a.b.c.d.example.com and get back an SOA for example.com, how do I know that there is no SOA for c.d.example.com?

The answer is that I don’t, without validating the answer.   And that requires traversing the trust anchors to the root, so as you say, this doesn’t save any work.

Clearly, this validation should be done—we shouldn’t just assume that what’s in the additional section is correct.   I think that this means that in the case of a query with DNSSEC enabled, the additional section should contain as much of the chain of trust as will fit, in the order the client resolver can be expected to need it.