Subject: Weird Wildcards Work item (on wildcards vs RR types, was Faux wildcards)

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Thu, 20 Jan 2005 16:25:16 -0500

There seems to be in some peoples mind  a "need" for mechanism to do a
wild-card "like" thing.

Without having clear requirements and usage examples it is hard to judge what
is wanted by the different people that have posted on the "Faux wildcards" and
"wildcards vs RR types" topic.  On the other hand we think that, given that we
have been going in circles, continuing on list will not lead us anywhere.

The chairs would like to propose the following path forward.

We assume that there will be a number of stake holders for such a
"Weird Wildcard Workitem"  and we would like them to take some time
to produce the following:

1. Requirement statement
2. Draft rules for proposed mechanism the rules must address at least
    the following questions:
	a. is this both/either a terminal or non terminal

	b. does this match:
		only existing names
		only non-existing names
		both

	c. Is this mechanism terminated by
		existing name
		delegation
	   if the answer is "delegation" then answer sub question
		how does same type at a name affect expansion 	
		
	d. Is this mechanism expanded to one or multiple labels
	
	e. If answer is multiple levels how are multiple expansion statements
	   for the same type handled.

3. Usage example or two.

4. List of active participants

Issues like how this is expressed in zone files and zone transfer do not
have to be included at this point, nor do issues like DNSSEC or
dynamic update interaction.

After this has been drafted we'll verify if this work can be done within
charter of this group and if there are sufficient people available that
actually are willing and able to do the work.

So essentially we are asking a small requirements-design team to form
that will do their work on the 0th version.  In order to bootstrap this
process stakeholders can contact Olafur (ogud at ogud.com) who will subscribe
them to a mailing list. The list will be discontinued and the archives of
the mailing list will be made available once version 0 is available.

We hope that the working group can have an in depth, in scope and
focused discussion on such version 0.

	Olafur and Olaf

--
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: David Blacka <[email-masked]>
Date: Fri, 21 Jan 2005 12:11:39 -0500

> have been going in circles, continuing on list will not lead us anywhere.

While I'm not personally invested in a new wildcard mechanism, I would
like to attempt to contribute to the discussion of what the issues
are at the risk of restating the obvious.

It seems to me that when non-experts look at wildcards they come to
one of two conclusions:

1. Wildcards don't match enough.

2. Wildcards match too much.

Don't match enough:

My experience has generally shown that when a naive user is introduced
to wildcards, they generally expect the wildcards to apply in more
situations than they actually do, leading to long-standing common
errors (c.f. RFC 1034, section 4.3.3).  The classic wildcard MX:

   $ORIGIN example.com
   *     IN MX  10 a
   a     IN A   1.2.3.4
   b     IN A   1.2.3.5
   mail  IN MX  b

The naive user generally expects the wildcard to match <c.example.com,
MX> (which it will), <a.example.com, MX> (which it won't), and
possibly even <b.a.example.com, MX>, but not <mail.example.com, MX>.

That is, a possibly more natural interpretation of the wildcard is one
of: this is the default MX record for the zone, use it when no other
MX in the zone applies.

Match too much:

This typically comes up when folks struggle with wildcards interacting
with DNS records that use so-called "name hacks", like the SRV.  "Why
can't I have a wildcard SRV?", they ask.  Why cannot a DNS server
exhibit a great deal of control over how a wildcard matches?  So we
see proposals that look like:

   _http._tcp.*.example.com. IN SRV ....

where the expected behavior is that <_http._tcp.foo.example.com, SRV>
matches, but <bar.example.com., SRV> does not, and
<_smtp._tcp.foo.example.com., SRV> certainly does not.

The limits of how much control this wildcard mechanism should have are
not typically well explored by such proposals.  However, the example
above might be considered a lower bound of control.  An upper bound
might be to use regular expressions as wildcard matching rules. (Not
that regular expressions represent a real upper limit -- any
arbitrarily complex language could be defined).

While I personally cannot think of many interesting uses for an
expressive (say regular expression-based) selectively matching
wildcard, my gut feeling is that there would be.

I do not necessarily think that there is a call for multiple new
wildcard mechanisms.  The first issue (match too little) could be
handled by a zone pre-processor (by which I mean that the desired
semantics are *expressible* using current DNS, but just verbose),
and/or a single new mechanism could encompass both behavioral issues.

-- 
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

---

From: Edward Lewis <[email-masked]>
Date: Fri, 21 Jan 2005 14:19:15 -0500

Very tangentially -

>and/or a single new mechanism could encompass both behavioral issues.

BTW, we ought to rewrite the SRV document to fix the 
misunderstandings it engenders.  E.g., I tried to load an SRV record 
to a name without underscored "prefixes" and it worked in BIND 9.2.2. 
(That was just a handy implementation/build.)

The SRV naming "convention" doesn't change the query processing.

 From that RFC:

#        _Service._Proto.Name TTL Class SRV Priority Weight Port Target
...
#   Name
#       The domain this RR refers to.  The SRV RR is unique in that the
#       name one searches for is not this name; the example near the end
#       shows this clearly.

The name queried for is still "_Service._Proto.Name", it is not 
"Name" (as stated in the RFC).

Later,

#   In this example, a client of the "foobar" service in the
#  "example.com." domain needs an SRV lookup of
#  "_foobar._tcp.example.com."

Basically, what the SRV did was create a convention by which 
applications would look up specific things in the DNS - which is what 
is supposed to be the case.

The SRV RR isn't broken, the description of it is.

I was thinking about this while reading David's message.  One 
underlying problem is the misperception that host name = domain name 
(and vice versa for the non-mathematical coding types).  1123 is not 
1034/1035.

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

"A noble spirit embiggens the smallest man." - Jebediah Springfield

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 21 Jan 2005 14:23:54 -0500

> of: this is the default MX record for the zone, use it when no other

This has long been a problem, and I've long been planning to write an I-D
on ways to deal with it.

Personally I think the best way to do this is to define a $DEFAULT
zonefile directive, with the value applying to any domain name which did
not have the declared RRtype[s] explicitly defined. For example, "$DEFAULT
MX 0 mailhost.example.com." would mean "all defined domain names have a
default MX that points to mailhost.example.com, unless there is an
explicit MX RR defined for that domain name". The use of a zone directive
solves the problem elegantly, in that it can be used for any domain name
that the zone is authoritative for. The big problem with this approach is
that zone directives aren't really supported; even though directives are
(somewhat) defined in STD13, they aren't really supported in transfers,
and there are a number of server implementations that don't really embrace
the concept either. Personally I still think that this is the best way to
go, and that secondary work items (like adding explicit support for zone
directives to xfers) is important and necessary anyway, and would be
useful for other work efforts (some of my i18n work made use of directives
also, and suffered from the same problems).

Another path I had explored here was defining a zone-cut RR that would
essentially append additional attributes to the SOA RR (or any names that
ended with the same suffix as the defined RR). The big problem here is
that there's a lot of sub-typing invovled, and that's actually more work
in the end, I think. For example, defining a default mail server means "ZC
[MX 0 mailhost.example.com.]" with the MX RR being formally sub-typed.
Going this route is feasible, but at minimum requires that every new RR be
added to the sub-type list, and at maximum requires significant amounts of
data-typing and inheritance rules. That's probably good too, if it were
ever to get done, and I have had such a need for other projects too, but
it's actually a lot more work.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Edward Lewis <[email-masked]>
Date: Fri, 21 Jan 2005 14:36:49 -0500

...
>(somewhat) defined in STD13, they aren't really supported in transfers,

...do they need to be?  Once you've expanded the directive (think 
$GENERATE, $TTL, $ORIGIN), there's no need to push it to other 
servers.

>the concept either. Personally I still think that this is the best way to

...the concept of zone files, yeah.  That's the problem with zone 
file directives.   But there's no reason a zone file implementation 
couldn't try it out.

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 21 Jan 2005 14:53:15 -0500

> $GENERATE, $TTL, $ORIGIN), there's no need to push it to other

It's certainly possible for the master to expand the directive prior to
transfer (and there wouldn't be any difference in the data that the
replication partners served out), but in the general case it would be more
efficient to have the servers be able to exchange meta-data explicitly,
rather than the expanded data. Things like large blocks of textual data
(like SPF, or worse, Sender-ID), which you don't really need/want to
duplicate for each and every entry in the zone.

> file directives.   But there's no reason a zone file implementation 

I don't see zone directives as necessarily being tied to zone "files";
they are a useful construct for zones in general. I mean, there are
servers that support things like variable-expansion and default values
already, and a generalized "zone directive" (as specifically opposed to a
"zone file directive") would be useful to formalize.

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 21 Jan 2005 12:07:17 -0800 (PST)

> $GENERATE, $TTL, $ORIGIN), there's no need to push it to other 

Yes. Directive would work best for synthesized wildcard done as 
preprocesing, i.e. if we have this in zone file:
 $DEFAULT	IN	MX	0 mail
 B		IN	A	127.0.0.1
 C		IN	A	127.0.0.2
 MAIL		IN	A	127.0.0.5	
Then after processing the actual zone file that is loaded by server is:
 B		IN	A	127.0.0.1
 B		IN	MX	0 mail
 C		IN	A	127.0.0.2
 C		IN	MX	0 mail
 MAIL		IN	A	127.0.0.2
 MAIL		IN	MX	0 mail
We also might want to have directive $NODEFAULT that would cause not using
default value for particular RR and leaving it as is (i.e. nodata):
 $NODEFAULT	IN	MX	mail
For above this would be usefull in order not to produce last line (MAIL IN MX)
Possibly $NODEFAULT should be called $NODATA directive (to explicitely set that
particular record exist but there is not such RR type for it).

> file directives.   But there's no reason a zone file implementation 

Well, if we're going with zone processing directive, it should be done so
that when zone is transfered to secondary server (or for DNSSEC signing), 
its the data after preprocessing that is seen, i.e. the secondary dns 
server would not need to do its own pre-processing (and would not 
necessarily need to have been updated to understand this directive), 
although the directive could be left in there, so that secondary dns 
server could if it wanted recognize wildcarded RR from real one.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Fri, 21 Jan 2005 13:30:11 -0800

Meta defaults for RR types add type selectivity, but this seems to lack
prefix selectivity.  Won't existence issues at a resolver remain without
including a unique prefix?  

Meta instructions created with '&' syntax, as example:

sel-d.sel-c.&.sel-b.sel-a TYPE  Data

-Doug

---

From: Peter Koch <[email-masked]>
Date: Mon, 24 Jan 2005 13:39:27 +0100

> $GENERATE, $TTL, $ORIGIN), there's no need to push it to other 

they don't have to be supported for XFR, but having a standardized zone
format also allows us to distribute zone contents by other protocols. Having
the root zone available via ftp is one example.

-Peter

---

From: Robert Elz <[email-masked]>
Date: Wed, 26 Jan 2005 11:10:53 +0700

Date:        Fri, 21 Jan 2005 14:53:15 -0500
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | It's certainly possible for the master to expand the directive prior to
  | transfer (and there wouldn't be any difference in the data that the
  | replication partners served out), but in the general case it would be more
  | efficient to have the servers be able to exchange meta-data explicitly,
  | rather than the expanded data. Things like large blocks of textual data
  | (like SPF, or worse, Sender-ID), which you don't really need/want to
  | duplicate for each and every entry in the zone.

Personally, I don't know why systems wanting large blocks of textual
data want it in the DNS at all.   It just makes no sense.

The DNS is deliberately designed as a fast, cheap, low-overhead distributed
lookup mechanism (definitely not a directory, it has no search capabilities,
and should never grow them).

It is great for accessing precisely defined small blocks of data.

It is unfathomable to me why everyone keeps wanting to stick "large blocks
of textual data" in the DNS, when there are other protocols around that
do a great job of moving around those large blocks - of course they have
higher overheads and costs, but that can't really be avoided - dumping the
higher overheads and costs into the DNS so it can be mangled into carrying
these unreasonable data sets is a truly insane end goal.

Either use another existing protocol (if you need the low overheads of UDP,
TFTP allows data units to approx 32MB, and just about the same basic security
as the DNS currently has) or if there's nothing suitable - invent a new
protocol - as long as it runs over TCP or UDP, doing so is not really any
harder than updating DNS servers and clients to support something new, or
shouldn't be.

kre

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 26 Jan 2005 10:09:59 -0500

> and should never grow them).

http://www.ehsco.com/misc/I-Ds/draft-hall-dns-data-04.txt pretty much
demonstrates that I agree with this I think. If you check the MARID
archives, you'll find my position to have been pretty clear there too,
especially as it pertains to XML in the DNS.

> do a great job of moving around those large blocks

Well for one thing, we've done a poor job of getting out the message that
DNS is a lightweight naming service. For another, we've done a poor job of
providing a distributed directory that provides what folks want.

But that's pretty much irrelevant to the point that you are replying to.
Obviously there is a need for something like $DEFAULT directives, even for
small RRs like MX, and moreso for things like SPF and Sender-ID,
regardless of whether or not they should exist in the first place. OTOH, I
can see some value in the argument that people should be made to suffer
for their mistakes, and in that case, replicating meta-data is not only
unneeded but counterproductive.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 26 Jan 2005 15:38:12 -0800

> data want it in the DNS at all.   It just makes no sense.

Agreed; does path registration make sense either?

> The DNS is deliberately designed as a fast, cheap, low-overhead
> distributed lookup mechanism (definitely not a directory, it has no
> search capabilities, and should never grow them).

I agree DNS should not be changed to offer features found with a
directory.  There is a sizable difference between a name tree and a file
system.  Publishing assertions at the top of a domain could allow a
means for establishing security enhancements for various protocols,
however.  Before creating a proposal, it seems exploring the basics
could be helpful.

A means to reflect higher information at lower nodes was the concept
behind the limited wildcard mechanism.  Locating a name for a RR remains
unused within inverse lookup.  DNSSEC adds the NXT mechanism.

It would seem there are few ways to ensure a wildcard is reliable for
asserting policy however.  Is there any solution beyond DNSSEC?

Are there viable options without changing resolvers?
a) DNSSEC
b) Global RR Type acting as an inverse lookup
c) Special prefix returning first RR within hierarchy
d) Special wildcard symbol with RR type independence

> It is great for accessing precisely defined small blocks of data.

These assertions could be contained within a single bit, or even by the
existence of a record.

> It is unfathomable to me why everyone keeps wanting to stick "large
> blocks of textual data" in the DNS, when there are other protocols
> around that do a great job of moving around those large blocks - of
> course they have higher overheads and costs, but that can't really be
> avoided - dumping the higher overheads and costs into the DNS so it
> can be mangled into carrying these unreasonable data sets is a truly
> insane end goal.

This bulky DNS information was to support a distributive system
accepting exchanges from anonymous sources.  (Dangerous by being active
as to illicit staging for corrupting caches.) 

> Either use another existing protocol (if you need the low overheads of
> UDP, TFTP allows data units to approx 32MB, and just about the same
> basic security as the DNS currently has) or if there's nothing
> suitable - invent a new protocol - as long as it runs over TCP or UDP,
> doing so is not really any harder than updating DNS servers and
> clients to support something new, or shouldn't be.

Agreed; the hundreds of possible lookups required to support path
registration makes DNS a very poor choice.

This still leaves a fundamental problem and the actual reason for the
ballyhoo over record types.  How to reliably announce new policy with
respect to all names within a specific domain?  With such a mechanism,
possibilities for transitioning protocols becomes more apparent.

-Doug