Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt

From: "Michael Sheldon" <[email-masked]>
Date: Tue, 04 Oct 2011 14:39:47 -0700

> -------- Original Message --------
> Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt
> From: Måns Nilsson <[email-masked]>
>
> Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt Date: Tue, Oct 04, 2011 at 12:40:50PM +0100 Quoting Alex Bligh ([email-masked]):
> > 
> > 
> > --On 4 October 2011 12:04:42 +0100 Tony Finch <[email-masked]> wrote:
> > 
> > >You can't increase the DNS message size beyond 64KB.
> > 
> > I was under the (mis) apprehension that was a UDP limitation, and that
> > large AFXRs could exceed 64KB. Live and learn.
> 
> I've done AXFRen of 1/2 GB zones. Not practical, but doable. The 64K
> limit does not apply to AXFR, but, then again, AXFR is not like the
> other children...
> 

The 64K DNS message limit applies to *all* TCP transactions. The TCP
length field is the limiting factor at two bytes. AXFR gets around this
by using multiple DNS messages, but it is still limited to 64K per
message.

*IF* this proposal survives, I agree with the suggestion that we keep it
as close to the current model as possible.

That said, I haven't seen any compelling reason to support a protocol
change that seems solely for the purpose of fixing other people's
network mis-configurations.

Michael Sheldon
Dev-DNS Services
GoDaddy.com

_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Ray Bellis <[email-masked]>
Date: Tue, 4 Oct 2011 22:36:15 +0000

On 4 Oct 2011, at 17:39, Michael Sheldon wrote:

The 64K DNS message limit applies to *all* TCP transactions. The TCP
length field is the limiting factor at two bytes. AXFR gets around this by using multiple DNS messages, but it is still limited to 64K per message.

And compression pointers are of course only 14 bits, so are constrained to point back only within the first 16K of any message.

Ray

---

From: Brian Dickson <[email-masked]>
Date: Tue, 4 Oct 2011 18:54:29 -0400

> network mis-configurations.

There are subtleties in the unintended consequences of messing with DNS.

By "messing with", I refer to ISPs doing arbitrary stuff, including
but not limited to NXDOMAIN or other forms of DNS hijacking.

Blocking the DNSSEC portion of DNS responses, either deliberately or
by lack of support, is another form of "messing with", and may also be
used to hide the other (deliberate) activity.

When DNSSEC stuff is blocked, not only does it reduce the trust in the
answers, it re-opens the window of vulnerability that DNSSEC was meant
to close. Not good.

Widespread blocking of DNSSEC threatens the adoption and utility of DNSSEC.

However ugly it might be, DNSSEC is important enough to warrant
considering counter-counter-measures.

This proposal is a very lightweight and elegant (IMHO)
counter-counter-measure. It makes valid answers from either authority
servers (if client == recursive server) or resolvers (if client ==
stub) possible to (a) get directly, and (b) trust and/or verify. In
many use cases, there is no alternative, particularly when there is a
local market monopoly or duopoly of such "bad actors".

Even if you don't use DNSSEC, please don't stop others from using it
or from making it possible to achieve widespread usage.

And I gently encourage use of DNSSEC by any and all -- especially when
your domain is your primary (sole?) source of revenue. (BTW - I am a
happy customer, FWIW. But I'd be happier if you used DNSSEC.)

Brian

P.S. Note also, that mis-configurations are often deliberate,
especially when performed by the state. This proposal at least makes
feasible, the unblocking of state-sponsored censorship at the DNS
level.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 05 Oct 2011 12:56:09 +0900

> happy customer, FWIW. But I'd be happier if you used DNSSEC.)

You seems to be using DNSSEC.

How do you make your clock securely synchronized with that of
the root?

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Oct 2011 15:27:28 +1100

> How do you make your clock securely synchronized with that of

Personally, I look at my wristwatch.  DNSSEC only requires loose
time syncronization.  Most machines, provided they have a battery
backed up clock, could run their entire life on the time as set
by the manufacturer.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 05 Oct 2011 14:10:55 +0900

Mark Andrews wrote:

> Personally, I look at my wristwatch.

You may but your computers can not.

> DNSSEC only requires loose

A problem is that, even though an hour of error is not significant
to DNSSEC, it is significant to most other purposes, which
means the clock is synchronized to external source.

						Masataka Ohta

---

From: David Conrad <[email-masked]>
Date: Wed, 5 Oct 2011 07:25:39 -0700

On Oct 4, 2011, at 3:54 PM, Brian Dickson wrote:
> This proposal is a very lightweight and elegant (IMHO) counter-counter-measure.

Not really. It is a hack that, if implemented, will ensure there is no pressure to actually fix broken infrastructures.  Realistically:

- states-sponsored censorship will continue to occur: states have a tendency to insist on that sort of thing, with guns if necessary;
- folks intentionally blocking working DNS to force the use of their name servers will figure out a way to continue blocking DNS: I have sufficient faith in the tenacity of such folks that all this will do is result in a cat-and-mouse game (e.g., it won't be that hard to figure out which HTTP{,S} server IP addresses to blacklist);
- middlebox vendors and lazy DNS operators won't need to fix their DNS implementations because there is now a HTTP{,S} bypass for the folks that whine about such things; and
- we now have to saddle DNSSEC server implementations (auth and recursive) with yet more complexity.  Permanently.

This feels like the wrong way to solve this problem.

Regards,
-drc

---

From: [email-masked]
Date: Wed, 5 Oct 2011 15:44:41 +0000

> - we now have to saddle DNSSEC server implementations (auth and recursive) with yet more complexity.  Permanently.

	complexity is a serious problem for maintaining a secure and auditable system.
	there is no clear, crisp engineering reason to persue this tactic... it is, as
	stated, a counter-counter measure... looks like an arms race to me, not useful
	engineering.

> This feels like the wrong way to solve this problem.

	amen.  (sorry - too religious -  +1)

/bill