Re: [dbound] DBOUND - updated use cases?

[Andrew Sullivan <[e-mail]>]

Hi,

Usual disclaimer: I work for the Internet Society, but I am not speaking for them.

On Wed, Sep 28, 2022 at 12:36:12PM -0700, Ian Williams wrote:

>1) We have a large number of boundaries we'd need to publish. Taking an
>example resource within an example service, that resource might have a
>domain name that follows the below pattern (2LD may vary)
[…]
>This puts an immense strain on
>the PSL - both on the size of the list itself, and the humans that help
>maintain the list for the internet community

This was one of the central problems I was trying to solve in several different proposals I made related to this topic prior even to DBOUND being formed.  My view at the end of DBOUND was that the things that had interested me in the first place had been completely swamped by a mail antiabuse issue that arose from the peculiar ways that mail antiabuse had itself mischaracterized the functioning if the domain name system.  (To be clear, that isn't to cast aspersions.  There might have been no other answer.  Regardless, the ones deployed are the ones we have.)  

>2) We have suffixes that are public, but not routable or resolvable
>outside of our network (public-like-PSL, not public-like-pool).
[…]

>For customers that have chosen to peer their VPC with another customer,
>this VPC-internal zone would now have multiple different customers
>operating within it. We'd like to prevent any inferred-level of trust
>(when it comes to things like cookies/CORS policies) between DNS names
>in this zone.

This was _also_ a problem I was aiming to address with the various proposals.  There were really two different issues for me.  One was this sort of "trust from domain boundary" problem that tended to arise for my then-employer (Dyn) in the various public zones it operated.  But the other was the imposition of various "trust policies" by parent zones due to policies that might come from registry operators.  I first started thinking about this in the context of the root expansion, and it was obvious that some registries were going to have expensive white elephants with a trapped community of registrant customers.  I was afraid of the potential for people who didn't understand the DNS announcing policy "in their domain" that didn't actually work as described, and I wanted it to be possible for someone to do a lookup to understand whether the child side was in fact also implementing some policy the parent asserted.

Note that this desire is in direct conflict with most of the antispam needs, where the parent needs to be able to _assert_ that child domains comply or else are not registered.

>3) We operate a DNS management service used by our customers (Amazon
>Route 53). In the auspices of the PSL, this would be considered as
>just-another-DNS-service - there are plenty of other DNS management
>services in existence, and we're likely all in the same pool here.

Yeah, these get listed (it seems on an _ad hoc_ basis) in the existing PSLs, but there's not even a way to do the discovery.  Again, a use case I had while working for Dyn.

>4) Registry operators and/or DNS application developers may have a
>desire to handle eTLDs/suffixes differently at runtime. This may be to
>prevent human error in their service, and/or mitigate abuse or misuse
>of their service. AWS is one such entity; we have applications which
>currently check the PSL at runtime to prevent inappropriate ownership
>claims about high value public suffixes or eTLDs.

I always thought that this use was a case of the tool you have, rather than the tool you need.  What I thought necessary in the proposals I made was to be able to model the boundary of administrative policy, which is why I called the record I proposed SOPA (Start Of Policy Authority, riffing off Start Of Authority).  The reason I wanted it to be possible on both sides of the "policy cut" was because I was trying to address what I regard as a lacuna in the way zone cuts worked in the DNS traditionally: it would be nice to be able to find it no matter which way you encounter it.

I hope these observations are useful.

A

-- 
Andrew Sullivan
[e-mail]