On Thu, 3 Apr 2019, John Levine wrote:
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.
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, jo...@taugh.com, 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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
