Subject: wcard discussions in Minneapolis

From: Edward Lewis <[email-masked]>
Date: Fri, 25 Mar 2005 11:32:05 -0500

This is a summary of wcards at Minneapolis.

On Monday of IETF week an informally gathered subset of the WG 
discussed issues in detail, here is the outcome of that discussion 
(note - this is not a WG decision, but a set of recommendations that 
were then discussed in the face-to-face meeting):

1) Considering '* NS' and '* DNAME'

1A) Change the text in RFC 1034, 4.3.2, step 3, part c to this:

c. If at some label, a match is impossible (i.e., the corresponding 
label does not exist), look to see if a the "*" label exists AND DOES 
NOT OWN AN NS RRSET NOR A DNAME RRSET.

1B) Any query that would have otherwise resulted in a wildcard match 
received a "return code=name error" (NXDOMAIN) so that caches can 
retain the negative answer.

1C) The label count in the RRSIG is not decremented for the presence 
of an asterisk label if there is a NS or DNAME owned there, as this 
name is now not capable of being a source of synthesis.

2) No other issues were raised, recognizing the document had changed 
once since the last meeting.  In particular I was curious about the 
SRV text.

During the scehduled IETF meeting on Wednesday morning, this proposal 
met with a something between a "less than enthusiastic" response and 
"tomato throwing" response.  One person did indeed brandish a piece 
of fruit, although it was not a tomato and it was not rotten.  (I.e., 
it would have left a welt.)

The cry was "don't change the signer."  Instead, the prevailing 
suggesting became to "outlaw" '* NS' and '* DNAME'.

"Outlawing" would entail:

1) Defining the semantics of '* NS/DNAME' on zone loading.
2) Defining the semantics of '* NS/DNAME' in a [AI]XFR zone transfer.
3) Defining the semantics of '* NS/DNAME' in a dynamic update request.
4) Convincing anyone who make use of a '*' zone to give it up.

The discussion ranged as far as whether rejecting a zone was an 
interoperability concern.  More or less yes, as it would be good to 
have masters and slaves behave consistently even if they are 
different implementations.

What I've listed here are just the recommendations, not the 
rationale.  E.g., I still need to figure out why this applies to 
DNAME, but I'm willing to suspend disbelief for the moment while 
gathering these comments.

PS - I would like to personally thank Mr. Ihren for showing restraint 
when it came to the use of fruit in the meeting.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Achieving total enlightenment has taught me that ignorance is bliss.

--
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: Rob Austein <[email-masked]>
Date: Fri, 25 Mar 2005 23:07:56 -0500

At Fri, 25 Mar 2005 11:32:05 -0500, Edward Lewis wrote:
> ...

The WG meeting suggested two possible approaches.  Outlawing the
pathological cases was one.  The other was to leave behavior in the
pathological cases undefined ("garbage in, garbage out").

If there was any consensus on which of these approaches to take, it
was not immediately obvious to me, but judging that's the chairs' job.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 29 Mar 2005 10:43:05 +0200

On Fri, 25 Mar 2005 23:07:56 -0500

>  was not immediately obvious to me, but judging that's the chairs' job.

There was no consensus during the WG meeting. We'll have to see if we
can reach consensus on the list.

Just to make sure we do not stall on this question I propose that if
there is no further discussion on the item we follow the recomendation
of the design meeting i.e. outlawing the behavior.

-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

---

From: Rob Austein <[email-masked]>
Date: Tue, 29 Mar 2005 04:16:25 -0500

> of the design meeting i.e. outlawing the behavior.

Sorry, but I have to stand in the way on this one.

We are talking about pathologically broken data that never could have
meant anything useful under the rules we have now.  The design team
proposed protocol changes (in particular, to DNSSEC) in order to nail
down the uselessness of these pathological cases.  This does not seem
helpful.  Don't we have enough whacky special cases yet?  Do we really
need to add still more special cases, change existing protocol and
implmentation, spend years debugging this nonsense, all for the sake
of having this form of pathologically broken data produce exactly the
same useless and incomprehensible behavior in all implementations?

Last time I checked, dividing by zero didn't work either.

I propose that we just leave this broken stuff broken.  The result of
putting an NS or DNAME RR at a wildcard name is undefined.  It might
just sit there and drool.  It might do something entertaining.  It
might cause the penguin on top of your telly to explode.  It might
spell the end of civilization as we know it.  You know, "undefined".

Garbage in, garbage out.

---

From: [email-masked] (Geoffrey Sisson)
Date: Tue, 29 Mar 2005 12:32:30 +0100 (BST)

Rob Austein <[email-masked]> writes:

> I propose that we just leave this broken stuff broken.

If so, would it be desirable to change -wcard-clarify (I'm guessing it
would stay "-clarify") to explicitly state that the behaviour for
"* DNAME" and "* NS" is undefined?  I'm trying to see this from the
viewpoint of an implementor, who may have difficulty reading between
the lines of the current language.

Regards

Geoff

---

From: [email-masked]
Date: Tue, 29 Mar 2005 17:18:03 +0000

> the lines of the current language.

	and unlike Rob, i'd like to see these things defined.
	defined as -undefined- (explicitly) at this time, or
	taking a crack at what should happen when these are seen
	in a zone.  Leaving things underspecified is distasteful.

--bill

---

From: Alex Bligh <[email-masked]>
Date: Tue, 29 Mar 2005 18:37:17 +0100

> Garbage in, garbage out.

But even so, at the very minimum isn't it necessary to define what is (and
what isn't) garbage? Currently "* NS" is not so defined. And people have
tried to use it.

Assuming it is defined, is the choice between
a) Use of {set of garbage things} is outlawed (which is what Olaf said)
and
b) Use of {set of garbage things} gives undefined behaviour

Presumably the difference is that case (a) yields a predictable error,
case (b) might do anything at all (including 'work' for some value
of 'work'). If so, I think I prefer the former.

Alex

---

From: David Conrad <[email-masked]>
Date: Tue, 29 Mar 2005 09:56:23 -0800

Doing (a) in such a way that there is predictable behavior would likely 
imply redeployment of many DNS servers.  Given full redeployment has 
proven essentially impossible for any significant deployment of any 
server (I still see fingerprints of BIND 4.8.3 on occasion and WinNT 
4.0 DNS), I suspect the only viable option is (b).

Rgds,
-drc

---

From: Alex Bligh <[email-masked]>
Date: Tue, 29 Mar 2005 19:05:31 +0100

--On 29 March 2005 09:56 -0800 David Conrad <[email-masked]> 
wrote:

> server (I still see fingerprints of BIND 4.8.3 on occasion and WinNT 4.0
> DNS), I suspect the only viable option is (b).

OK so how about: {set of garbage things} is reserved, behaviour is
undefined, but implementations SHOULD produce $error.

Alex

---

From: [email-masked]
Date: Tue, 29 Mar 2005 18:18:06 +0000

> undefined, but implementations SHOULD produce $error.

	such a tactic will preclude doing anything useful with this
	in the future.  would prefer something like:
	{set of things} is reserved, the behaviour of DNS components
	is undefined at this time.  Implementations should produce
	$warning if {set of things} is encountered.
--bill

---

From: Rob Austein <[email-masked]>
Date: Tue, 29 Mar 2005 13:21:58 -0500

> the lines of the current language.

Yes.

To be clear (since apparently my previous message was not):

- I have no problem with explictly documenting the behavior of these
  cases as undefined, and agree that it would be useful to do so.

- What I object to is changing the specifications in ways that require
  implementation of new special handling rules.  In particular, I
  object to the proposed changes to the DNSSEC signing algorithm.

---

From: Peter Koch <[email-masked]>
Date: Tue, 29 Mar 2005 20:26:00 +0200

> undefined, but implementations SHOULD produce $error.

as already mentioned during the meeting, this will lead to interoperability
hassles, where the primary accepts but one of the slaves rejects. I'd
prefer a solution which is consistent within the DNS. That's the one
allowing * NS, but per corollary taking away the synthesis property per
that very delegation (which was the result of the morning meeting).

-Peter

PS: Strange enough, in the hostcount data I've found quite a few '* NS',
    although I doubt they were the results of discussions anywhere near this.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 29 Mar 2005 13:57:25 -0500

Speaking as the person who has to edit a response from all this...

How about we document that there are inconsistencies in the 
definition of DNS which lead to unclear semantics when asterisk 
labels are delegation points or DNAME rewrite points.  In the spirit 
of their being inconsistencies, i.e., no right and wrong, no best 
current practice, we declare that we are not going to delineate rules 
at this time.

One reason for this is that there is a fear that if we outlaw 
behavior now, it will be unavailable to us in the future.  While I 
have deep sympathy for this, I think the future for DNS as we know it 
has already been crimped by many forces.  I think that we're past the 
point where we ought to be anticipating the unanticipatable.  (No, 
it's not a word.)

E.g., CNAME rewriting of queries in the authoritative server in RFC 
1034 was the first ill advised crimp.  (Did they forget CNAMEs in the 
infamous step 3 part c or was the omission intentional?)  In a 
perfect world, we should be able to define a base behavior that 
accommodates future innovation via extension.  We've already been in 
a phase where surgery is needed to the base (e.g. EDNS0) to 
accommodate new features (DNSSEC).

I don't think we have a critical mass of understanding of just how 
wild cards and delegation points/rewrite points work profit anyone. 
We have heard of some use cases that are operationally abnormal (like 
a zone whose name is *.anydomain.) but fit within protocol guidelines.

IMHO, it's arguments over such situations that endanger the IETF's 
relevance to operations.  Think of how much time we've devoted to an 
example that no would do except to prove a point.  It's like paying 
for lunch with US$2 bills.  (You know who you are!)  Yeah, they're 
legal tender in the US and, yes, the cash register makers don't give 
them a bay.

I would say that now we just recognize and document the 
inconsistencies.  I would say that when there is a clear way to iron 
out the wrinkles we do so, and no sooner.  I would say that if we 
lose something by not defining this now, well, I don't think we will 
be losing much.  There are bigger problems in DNS.

Maybe the latter is my motivation of this answer: I'm getting to the 
point where I would like to wrap this document up and move on to 
cleaning up the IANA references or to some of the Proposed Standard 
documents that haven't made it to Draft Standard yet.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 29 Mar 2005 12:29:25 -0800

> current practice, we declare that we are not going to delineate rules 

Declaring such a cause for a warning or error, when there is no
behavioral definition, reduces risks.

-Doug

---

From: Paul Vixie <[email-masked]>
Date: Tue, 29 Mar 2005 21:13:12 +0000

bill wrote:

> 	..., i'd like to see these things defined.

...and i agree.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 30 Mar 2005 10:45:03 +0200

On Tue, 29 Mar 2005 13:57:25 -0500

> current practice, we declare that we are not going to delineate rules 

Sounds like a fair approach to me. Anybody not agreeing raise your voices.

--Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
---------------------------------| JID: olaf at jabber.secret-wg.org

---

From: [email-masked]
Date: Wed, 30 Mar 2005 12:50:30 +0000

> Sounds like a fair approach to me. Anybody not agreeing raise your voices.

	i like the words and intent.

--bill

---

From: Rob Austein <[email-masked]>
Date: Thu, 31 Mar 2005 09:37:16 -0500

> current practice, we declare that we are not going to delineate rules 

Ok with me.