Subject: Re: wcard discussions in Minneapolis

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 cry was "don't change the signer."  Instead, the prevailing 
> suggesting became to "outlaw" '* NS' and '* DNAME'.

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.

--
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: "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.