Subject: wildcards, dnssec, and opt-in

From: Edward Lewis <[email-masked]>
Date: Tue, 17 Sep 2002 08:28:42 -0400

As far as whether wild cards stay or go, I think it is up to the 
users of DNS to determine, not the protocol designers.  Whether they 
are a pain or not, if the use of wild cards is deemed necessary, it 
is up to the engineers to answer the requirement.

Pre-BIND 8, when a small group of us were struggling to write the 
first DNSSEC code we came upon a feature that made validating answers 
problematic.  Round robining of answers was a stumbling block - 
because it meant having to reorder the RR's for validation.  There 
was an internal proposal then to make users of DNSSEC turn off round 
robining so that the DNSSEC code wouldn't have to copy and sort 
before validating.  Eventually, it was determined that round robining 
is a requirement and DNSSEC will just have to deal with it.  I think 
the same applies to wild cards.

If opt-in is to be adopted, it too will have to deal with wild cards. 
If there's a choice between wild cards and opt-in, I'd have to lean 
in favor of wild cards as I see that wild cards as a requirement. 
Yes, some feel that opt-in is a requirement for deployment in large 
zones.  Although I'm pressing for DNSSEC to succeed, if in doing so 
it causes harm to the legacy of DNS, perhaps DNSSEC is better off not 
being deployed.

(If that's the case, we better start on DNS2010.)

Keep in mind that the issues being bickered about here are unusual 
cases.  Most zones are one label deep.  Most uses of wild cards are 
simplistic.  Most zones don't even use wild cards.  Will any zone 
that is a candidate for opt-in want to have a wild card?  But 
complicated uses do exist.  What we need to keep in mind is that the 
solution we generate needs to work best for the majority of cases and 
work in some fashion for all cases.

I personally fail to see the difficulty caused by wild cards, 
especially for DNSSEC.  They are tedious perhaps, but the algorithms 
to process them are deterministic, decidable, and will terminate. 
With opt-in, I think there's a choice to be made, whether an unsigned 
(opted-out) domain name is matched before a signed wild card.  If we 
choose one of the options, and no other "corner cases" are found, we 
should be again in the situation of a decidable algorithm that 
perhaps takes time - but will terminate.

(Worried about amplification as a springboard for a DOS?  I don't 
have an answer to that without looking at the algorithm and the 
potential for triggering it.)

Remember that we can imagine really weird uses of wild cards, CNAMEs, 
DNSSEC, etc., but for the most part these engineer-dreamed scenarios 
do not occur in the wild.  Cover the odd-ball cases, but let's just 
optimize on the cases that are actually used in nature.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

--
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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 17 Sep 2002 07:53:27 -0700

> in favor of wild cards as I see that wild cards as a requirement. 

I believe that the ability to deploy in .com, .net and .org is 
a requirement.

Unless the protocol is fixed there is no way that DNSSEC should go 
to the IESG.

DNSSEC in its current form is BROKEN. 

		Phill

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 17 Sep 2002 21:30:42 +0200

State your believes. Citate the requirements. What makes you think
that these domains are different then the ones you don't mention?

Why?

Because of what?

	jaap

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 17 Sep 2002 13:41:40 -0700

> that these domains are different then the ones you don't mention?

We have been over this many, many times as you are undoubtedly aware.

Without OPTIN the cost of creating unnecessary NXT records is 
prohibitive. 

It is a scale issue that becomes apparent when you have over a 
million records.

I find it bizare that we are talking about hypothetical applications
of enum in Andora when it has already been established that without
a change to the processing of NXT, the DNSSEC protocol is undeployable
for the vast majority of current users.

		Phill

---

From: Brian Wellington <[email-masked]>
Date: Tue, 17 Sep 2002 14:07:10 -0700 (PDT)

> We have been over this many, many times as you are undoubtedly aware.

Far too often, yes.

> It is a scale issue that becomes apparent when you have over a 

I don't think it's ever been shown to be prohibitive.  Given modern 
hardware, why?

> for the vast majority of current users.

The vast majority of current users don't have zones the size of .com, so 
this is irrelevant.

Brian

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 17 Sep 2002 14:33:32 -0700

> The vast majority of current users don't have zones the size 

The vast majority of users have zones that are IN .com so for them the
issue is pretty damn important.

The .com hardware supports 7 billion transactions per day. There is 
simply no way that anyone is going to allow deployment of any protocol
modification that does not take account of the fact that DNS is a 
critical infrastructure for the Internet and take every step possible
to minimize impact on those systems.

Call these issues 'irrelevant' if you like, but in every successful
standards group I have been involved in the group has taken great
pains to gain the active endorsement of the principal stakeholders
rather than dismissing their needs as 'irrelevant'. 

Since I first attended a DNSEXT meeting in San Diego I have started 
two open standards groups, one of which has its specs in final vote 
and the other is just about to go to last call. Both specifications
have a very broad base of support amongst industry and developers.

I don't expect anyone to use XKMS or SAML or even WS-Security because
they are told to by a standards body, I expect them to use the 
specifications because they meet their needs. If a working group goes 
out of its way to tell a group that their requirements are considered 
'irrelevant' they are effectively saying that they do not intend to
service that groups needs and consequently cannot expect that group
to adopt any resulting proposal.

Standards groups are a two way street, don't tell me my requirements
are irrelevant one day and then go and complain later if I do something
you don't like.

		Phill

---

From: Brian Wellington <[email-masked]>
Date: Tue, 17 Sep 2002 14:51:15 -0700 (PDT)

> issue is pretty damn important.

It's important for you, not for them.  Do you really think the users care 
how long it takes to sign .com?

> to minimize impact on those systems.

7 billion transactions?  Presumably you're referring to queries, and 
opt-in doesn't make query responses any shorter.

> rather than dismissing their needs as 'irrelevant'. 

They're irrelevant to most users, and important to large registries.  You 
work at a large registry.  Of course you think it's important.  You 
should.

> are irrelevant one day and then go and complain later if I do something

This seems pretty off-topic.  I didn't intend to dismiss your claims;
merely that they don't apply to most users.

Brian

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 17 Sep 2002 18:01:14 -0700

> how long it takes to sign .com?

They care if the impact of DNSSEC on .com is such that we do not deploy.

The time issue is far less important than the data volume issue. No
extension that causes an immediate and sudden increase in the
data volumes will be deployed.

> merely that they don't apply to most users.

On the contrary, they apply to the vast majority of users whose domains
are in .com and .net.

I do not believe it is off topic to point out that rejection of a 
set of requirements has consequences that will render the entire 
group irrelevant.

If you tell me that you are not going to address people's requirements you
have absolutely no reason to complain if they do not accept the decisions
made here. We already reached consensus here, but for Katherine Harris II
and her supreme cabal the drafts could have been RFCs by now. So don't
complain if people choose the original group consensus over the cabal, or
go form their own cabal somewhere else.

		Phill

---

From: Edward Lewis <[email-masked]>
Date: Wed, 18 Sep 2002 07:55:20 -0400

Before we get too far into this rat hole, the DNSSEC performance 
issue behind opt-in isn't signing time.  That's been discussed 
before.  The issue is the memory required to hold the zone in a 
server (whether primary or secondary storage) and the cpu needed to 
search through the data.

I claim that signing a zone of any size is an easy proposition.  My 
first signer could handle (late-90s) com. from scratch - then at 700K 
delegations - on a mid-90's Pentium in 40 hours.  My second signer 
(the one distrubuted with BIND 8.2) couldn't sign com. because I 
didn't include my "memory tricks" simply because it didn't seem 
important to to do so in experimental code.  Signing is the easy part.

The "response time" for adding a new signed delegation is more a 
function of institutional practices than computing power.

At 2:22AM -0700 9/18/02, Jim Reid wrote:
>>>>>>  "Brian" == Brian Wellington <[email-masked]> writes:
>
>     Brian> It's important for you, not for them.  Do you really think
>     Brian> the users care how long it takes to sign .com?
>
>Of course not. Though they will care if the signing time has an impact
>on how quickly new delegations get published.

---

From: Roy Arends <[email-masked]>
Date: Wed, 18 Sep 2002 17:15:46 +0200 (CEST)

On Wed, 18 Sep 2002, Jakob Schlyter wrote:

> people will deploy dnssec either to increase the security of the dns or to
> make money. I would guess verisign falls into the second category.

Nonsense.

People will deploy dnssec to increase the security of the DNS and (or) not
to loose money (because of lack of security). These are effectively the
same.

Roy

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 18 Sep 2002 17:36:12 +0200 (CEST)

> to loose money (because of lack of security). These are effectively the

yes, that may be true for end-zone administrators - I was talking about
the registry.

	jakob

---

From: Roy Arends <[email-masked]>
Date: Wed, 18 Sep 2002 17:39:40 +0200 (CEST)

> yes, that may be true for end-zone administrators - I was talking about

fud, stop it :-)

---

From: David Conrad <[email-masked]>
Date: Wed, 18 Sep 2002 09:38:41 -0700

Roy,

>> yes, that may be true for end-zone administrators - I was talking about

This is not FUD.

Whether any registry deploys DNSSEC is a business decision of that registry.
The registry, by and large, is not affected by the integrity issues DNSSEC
protects against.  If the registry's customers really want (that is, be
willing to pay for) DNSSEC, it will get deployed, regardless of the
implications that deployment might have on the registry's infrastructure.

Unfortunately, to date, there has not been significant demand for DNSSEC
from customers.  As such, any registry that considers deploying it must be
willing to assume some risk, believing that in the future customers will
want DNSSEC.  What I take Phill's comments to mean is that Verisign is not
willing to take the risk.

Rgds,
-drc

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 18 Sep 2002 11:02:29 -0700

> willing to take the risk.

Well we all speak for ourselves in these mailing lists.

However it is clear that we have not been able to persuade the 
registry to deploy to date on the basis of the non-OPTIN specs.

It does absolutely nothing for DNSEXT credibility inside the company
to have loonies on this list stating that their intention is to 
design a protocol that cannot be deployed in .com because they are
persuing some personal political campaign against the registry.

Nor does it do much for DNSEXT credibility inside the IETF.

The 'I am not comfortable with it line' is pure FUD straight
out of the textbooks on Agenda Denial. I do not believe the
issues being raised are being raised in good faith.

		Phill

---

From: Brian Wellington <[email-masked]>
Date: Wed, 18 Sep 2002 14:27:52 -0700 (PDT)

On Wed, 18 Sep 2002, Edward Lewis wrote:

> I don't mean to pick on my esteemed colleague quoted above, but let's 
> drop picking on business models and the motivation behind deploying 
> DNSSEC.  Let's instead get out hands on code that will let us look at 
> our own personal "corner cases" to see just how (bad/painless/good) 
> opt-in is.  I would think this is an action item from the proponents 
> of the change.

As soon as there is working code, the argument becomes "There's working
code, how bad can it be?".  A decision should be made based on the merit
of the ideas, and I don't think the existence of an implementation should
ever be used to further progress.

> Besides my FUD over wildcards and DNSSEC (and FUD it is as I can't 
> test it), I have FUD over how an application might interpret the 
> results of an opt-in impacted response.  I'm not saying "it ain't 
> gonna work," I'm saying "I can't tell right now."

To my knowledge, no one's ever claimed that opt-in won't work.  Only
Phill, as far as I can tell, claims that DNSSEC won't work without opt-in.

Brian