Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] RFC: comments on discovery mechanisms

David-Sarah Hopwood david-sarah at
Fri Dec 3 15:39:59 PST 2010

On 2010-12-03 20:00, Jacob Appelbaum wrote:
> On 12/03/2010 02:48 PM, David-Sarah Hopwood wrote:
>> DNSSEC might prevent forgery, but cannot prevent blocking.
> This is my major point of frustration with DNSSEC. It is easy to provide
> query privacy for clients and some important DNSSEC people don't
> understand why this is important.
> My attempts to discuss this with DNSSEC people usually ends in
> frustration. They see no point in privacy for a user's queries if they
> intend to directly connect to the site. Of course if the site has TLS,
> the game changes and DNSSEC becomes the weakest privacy link.

Whether the site has TLS makes little difference, since the domain name is
in the clear in the TLS handshake -- both in the server_name extension if
the client sends it (as most recent browsers do [*]), and in the server's

That's not to say it wouldn't be useful to put obstacles in the way of
DNS-level blocking. Blocking at the DNS level is particularly cheap and
easy; it can be done just by putting pressure on the domain registrar and
without filtering individual connections. Similar blocking at the IP
level without filtering individual connections would require manipulating
routing tables, which is also not particularly difficult technically, but
might be more difficult politically for some actors.

I don't really see how DNSSEC with query privacy would help much in raising
obstacles to DNS-level blocking, though. Am I missing something?


David-Sarah Hopwood  ⚥

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the liberationtech mailing list