Re: [dbound] BoF request for IETF 115

["Vixie, Paul" <[e-mail]>]

See inline. (Sorry, it's Outlook.)

-- 

Paul Vixie
VP & Distinguished Engineer

-----Original Message-----
From: John R Levine <[e-mail]>
Date: Thursday, December 22, 2022 at 14:51

    Vixie: ... ability to (as an example) let google.com set a cookie which would be sent to gmail.com. I agree that it's a hard problem. If someone wants to work on that problem in the IETF, I have yet to see evidence of that interest. The coalition of the willing that I hope we can isolate for this WG is narrowly just the thing Tim quoted out of the earlier charter:

        Tim: What appears to be needed is a mechanism to determine policy realm
        boundaries in the DNS.  That is, given two domain names, one needs to
        be able to answer whether the first and the second are either within
        the same policy realm or have policy realms that are related in some
        way.

    John: The hard bit is to do it in a way that people are willing to use.  If
    domain owners are willing to put a few records in the DNS and domain users
    are willing to do a DNS lookup or two each time they're checking a
    boundary, then my thing or Casey's should work.

If by "it" you mean my example (google.com can set-cookie for gmail.com) then it's out of scope for the BOF and we can stop workshopping it here. Nobody so far has said they want to work on it. If someone like that shows up we can try to find them some co-authors.

If by "it" you mean putting PSL-like stuff into the DNS per your (John's) 2016 draft, then I do not expect some people (like browser makers) to be "willing to use it" unless it gets aggregated. A team who wants to do what the PSL team does now can aggregate from the DNS schema that your 2016 draft (or Casey's for that matter) defines. If we want IANA (via ICANN) to operate a PSL-like aggregator we can write a second draft explaining how that should work based on querying the data that's published according to the schema of the first draft.

Publication is one problem. Access is an opportunity. See for example dnsdbq (URL as previously given) where we'd like to be able to do these lookups in real time as part of doing passive DNS investigations.

Another access opportunity is aggregation. Aggregation would become a second problem.

If we conjoin all these problems we will get 2016-style mud.

    ... If you want to be able to
    prefetch everything, they won't.

So, I could disagree. Any decent passive DNS database can "prefetch everything" even if there is no linkage in the DNS tying related records together. This is routinely done for SPF and DMARC now. However, none of that matters, so I won't disagree on that basis. Instead I will say that not everyone wants to prefetch everything, and the requirement to do so is one of the problems with the PSL today. Some of us want to fetch on demand. We can't. We are hoping to be able to fetch on demand after there is an IETF-defined DNS schema as to how to do so. Once that is done, the people who "want to be able to prefetch everything" will be able to prefetch that in a directed way ("whosoever asks a PSL-like team to prefetch their data").

In no case need the data be independently prefetchable without a priori knowledge such as a list of domains to prefetch DBOUND data from. I hope we can erase that use case from our thinking because _that_ cannot be done in a way that people will use, so it would be dooming.

    ... Our approach has the advantage that
    people publish in their own zones so there's no question whether they are
    authorized.  If it's published somewhere else that might make the
    prefetching easier (put them all in one zone you can xfer) but now we need
    some way to check what's authorized.  Like I said, it's hard.

I like those words "no question whether they are authorized" and I think you could have ended your statement at that point. Nobody has said that they want to work on the other problem but if they do we can try to build a team for them. It's a separable problem so we must separate it.