New DNS Perimeter IETF Draft
55 views
Skip to first unread message
Jothan Frakes
Apr 2, 2019, 9:45:09 PM4/2/19
to psl-discuss
I am still reading this but wanted to get some early feedback
https://www.ietf.org/id/draft-dcrocker-dns-perimeter-00.txt
Dave Crocker
Apr 2, 2019, 10:21:30 PM4/2/19
to Jothan Frakes, psl-discuss
On 4/2/2019 6:44 PM, Jothan Frakes wrote:
> I am still reading this but wanted to get some early feedback
>
> https://www.ietf.org/id/draft-dcrocker-dns-perimeter-00.txt
Oh, yes, please! And thanks for posting this.
> I am still reading this but wanted to get some early feedback
>
> https://www.ietf.org/id/draft-dcrocker-dns-perimeter-00.txt
Sorry for not posting the draft to this list, myself. I'm always a bit
skittish about multi-list posting and already did two in the IETF.
But yes, any and all feedback and suggestions are eagerly sought.
As the draft notes, I tried to represent PSL existing practice but since
I'm not hands-on with the PSL, I am sure there are issues that I missed
-- even with diligent assistance I got from a PSL expert(*)
d/
(*) unnamed only to protect them from blowback if I screwed up...
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Ryan Sleevi
Apr 3, 2019, 6:21:07 PM4/3/19
to Dave Crocker, Jothan Frakes, psl-discuss
On Tue, Apr 2, 2019 at 10:21 PM Dave Crocker <dcro...@gmail.com> wrote:
On 4/2/2019 6:44 PM, Jothan Frakes wrote:
> I am still reading this but wanted to get some early feedback
>
> https://www.ietf.org/id/draft-dcrocker-dns-perimeter-00.txt
Oh, yes, please! And thanks for posting this.
Sorry for not posting the draft to this list, myself. I'm always a bit
skittish about multi-list posting and already did two in the IETF.
But yes, any and all feedback and suggestions are eagerly sought.
As the draft notes, I tried to represent PSL existing practice but since
I'm not hands-on with the PSL, I am sure there are issues that I missed
-- even with diligent assistance I got from a PSL expert(*)
Thanks for sharing, Dave and Jothan.
I'm not sure this would address many of the use cases of the PSL I'm familiar with, mostly because those use cases rely on having a static and efficient list for querying. That is, DNS-based solutions tend to fall apart for last-mile users due to a host of things that "should" work, but rarely do, and even when they do work, rarely performantly. While it's true that the Appendix suggests an exhaustive tree walk might be able to support generating such a database, that relies on knowing the names apriori to walk through and examine the boundaries.
The consequence is that I'm not sure this would save much for many consumers, although it may be useful for some of them that are able to take the latency hit, in return for freshness.
While in an ideal world, I could see this being useful to more automatically manage the 'freshness' of the PSL, by ensuring these records are present, we haven't even gotten that far for the _psl record's continued existence, nor do we have a path to grandfather in the preexisting domains and ccTLDs. So I'm not too sure we'll find a path there either.
I'd be curious to know more about what are the use cases where the latency/freshness tradeoff would work favorably. The use cases I primarily deal with are ones where it wouldn't be a good tradeoff (e.g. browser cookies, storage policies, document.domain, UI highlighting, and even antispam)
Dave Crocker
Apr 3, 2019, 8:26:17 PM4/3/19
to Jothan Frakes, Ryan Sleevi, Jothan Frakes, psl-discuss
On 4/3/2019 4:53 PM, Jothan Frakes wrote:
> to me, I see Dave clearly put a lot of careful thought into this ... so
> I am looking at ways to be addative about it.
>
> as volunteers, we have to focus on time investments on PSL, but one
> challenge I see in Dave's message is that he could do more if we had a
> better list of user stories and use cases.
Definitely. Yes. That would help.
The goal here is to provide something that has real operational benefit
over the existing arrangement.
And when there is an installed operational base, proposals for change
usually have a higher threshold to reach than when starting with no
history. The benefits have to be appealing enough to overcome
entrenched behavior. I think that usually involves clarity about the
straightforward benefits and clarity about the perceived (or feared)
detriments.
> I see a bit of promise in the potential of a TLD adding these entries
> and perhaps we add to our automation process where we sweep through and
> query within the IANA root for these for the ICANN section or something
> like that. It is a "two-fer" potentially as a benefit because it would
> let a TLD admin directly impact their destiny and it would be a super
> trusted source (assuming our sweep process that did the zone scan didnt
> get cache poisoned or mim'd) from the authoritative zone.
Exactly. I think the 'public' suffixes fall into this model pretty
easily. The worst-case overhead of having to traverse all upper-level
domain names would not be all that terrible.
I'm less clear about the overhead for finding the 'private' domains of
the type now listed in the PSL. My impression is that they are
contiguous with the public set. If so then the search merely needs to
keep going, looking for "suffix private" entries, and stopping on a
branch when finding no such listing.
> We would have to figure out conflict resolution and what takes priority
> where DNS does not match PSL submissions. Again, we volunteers are
> already putting a lot into this, and not seeking an opportunity to do
> more work - and we might have other backlog items or frisbee requests to
> address ahead of such things.
frisbee requests? can't you get some dogs to catch those?
d/
> to me, I see Dave clearly put a lot of careful thought into this ... so
> I am looking at ways to be addative about it.
>
> as volunteers, we have to focus on time investments on PSL, but one
> challenge I see in Dave's message is that he could do more if we had a
> better list of user stories and use cases.
Definitely. Yes. That would help.
The goal here is to provide something that has real operational benefit
over the existing arrangement.
And when there is an installed operational base, proposals for change
usually have a higher threshold to reach than when starting with no
history. The benefits have to be appealing enough to overcome
entrenched behavior. I think that usually involves clarity about the
straightforward benefits and clarity about the perceived (or feared)
detriments.
> I see a bit of promise in the potential of a TLD adding these entries
> and perhaps we add to our automation process where we sweep through and
> query within the IANA root for these for the ICANN section or something
> like that. It is a "two-fer" potentially as a benefit because it would
> let a TLD admin directly impact their destiny and it would be a super
> trusted source (assuming our sweep process that did the zone scan didnt
> get cache poisoned or mim'd) from the authoritative zone.
Exactly. I think the 'public' suffixes fall into this model pretty
easily. The worst-case overhead of having to traverse all upper-level
domain names would not be all that terrible.
I'm less clear about the overhead for finding the 'private' domains of
the type now listed in the PSL. My impression is that they are
contiguous with the public set. If so then the search merely needs to
keep going, looking for "suffix private" entries, and stopping on a
branch when finding no such listing.
> We would have to figure out conflict resolution and what takes priority
> where DNS does not match PSL submissions. Again, we volunteers are
> already putting a lot into this, and not seeking an opportunity to do
> more work - and we might have other backlog items or frisbee requests to
> address ahead of such things.
frisbee requests? can't you get some dogs to catch those?
d/
Reply all
Reply to author
Forward
0 new messages