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

2014-04-25 Thread Tony Finch
Tirumaleswar Reddy (tireddy) tire...@cisco.com wrote:

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

RFC 5966

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
South Utsire, Northeast Forties: Easterly 4 or 5, increasing 6 or 7. Slight or
moderate. Fair. Good.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy


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

2014-04-25 Thread Phillip Hallam-Baker
On Fri, Apr 25, 2014 at 10:46 AM, Ralf Weber d...@fl1ger.de wrote:
 Moin!

 On 25 Apr 2014, at 16:22, Tirumaleswar Reddy (tireddy) tire...@cisco.com 
 wrote:
 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

Yes and RFC  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/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy


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

2014-04-25 Thread Joe Abley

On 25 Apr 2014, at 11:14, Phillip Hallam-Baker hal...@gmail.com wrote:

 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.

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.

 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.

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
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy