The public suffix list contains points in the DNS where (roughly speaking) names below that point are under different management from each other and from that name. It's here: http://publicsuffix.org/ The idea is that abc.foo.com and xyz.foo.com have the same management, but abc.co.uk and xyz.co.uk do not. You don't have to tell me that it's a gross crock, but it seems to be a useful one. What do people use it for? Here's what I know of: * Web browsers use it to manage cookies to keep a site from putting cookies that will affect other sites, e.g. abc.foo.co.uk can set a cookie for foo.co.uk but not for co.uk. * DMARC (www.dmarc.org) uses it to find a policy record in the DNS that describes a subtree, e.g., if you get mail that purports to be from eBay@reply1.ebay.com it checks the policy at ebay.com. What other current applications are there? R's, John PS: Really, you don't have to tell me what a crock it is.
On Mon, Apr 15, 2013 at 3:10 PM, John Levine <johnl@iecc.com> wrote:
You don't have to tell me that it's a gross crock, but it seems to be a useful one. What do people use it for? Here's what I know of:
At dnswl.org, we use a heuristic (and manual checks) to derive different "levels" of management (ie, foo.example.org may or may not be under the same operational responsibility as bar.example.org). Using publicsuffix.orgdata would allow us to automate some of that work (I just have not yet got around to implement it). -- Matthias
----- Original Message -----
From: "John Levine" <johnl@iecc.com>
The public suffix list contains points in the DNS where (roughly speaking) names below that point are under different management from each other and from that name. It's here: http://publicsuffix.org/
The idea is that abc.foo.com and xyz.foo.com have the same management, but abc.co.uk and xyz.co.uk do not.
You don't have to tell me that it's a gross crock, but it seems to be a useful one. What do people use it for? Here's what I know of:
* Web browsers use it to manage cookies to keep a site from putting cookies that will affect other sites, e.g. abc.foo.co.uk can set a cookie for foo.co.uk but not for co.uk.
* DMARC (www.dmarc.org) uses it to find a policy record in the DNS that describes a subtree, e.g., if you get mail that purports to be from eBay@reply1.ebay.com it checks the policy at ebay.com.
What other current applications are there?
Seems to me that it's a crock because *it should be in the DNS*. I should be able to retrieve the AS (administrative split) record for .co.uk, and there should be one that says, "yup, there's an administrative split below me; nothing under there is mine unless you also get an exception record for a subdomain". The people who know authoritatively that their subdomains are within someone else's administrative span of control *are the people who own those domains*. No? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On 2013-04-15, at 12:00, Jay Ashworth <jra@baylink.com> wrote:
Seems to me that it's a crock because *it should be in the DNS*.
I should be able to retrieve the AS (administrative split) record for .co.uk, and there should be one that says, "yup, there's an administrative split below me; nothing under there is mine unless you also get an exception record for a subdomain".
I've always quite liked that idea (if we accept for the point of discussion that there are use-cases like cookie naming that make identifying this kind of boundary useful). There's a concern though that there are multiple ways to spoof such a DNS response, and do so in a distributed fashion that might not be easy to detect by an individual client application. If the AS (or whatever) record was signed, that would make things better. But only if you could rely upon clients to validate those responses (or have a sufficiently clean DNS path out that validation was even possible). There's also the question of what to do with a TLD (or other part of the namespace) that doesn't include this record. Some of the zones we're talking about are generated by registry machinery with long software development lifecycles. If your starting point is (a) the records might not be there, (b) we might not be able to find them even if they are there, and (c) if we get them we can't always be sure they are genuine, then the natural conclusion is that you can't rely on the mechanism to work and you look for another answer. If you need the mechanism to work (say you're say a browser vendor who is going to get heat if cookie-leakage causes widespread privacy violations) then I can see why fetching and caching a browser list over SSL (and perhaps shipping with a baseline version of it) seems attractive. And that I guess takes us back to where we are. Joe
On Apr 15, 2013, at 9:30 AM, Joe Abley <jabley@hopcount.ca> wrote:
[...] If you need the mechanism to work (...) then I can see why fetching and caching a browser list over SSL (and perhaps shipping with a baseline version of it) seems attractive.
Sounds like this could've been good logic for the use of HOSTS.TXT :) Regards, -drc
Jay Ashworth <jra@baylink.com> writes:
----- Original Message -----
From: "John Levine" <johnl@iecc.com>
The public suffix list contains points in the DNS where (roughly speaking) names below that point are under different management from each other and from that name. It's here: http://publicsuffix.org/
The idea is that abc.foo.com and xyz.foo.com have the same management, but abc.co.uk and xyz.co.uk do not.
You don't have to tell me that it's a gross crock, but it seems to be a useful one. What do people use it for? Here's what I know of:
* Web browsers use it to manage cookies to keep a site from putting cookies that will affect other sites, e.g. abc.foo.co.uk can set a cookie for foo.co.uk but not for co.uk.
* DMARC (www.dmarc.org) uses it to find a policy record in the DNS that describes a subtree, e.g., if you get mail that purports to be from eBay@reply1.ebay.com it checks the policy at ebay.com.
What other current applications are there?
Seems to me that it's a crock because *it should be in the DNS*.
It is already, isn't it? The NS and SOA records will tell you all there is to know about zone splits and cross zone relations.
I should be able to retrieve the AS (administrative split) record for .co.uk, and there should be one that says, "yup, there's an administrative split below me; nothing under there is mine unless you also get an exception record for a subdomain".
Use the SOA record. If it is identical for two zones, then the adminstrative authority for those zones is the same. For example, "microsoft.co.uk" and "microsoft.com" can be considered under the same administration: bjorn@nemi:~$ dig +short soa microsoft.co.uk ns1.msft.net. msnhst.microsoft.com. 2013032601 1800 900 2419200 3600 bjorn@nemi:~$ dig +short soa microsoft.com ns1.msft.net. msnhst.microsoft.com. 2013041803 300 600 2419200 3600 While "apple.co.uk" and "apple.com" may be, depending on how strict you are going to be when comparing: bjorn@nemi:~$ dig +short soa apple.co.uk nserver.euro.apple.com. hostmaster.apple.com. 10 1800 900 2592000 1800 bjorn@nemi:~$ dig +short soa apple.com gridmaster-ib.apple.com. hostmaster.apple.com. 2010086586 1800 900 2016000 86500 etc. Bjørn
On 2013-04-19, at 14:17, Bjørn Mork <bjorn@mork.no> wrote:
It is already, isn't it? The NS and SOA records will tell you all there is to know about zone splits and cross zone relations.
Not really. In general, just because a zone is served by the same nameservers as another zone doesn't mean that they are administratively equivalent (e.g. for cookie hygiene purposes). Just because two zones are served on different nameservers doesn't mean they are administratively separate. Lots of administratively-separate domains share the same nameservers. Drawing related conclusions from similarity of SOA RDATA between zones, or the number of zone cuts between a particular zone and the root, or the number of labels in a domain name is similarly flawed. If the rule was just "the nameservers need to be the same and the SOA RDATA needs to be the same, for some well-documented meaning of 'same'" then gaming that rule (e.g. for purposes of cookie injection) as a miscreant is unpleasantly straightforward. Joe
Joe Abley <jabley@hopcount.ca> wrote:
If the rule was just "the nameservers need to be the same and the SOA RDATA needs to be the same, for some well-documented meaning of 'same'" then gaming that rule (e.g. for purposes of cookie injection) as a miscreant is unpleasantly straightforward.
To reinforce Joe's point, there doesn't even need to be a zone cut for there to be an administrative cut. There are various ISPs and dynamic DNS providers that put all their users in the same zone, and the common suffix of a zone like this should be treated as public suffix even though there is no zone cut. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.
On 4/19/2013 12:57 PM, Tony Finch wrote:
To reinforce Joe's point, there doesn't even need to be a zone cut for there to be an administrative cut. There are various ISPs and dynamic DNS providers that put all their users in the same zone, and the common suffix of a zone like this should be treated as public suffix even though there is no zone cut.
Zones are nice constructs for partitioning operational management of DNS data, but I believe they were not intended to impart semantics about organizational boundaries. The fact that they often correlate moderately well makes it easy to miss the facts that a) that's not their job, and b) the correlation isn't perfect. And the imperfections matter. That is why there is the current interest in developing a cheap, accurate method that /is/ intended to define organizational boundaries. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
On 4/19/13, Dave Crocker <dhc2@dcrocker.net> wrote:
On 4/19/2013 12:57 PM, Tony Finch wrote:
To reinforce Joe's point, there doesn't even need to be a zone cut for there to be an administrative cut. There are various ISPs and dynamic DNS providers that put all their users in the same zone, and the common [snip]
In this case, there really is no administrative cut though... the provider administers the DNS record.
The fact that they often correlate moderately well makes it easy to miss the facts that a) that's not their job, and b) the correlation isn't perfect. And the imperfections matter.
That is why there is the current interest in developing a cheap, accurate method that /is/ intended to define organizational boundaries.
It seems this is more about providing a security function to DNS, to inform the public, about where the responsible parties change. The right place for this, is clearly the DNSSEC extensions.... If the DS record identifies a different signer, then you have an administrative split, or if the e-mail address field in the SOA fields of the parent zone are different, then you have an administrative split, OR if one of the two zones has RP (responsible party records), and the list of RP records are different for the two zones, then you have an administrative split. If the DS record identifies the same signer, AND the e-mail address in the SOA records is the same; or the list of e-mail addresses in the two zones' RP records are identical, then you don't have an administrative split. -- -JH
If the DS record identifies a different signer, then you have an administrative split, or if the e-mail address field in the SOA fields of the parent zone are different, then you have an administrative split, OR if one of the two zones has RP (responsible party records), and the list of RP records are different for the two zones, then you have an administrative split.
Sigh. See messages from about an hour ago about why zone cuts aren't the same as management boundaries. Sprinking DNSSEC pixie dust on the zone cuts doesn't change that.
On 4/19/2013 4:33 PM, Jimmy Hess wrote:
It seems this is more about providing a security function to DNS, to inform the public, about where the responsible parties change.
Absent a view that somehow says all metadata is a security function, I don't see how the marking of administrative boundaries qualifies as a security function. It's easy to imagine security functions that are 'in support of' the enforcement of the boundaries, but that's quite different from having an annotation mechanism to assert the boundaries. Let's be careful not to overload functions here. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
On 4/19/13, Dave Crocker <dhc2@dcrocker.net> wrote:
On 4/19/2013 4:33 PM, Jimmy Hess wrote: [snip] Absent a view that somehow says all metadata is a security function, I don't see how the marking of administrative boundaries qualifies as a security function.
The security function comes in immediately, when you consider any actual uses for said kind of metadata. The issues are alleviated only by assuming that an administrative division always exists, unless you can show otherwise, and showing that the records are in the same zone is one way of showing otherwise. When you come to rely on it, there are new security issues. It becomes such that; It is perfectly safe to assume that there is an administrative division when there is not (in the worst case, you break some desired function, such as the sharing of cookies across subdomains within the same administrative boundary). But if you assume no administrative division exists, when there is supposed to be one -- you have some kind of access control permit leakage or data leaking through permissions that are supposed to block operations across the administrative boundaries. Only a zone signed with DNSSEC can really be trusted not to be tampered with; therefore, any declaration of an administrative division cannot be proven, and should not be relied upon, if any parent zone up the tree is not signed with delegation validated using signed records.
Let's be careful not to overload functions here.
The function becomes pretty useless, if you cannot safely rely on it in the real world. Because tampering can occur through lack of integrity validation, Or by a child domain claiming to not be administratively divided (when actually, there is supposed to be an administrative division). In those cases, a static list is safer.
d/ -- -JH
1. Explicitly marking an administrative boundary is not inherently a 'security' function, although properly authorizing and protecting the marking no doubt would be. 2. Defining a marking mechanism that is built into a security mechanism that is designed for other purposes is overloading functionality, as well as setting up a problematic critical dependency. That's not just asking for trouble, it's guaranteeing it. 3. Since you made reference to assumptions a couple of times: the goal here is an explicit marking mechanisms. No assumptions involved. d/ On 4/19/2013 7:58 PM, Jimmy Hess wrote:
On 4/19/13, Dave Crocker <dhc2@dcrocker.net> wrote:
On 4/19/2013 4:33 PM, Jimmy Hess wrote: [snip] Absent a view that somehow says all metadata is a security function, I don't see how the marking of administrative boundaries qualifies as a security function.
The security function comes in immediately, when you consider any actual uses for said kind of metadata.
The issues are alleviated only by assuming that an administrative division always exists, unless you can show otherwise, and showing that the records are in the same zone is one way of showing otherwise.
When you come to rely on it, there are new security issues.
It becomes such that; It is perfectly safe to assume that there is an administrative division when there is not
-- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net
On 4/19/13, Dave Crocker <dhc2@dcrocker.net> wrote: That is only theoretically possible, if every boundary keeper participates. In reality, you would wind up with some zones having explicit marking, and most zones not having any marking at all, just because the admin didn't bother to pick up on the new idea and implement it.
3. Since you made reference to assumptions a couple of times: the goal here is an explicit marking mechanisms. No assumptions involved.
d/
-- -JH
"John Levine" <johnl@iecc.com> writes:
The public suffix list contains points in the DNS where (roughly speaking) names below that point are under different management from each other and from that name. It's here: http://publicsuffix.org/
The idea is that abc.foo.com and xyz.foo.com have the same management, but abc.co.uk and xyz.co.uk do not.
You don't have to tell me that it's a gross crock, but it seems to be a useful one. What do people use it for? ...
CAs use it as part of a procedure to determine whether it's safe to issue a wildcard domain (as in, if it's on the list, it's not safe). See <https://www.cabforum.org/Baseline_Requirements_V1_1_3.pdf>, section 11.1.3. They'd really like to have a process which is less ad-hoc. For example, it'd be great if these points were annotated in the DNS itself, perhaps with a record which points to the corresponding whois server.
They'd really like to have a process which is less ad-hoc. For example, it'd be great if these points were annotated in the DNS itself, perhaps with a record which points to the corresponding whois server.
I've been thinking about a way to do that, but I want to understand the use cases first. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
On Mon, Apr 15, 2013 at 11:34 PM, Geoffrey Keating <geoffk@geoffk.org>wrote:
They'd really like to have a process which is less ad-hoc. For example, it'd be great if these points were annotated in the DNS itself, perhaps with a record which points to the corresponding whois server
Btw., this would similarly apply to reverse DNS. Having a well-defined way to identify administrative control (maybe some better wording would be required) could be helpful in defining boundaries for reputation systems (eg "all IPs in this IPv6-/32 belong to the same ISP, but the adjacent /32 is someone else."). -- Matthias
On Apr 15, 2013, at 5:34 PM, Geoffrey Keating wrote:
CAs use it as part of a procedure to determine whether it's safe to issue a wildcard domain (as in, if it's on the list, it's not safe). See <https://www.cabforum.org/Baseline_Requirements_V1_1_3.pdf>, section 11.1.3.
They'd really like to have a process which is less ad-hoc. For example, it'd be great if these points were annotated in the DNS itself, perhaps with a record which points to the corresponding whois server.
Concur - I think codifying DNS's dynamic structure in an outside medium is only going to cause problems down the road (e.g., especially with namespace diffusion from the likes of new gTLDs, etc..). While an unfortunate naming collision here (i.e., the "SOPA" RR), I think an approach such as [1] has some merit - but much work needs to be done. -danny [1] http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02
participants (12)
-
Bjørn Mork -
Danny McPherson -
Dave Crocker -
David Conrad -
Geoffrey Keating -
Jay Ashworth -
Jimmy Hess -
Joe Abley -
John Levine -
John R. Levine
-
Matthias Leisi -
Tony Finch