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 PROTECTED]> wrote:
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 PROTECTED]>
To: <[email protected]>
Sent: Monday, November 03, 2008 10:47 PM
Subject: [DNSOP] Fwd: I-D Action:draft-pettersen-subtld-structure-04.txt
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 PROTECTED]
To: [EMAIL PROTECTED]
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 PROTECTED]
Opera Software ASA http://www.opera.com/
Phone: +47 24 16 42 60 Fax: +47 24 16 40 01
********************************************************************
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
