[Chapter-delegates] Input Request: DNS Blocking

[Leslie Daigle]

Peter,

I'd like to follow up a bit on the DNSSEC angle.  In brief -- the point was not so much that DNSSEC is a mitigating force here, nearly so much as that possible reactions and work arounds will impact the viability of DNSSEC deployment.   See below:

On Jan 22, 2011, at 8:11 AM, Peter Koch wrote:

> Sally,
> 
> thanks for raising this and for the opportunity to comment.
> 
>> we believe that policies of this sort would have negative implications for the global DNS and for the implementation of DNSSEC, among other issues.
> 
> I'd recommend to keep DNSSEC out of this because it is not really incompatible with
> the "blocking" regime.

Our thinking (and that of other DNSSEC proponents) is:  DNSSEC _usage_ is fledgling, and to the extent its validity is undermined, it perceived use will be reduced, thereby slowing down further uptake for use.  Specifically, in your scenarios -- 

> The reason is that there are three operational scenarios:
> 
> 1) End user uses ISP's DNS infrastructure for DNS resolution and DNSSEC validation
>   In this case, the ISP will implement the "block" and commumicate the modified
>   DNS responses as authentic.  The end user "trusts" the ISP and the ISP modifies
>   (or is obliged to modify) the responses.  There's no case or chance for DNSSEC here.

Agree.  And, also, no value to trying to make use of DNSSEC, because your ISP is lying to you.  What was that about integrity, again?  :-(


> 
> 2) End user operates private DNS resolver and validator.  ISP's infrastructure is
>   bypassed and no modifications apply.  Blocking is essentially mitigated, but this
>   is not due to DNSSEC but due to bypassing the blocking infrastructure.  No case
>   for DNSSEC.

Agreed DNSSEC doesn't mitigate the issue.  But, it isn't undermined by false integrity, either.  

> 
> 3) End user uses ISP's DNS infrastructure (resolver) and operates a private DNSSEC
>   validator.  This scenario isn't too likely, but thinkable.  ISP's infrastructure

Having finally gotten a single signed root, it would be unfortunate if "best practice" encouraged using alternate trust hierarchies.  Overall, this undermines the notion of having a single stable DNS infrastructure with integrity.

(And, yes, the user still does not get the data for the site).

So, again, the point wasn't to try to solve blocking through the use of DNSSEC, so much as to observe that these blocking routines could undermine DNSSEC as a step towards securing the Internet's infrastructure.

Leslie.
 
>   will modify certain responses and these modifications can be detected by the user's
>   DNSSEC validator, provided the zones in questions have been signed.  However, since
>   the correct information is repeatedly unavailable, all the end user gets to know
>   is that someone modified the responses.  Name resolution is essentially blocked
>   which is what was intended.  Hans Peter already mentioned the German approach
>   of a redirection to a special "STOP sign" web page (interesting under DoS and
>   other aspects) and indeed here's the one thing that DNSSEC can avoid: the
>   redirection would not be followed because it could be detected as a spoofed response.
> 
> The above scenarios assume there are no port 53 blocks and no transparent DNS packet
> modifications but even with those the only thing DNSSEC would deliver is the fact
> that repsonses have been spoofed. It wouldn't make the original responses any more
> accessible.
> 
>> We are thinking of principles along the following lines:
>> 
>> - The Internet is a global network of networks that provides for the neutral passage of packets - requirements to adjust or prevent DNS responses would impair this neutrality.
> 
> that's a nice technical argument but of course this "neutrality" has limits in the real
> world as well: we have body scanners at airports, searches at borders, regulation of
> speed and shape of vehicles on roads and tracks and so forth.  Also, as was probably
> mentioned before: it might turn out not too helpful that larger parts of the industry
> do not have these architectural concerns if there is positive impact on their revenue
> stream (read: NXDOMAIN rewriting).  Is ISOC going to recommend against these practices,
> too?
> 
>> - For the Internet to be truly global it must be consistent - in general, what an Internet user "sees" when accessing a particular domain name from one location should be the same as what is seen when accessing the same domain name from another location
> 
> Another nice technical argument, but again, there is "GeoIP" or global DNS based load
> balancing and the likes, so also this principle is already violated or revenue reasons.
> Are we going to tell governments that this principle is more valuable than their
> desire or obligation to "protect" their citizens?
> 
> And, while at it, another part of the industry is actively promoting DNS blocking as
> a successful botnet mitigation strategy.  When it demonstratably works against botnets,
> why is it evil or impossible to apply the same technology to "illegal" content?
> 
>> - Policies should be narrowly tailored and consistent with open standards and accepted operational practices: technical ?fixes? to short-circuit due process or violate fundamental and accepted procedures may harm the global Internet.
> 
> A typical government response to this would be that if your "fundamental and accepted
> procedures" bring you in conflict with $sovereign_state's legislation, you better review
> and reconsider these procedures.
> 
>> I would appreciate your comments on the above points.  We would also welcome information on whether and how DNS blocking policies are being considered or implemented in your country.  Please send your feedback by Friday, 28 January 2011. 
> 
> As sketched out above, arguments along the lines of Internet architectural principles
> do have my sympathy but aren't too well received within the prospective target audience.
> For the unavailability of technical solutions I'd like to suggest it needs some
> background in, or at least affinity to, maths or computer science to accept that
> a proof of insoluablity is actually a useful concept rather than a demonstration
> of unwillingness or incompetence - no matter whether this does or does not hold
> for the problem under discussion.
> 
> -Peter (ISOC.DE member of the board)
> _______________________________________________
> Chapter-delegates mailing list
> Chapter-delegates at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/chapter-delegates

Leslie Daigle
Chief Internet Technology Officer
Internet Society
daigle at isoc.org