Subject: Re: [DNSOP] [dns-privacy] DNS over DTLS (DNSoD)

From: Tony Finch <[email-masked]>
Date: Fri, 25 Apr 2014 15:24:26 +0100

Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
>
> Any specific reason for the firewalls to permit TCP/53 other than for zone transfer ?

RFC 5966

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South Utsire, Northeast Forties: Easterly 4 or 5, increasing 6 or 7. Slight or
moderate. Fair. Good.

---

From: Ralf Weber <[email-masked]>
Date: Fri, 25 Apr 2014 16:46:58 +0200

Moin!

> Any specific reason for the firewalls to permit TCP/53 other than for zone transfer ?
Wat? Because it is defined in the RFC. RFC1035 may not been totally clear on that. IMHO 
the language is strong enough, but if not there is RFC5966:
	"All general-purpose DNS implementations MUST support both UDP and TCP transport."
Any more questions?! Also all this new DNS stuff like DNSSEC and mitigating DNS 
amplification attack with RRL or similar techniques require that the TCP transport works.

So long
-Ralf

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 25 Apr 2014 11:14:54 -0400

> amplification attack with RRL or similar techniques require that the TCP transport works.

Yes and RFC 8888 quite definitely says that I get a pony.

The existing DNS works as far as the people running their firewalls
are concerned. The failure of TCP fallback in practice has been an
understood problem for 20+ years.

If people want to design a protocol that is going to be usable, they
are going to end up having to accept some constraints that are not in
the specs.

-- 
Website: http://hallambaker.com/

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 25 Apr 2014 14:22:03 +0000

> -----Original Message-----
> From: Ralf Weber [mailto:[email-masked]]
> Sent: Thursday, April 24, 2014 7:22 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: Nicholas Weaver; Paul Wouters; dnsop; [email-masked]
> Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD)
> 
> Moin!
> 
> 
> On 24.04.2014, at 15:28, "Tirumaleswar Reddy (tireddy)" <[email-masked]>
> wrote:
> 
> >> -----Original Message-----
> >> From: dns-privacy [mailto:[email-masked]] On Behalf Of
> >> Nicholas Weaver
> >> Sent: Thursday, April 24, 2014 1:58 AM
> >> To: Paul Wouters
> >> Cc: dnsop; Nicholas Weaver; [email-masked]
> >> Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD)
> >>
> >>
> >>> On Apr 23, 2014, at 1:00 PM, Paul Wouters <[email-masked]> wrote:
> >>> No, I fully disagree with this. Port 53 TCP has a much better chance
> >>> at working these days than a random other newly assigned port.
> >
> > On the contrary, Firewalls are configured today to permit UDP port 53 and
> block TCP port 53. Why should firewalls change their configuration ?
> I know lots of firewalls that also allow TCP/53, 

> but the real problem with all
> these middle boxes that make changing DNS hard is that they believe to
> understand the full protocol and only pass what they think is right. So everything
> new we come up will be dropped (Been there, done that). We have to be very
> careful with changes to the DNS protocol if we want them to be deployed

Agreed, It totally depends on the environment in which the firewall is deployed, it's capability and configuration. 

For example
[1] For firewalls  deployed in Enterprise network and the I.T realizing the importance of privacy then FW could be configured to permit DNSoD over 53. Similarly I don't see any problem with the firewall deployed in the Home network.
[2] It could be a problem with firewalls deployed in airports, coffee shops,  where I.T may not care about privacy, and the  firewall configured could block non-DNS traffic on port 53. In such environments if a user wants privacy then it's probably better to go with DNS servers that the user trusts. For example DNSCrypt uses UDP/443 by default and if the connectivity with the DNS servers fails then it resorts to TCP/443 and it works on UDP/53 too. I guess With {D}TLS we will need a similar approach where client tries connectivity using multiple ports, L4 protocols etc.

Firewalls today are already capable of inspecting the TLS handshake and can also act as {D}TLS proxy.  DTLS is already deployed and used today to secure WebRTC media, data channels and CoAP protocol in IOT environments. Firewalls are catching up with these emerging protocols to make sure it works with them.

Cheers,
-Tiru

> Ralf
> Sent from my iPhone

---

From: Joe Abley <[email-masked]>
Date: Fri, 25 Apr 2014 14:56:46 -0400

> understood problem for 20+ years.

Understood, perhaps; measured and understood, not so much.

What is sorely missing from most/all protocol evolution discussions is a rigorous study of the actual impact of larger response sizes, fragmentation, interception/middebox-mangling, TCP fallback and TCP pipelining in the real world in at least two problem domains, recursive-authority and stub-recursive.

> are going to end up having to accept some constraints that are not in

And it would be great if we could describe those constraints with confidence.

There was concern that signing ORG might cause resolution problems due to larger responses, or might cause TCP fallback on a scale not seen before. The former were not apparent. The latter happened (due to a defect in the signer used for ORG) but did not cause any obvious problems.

There was widespread expectation that DNSSEC in the root zone would impact resolvers' ability to prime, hence the DURZ, global netops meeting roadshow, LTQC, etc. No issues were identified.

We will get much further, much more quickly if we know more about what problems are likely and which ones are unlikely. Being afraid of every possible negative outcome is just a recipe for doing nothing. No useful risk analysis is possible without data.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Apr 2014 17:55:41 -0400

> Any specific reason for the firewalls to permit TCP/53 other than for zone transfer ?

"Because DNS uses TCP in lots of cases, and always has"?  Anyone who
is still configuring firewalls to deny TCP/53 as a matter of course
ought to have his or her Internet license revoked.

A

-- 
Andrew Sullivan
[email-masked]