Yngve Nysaeter Pettersen wrote: > On Thu, 12 Jun 2008 14:54:32 +0200, Niall O'Reilly <[EMAIL PROTECTED]> > wrote: > > >> On 12 Jun 2008, at 12:25, Gervase Markham wrote: >> >> >>> The second question is one of resources and client complexity. I am >>> meeting resistance to the idea of having the existing list regularly >>> dynamically downloaded, which would be the simplest method of >>> providing >>> more frequent updates than the six-to-eight week Firefox security >>> releases. An assemble-and-cache-the-data-from-DNS scheme would be an >>> order of magnitude more complex. >>> >> I'm not sure why you would need to assemble anything. >> Couldn't you seize the data you need, on demand, from >> the DNS (and cache at will). >> > > DNS, or full DNS, is not always available. > > There are at least two scenarios where this is the case: > > - Behind (very) closed firewalls, where all access go through a HTTP-only > proxy. No DNS for external addresses is available. For that matter, when > going through a proxy you have no way of knowing if the DNS available to > you know anything about the address space you are accessing through the > proxy. > > - On a number of systems, in particular phone devices, the application > does not even have access to DNS to do a name lookup, it must specify the > hostname, and try to connect. > >
A DNS-based solution does not *need* to be a DNS-*only* solution. As I understand it, your list associates suffixes with "true/false" state, i.e. whether they are public or not. Imagine a tree of subdomains, all of which exist only to provide true/false information, rooted at, say, suffix-list.mozilla.org. If a given subdomain exists, "true", otherwise "false". And for http-only scenarios, have each of these subdomains be a CNAME pointing a static web page, say "true.suffix-lists.mozilla.org.", which contains just the word "True". Both the content of the pages, and the DNS entries, could be cached in their respective systems (web browser cache, or DNS resolver cache). Timeliness of updates would be maintained by appropriate mechanisms to tell the querying agent to check again (HTTP tag or DNS TTL). The HTTP side of things does not require a separate DNS client. But, the updates to the list can be made trivially by manipulation of DNS data alone, and use of DNS involves much less processing on the client side if DNS client querying is possible (one UDP packet, generally). Brian > Additionally, a DNS-only solution would mean implementing a DNS client > inside the application, since AFAICT the platform socket APIs usually do > not provide the necessary functionality needed to access non-IPaddress > data. > > While I am not opposed to the data being available in DNS, there must be a > simple way to collect and provide it to clients efficiently and for any > use case, while reducing privacy issues (which a batch of data for a given > TLD will solve neatly), and with respect to HTTP clients, HTTP is the only > method we can rely on, and it will also be available to many specialized > applications that use HTTP, perhaps through some library. > > > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
