Subject: Re: [dnsext] Name server agility with DNSSEC

From: Paul Vixie <[email-masked]>
Date: Sun, 05 Jul 2009 01:47:03 +0000

> From: "George Barwood" <[email-masked]>
> Date: Sat, 4 Jul 2009 20:28:16 +0100
> 
> Some thoughts on sending child NS RRsets and glue, in a DNSSEC context.
> 
> I suggest sending the child NS RRset with each response, but NOT the glue.

the child can only usefully send in-zone or sub-zone glue, not sibling or
unrelated glue.  for kashpureff resistance, any other glue will be ignored.

in the absence of in-zone or sub-zone glue, not all nameservers will have
a way to be reached.

so i think the situation is already at its local minima.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "George Barwood" <[email-masked]>
Date: Sun, 5 Jul 2009 14:37:06 +0100

----- Original Message ----- 
From: "Paul Vixie" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, July 05, 2009 2:47 AM
Subject: Re: [dnsext] Name server agility with DNSSEC 

> in the absence of in-zone or sub-zone glue, not all nameservers will have

Ah, hold on. I'm talking about requests to the child, where the child returns
unsolicited NS records and associated A/AAAA/RRSIG records, for
reasons that are not 100% clear ( I think only BIND does this, and then
only for positive authoritative responses, i.e. not for referrals or NxDomain/
NoData responses ).

The parent will already have provided complete (unsigned) glue where required.

>¶‹§²æìr¸›zÇ§u©ž²Æ zÚ'jg®Šiz»+z«ž²Ú)²'~ŠàÂ+a¶°¢·nžË›±Êâmè§jÈ§‚W¥Šwš²Ø^™ë,j{[¡ÜšÈb½èm¶Ÿÿ¢›"z×è®åŠËlþv¦yÚè¦—«³

---

From: Paul Vixie <[email-masked]>
Date: Sun, 05 Jul 2009 17:18:29 +0000

> Date: Sun, 5 Jul 2009 14:04:38 +0100
> 
> I'm looking at queries like
> 
> dig txt se @a.ns.se +dnssec
> 
> which gives a 2,941 byte response, because it has 15 RRSIG records.
> 
> One for the requested TXT, one for the NS, and 13 for the A and AAAA records.

> I'm suggesting it is not appropriate to send the A and AAAA records and
> their signatures.
> 
> Especially if this causes truncation, or causes the response to be > 1500
> bytes.

i tend to agree that sending the NS RRsets on authoritative responses is
mostly a waste of resources.  i believe the current thinking is, apex NS
RRsets can change, and so every authoritative response should have the
power to overwrite them.  also, delegation NS RRsets are not signed in the
parent, whereas the apex NS RRsets are.  so we're stuck with the NS RRsets.
so what you could ponder is whether the additional data rules could be
relaxed to include an "unless it would cause truncation" exception, as in:

> Instead they can be given very high TTLs, so that caches need fetch them
> only once.

since the A/AAAA names in your example are all in-zone and are all ref'd by
the NS RRset, there's presumptive nonfetchability of those A/AAAA RRsets
and therefore presumptive nonreachability of the zone itself, if they are
not included whenever the NS RRset appears in an authority section.  this
gets back to yesterday's topic here -- a new and protocol-defined kind of
iteration restart whenever a zone goes unreachable.  if we knew that all
caching servers were going to perform iteration restart (with holddown)
then we could leave out A/AAAA RRsets from the additional section when
sending NS RRsets in the authority section, unless it's a referral.  if we
can't assume iteration restart, then we have to keep sending these A/AAAA's.

---

> Date: Sun, 5 Jul 2009 14:37:06 +0100
> 
> Ah, hold on. I'm talking about requests to the child, where the child
> returns unsolicited NS records and associated A/AAAA/RRSIG records, for
> only for positive authoritative responses, i.e. not for referrals or
> NxDomain/ NoData responses ).

it's not just BIND.  a close re-reading of RFC 2308 seems indicated here.

> The parent will already have provided complete (unsigned) glue where

yes, and the fact that it's unsigned in the parent, is one of the reasons
it has to be sent by the child.

---

From: Matthew Dempsky <[email-masked]>
Date: Sun, 5 Jul 2009 12:22:56 -0700

On Sun, Jul 5, 2009 at 10:18 AM, Paul Vixie<[email-masked]> wrote:
> power to overwrite them.

It also provides zones a way to lessen their dependence on the root
and TLD name servers.  E.g., if www.isc.org is resolved by a cache at
least once every ~12 hours, the cache only has to contact the root and
.org name servers on the first lookup.  Every www.isc.org query
response includes new NS and A/AAAA records with fresh TTLs that the
cache can hold onto for another 12 hours.

P.S. This is at least the third time in recent history that I've had
to send mail to namedroppers multiple times because it's rejecting
mail from Google.

---

From: Florian Weimer <[email-masked]>
Date: Sun, 05 Jul 2009 21:48:15 +0200

> cache can hold onto for another 12 hours.

Any resolver which does this is buggy in the sense that it requires
manual cache flushes from time to time.

---

From: Matthew Dempsky <[email-masked]>
Date: Sun, 5 Jul 2009 13:28:55 -0700

> manual cache flushes from time to time.

Why?  If a zone changes name servers, they have to continue
maintaining the old name servers for a while anyway, which includes
updating the NS and A/AAAA records that the old name servers publish.

---

From: Florian Weimer <[email-masked]>
Date: Sun, 05 Jul 2009 22:43:06 +0200

> updating the NS and A/AAAA records that the old name servers publish.

People don't do that when changing name servers.  Servers to which the
zone isn't delegated anymore keep publishing stale data.

---

From: Matthew Dempsky <[email-masked]>
Date: Sun, 5 Jul 2009 13:56:07 -0700

> zone isn't delegated anymore keep publishing stale data.

If we need to support people who won't properly handle how to
transition their name servers, then yes, we should follow Paul's
suggestion and have name servers stop including NS records in
authoritative answers by default.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 05 Jul 2009 21:44:17 +0000

> Date: Sun, 5 Jul 2009 12:22:56 -0700
> From: Matthew Dempsky <[email-masked]>
> 
> ...  E.g., if www.isc.org is resolved by a cache at least once every ~12
> hours, the cache only has to contact the root and .org name servers on
> the first lookup.  Every www.isc.org query response includes new NS and
> A/AAAA records with fresh TTLs that the cache can hold onto for another
> 12 hours.

interestingly, this turns into an optimization opportunity in a caching
recursive nameserver.  if a replacement ns rrset is the same as what's in
cache, it can be cheaper to just update the cache ttl than to replace the
rrset in cache.

> P.S. This is at least the third time in recent history that I've had to
> send mail to namedroppers multiple times because it's rejecting mail from
> Google.

google's mail service is abuse-prone and highly scalable.  any scalable
free service will be abuse-prone, and the providers of such services are
practicing a form of the "chemical polluter business model".  if you want
your mail to get through, then send it from a better neighborhood.  for a
list of same, see <http://www.vix.com/personalcolo/>.  i do not blame the
operators of the namedroppers@ mailing list server for periodically
rejecting all mail from google.  i do it here, it's practical self defense.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 05 Jul 2009 21:57:56 +0000

> Date: Sun, 5 Jul 2009 22:28:22 +0100
> 
> I strongly suspect (without having done any testing) that most/all
> resolvers will just accept the child NS records and not refresh from the
> parent.

yes.  that's correct behaviour.  but perhaps not optimal in every situation.

> I can see there is an argument that this is incorrect though. Delegation
> should be bounded in time, so that where a zone is forcibly transferred
> from one owner to another, the new owner has an assurance that after the
> parent TTL has expired, only the new zone data will be used by resolvers.

in my own private (non-BIND) recursive nameserver, i implemented full-chain
TTL checking on every cache reference.  so if the delegation of VIX.COM from
COM had a TTL of 600 seconds, and the delegation of COM from the root zone
had a TTL of 700 seconds, but all data in the VIX.COM zone including the
apex NS RRset has a TTL of 800 seconds, then i do a partial iteration restart
at VIX.COM every 600 seconds, and a partial iteration restart of COM every
700 seconds, in addition to normal response processing for VIX.COM (updating
TTL when an unchanged NS RRset arrives from a VIX.COM server, or replacing it
if a changed one arrives; discarding expired data; and restarting iteration
if the apex NS RRset expires.)  if during a partial iteration restart i find
that the parent no longer knows about the child, i purge all cached data at
or below that delegation point.  if during partial iteration restart i find
that the parent is still delegating the child to the same servers, i update
the "delegation-chain TTL" and continue.  if it's to different servers then
i update the delegation-chain TTL and also follow it to one of the child zone
servers to update the apex NS RRset.

if everybody did this, then we could stamp out a fair bit of misconfiguration
of zones, and also stop a any eCrime that depends on high cached TTLs lasting
longer than a zone's cancellation by a registrar's abuse desk.  as you can
see it's easier to code it than to write it up as an RFC.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 06 Jul 2009 09:42:17 +1000

The NS RRset is returned with authoritative answers because
	you have delegations where the set of authoritative servers
	for the child zone is a super set of the authoritative
	servers for the parent zone.  With such configurations you
	never learn the NS RRset for the child zone unless you
	include them in the responses from the common subset of
	servers.  The additional servers for the child zone almost
	never get queried.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Mon, 06 Jul 2009 09:57:40 +1000

> zone isn't delegated anymore keep publishing stale data.

And if parent zones administrators did the correct thing and not
process changes to NS RRsets until both the old and new servers are
serving the NS RRset being requested to be added this stupid practice
would just ceases to be a issue.

You just need to make the old master be a slave of the new master
and the zone contents will just transfer to all the other old slaves.
This isn't rocket science.  This was how zone transfers were done
originally.

We need to put operational correctness back into DNS operations.
The race to be "fastest" has resulted in a badly managed/unmanaged
system.  There are no checks and balances anymore.

Mark

---

From: Matthew Dempsky <[email-masked]>
Date: Sun, 5 Jul 2009 16:55:33 -0700

On Sun, Jul 5, 2009 at 4:42 PM, Mark Andrews<[email-masked]> wrote:
>        servers for the parent zone.

Does this happen in practice?  It doesn't seem like a very interesting
use case to me, but maybe I'm not thinking creatively enough.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 06 Jul 2009 00:49:53 +0000

> Date: Sun, 5 Jul 2009 16:55:33 -0700
> > The NS RRset is returned with authoritative answers because you have
> > delegations where the set of authoritative servers for the child zone
> > is a super set of the authoritative servers for the parent zone.
> 

yes, it used to be fairly common, and still is, on non-vanity zones.

---

From: Matthew Dempsky <[email-masked]>
Date: Sun, 5 Jul 2009 23:50:12 -0700

On Sun, Jul 5, 2009 at 11:37 PM, George
Barwood<[email-masked]> wrote:
> Do we know why anyone would not list all the name servers at the parent?

Mark's talking about configurations like:

    example.dom. NS ns1.example.dom.
    example.dom. NS ns2.example.dom.

    sub.example.dom. NS ns1.example.dom.
    sub.example.dom. NS ns2.example.dom.
    sub.example.dom. NS ns.sub.example.dom.

If a cache wants to resolve www.sub.example.dom, it'll first learn the
delegation for example.dom, but then either ns[12].example.dom will
answer authoritatively for the sub.example.dom zone.  Without the NS
records, it would never learn it can also query ns.sub.example.dom.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 06 Jul 2009 17:01:03 +1000

In message <7AA80B7277CF49D6AA8E4513F093C608@localhost>, "George Barwood" write
s:
> From: "Mark Andrews" <[email-masked]>
>  
> Ah, ok. 
> RFC 1034 4.2.1 does say
> "Since the cuts are between nodes, these RRs are NOT part of the 
> authoritative data of the zone, and should be exactly the same as the 
> corresponding RRs in the top node of the subzone."
> 

	This has nothing to do with problem
 
> I suppose the parent or registrar may impose limits, but going against 
> the standard seems a doubtful way to proceed ( instead unreasonable 
> limits should be increased ).
> 
> I suggest that BIND might at least provide a configuration option
> that disables the sending of unsolicited child NS records
> ( maybe it already does... I'm not very familiar with BIND ).

	George please re-read the description of the problem.

	Say you have example.com and child.example.com delegated
	to these servers.

	example.com NS ns1.example.com 
	example.com NS ns2.example.com 

	child.example.com NS ns1.example.com 
	child.example.com NS ns2.example.com 
	child.example.com NS ns1.child.example.com 
	child.example.com NS ns2.child.example.com 

	You then ask for MX child.example.com, then AAAA child.example.com
	and then A child.example.com.

	If you don't return the NS RRset then:
	Which nameservers will be used for the MX query.
	Which nameservers will be used for the AAAA query.
	Which nameservers will be used for the A query.
	
	If you do return the NS RRset then:
	Which nameservers will be used for the MX query.
	Which nameservers will be used for the AAAA query.
	Which nameservers will be used for the A query.

	Such configuration are reasonably common.

	Mark

---

From: "George Barwood" <[email-masked]>
Date: Mon, 6 Jul 2009 08:32:44 +0100

----- Original Message ----- 

> child.example.com NS ns2.child.example.com 

Ok, I consider this to be a mis-configuration, since it's a "partial" delegation.

Someone moving this zone to another name server vendor will find a change
in behavior.

Maybe BIND could send the NS RRset only in these cases?

I suggest declaring such configurations incorrect (or at least inadvisable), 
while maintaining support for them in BIND, and advising BIND customers 
that with DNSSEC large responses subject to truncation can occur for such 
configurations.
¶‹§²æìr¸›zÇ§u©ž²Æ zÚ'jg®Šiz»+z«ž²Ú)²'~ŠàÂ+a¶°¢·nžË›±Êâmè§jÈ§‚W¥Šwš²Ø^™ë,j{[¡ÜšÈb½èm¶Ÿÿ¢›"z×è®åŠËlþv¦yÚè¦—«³

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 6 Jul 2009 12:04:49 +0200

On Mon, Jul 06, 2009 at 09:57:40AM +1000,
 Mark Andrews <[email-masked]> wrote 
 a message of 39 lines which said:

> serving the NS RRset being requested to be added this stupid
> practice would just ceases to be a issue.

We (the .FR managers) are often regarded as specially anal-retentive
because a successful technical check is required before any change
(not only the creation, any technical change) in the delegation.

Nevertheless, we do not perform this test, so I doubt anyone actually
does it.

> and the zone contents will just transfer to all the other old
> slaves.  This isn't rocket science.

But the problem is not entirely technical. It is partly a question of
scale (imagine running a DNS hoster with 100,000 zones, all from your
database, how many changes of your ACL - for ingoing transfers - and
of your authoritative configuration - for outgoing transfers?).

But it is mostly a matter of business. If you mandate such a rule, any
DNS hoster will be able to delay the departure of a customer at
will. A transfer from one hoster to another MUST NOT depend on the
good will of the "loser".

(We will have simlilar problems with DNSSEC, with DNS hosters refusing
to give the private key to a leaving customer.)

---

From: "Antoin Verschuren" <[email-masked]>
Date: Mon, 6 Jul 2009 12:46:44 +0200

LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb3duZXItbmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9yZyBbbWFpbHRvOm93bmVyLQ0KPiBuYW1lZHJvcHBlcnNAb3BzLmlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyayBBbmRyZXdzDQo+IFN1YmplY3Q6IFJlOiBbZG5zZXh0XSBOYW1lIHNlcnZlciBhZ2lsaXR5IHdpdGggRE5TU0VDDQo+IA0KPiBBbmQgaWYgcGFyZW50IHpvbmVzIGFkbWluaXN0cmF0b3JzIGRpZCB0aGUgY29ycmVjdCB0aGluZyBhbmQgbm90DQo+IHByb2Nlc3MgY2hhbmdlcyB0byBOUyBSUnNldHMgdW50aWwgYm90aCB0aGUgb2xkIGFuZCBuZXcgc2VydmVycyBhcmUNCj4gc2VydmluZyB0aGUgTlMgUlJzZXQgYmVpbmcgcmVxdWVzdGVkIHRvIGJlIGFkZGVkIHRoaXMgc3R1cGlkIHByYWN0aWNlDQo+IHdvdWxkIGp1c3QgY2Vhc2VzIHRvIGJlIGEgaXNzdWUuDQoNClRoaXMgd291bGQgd29yayB3ZWxsIGlmIGFsbCBkcml2ZXJzIHdvdWxkIGJlIGNhci1tZWNoYW5pY3MgYXMgd2VsbC4NCkJ1dCBsZXQncyBmYWNlIGl0LCBub3QgYWxsIGRucy1vcGVyYXRvcnMgYXJlIGRucyBleHBlcnRzIGFueW1vcmUuDQpJZiB0aGlzIGlzbid0IGF1dG9tYXRlZCBpbiBkZXBsb3llZCBzb2Z0d2FyZSwgd2l0aCBhIHNpbXBsZSBlbm91Z2ggYnV0dG9uIGZvciB0aGUgb3BlcmF0b3IgdG8gcHVzaCBvbiwgaGUncyBub3QgY2FwYWJsZSBvZiBkb2luZyB0aGlzLg0KTW90aGVyLWluLWxhd3MgaGF2ZSBiZWNvbWUgZG9tYWluIG93bmVycy4NCldlIG5lZWQgdG8gZ2l2ZSB0aGVtIHRoZSB0b29scyB0byBvcGVyYXRlIHRoZWlyIHpvbmVzIHNhZmVseS4NCg0KV2Ugc3RpbGwgaGF2ZSB0aGUgcnVsZSBpbiBvdXIgcG9saWN5IHRoYXQgbG9zaW5nIEROUy1vcGVyYXRvcnMgc2hvdWxkIHJ1biBzZWNvbmRhcnkgZm9yIGEgd2hpbGUgYWZ0ZXIgYSB0cmFuc2Zlci4gQnV0IGluIHByYWN0aWNlLCBzaW5jZSAic2VjdXJpdHkgcnVsZXMiIGRvbid0IGFsbG93IEFYRlIgdHJhbnNmZXJzIGFueW1vcmUsIG5vYm9keSBpcyBhYmxlIHRvIGNvbmZvcm0gdG8gdGhlc2UgYmVzdCBwcmFjdGljZXMgYW55bW9yZS4gSXQncyBzaW1wbHkgbm90IHNjYWxhYmxlIGFueW1vcmUgdG8gaGF2ZSBhIG1hbnkgdG8gbWFueSByZWxhdGlvbnNoaXAgYmV0d2VlbiBETlMtb3BlcmF0b3JzIHRvIGFsbG93IGZvciBhIHNtb290aCB0cmFuc2l0aW9uLg0KDQpBbmQgYXMgSSd2ZSBkZW1vbnN0cmF0ZWQsIHdpdGggRE5TU0VDLCB3ZSBvbmx5IGhhdmUgYSBjaG9pY2UgYmV0d2VlbiBjaGFuZ2luZyByZXNvbHZlciBiZWhhdmlvciwgb3IgY2xlYXJseSBkb2N1bWVudCBhbmQgZGVwbG95IGEgY29tcGxleCB0cmFuc2l0aW9uIHByb2Nlc3MgdGhhdCBjb25mbGljdHMgd2l0aCBidXNpbmVzcyBpbnRlcmVzdHMuIEkgZG8gaGF2ZSBzb21lIGZhaXRoIGluIGRvY3VtZW50aW5nLCBidXQgZ2V0dGluZyB0aGlzIGRlcGxveWVkIGluIGFsbCB0aGUgY29tbWVyY2lhbGx5IGRyaXZlbiBub24tdGVjaG5pY2FsIGRvbWFpbiBwb3J0Zm9saW8gbWFuYWdlbWVudCBwYWNrYWdlcyBpcyBhIGJhdHRsZSBJJ20gYWZyYWlkIHdlJ3JlIGdvaW5nIHRvIGxvc2UuDQpNYW5kYXRpbmcgdGhpcyBpbiBwb2xpY3kgYnkgYSBwYXJlbnQgd2l0aG91dCB0aGUgcHJvcGVyIHRvb2xzIG9yIGV4cGVydGlzZSBpbiB0aGUgY3VycmVudCBkZXBsb3llZCBiYXNlIG9mIGRucy1vcGVyYXRvcnMgd291bGQgbWVhbiBzdWljaWRlIGZvciBhIHJlZ2lzdHJ5LCBzbyB0aGV5IGNob3NlIG5vdCB0byBkbyB0aGlzLg0KDQpTbyBpbnN0ZWFkIG9mIHN0aWNraW5nIG91ciBoZWFkcyBpbnRvIHRoZSBzYW5kLCBsZXQncyBjb21lIHVwIHdpdGggYSBzb2x1dGlvbiB0aGF0IGRvZXMgd29yayBpbiB0aGUgcmVhbCB3b3JsZC4NCg0KQW50b2luIFZlcnNjaHVyZW4NCg0KVGVjaG5pY2FsIFBvbGljeSBBZHZpc29yIFNJRE4NClV0cmVjaHRzZXdlZyAzMTAsIFBPIEJveCA1MDIyLCA2ODAyIEVBIEFybmhlbSwgVGhlIE5ldGhlcmxhbmRzDQoNClA6ICszMSAyNiAzNTI1NTAwICBGOiArMzEgMjYgMzUyNTUwNSAgTTogKzMxIDYgMjMzNjg5NzANCm1haWx0bzphbnRvaW4udmVyc2NodXJlbkBzaWRuLm5sICB4bXBwOmFudG9pbkBqYWJiZXIuc2lkbi5ubCAgaHR0cDovL3d3dy5zaWRuLm5sLw0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IDkuNi4zIChCdWlsZCAzMDE3KQ0KDQp3c0JWQXdVQlNsSFdGRHFIck04ODNBZ25BUWdvdlFnQTNsQ3oyaU9scmlqc052dEp1UnloNnZPY29Xa0JCRmZyDQphVEdyZWcwZUJsNkp2WVVmQm8zR1FTMHZzTVdkbGIvODF2ZXg5K2xqU3QxRGlxejJwRXp0N3Z3czRyT2FZL2w0DQpzc3dET3d5cXBUZjV6OWFYV2FzdmZoRWJQWko2dkJqaWVtZXdMUEFRZEwwTE1VbnFET0NqemV6ck9VdmRtTTBQDQoyVGRlUytkSFYrd21RWm4zei8zR1hzWjRrY0tHWGpmTUk1S3NmUlNWK3RGcnNWMVVlUzVEZksraDNDcDU1UmlKDQpTcSt4UXZlRElrTDlKUnJodzBxUHBva3NRZCtjSndaQlZnVDVKdXhabEZXSUZuNEtQY25NakZoNXpSOUdka2JkDQpFUUREMWt2Vll1MTNhT0piUzlMTFRReFJnUndrZUUvS2VhSktKTkNjSFR6ZGdQc1N1UmhsTVE9PQ0KPXRNcEUNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0KDQo=--to unsubscribe send a message to [email-masked] withthe word 'unsubscribe' in a single line as the message text body.archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 06 Jul 2009 15:16:18 +0000

> Date: Mon, 6 Jul 2009 07:37:15 +0100
> 

registrars and registries are more painful to deal with, for creating and
maintaining nameserver names and then updating parent-zone delegations to
use or not use those names, compared to just putting the data into one's
own zone file and reloading the primary master server.

in other words, human nature is the reason for most deviations between the
parent's delegation and the child's apex.  and as we have all discovered by
now, bugs in human nature can't be patched, they have to be worked around.

> limits should be increased ).

the standard says "should" not "must".  and i agree with the "should" but
since it's not a "must", correct operation must ensue even when the advice
isn't followed.

> I suggest that BIND might at least provide a configuration option that
> disables the sending of unsolicited child NS records ( maybe it already
> does... I'm not very familiar with BIND ).

as i said earlier in this thread, this isn't BIND-specific.

---

From: Chris Hills <[email-masked]>
Date: Mon, 06 Jul 2009 20:11:49 +0200

> use case to me, but maybe I'm not thinking creatively enough.

To give an example.

There may be an operational limit on the number of glue records that may 
be added to the parent zone, however the end-user has more servers 
available, with a diverse range of addresses. A recursor may find one of 
the addresses to be more preferable than the others.

For a couple of my zones there are glue records for only three (using 
three different TLDs), wheras the zone is available on 9 servers in total.

Example in point: 2.2.d.d.8.d.6.1.1.0.0.2.ip6.arpa.

(Pretend for now that it is reachable using an ipv6-only resolver. In 
practice, at least ipv4 connectivity is required.)

---

From: Edward Lewis <[email-masked]>
Date: Mon, 6 Jul 2009 14:56:35 -0400

>use case to me, but maybe I'm not thinking creatively enough.

Yes.

Add a name server.  Watch the traffic rate grow, gain confidence. 
Tell the parent you added it. Parent adds name server to it's DNS. 
If this weren't "allowed" you would have to get parent and child to 
do a simultaneous change.

Fat chance of that.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Matthew Dempsky <[email-masked]>
Date: Mon, 6 Jul 2009 12:42:48 -0700

On Mon, Jul 6, 2009 at 11:56 AM, Edward Lewis<[email-masked]> wrote:
> Add a name server.  Watch the traffic rate grow, gain confidence. Tell the
> parent you added it. Parent adds name server to it's DNS. If this weren't
> "allowed" you would have to get parent and child to do a simultaneous
> change.

This isn't the scenario I understood we were discussing.

---

From: Michael Graff <[email-masked]>
Date: Mon, 06 Jul 2009 15:52:37 -0500

George Barwood wrote:
> (4) I still think a protocol extension to allow large responses to be sent using 
> short UDP packets may be advisable. I'm concerned about relying on TCP.

Every time I see someone propose implementing TCP using UDP, I worry.
TCP has a long history, and includes features like flow-control, and is
well understood by filtering engines, etc.  Anything we do to re-write
parts of it will eventually run into the same issues, and we'll end up
with TCP as it was 15 years ago.  And we'll have firewalls which try to
be overly-clever and change the contents of the DNS packets returned, or
just drop them as strange and broken.  Or decide to re-assemble them to
analyze them after.

- --Michael

---

From: Paul Vixie <[email-masked]>
Date: Mon, 06 Jul 2009 21:26:10 +0000

> Date: Mon, 6 Jul 2009 12:42:48 -0700
> > Add a name server. Watch the traffic rate grow, gain confidence. Tell
> > the parent you added it. Parent adds name server to it's DNS. If this
> > weren't "allowed" you would have to get parent and child to do a
> > simultaneous change.
> 

it's an in-scope and compatible variation on the theme we were discussing.

---

From: Matthew Dempsky <[email-masked]>
Date: Mon, 6 Jul 2009 14:40:57 -0700

> it's an in-scope and compatible variation on the theme we were discussing.

I asked "does X actually happen?" and I was given the answer "yes, Y
happens all the time."  I don't mind discussing Y too, but it doesn't
answer my question.

---

From: "George Barwood" <[email-masked]>
Date: Mon, 6 Jul 2009 23:36:03 +0100

----- Original Message ----- 
From: "Michael Graff" <[email-masked]>

> Every time I see someone propose implementing TCP using UDP, I worry.

Well I don't think that is what is proposed. What I think best is to mimic
the current UDP traffic characteristics, with a modest increase in the 
number
of packets, and a moderate increase in packet size, below the ethernet MTU
( and with the option to stay below 512 bytes ).

I don't think that is worrisome, given that the UDP capability of the 
infrastructure
is hugely in excess of that needed for legitimate traffic.

I don't have a deep understanding of TCP, but the little I do know worries 
me.
Isn't it very vulnerable to denial of service attacks? Will it not be almost 
trivial
to take down the TLD's TCP service?

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Jul 2009 10:39:11 +1000

> Nevertheless, we do not perform this test, so I doubt anyone actually

But the lack of the check is what has got us into this silly position.
We should be encouraging best current practice rather than saying
it shouldn't be done.

> of your authoritative configuration - for outgoing transfers?).

Which can all be automated.
 
> good will of the "loser".

Then have a option that says something like "By proceeding with
this transfer you acknowledge that there will be disruptions to the
serving of this zone."

People need to be made aware that they are not following best current
pratice.
 
> to give the private key to a leaving customer.)

You don't need to give the private key.  You just need to the DNSKEY
RRset signed with it to enable a smooth transition.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Jul 2009 11:11:05 +1000

In message <[email-masked]>, "Antoin
 Verschuren" writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:owner-
> > [email-masked]] On Behalf Of Mark Andrews
> This would work well if all drivers would be car-mechanics as well.
> But let's face it, not all dns-operators are dns experts anymore.
> If this isn't automated in deployed software, with a simple enough
> button for the operator to push on, he's not capable of doing this.
> Mother-in-laws have become domain owners.
> We need to give them the tools to operate their zones safely.

Most of them out source the operation of the DNS service.  For those
that don't this really isn't a issue.
 
> We still have the rule in our policy that losing DNS-operators
> should run secondary for a while after a transfer. But in practice,
> since "security rules" don't allow AXFR transfers anymore, nobody
> is able to conform to these best practices anymore. It's simply not
> scalable anymore to have a many to many relationship between
> DNS-operators to allow for a smooth transition.

"security rules" which have no justifiable reason for existing
99.99% of the time (general blanket on AXFR) and which have no
reason to exist at all when a zone is being transfered.

This is the tail wagging the dog.

> And as I've demonstrated, with DNSSEC, we only have a choice
> between changing resolver behavior, or clearly document and deploy
> a complex transition process that conflicts with business interests.
> I do have some faith in documenting, but getting this deployed in
> all the commercially driven non-technical domain portfolio management
> packages is a battle I'm afraid we're going to lose.
> Mandating this in policy by a parent without the proper tools or
> expertise in the current deployed base of dns-operators would mean
> suicide for a registry, so they chose not to do this.

The tools to do this have existed for 20 plus years.  Just about
every nameserver supports AXFR.  Those that don't directly have
toolkits that do.

> So instead of sticking our heads into the sand, let's come up
> with a solution that does work in the real world.

The companies that host the DNS services are being paid money to
run and manage the DNS operations for their clients.  Part of that
is managing transfers of domains to and from them.  All we are
asking them to do is what they have been paid to do.  It is a
cost of business.

Mark
 
> Antoin Verschuren
> 
> Technical Policy Advisor SIDN
> Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands
> 
> P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
> mailto:[email-masked]  xmpp:[email-masked]  http://www.sidn.nl/
> -----BEGIN PGP SIGNATURE-----
> Version: 9.6.3 (Build 3017)
> 
> wsBVAwUBSlHWFDqHrM883AgnAQgovQgA3lCz2iOlrijsNvtJuRyh6vOcoWkBBFfr
> aTGreg0eBl6JvYUfBo3GQS0vsMWdlb/81vex9+ljSt1Diqz2pEzt7vws4rOaY/l4
> sswDOwyqpTf5z9aXWasvfhEbPZJ6vBjiemewLPAQdL0LMUnqDOCjzezrOUvdmM0P
> 2TdeS+dHV+wmQZn3z/3GXsZ4kcKGXjfMI5KsfRSV+tFrsV1UeS5DfK+h3Cp55RiJ
> Sq+xQveDIkL9JRrhw0qPpoksQd+cJwZBVgT5JuxZlFWIFn4KPcnMjFh5zR9Gdkbd
> EQDD1kvVYu13aOJbS9LLTQxRgRwkeE/KeaJKJNCcHTzdgPsSuRhlMQ==
> =tMpE
> -----END PGP SIGNATURE-----
>

---

From: Edward Lewis <[email-masked]>
Date: Tue, 7 Jul 2009 09:17:52 -0400

>Well I don't think that is what is proposed.

Pretty much (replacing UDP with TCP) is what you proposed, once you 
get through all of the error cases it'll be much like TCP.  I've seen 
this suggestion over 20 years of time, it's a fool's errand.

---

From: "George Barwood" <[email-masked]>
Date: Tue, 7 Jul 2009 18:43:22 +0100

----- Original Message ----- 
From: "Edward Lewis" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "IETF DNSEXT WG" <[email-masked]>; "Michael Graff" 
<[email-masked]>
Sent: Tuesday, July 07, 2009 2:17 PM
Subject: Re: [dnsext] Name server agility with DNSSEC

> Pretty much (replacing UDP with TCP) is what you proposed, once you get 
> through all of the error cases it'll be much like TCP.  I've seen this 
> suggestion over 20 years of time, it's a fool's errand.

Err.. did you read the proposal? ( EDNS Page Option to handle large 
responses,
http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg01278.html )

It's nothing like TCP, the server has no state ( that's important, it makes 
it simple and cannot consume server resources ). There is the complication 
that the server is required to maintain a zone or more specific RRset 
version. But that's the only complication, and it solves many problems at 
one go:
(1) TCP fallback is never required.
(2) IP fragmentation ( which often doesn't work and has security and 
performance problems ) is avoided.
(3) Middleboxes that stop DNS packets  > 512 bytes are catered for.

TCP fallback will I think make DNSSEC horribly insecure/unreliable when 
people start fetching DNSKEY RRsets in earnest. What's especially nasty is 
the modal behavior during KSK rollover, as the ethernet MTU is exceeded.

Is no-one else concerned about this? I think Paul Vixie is looking at an 
alternative to TCP, but if it has server state, I'm doubtful whether it is a 
good way forward.

If experts think it's not a problem, and can explain why, then I will accept 
that...
But there seems to be a spirit of resignation, "it's not going to work and 
no one cares".

---

From: Michael Graff <[email-masked]>
Date: Tue, 07 Jul 2009 14:12:34 -0500

> (1) TCP fallback is never required.

A common belief is that TCP fallback is a very bad thing.  And yet there
are web servers which handle multi-thousands of TCP connections/sec and
don't fall down flat.

The fact that DNS servers today are where web servers were 10 years ago
is not really a valid argument against using TCP.

> performance problems ) is avoided.

I don't buy the argument that fragmentation is broken, only that people
choose to break it.  Fragmentation is not in and of itself evil, and
while there have been many fragmentation attacks, the mitigation methods
in place today largely make them ineffective.  Fragmentation being
blocked is a major problem, but once again, breaking that is a choice.

> (3) Middleboxes that stop DNS packets  > 512 bytes are catered for.

By letting them remain broken.

> alternative to TCP, but if it has server state, I'm doubtful whether it is a 

If a middleware box is capturing UDP port 53, why do we think they will
let something not-TCP and not-UDP through at all?

Wouldn't running DNS on port 54 as well as 53 "fix" this problem just as
effectively, if the goal is to prevent middleware boxes from mangling?
After all, both solutions (your UDP-page option and running on a
differen port) require both ends of a conversation to change protocols,
and the port one is actually easier in most cases:  just treat port 54
as another server.  That is, 10.1.1.2:53 and 10.1.1.99:53 are treated no
differently than 10.1.1.2:53 and 10.1.1.2:54

- --Michael

---

From: Paul Vixie <[email-masked]>
Date: Tue, 07 Jul 2009 21:09:03 +0000

> Date: Tue, 07 Jul 2009 14:12:34 -0500
> From: Michael Graff <[email-masked]>
> ...
> ...

first, see <http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.html>.

second, the choice to break fragmentation is almost never a conscious one
since the ill effects are almost never immediate and almost never local.

so, fixing fragmentation is the ultimate "pushing on a rope" exercise.

---

From: Michael Graff <[email-masked]>
Date: Tue, 07 Jul 2009 16:26:36 -0500

> first, see <http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.html>.

Interesting read, even if 14+ years old now.

> since the ill effects are almost never immediate and almost never local.

It seems to me that the most common cause of brokenness is either in one
 of three cases.  Please correct me if I'm wrong.

(1)  It is accidental, in that there is a device that is broken very
near to the end user.  These will be fixed as support calls increase.  A
list of things that are broken for DNSSEC and published on a web site
where search engines can find will help here greatly.  People will see
"this device breaks DNSSEC, and this is bad because you'll need to buy
another in 5 years if you buy this thing now" and buy something else.
If not, they'll buy a new one in 5 years.

(2)  It is purposeful, in that it is very intentionally broken.  This is
a captured environment, like inside a hotel.  Whatever we do, people who
intentionally break DNS to ensure they are the only ones queried will
continue to do so, since not doing this means things get, at best, more
difficult: people get odd timeouts when they have not clicked "I'll pay
$12/day" yet, or the web sites themselves need to be what is captured,
which is harder because they saw DNS as a choke-point.  It is not an
advantage that they can no longer muck with DNS, but it is an advantage
to ensure an end user cannot bypass their mucking.

(3)  A restricted environment, like inside a corporate firewall or in an
ISP that demands you use THEIR services.  DNSSEC needs adoption for this
to change, but it will change.  Catch 22, perhaps, but even then, the
answer is available to DNSSEC users:  allow fragments only to a
recursive resolver, not to the whole company.

- --Michael

---

From: Paul Vixie <[email-masked]>
Date: Tue, 07 Jul 2009 21:56:38 +0000

> Date: Tue, 07 Jul 2009 16:26:36 -0500

i was an assistant to the authors and though i did not work on this with
them i participated in some lunchtime discussions about it.  the result of
this work was PMTUD, which as we now know, still does not fix the problem.

> near to the end user.  These will be fixed as support calls increase. ...

the support calls will almost never reach the right destination, and in the
rare case where they do, the response will be "but it's always worked this
way before, you must be trying something new, you should downgrade to a
working version of your software."  the successful way to add a new app to
an internet containing OPN's (other people's networks) is what "bittorrent"
did-- leverage the things that aren't blocked and/or can't be blocked.  i'm
pretty sure DNS will end up as an XML profile carried over HTTPS some day.

> a captured environment, like inside a hotel.  ...

in this sense, hotels aren't part of "the internet", or if they are, then
the internet is no longer a "network of networks" but rather a "network of
internet access clouds".  there are some hard choices to be made by the IAB
and by each of us as to whether we want to try to deliver new applications
into such networks, or whether we think that the "real internet" is enough
of a playground/marketplace for our ideas/products.

> answer is available to DNSSEC users: allow fragments only to a recursive
> resolver, not to the whole company.

even in a small 35-person technology company it's often hard to get changes
made to the corporate firewall without a lot of meetings and debates.  now
i'm trying to imagine doing this in a fortune 500 company, and i just can't.

consider this:

ipfw2, which is a mature and stable and reliable host based firewall found
on freebsd and used extensively, does not have any way to tie fragments
together by their <IP SRC,IP ID> so that the non-leading fragments (which
lack UDP headers and therefore a UDP port number) can share fate (allow or
reject) with the leading fragment.  this means every ipfw2 configuration in
the universe that has a rule like "add allow udp from any to any 53" or
similar, breaks fragmentation.  and because DNS didn't generate fragments
for its first few decades, these configurations are considered correct by
their operators.  and ipfw2 is far from the only firewall with those types
of limitations.

if a firewall allows fate-binding among <IP SRC, IP ID> then it's a matter
of convincing the firewall operator to turn this on.  hopefully they'll
agree and even more hopefully they will test it before declaring victory,
but more likely they'll say "not my problem, use TCP/53, that works fine"
or if they make a change it'll fsck things up and make that corner of the
internet less stable for the period of time it takes to operationalize the
new policy.  and then some clown will get back from vacation or restore
from a backup tape and revert to the previous behaviour.  lather, rinse,
repeat.

if a firewall doesn't allow fate-binding among <IP SRC, IP ID> then the
operator will have to either upgrade, or switch to new firewall technology,
or just allow all fragments.  upgrades or technology switches will require
investment in training and testing, which are very difficult to budget when
the underlying problem (EDNS doesn't work) is so terribly obscure and only
affects potential applications (some of our users would like DNSSEC to work
some day when DNSSEC is deployed).  allowing all fragments requires either
that there be no limit as to what internal hosts can receive/transmit same
(which could become a back door for bad guys to use) or that the recursive
name server addresses be hardcoded (which leads to trouble when more are
added or when existing ones are renumbered.)

the systemic inertia of "fragmentation not working" is extraordinarily high
compared to any immediate benefit of "EDNS is working".  i did the math and
found that EDNS's dependence upon fragmentation was one of my great errors
in judgement.  had we used SCTP instead, we'd be about as far along as we
are now, but with shorter to go in order to get finished.

---

From: Michael Graff <[email-masked]>
Date: Tue, 07 Jul 2009 17:15:18 -0500

I suppose a lot of this is assumptions.

I assume that, within a corporate cloud, DNSSEC may never be used by end
users, or the uptake will be very, very small.  If I am wrong here,
fragments will become important to deal with.  If they cannot be,
internal pressures pushing for DNSSEC will push the fragment issue.

I assume that, within a corporate cloud, a corporate resolver may have
fragments allowed to it, and from it to end users.  However, the world
to end users is not likely to change in all but the most enlightened
companies.  DNSSEC will work, using smart or dumb stub resolvers, in
this case.

I also assume that since DNSSEC is in the press, fortune 500 companies
that never even knew what DNS was other than the lawyers had to once in
a while ask for this strange thing called a "domain" to be registered to
protect some trademark or other, these same companies are suddenly
taking notice that things are different.  At least their IT departments are.

Of all the companies out there which should be screaming most loudly
over DNSSEC and fragmentation, the US Government seems oddly quiet on
the issue.  I'd think if anyone meets my definition of overly paranoid,
they would.  How are they adapting to a world where fragments are a
matter of course?

- --Michael

---

From: "George Barwood" <[email-masked]>
Date: Tue, 7 Jul 2009 23:25:53 +0100

Michael,

I admit I'm mainly going on instinct here.

But isn't the conservative, safe option to rely on existing transport?

Which is 512 byte UDP packets, and small amplification factors.

Or at least define a standard way of using the existing transport, in case 
it is needed.

I'm not sure which attack concerns me most, but I think it would be a DDoS 
attack against TCP that requests a large response after establishing the 
connection and then either stops sending ACKS or fiddles with the congestion 
protocol, leading to huge buffering requirements on the servers. Well, 
something roughly like that.

The other might be amplification attacks, where large UDP packets get 
directed towards the victims computer or network.

These seem bad enough to me, but there are probably much worse, things are 
usually worse than you ever imagined.

My instinct says that changing the lower level traffic pattern is quite 
risky, and I'm against taking risks with DNS infrastructure. It's too easy 
to think we know what we are doing, when really we don't.

Maybe I'm just crazy though... but after all hardening DNS is now an active 
item for the working group, so I don't feel too embarassed bringing it up.

George

----- Original Message ----- 
From: "Michael Graff" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Edward Lewis" <[email-masked]>; "IETF DNSEXT WG" 
<[email-masked]>
Sent: Tuesday, July 07, 2009 8:12 PM
Subject: Re: [dnsext] Name server agility with DNSSEC

> Hash: SHA1
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkpTniIACgkQ+NNi0s9NRJ30ugCeNmLpGZPG9PMKaBaqJpQw8jcp
> TRgAnjNbE/FJVPNerq26NhpOEq0XDlMx
> =HYsP

---

From: Diane Bruce <[email-masked]>
Date: Tue, 7 Jul 2009 18:38:42 -0400

...
> Interesting read, even if 14+ years old now.

You might also read:
http://www.ietf.org/proceedings/06jul/slides/tsvarea-1.pdf
'fragmentation considered very harmful' 2006

Though now way off topic, Fernando Gont is also worth reading.
http://www.gont.com.ar/

- Diane
--
- [email-masked] [email-masked] http://www.db.net/~db

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Jul 2009 11:53:59 +1000

In message <FF168C3DCB5A4EA78304A7DD88244C73@localhost>, "George Barwood" write
> Or at least define a standard way of using the existing transport, in case 

	We did define a standard way (EDNS) to use the existing transport
	(UDP).
 
> something roughly like that.

	Breaking up UDP responses at the application layer doesn't
	address that.  A DoS attack is a DoS attack and will happen
	regardless of what we do at the UDP layer.
 
> directed towards the victims computer or network.

	Breaking up the UDP response at the application layer doesn't
	make this better.  It makes this worse as you have additional
	overhead.
 
> to think we know what we are doing, when really we don't.

	The low level traffic pattern has constantly been changing
	since the DNS was created.  Response sizes have slowly been
	increasing.  We saw that over 10 years ago and EDNS was the
	response to that.  EDNS actually works very well.  It will
	continue to work well as long as we educate vendors when
	we see that they have a defective product.

> item for the working group, so I don't feel too embarassed bringing it up.

	Breaking up the UDP response at the application layer doesn't
	doesn't harden the DNS.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Jul 2009 16:04:40 +1000

In message <[email-masked]>, Paul Vixie writes:
> reject) with the leading fragment.

Which is easy enough to do if the firewall re-assembles the packet
or at least holds the other fragments until the first fragment is
processed.   The NAT code does half of this already by tracking <IP
SRC,IP ID> + outstanding fragment windows.  It just doesn't look
in the re-assembly queue for out of order fragments.

If you want multiple paths to work you don't re-assemble and let
all fragments through.

> this means every ipfw2 configuration in

The alternative is to introduce a firewall friendly fragmentation
method.  Add a IP option which says you understand the new method.
This option get added to the reply packet along with a indication
to use the new method.  When you fragment you wrap the resulting
fragments inside another packet which holds the original upper layer
headers as well as the fragment itself.  This allows NATs and
firewalls to make decisions w/o reassembling.  When the packet
reaches its final destination it is de-encapsulated and is added
to the re-assembly queue.

---

From: "George Barwood" <[email-masked]>
Date: Wed, 8 Jul 2009 07:22:55 +0100

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Michael Graff" <[email-masked]>; "Edward Lewis" <[email-masked]>; 
"IETF DNSEXT WG" <[email-masked]>
Sent: Wednesday, July 08, 2009 2:53 AM
Subject: Re: [dnsext] Name server agility with DNSSEC

> regardless of what we do at the UDP layer.

Breaking up the UDP response reduces/stops fragmentation.
That's one effect.
It also means TCP isn't required where fragmentation fails, which is very 
common above 1500 bytes (according to netalyzer). TCP is subject to DoS, and 
this is inherent to the protocol.

> make this better.  It makes this worse as you have additional

Huh? Currently you can send spoof UDP queries to a.ns.se and generate > 4000 
byte UDP responses. With paging (my suggestion) the responses can be limited 
to 200 bytes, at the discretion of the server, i.e. almost no amplification, 
so an attacker gains little benefit.

---

From: Michael Graff <[email-masked]>
Date: Wed, 08 Jul 2009 01:45:56 -0500

> this is inherent to the protocol.

If it doesn't stop fragmentation, then why bother?

TCP is subject to DoS, but so is UDP.  Servers have to maintain state on
TCP, sure, but they have some control over the size of that state and
the number of connections.

If this were not true, we would not currently have the web.  How is it
that nearly every protocol which uses DNS also uses TCP, but we are so
afraid of using it ourselves?

> so an attacker gains little benefit.

So...  if the server can send as little as 200 bytes, then I assume that
state is stored on the server for when the client asks for the rest of
that 4,000 byte response?  Or is the reply regenerated each time?  I
guess I need to re-read your proposal.

I, for one, don't think we need to reinvent protocols here.  SCTP is
perhaps a good idea since it appears to scale down to something very
close to UDP if desired.  Paginating a UDP response seems like a hack
and is just as likely to be rejected by the very devices you are
attempting to bypass, that of a broken filtering gateway.

I simply fail to understand here why fallback to TCP has suddenly become
so frightening.  Note that for .org, even that 700x increase was still
so low in the noise.  I think it was less than 1000/sec?  Something like
380?  And that was with a TTL on SOA, negative caching, and the DNSKEY
record of 0!

- --Michael

---

From: "George Barwood" <[email-masked]>
Date: Wed, 8 Jul 2009 09:08:49 +0100

----- Original Message ----- 

> guess I need to re-read your proposal.

No state exists on the server, that is the point, yes.
Client says: Send me the first page.
Server: Here it is, bye ( end of transaction, server state returns to 
initial state ).
Client says: Ok, send me the second page.
Server: Ok, here you are. Bye.

The server does have to maintain version information though, so it's not 
100% magic. I haven't thought too much about the implementation details, but 
it's clearly doable. Some kind of clock that increments when the local 
database is updated, stored at some level ( maybe RRset, maybe domain, 
maybe zone, or just globally if updates are infrequent ). The server 
computes the version as it assembles the response, using the largest value 
in the data it references.

> close to UDP if desired.

I haven't studied SCTP closely, but it seems quite similar to TCP, so I 
suspect it will suffer from the same problem inherent in any 
connection-oriented protocol, which will always have state.

> Paginating a UDP response seems like a hack

I don't think there is any evidence for this, it semes unlikely.
The packets are properly formatted, I doubt a gateway would be inspecting 
EDNS option records.

> 380?  And that was with a TTL on SOA, negative caching, and the DNSKEY

It's not frightening until someone mounts an attack.
Unless you happen to consider this possibility...
Servers coping with good faith traffic is not an issue.

Best wishes,
George

---

From: Michael Graff <[email-masked]>
Date: Wed, 08 Jul 2009 04:09:29 -0500

George Barwood wrote:

You say this...

And then you say this:

> 100% magic.

That, to me, is state.  How long would it maintain version information
for?  How is this sufficiently different than maintaining TCP state for
a short time?

> The packets are properly formatted, I doubt a gateway would be inspecting 

I think EDNS filtering is happening on these boxes.  I think that's been
discussed here many times.

> Servers coping with good faith traffic is not an issue.

Once again, if TCP is so weak that it is trivially attackable, how is it
we have web servers, how is it I'm able to send this mail to you at all?
 Both use TCP, and both services are what I'd consider well-known
services.  I know attacks are a regular order of business on the net.  I
know that TCP is more load on a sever than UDP.  I also know that my web
server has been attacked and the universe did not end.  In fact, either
did my actual page loads.

- --Michael

---

From: "George Barwood" <[email-masked]>
Date: Wed, 8 Jul 2009 12:51:50 +0100

----- Original Message ----- 
From: "Michael Graff" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "IETF DNSEXT WG" <[email-masked]>
Sent: Wednesday, July 08, 2009 10:09 AM
Subject: Re: [dnsext] Name server agility with DNSSEC

> for?  How is this sufficiently different than maintaining TCP state for

This is not state on a per client basis, it's global.
It's tracking when the DNS data changes ( due to dynamic updates, AXFR/IXFR 
etc. )
This is needed so that the client knows it has got a consistent set of 
pages.
A single global 32 bit integer is probably adequate if updates are 
infrequent.

---

From: bert hubert <[email-masked]>
Date: Wed, 8 Jul 2009 11:01:11 +0200

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

> first, see <http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.html>.

Nice how you can see the complete corporate history in one URL! And
good of them that they still have this online. For a 1987 document it
looks remarkably up to date.

But what is the the message to take away from this? That we should not
rely on fragmented UDP packets?

    Bert

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 8 Jul 2009 13:18:44 -0700

On Jul 8, 2009, at 2:01 AM, bert hubert wrote:

>> first, see <http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.html 
>> >.
>

Thats my take based on current measurements.  At least for DNS,  
fragmented UDP does not get through a shockingly high percentage of  
the time, when non-fragmented UDP gets through just fine.

To my mind, this suggests that, as an authority, whenever possible,  
make sure you fit in the Ethernet MTU, unless you are happy with TCP  
fallback on those queries.

---

From: "George Barwood" <[email-masked]>
Date: Wed, 8 Jul 2009 12:51:50 +0100

---

From: Douglas Otis <[email-masked]>
Date: Thu, 9 Jul 2009 16:54:17 -0700

On Jul 8, 2009, at 1:08 AM, George Barwood wrote:

>> I, for one, don't think we need to reinvent protocols here.  SCTP  
>> is perhaps a good idea since it appears to scale down to something  
>> very close to UDP if desired.
>
> I haven't studied SCTP closely, but it seems quite similar to TCP,  
> so I suspect it will suffer from the same problem inherent in any  

SCTP is not dependent upon unspecified auxiliary defensives such as  
those offered in firewalls that defend resource commitment from  
spoofed IP addresses.  SCTP simplifies message handling by offering  
header alignment to facilitate partial message placement, and PR-SCTP  
can delegate message loss recovery to that of the client.  TCP  
resource exhaustion mitigation at the application would likely be  
limited to controlling resources that are in the established state,  
although several other states can strand resources.  Auxiliary TCP  
defensive strategies normally are aimed at protecting the OS, and not  
at retaining a fair minimum, which would be desired for a critical  
service.  Importantly, SCTP/53 does not prevent UDP/53 from  
functioning, but SCTP should have priority.

>> Paginating a UDP response seems like a hack and is just as likely  
>> to be rejected by the very devices you are attempting to bypass,  
>> that of a broken filtering gateway.
>
> I don't think there is any evidence for this, it semes unlikely. The  
> packets are properly formatted, I doubt a gateway would be  
> inspecting EDNS option records.

This needs further review with respect potential exploits that might  
be enabled.  A global state determining the version does not offer  
much protection when not used with DNSSEC.  Perhaps this scheme would  
expect query information be repeated in each packet?  Eventually, this  
approach might arrive at being fairly similar to that of SCTP.

-Doug