Subject: [DNSOP] Fwd: I-D Action:draft-pettersen-subtld-structure-04.txt

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Mon, 03 Nov 2008 23:47:51 +0100

Hi,

FYI, this draft removes the central repository requirement, and moves the  
method for collecting the information out of scope.

Suggestions for how to collect the information are welcomed.

------- Forwarded message -------
From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-pettersen-subtld-structure-04.txt
Date: Mon, 03 Nov 2008 23:15:01 +0100

A New Internet-Draft is available from the on-line Internet-Drafts  
directories.

	Title           : The TLD Subdomain Structure Protocol and its use for  
Cookie domain validation
	Author(s)       : Y. Pettersen
	Filename        : draft-pettersen-subtld-structure-04.txt
	Pages           : 14
	Date            : 2008-11-03

This document defines a protocol and specification format that can be
used by a client to discover how a Top Level Domain (TLD) is
organized in terms of what subdomains are used to place closely
related but independent domains, e.g. commercial domains in country
code TLDs (ccTLD) like .uk are placed in the .co.uk subTLD domain.
This information is then used to limit which domains an Internet
service can set cookies for, strengthening the rules already defined
by the cookie specifications.Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pettersen-subtld-structure-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Mon, 03 Nov 2008 23:47:51 +0100

Hi,

------- Forwarded message -------
From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-pettersen-subtld-structure-04.txt
Date: Mon, 03 Nov 2008 23:15:01 +0100

-- 
Sincerely,
Yngve N. Pettersen

---

From: Paul Wouters <[email-masked]>
Date: Mon, 3 Nov 2008 18:04:38 -0500 (EST)

> Suggestions for how to collect the information are welcomed.

The other question is, how will people know where to find the information?

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 3 Nov 2008 18:04:38 -0500 (EST)

Paul

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Tue, 04 Nov 2008 01:04:26 +0100

Hello Paul,

On Tue, 04 Nov 2008 00:04:38 +0100, Paul Wouters <[email-masked]>  
wrote:

>> FYI, this draft removes the central repository requirement, and moves  
>> the method for collecting the information out of scope.
>>

Good question.

The application will retrieve it where the vendor specifies. This is  
likely to be a mirror of the original repository, hosted by the vendor  
(like fraud protection is today).

The original repository (or repositories) can be built by vendor,  
crowd-sourced (example: PublicSuffix.org), hosted at the IANA, by the TLD  
registries, or somewhere else.

The major question is where to get good quality data for the repository,  
wherever it is hosted. For that there are serveral possible solutions, DNS  
extensions with a deep treewalking search to build a database, TLD  
registries providing information to a repository, volunteers gathering  
publicly available information about registry-like domains (e.g  
PublicSuffix) , etc.

My personal preference is that the TLD registries provide the information  
through some kind of web service, either hosted by them or mutually  
acceptable repository, that can then be collected/mirrored by the vendors.  
The registries are IMO the agents that are most likely to have accurate  
and up-to-date information about their domain structure.

Given the emergence of PublicSuffix, I decided it was time to separate the  
data collection method(s) from the distribution method of this  
specification.

-- 
Sincerely,
Yngve N. Pettersen

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Tue, 04 Nov 2008 01:04:26 +0100

Hello Paul,

Good question.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Paul Wouters <[email-masked]>
Date: Mon, 3 Nov 2008 19:42:03 -0500 (EST)

> The application will retrieve it where the vendor specifies. This is likely to
> be a mirror of the original repository, hosted by the vendor (like fraud
> protection is today).

So it is the same now as whois. The software (eg jwhois) needs to know
all these days hardcoded. If we only we had agreed on some standard a
long time ago (eg whois.nic.tld or subtld.nic.tld)

> registries, or somewhere else.

But if you go through all of that, you might as well harvest the subtld
structure too. eg I don't think the draft is very meaningful without
either the central repository/registry or a bootstrap that is similar
in all TLD's (I'd use the DNS for this, but someone would probably shoot
me)

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 3 Nov 2008 19:42:03 -0500 (EST)

Paul

---

From: "George Barwood" <[email-masked]>
Date: Tue, 4 Nov 2008 11:37:20 -0000

Hi

Just a thought - I don't know if it is a good one.

Can you not use the SOA record to make this determination?

I would suggest that information should be shared only if two domains have 
the same SOA.

That is, we check for existence of an SOA record for a domain, it's parent, 
etc. until we find an SOA record.

To check two domains, we use this function on both, and compare for 
equality.

example1.co.uk

and

example2.co.uk

will each have their own SOA record, so it is clear information should not 
be shared.

There might be instances where this is too restrictive, but it should be 
fairly good I think.

George Barwood

----- Original Message ----- 
From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
To: <[email-masked]>
Sent: Monday, November 03, 2008 10:47 PM
Subject: [DNSOP] Fwd: I-D Action:draft-pettersen-subtld-structure-04.txt

Hi,

------- Forwarded message -------
From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-pettersen-subtld-structure-04.txt
Date: Mon, 03 Nov 2008 23:15:01 +0100

A New Internet-Draft is available from the on-line From [email-masked]  Tue Nov  4 03:37:31 2008
From: "George Barwood" <[email-masked]>
To: <[email-masked]>,
	"Yngve N. Pettersen \(Developer Opera Software ASA\)" <[email-masked]>
Date: Tue, 4 Nov 2008 11:37:20 -0000
Subject: Re: [DNSOP] Fwd: I-D Action:draft-pettersen-subtld-structure-04.txt
Sender: [email-masked]

Hi

Just a thought - I don't know if it is a good one.

Can you not use the SOA record to make this determination?

I would suggest that information should be shared only if two domains have 
the same SOA.

That is, we check for existence of an SOA record for a domain, it's parent, 
etc. until we find an SOA record.

To check two domains, we use this function on both, and compare for 
equality.

example1.co.uk

and

example2.co.uk

will each have their own SOA record, so it is clear information should not 
be shared.

There might be instances where this is too restrictive, but it should be 
fairly good I think.

George Barwood

----- Original Message ----- 
From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
To: <[email-masked]>
Sent: Monday, November 03, 2008 10:47 PM
Subject: [DNSOP] Fwd: I-D Action:draft-pettersen-subtld-structure-04.txt

Hi,

------- Forwarded message -------
From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-pettersen-subtld-structure-04.txt
Date: Mon, 03 Nov 2008 23:15:01 +0100

A New Internet-Draft is available from the on-linInternet-Drafts
directories.

-- 
Sincerely,
Yngve N. Pettersen

--------------------------------------------------------------------------------

e Internet-Drafts
directories.

-- 
Sincerely,
Yngve N. Pettersen

--------------------------------------------------------------------------------

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 4 Nov 2008 13:27:47 +0100

On Tue, Nov 04, 2008 at 11:37:20AM -0000,
 George Barwood <[email-masked]> wrote 

> Can you not use the SOA record to make this determination?

First, let me repeat my opinion: there is no way to make a sure
determination of the *administrative* zone cuts in the DNS
tree. Browser authors should admit it and fix the cookie mechanism
instead of trying to figure out the administrative borders.

> I would suggest that information should be shared only if two domains 
> have the same SOA.

No, some domains do not use DNS delegation and are still
separated. Counter-examples:

* carthage.tn, benali.tn and pasteur.tn all have the same SOA but are
clearly different (the ".tn" TLD does not do delegations).

* ".tel" intended to have a flat zone for the entire TLD (this seems
to have been dropped for non-technical reasons).

* yaouankizbreizh.free.fr, pokerslam.free.fr and abarbot.free.fr have
different SOA and are different domains, managed by different persons,
all customers of the ISP Free.
_______________________________________________
DNSOP mailing list
[email-masked]
hFrom [email-masked]  Tue Nov  4 04:27:51 2008
Date: Tue, 4 Nov 2008 13:27:47 +0100
From: Stephane Bortzmeyer <[email-masked]>
To: George Barwood <[email-masked]>
Organization: NIC France
Cc: [email-masked]
Subject: Re: [DNSOP] Fwd: I-D Action:draft-pettersen-subtld-structure-04.txt
Sender: [email-masked]

On Tue, Nov 04, 2008 at 11:37:20AM -0000,
 George Barwood <[email-masked]> wrote 

> Can you not use the SOA record to make this determination?

First, let me repeat my opinion: there is no way to make a sure
determination of the *administrative* zone cuts in the DNS
tree. Browser authors should admit it and fix the cookie mechanism
instead of trying to figure out the administrative borders.

> I would suggest that information should be shared only if two domains 
> have the same SOA.

No, some domains do not use DNS delegation and are still
separated. Counter-examples:

* carthage.tn, benali.tn and pasteur.tn all have the same SOA but are
clearly different (the ".tn" TLD does not do delegations).

* ".tel" intended to have a flat zone for the entire TLD (this seems
to have been dropped for non-technical reasons).

* yaouankizbreizh.free.fr, pokerslam.free.fr and abarbot.free.fr have
different SOA and are different domains, managed by different persons,
all customers of the ISP Free.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

ttps://www.ietf.org/mailman/listinfo/dnsop

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Tue, 04 Nov 2008 13:28:18 +0100

Hi,

It is a possibility, but unfortunately, there are a couple of problems  
with that approach, at least in my area.

In my use case, browsers, I cannot rely on having *direct* access to  
Internet DNS (local yes, public no), this can be due to restrictive  
firewall procedures, e.g. a HTTP proxy is the only way onto the net. That  
is why the heuristic draft (DNSCOOKIE) specifies both a DNS IP lookup and  
a HTTP proxy method. You also have the fact that AFAIK both Mozilla and  
IE8 are using or planning to use this information is other areas as well,  
such a display of hostname in URLs and bookmark/visited lists.

Also, AFAIK the current APIs for name lookup on various platform does not  
provide methods for looking for anything but IP addresses (in fact, there  
are platforms where we are not able to access the IP address at all),  
which would mean that my client would need to implement a reasonably  
complete DNS client (which means extra footprint, of course it may be less  
or more than the suggested protocol, but my suggestion does not require a  
new transport protocol in the application). Such a client might also have  
to bypass the local caching mechanisms, unless complex (platform specific)  
network configuration discovery mechanims are used. Assuming there is  
direct access to the required DNS servers ...

It may be possible to use this as a source for generating a database, but  
that approach requires (repeated and maybe frequent) spider crawls across  
all DNS servers. I am not familiar enough with DNS to know if such a crawl  
is feasible.

It might also be used by a webservice, but that would require the client  
to send a request for each individual domain it needs to check, causing a  
privacy problem. It might also be possible to integrate this with fraud  
protection request made by clients, but those are generally only made for  
top documents, not images (e.g advertisements) which may come from  
different domains.

The domain structure of a TLD is not something that changes frequently, it  
is therefore suitable for a static file that contain the necessary  
information, something which will also reduce network traffic. IIRC,  
PublicSuffix's specification for dot-no contain about 700 items, even  
assuming 50 bytes per specification that results in just 35 KB of data  
(and it can probably be compressed to a lot less); which would quickly be  
surpassed by any type of dynamic lookup.

On Tue, 04 Nov 2008 12:37:20 +0100, George Barwood  
<[email-masked]> wrote:

> That is, we check for existence of an SOA record for a domain, it's  
> parent, etc. until we find an SOA record.
>
> will each have their own SOA record, so it is clear information should  
> not be shared.
>
> ----- Original Message ----- From: "Yngve N. Pettersen (Developer Opera  
> Software ASA)" <[email-masked]>
> To: <[email-masked]>

-- 
Sincerely,
Yngve N. Pettersen

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Tue, 04 Nov 2008 13:28:18 +0100

Hi,

-- 
Sincerely,
Yngve N. Pettersen

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Tue, 04 Nov 2008 13:42:26 +0100

> instead of trying to figure out the administrative borders.

Please see  
http://www.ietf.org/internet-drafts/draft-pettersen-cookie-v2-03.txt

But changing to such a new spec will take 10+ years, unless browser  
vendors jointly decides to break the net (I don't see that happening).  
Case in point: Opera is currently the only major client supporting RFC  
2965, 9 years after it was made an RFC.

In the meantime alternative mechanisms are required. My drafts in this  
area are the best suggestions I have for such workaround, but they may not  
be the best.

However: Cookies is just the one area where this type of information is  
being desired. IE8 is going to use this to highlight the effective domain  
of a URL, making the rest of the URL almost invisible, as a counter to  
hostname spoofing. FF3 is AFAIK already using this for similar purposes,  
and is to my knowlegde using or planning to use it in lists of URLs,  
bookmarks or history lists.

BTW, even assuming SOA works, I suspect one would have to track it all the  
way to the TLD, unless it is impossible to leave it out at a subdomain.

-- 
Sincerely,
Yngve N. Pettersen

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Tue, 04 Nov 2008 13:42:26 +0100

Please see  

-- 
Sincerely,
Yngve N. Pettersen

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Nov 2008 15:40:01 -0500

> long time ago (eg whois.nic.tld or subtld.nic.tld)

Of course, we could invent a DNS RRTYPE that allows us to put service
data in the DNS, so that people can look it up.  And, happily, we
have.

A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Nov 2008 15:40:01 -0500

A