Subject: [dns-dir] FW: [AAA-DOCTORS] Secdir review of draft-ietf-dnsext-dnsproxy-05

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 3 Jun 2009 11:40:11 +0200

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard Aboba
	Sent: Wednesday, June 03, 2009 12:38 PM
	To: Alan DeKok; [email-masked];
[email-masked]; [email-masked]
	Subject: Re: [AAA-DOCTORS] Secdir review of
draft-ietf-dnsext-dnsproxy-05

	There are also some pretty  nasty effects on multi-homed hosts
who may send DNS queries on
	multiple interfaces, including the "WiFi hotspot" interface. 
	
	This can result in a user who has a perfectly serviceable
alternative connection (e.g. Ethernet, HSDPA, etc.)
	being unable to resolve names because their WiFi hotspot has
decided to (quickly) return a synthesized (bogus) 
	answer to every query. 
	
	The load of support calls this can create is so large that the
practice of forbidding multi-homing (via use of
	suitably configured connection managers) has become quite common
place.   

	> Date: Sat, 30 May 2009 09:31:08 +0200
	> From: [email-masked]
	> To: [email-masked];
[email-masked]; [email-masked]
	> Subject: [AAA-DOCTORS] Secdir review of
draft-ietf-dnsext-dnsproxy-05
	> 
	> I have reviewed this document as part of the security
directorate's
	> ongoing effort to review all IETF documents being processed by
the
	> IESG. These comments were written primarily for the benefit of
the
	> security area directors. Document editors and WG chairs should
treat
	> these comments just like any other last call comments.
	> 
	> Over all, the document appears to be clear.
	> 
	> 
	> I wonder about the following text in section 4.5, however:
	> 
	> NB: any DNS proxy (such as those commonly found in WiFi
hotspot
	> "walled gardens") which transparently intercepts all DNS
queries, and
	> which returns unsigned responses to signed queries, will also
cause
	> TSIG authentication failures.
	> 
	> 
	> The problem with WiFi hotspot DNS proxies is much, much, worse
than
	> this simple paragraph would suggest. There are issues found in
in those
	> deployments that are not discussed in this document. I will
summarize
	> them here:
	> 
	> 
	> Issue: responding to all DNS requests with the IP of the
hotspot
	> 
	> Goal: to guide all client traffic to the hotspot
	> 
	> Background: Many client machines have VPN software that checks
for the
	> existence of "internal" corporate DNS names. If the names
resolve, the
	> client is assumed to be "within" the corporate network. If the
name
	> does not resolve, the client is assumed to be elsewhere, and
the VPN
	> software behaves differently. DNS proxies that return an
answer for all
	> names result in the client erroneously believing it is in the
"internal"
	> network. Various things then fail in weird and wonderful ways.
	> 
	> Even when VPN software doesn't exist, this practice can cause
other
	> problems. A commonly used web browser (I.E. from a major
vendor) can
	> cache the results of DNS queries at the application layer.
This
	> information is cached even across DHCP lease assignments from
a new
	> subnet, where DNS caches are usually flushed. The result is
that the
	> web browser cannot view the first web page that the user tries
to visit.
	> The captive portal page is always shown instead.
	> 
	> Suggestion: DNS proxies MUST NOT respond with an answer if the
name is
	> not resolvable. DNS proxies MUST NOT synthesize an answer.
	> 
	> 
	> Issue: responding to all DNS requests with a fake IP (commonly
1.1.1.1)
	> 
	> Goal: to catch *different* kinds of traffic than the previous
issue
	> (this is no explanation, I've never had one explained to me in
a way I
	> understand)
	> 
	> Background: Some proxies return synthetic responses with
"fake" IP
	> addresses. While 1.1.1.1 is not currently allocated, it may be
in the
	> future. Using it is a bad choice. In fact, this whole practice
is
	> completely wtong.
	> 
	> Suggestion: Same as above. DNS proxies MUST NOT synthesize an
answer.
	> 
	> 
	> The above suggestions might be a little strong. There are
valid cases
	> where a proxy inside of a corporate network might need to
synthesize
	> incorrect answers. These situations are better described as
"internal
	> corporate policy". i.e. Notwithstanding the suggestions above,
if you
	> want to break your own network, there are often valid reasons
for doing so.
	> 
	> Alan DeKok.
	> _______________________________________________
	> AAA-DOCTORS mailing list
	> [email-masked]
	> https://www.ietf.org/mailman/listinfo/aaa-doctors

_______________________________________________
AAA-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/aaa-doctors

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 03 Jun 2009 13:58:44 -0400

Moral: DNS lies are a terrible idea.

         Olafur

At 05:40 03/06/2009, Romascanu, Dan (Dan) wrote:
>----------
>Subject: Re: [AAA-DOCTORS] Secdir review of draft-ietf-dnsext-dnsproxy-05
>
>There are also some pretty  nasty effects on multi-homed hosts who 
>may send DNS queries on
>being unable to resolve names because their WiFi hotspot has decided 
>to (quickly) return a synthesized (bogus)
>answer to every query.
>
>suitably configured connection managers) has become quite common place.
>
>
> > Subject: [AAA-DOCTORS] Secdir review of draft-ietf-dnsext-dnsproxy-05
> >
> > I have reviewed this document as part of the security directorate's
> > ongoing effort to review all IETF documents being processed by the
> > IESG. These comments were written primarily for the benefit of the
> > security area directors. Document editors and WG chairs should treat
> > NB: any DNS proxy (such as those commonly found in WiFi hotspot
> > "walled gardens") which transparently intercepts all DNS queries, and
> > which returns unsigned responses to signed queries, will also cause
> > The problem with WiFi hotspot DNS proxies is much, much, worse than
> > this simple paragraph would suggest. There are issues found in in those
> > deployments that are not discussed in this document. I will summarize
> > them here:
> >
> >
> > Issue: responding to all DNS requests with the IP of the hotspot
> >
> > Background: Many client machines have VPN software that checks for the
> > existence of "internal" corporate DNS names. If the names resolve, the
> > client is assumed to be "within" the corporate network. If the name
> > does not resolve, the client is assumed to be elsewhere, and the VPN
> > software behaves differently. DNS proxies that return an answer for all
> > names result in the client erroneously believing it is in the "internal"
> > Even when VPN software doesn't exist, this practice can cause other
> > problems. A commonly used web browser (I.E. from a major vendor) can
> > cache the results of DNS queries at the application layer. This
> > information is cached even across DHCP lease assignments from a new
> > subnet, where DNS caches are usually flushed. The result is that the
> > web browser cannot view the first web page that the user tries to visit.
> > Suggestion: DNS proxies MUST NOT respond with an answer if the name is
> > Issue: responding to all DNS requests with a fake IP (commonly 1.1.1.1)
> >
> > Goal: to catch *different* kinds of traffic than the previous issue
> > (this is no explanation, I've never had one explained to me in a way I
> > understand)
> >
> > Background: Some proxies return synthetic responses with "fake" IP
> > addresses. While 1.1.1.1 is not currently allocated, it may be in the
> > future. Using it is a bad choice. In fact, this whole practice is
> > completely wtong.
> >
> > Suggestion: Same as above. DNS proxies MUST NOT synthesize an answer.
> >
> >
> > The above suggestions might be a little strong. There are valid cases
> > where a proxy inside of a corporate network might need to synthesize
> > incorrect answers. These situations are better described as "internal
> > corporate policy". i.e. Notwithstanding the suggestions above, if you
> > want to break your own network, there are often valid reasons for doing so.
> >
> > Alan DeKok.
>dns-dir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dns-dir