Subject: Re: still not sure

From: Robert Elz <[email-masked]>
Date: Thu, 30 Sep 2004 16:44:01 +0700

Date:        Wed, 29 Sep 2004 12:01:50 -0400
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a0602040bbd808b0ce5af@[192.136.136.113]>

  | Does the slave server note this in logs?

You can't expect a meaningful answer to that question - servers note
in their logs whatever the server author wants them to note.

However, there's no more reason to "note" that than any other domain
that happens to be being loaded.

  | Does the slave server dump the zone update upon completion of transfer?
  | 
  | (Or) Does the slave server press this zone into service as if the 
  | above is legal (wrt RFC 1034, 4.3.3)?

The latter.

  | Does the slave server recognize that *.example. is a Wild Card Domain 
  | Name (even if there is no other *.example. entry)?

Yes, if it gets a query for gibberish.example. it needs to reply NODATA
and not NXDOMAIN (you all know what those mean).   For any practical purpose,
that makes no (external) difference that matters, so for practical
purposes, whichever decision makes little difference - but the implementation
can be much simpler and cleaner if we can ignore these special cases.

[Aside:
[ Incidentally, that's why in the version of the draft I sent you I had
[ "undefined" for what happens here - that is, allow either NXDOMAIN or
[ NODATA, as the difference between them doesn't matter much most of the
[ time (and clients really need to handle either possibility, as much
[ as they care about the difference, which isn't usually very much).
[ But for technical correctness, and for the purposes of proofs of
[ existence, NODATA is the right answer.

The effect is that there is no need to go looking to see if a domain name
happens to have sub-domains before deciding whether or not it is a valid
wildcard (the algorithms in 4.3.2 say nothing about that, just
	'look to see if a the "*" label exists'  [sic]

Here, *.example. exists (after searching in example. for gibberish.example.
and not finding that one, and still looking in example. for the '*').

Nothing anywhere about looking for sub-domains and ignoring the '*' if
any are found.  Nothing about doing that depending upon whether or not
the '*' label has RRs attached to it or not (the test for matching RRs
comes later, after the '*' is found).

What's more, adding another *.example. RR explicitly (other than that it
would provide an RRset to return for one type of query, instead of NODATA) 
changes nothing at all - the *.example. in "*.example." is exactly the same
domain as the *.example. in "*.foo.*.example."   There is exactly one '*'
sub-domain of "example." regardless of how many times the '*' in the
appropriate place happens to appear in the label field of the zone file.

  | Does the slave server recognize that *.foo.*.example. is one too?

Yes, of course, for gibberish.foo.*.example. queries (and only those).
Again, doing anything else is needlessly complicated, for close to
zero practical effect upon the world.

  | What I sense from the group is:
  | 
  |      *.foo.*.example. is confusing so operators SHOULD NOT use it.
  |      *.foo.*.example. MUST be allowed (anticipated) in a query.
  |      *.foo.*.example. MUST be allowed to exact match "itself."

Agreed (both with the sense of the group, such a "group" as it has been
on  this question, and with that being the correct interpretation anyway).

  | What's still knocking me around is whether we need to make it clear that:
  | 
  |    Implementations ought to anticipate such a name, and make the name act
  |    like a Wild Card Domain Name should - all the while we tell operators
  |    to not bother using it.

I'm not even sure we need to tell anyone not to bother using it.   It isn't
as if operators are racing about doing absurd things like this - no-one
actually uses '*' as a literal domain name (in zones, or in queries they
expect to get answers to), so this isn't really important.

What we need to do is make it clear that *.foo.*.example does NOT mean
"any name in a foo sub-domain of any sub-domain of example".

If we do that, and actually succeed in getting the message across,
then there won't be any need to worry about people doing this by
accident.   If we fail to make it clear, then there's no point in
this draft doing anything at all.   If we make it clear, but fail to
get the message delivered properly, then it really makes no difference
what we say, we're going to be ignored anyway.

I prefer to assume that we can make it clear, and that the community
will take (sufficient) notice (even if it just means that the book
authors take note...) that this can all be productive.

kre

--
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: Alex Bligh <[email-masked]>
Date: Thu, 30 Sep 2004 11:17:38 +0100

Ed,

Executive Summary: IMHO these are no more bad than any other name
which does not consist of [0-9a-zA-Z-] with interior hyphens, so
for reasons of consistency we should not introduce a "SHOULD NOT" -
the existing discouragement from using wild and whacky characters
in labels is sufficient.

> At a slave server, accepting zone transfer (updates) the following record
> is seen:
>
>
>      *.foo.*.example.  3600 IN TXT "just to be a pest"
>
>
> Does the slave server note this in logs?

I don't know. If the server gets any of
	\040			3600	IN TXT "at sign"
	~			3600	IN TXT "tilde"
	-name-		3600	IN TXT "name starting and ending dash"
	\001\046\042\046	3600	IN TXT	"that's ascii(1) '.' '*' '.'"

then for some value of "should", they "should" not be in the zone
file, and it might thus be worth logging them.

But not for an RFC value of "should", else they'd all have "SHOULD NOT"
in the RFC (which they don't). Neither does this.

So I guess if I was going to put something in the RFC, I would deprecate
their usage to the extent all the above are discouraged (which is weaker
discouragement than "SHOULD NOT"). But that's already done in precisely
the section that discourages uses outside [0-9a-zA-Z-] with interior
hyphens only. So I don't think that needs to be done.

> Does the slave server dump the zone update upon completion of transfer?

That sounds like application dependent behaviour - I can quite see
why people might want a switch that dumps zones if the contents don't
match some more restricted than usual regex, but if things are legal
(albeit discouraged) under the RFC, the RFC should not recommend a
server does the above.

> (Or) Does the slave server press this zone into service as if the above
> is legal (wrt RFC 1034, 4.3.3)?

See above.

> Does the slave server recognize that *.example. is a Wild Card Domain
> Name (even if there is no other *.example. entry)?

I am presuming you mean "no other <AnythingButStar>.example entry"...

> Does the slave server recognize that *.foo.*.example. is one too?

*.foo.*.example. is indistinguishable in my mind from
  *.foo.bar.example.
  *.foo.example.
  *.*.example.

Logic suggests these should also be treated the same as *.example.
(with no other <anything>.example. entry).

> What I sense from the group is:
>
>      *.foo.*.example. is confusing so operators SHOULD NOT use it.
>      *.foo.*.example. MUST be allowed (anticipated) in a query.
>      *.foo.*.example. MUST be allowed to exact match "itself."

I can see no reason to make *.foo.*.example. any more recommended
against than (say) names with dots in.
 "*" . "f" "o" "o" "." "e" "x" "a" "m" "p" "l" "e" .

If we are going to make pronouncements about confusing things, we
should catch everything confusing - I'd suggest that's at a minimum
"*", "@", "*" (anything other than as LHS wildcard including
in the middle of a label), ".", <=32, >=127, and possibly quotes.
But I don't think we should really be going there.

What we might need is a clarifying example saying

LABELS:
	*.foo.*.example.	- Left hand * is wildcard, RH is literal
	*.*.example.	- Left hand * is wildcard, RH is literal
	*.example.		- * is wildcard
	a.*.example.	- No wildcard
QNAMES:
	All instances of * are literals

> What's still knocking me around is whether we need to make it clear that:
>
>    Implementations ought to anticipate such a name, and make the name act
>    like a Wild Card Domain Name should - all the while we tell operators
>    to not bother using it.

"tell the operators" (IMHO) in exactly the same terms as we tell them
not to do other daft but permissible things, like use dots in their
names. Which does not amount to "SHOULD NOT".

Alex

---

From: Peter Koch <[email-masked]>
Date: Thu, 30 Sep 2004 14:14:00 +0200

Hi Ed,

> Does the slave server note this in logs?

nothing we should worry about. I'd like a server to do so, but that's up
to the choice of the implementor.

> (Or) Does the slave server press this zone into service as if the 
> above is legal (wrt RFC 1034, 4.3.3)?

Yes, since we haven't found a good reason for ``<anydomain> should not contain
other * labels''.

> Name (even if there is no other *.example. entry)?

Sure, why should the slave behavior differ from the master's?

>      *.foo.*.example. is confusing so operators SHOULD NOT use it.

agreed.

>      *.foo.*.example. MUST be allowed to exact match "itself."

If one follows the algorithm outlined in 4.3.2, no special treatment is needed.
However, with regards to kre, a "MUST be allowed (anticipated) in a query"
might conflict with ``check-names'' like features, which have nothing to do
with wildcards, but lot to do with A or AAAA queries. So, in general, they
should be allowed but I'd rather not see this as an argument that '*' must
be accepted in a ``hostname''.

>    like a Wild Card Domain Name should - all the while we tell operators

We've found some oddities which might be best listed in an appendix as kind
of implementors guide or checklist. The inner '*' is one of them.

-Peter

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 30 Sep 2004 13:47:45 -0400 (EDT)

-protocol section C.8 suggests using explicit DS queries to get around
the grandparent problem.  Section 4.2 of the same document suggests
using NS queries.  These are worded as suggestions, not instructions;
there's no 2119 language here.

1) Do we know that NS queries work?  (No wierd caching
   effects, no confusion over authoritative v. glue NSset?)

2) Should the doc be changed to be self-consistent?

-- Sam