Re: [dbound] BoF request for IETF 115

[Tim Wicinski <[e-mail]>]

On Thu, Dec 22, 2022 at 12:38 AM Vixie, Paul <upavixie=
[e-mail]> wrote:

> See inline.
>
> --
> Paul Vixie
> VP & Distinguished Engineer
>
> -----Original Message-----
> From: John R Levine <[e-mail]>
> Date: Wednesday, December 21, 2022 at 19:12
>
>     ... Take another look at my draft.  If we expect each TLD to publish
> its own
>     dbound records, it's not practical to extract them mechanically from
> the
>     zone.
>
> I will take another look. I think that the aggregator (someone like the
> PSL team is today) who wants complete coverage ("to be relevant and
> successful") will have to invite people to enter things into some kind of
> corpus (via web site, API, whatever). Today ("the PSL") they supply a
> record. In a post-DBound world I expect they will supply a domain name.
> These domain names will drive a mechanical extraction process whereby the
> actual data is found (or not) in the DNS itself. Only aggregators (like the
> PSL team is now) and their audiences will care about this.
>

Yes, I totally agree.  And if the data ends up in an IANA registry, the
process would still be the same in my mind.

>
>     ... I suppose I coould tweak it and put in some links to make the lower
>     level records easier to find, but that's one of those things that
> doesn't
>     exist yet that I referred to.
>
>     I think Casey's design has the same problem.
>
> I think that would be a mistake. Putting the data into the DNS itself
> makes it possible to look it up in real time (similar to how ASN
> information is looked up in real time by https://github.com/dnsdb/dnsdbq).
> Aggregation would be a valuable second use case but the aggregator will
> have its own way to know (see above) what periodic real-time lookups to
> make.
>
> I think there is no way to reach consensus on a high quality way to
> directly support aggregation. So we just have to improve that aggregation
> over how things work today in order to drastically reduce the work load for
> teams like PSL and drastically improve the capabilities for
> non-aggregation-based work flows.
>
>
And to Paul V's point on ketchupping,  I am making the assumption that if
you own "fancy.cloud", you are looking to say "NS records for
super.fancy.cloud are not ours."   (creating real examples of DNS records
clarifies things for me).

Also, I was reviewing the original problem statement


https://datatracker.ietf.org/doc/html/draft-sullivan-dbound-problem-statement-02

and this paragraph was what I was

   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.  We may suppose that, if this information were to be available,
   it would be possible to make useful decisions based on the
   information.


This was the situation I was thinking of.


tim





> _______________________________________________
> dbound mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dbound
>