Subject: DNS Administrative wildcards

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 11 May 2007 13:23:47 -0700

I am trying to find out where the discussion of administrative wildcards went, without much success so far.
 
Ordinary wildcards do not have the semantics that are typically required for many real world DNS management operations. .example.com will not match nodes that exist in the zone.
 
Until now some (most) DNS servers have gone their own way anbd defined the semantics that make most sense for administrative convenience. The deployment of DNSSEC means that we need to re-establish consitency. 
 
What this boils down to is that many folk would like to be able to define an administrative wildcard such as **.example.com, or maybe ?.example,com or maybe something else which triggers a macro processor built into the DNSSEC signing routine which expands the wildcard out to the complete set of records required.
 
We had lots of discussion on this, did we ever come to consensus on what the character for representing an administrative wildcard in a zone file might be??? I can't find it in the archive.

---

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Fri, 11 May 2007 17:22:40 -0400

The chairs asked for requirements for "alterative wildcards" and some people
volunteered for a design team. Nothing came out of it.
http://psg.com/lists/namedroppers/namedroppers.2005/msg00182.html

The chairs hosted a meeting on wildcards in general at the IETF meeting in
Minneapolis in March 2005, all the discussion there was about wcard-clarify.

So the question is: does anyone have requirements with or without
explicit proposals ?

Of the things I remember from the discussion is that people seemed to 
have different
requirements that where all being lumped together.

One group is calling for what I would call "Default" is a call for 
mechanism to
add default RRset at all names that do not have that RR type.

Another group wants wildcards to that work through empty non terminals.

I'm not sure the same solution would apply in both cases.

(this is not a complete list of what people want)

Some people say this is not a DNS server/protocol issue, but an issue to be
solved by a zone preprocessor, others want to be able to use dynamic update
to change things in that case at least the primary server needs to understand
what is being done.

         Olafur

At 16:23 11/05/2007, Hallam-Baker, Phillip wrote:
>I am trying to find out where the discussion of administrative 
>wildcards went, without much success so far.
>
>Ordinary wildcards do not have the semantics that are typically 
>required for many real world DNS management operations. .example.com 
>will not match nodes that exist in the zone.
>
>Until now some (most) DNS servers have gone their own way anbd 
>defined the semantics that make most sense for administrative 
>convenience. The deployment of DNSSEC means that we need to 
>re-establish consitency.
>
>What this boils down to is that many folk would like to be able to 
>define an administrative wildcard such as **.example.com, or maybe 
>?.example,com or maybe something else which triggers a macro 
>processor built into the DNSSEC signing routine which expands the 
>wildcard out to the complete set of records required.
>
>We had lots of discussion on this, did we ever come to consensus on 
>what the character for representing an administrative wildcard in a 
>zone file might be??? I can't find it in the archive.

--
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, 15 May 2007 05:44:26 -0700

I think that dynamic update and zone transfers are important here.

If we have a home user configuring their DNS via a gateway box it is quite likel that we will want to do DNSSEC processing, macro expansion &ct on the zone at the dynamic DNS hosted service.

If we have more than one possible semantics it is even more important to define symbols. Otherwise we have a real possibility of the same symbol being used with multiple semantics.

I was thinking mostly of a 'default' type wldcard. I am not sure whether binding to empty non terminals is very important. I can come up with lots of artificial examples, but there are rather few empty non terminals in conventional DNS zones. Most people have a suffix (example.com) and a single undifferentiated flat space beneath (a.example.com, b.example.com, ... )

Things are different with ENUM and reverse DNS. But I am not sure that is relevant.

> -----Original Message-----
> From: Ólafur Guðmundsson /DNSEXT co-chair [mailto:[email-masked]] 
> Sent: Friday, May 11, 2007 5:23 PM
> To: Hallam-Baker, Phillip; [email-masked]
> Subject: Re: DNS Administrative wildcards
> 
> 
> The chairs asked for requirements for "alterative wildcards" 
> and some people volunteered for a design team. Nothing came out of it.
> The chairs hosted a meeting on wildcards in general at the 
> IETF meeting in Minneapolis in March 2005, all the discussion 
> there was about wcard-clarify.
> 
> So the question is: does anyone have requirements with or 
> without explicit proposals ?
> 
> Of the things I remember from the discussion is that people 
> seemed to have different requirements that where all being 
> lumped together.
> 
> One group is calling for what I would call "Default" is a 
> call for mechanism to add default RRset at all names that do 
> not have that RR type.
> 
> Some people say this is not a DNS server/protocol issue, but 
> an issue to be solved by a zone preprocessor, others want to 
> be able to use dynamic update to change things in that case 
> at least the primary server needs to understand what is being done.
> 
>          Olafur
> 
> >Until now some (most) DNS servers have gone their own way 
> anbd defined 
> >the semantics that make most sense for administrative 
> convenience. The 
> >deployment of DNSSEC means that we need to re-establish consitency.
> >
> processor 
> >built into the DNSSEC signing routine which expands the 
> wildcard out to

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 May 2007 09:04:53 -0400

I circulated this privately some time back and it was soundly 'booed' 
so I put it on the shelf.  But the mention of dynamic update (which 
was the 'problem' was mentioned so I decided to dump this on the list.

STHSRC Resource Record

Problem Statement
===============

There is a desire to place records in the DNS to augment explicitly 
configured zone data.  One observation has been that this desire can 
be done by pre-calculating all the augmented names, which is 
basically what is done here - with the pre-calculating done at the 
place where zone data hits the master server.

E.g., any domain name that might appear as a source of email will 
also be able to own mail policy records in a manageable way.  The 
goal is to eliminate the need for an application to walk up or down 
the domain tree to find a policy that might apply.

Design constraints avoided/considered
==============================

o The augmentation rules are not in AXFR or IXFR.  The *results* of 
the augmentation are in the zone updates.
o The augmentation plays well with existing wild cards by augmenting 
the wild card.
o The augmentation plays with the underscore names by being oblivious 
to what that is.
o The augmentation plays with DNAME and CNAME as well as NS names.
o The augmentation does not alter the searching algorithms.
o The augmentation can work with just the master server understanding 
the STHSRC RR type.
o The augmentation rules affect the dynamic update process and the 
final stages of loading a zone.
o Other than the master server, no other element of the DNS has to be 
updated to use this.
o The requirement for the master server to have access to the DNSSEC 
key (if used) is assumed to be operationally acceptable.

Rules for the record
===============

owner.name. STHSRC domain.name.

This record is only processed at master servers.  To any other server 
(including slaves) it is just another record or an unknown RR type.

When the record is owned at a zone apex, all names names explicitly 
inside the zone are augmented with a copy of each RR set owned by the 
domain name in the RDATA if the corresponding RR set is not otherwise 
owned, subject to the following exceptions.  Domain names owning an 
NSEC3 RR set,  domain names owning a CNAME RR set and domain names 
owning no explicitly RR sets (i.e., empty non-terminals) do not get 
augmented.  (Notes: Non-apex names with NS RR sets are not explicitly 
inside the zone nor are results of wild card operations. The domain 
name in the RDATA of STHSRC is also not augmented via the rule of 
"corresponding RR set" mentioned above.)  This operation is done upon 
the loading of the zone and upon the receipt of a dynamic update.

The STHSRC record is not needed by slave servers as the AXFR/IXFR 
will contain the added RR sets.

The STHSRC record is not needed by cache servers as all data is 
pre-synthesized.

Note that the wildcard must exist to be included in the augmentation feature.

The RDATA of the STHSRC is treated as an opaque blob when included in 
DNSSEC processing (no down-casing) and in messages (no compression). 
However, note that any server that is STHSRC aware has to know that 
the RDATA is a domain name.

The domain name in the STHSRC MUST belong to the zone whose apex owns 
the record.

Only one STHSRC RR may be in the set.

If the zone is DNSSEC signed, the private key must be available to 
the master server while serving the zone.  This is because there is a 
need to sign the records upon loading and in response to dynamic 
updates.

Wild card domain names are augmented by the STHSRC record. 

If the records owned by the STHSRC RDATA domain name are changed, the 
changes are replicated to all affected names.

The STHSRC record can be queried and included in responses.

The STHSRC record can be owned by any (eligible) name.  Eligible 
means, for instance, not owning a CNAME RR set.

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

Sarcasm doesn't scale.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 16 May 2007 11:17:36 +0200

On Tue, May 15, 2007 at 09:04:53AM -0400,
 Edward Lewis <[email-masked]> wrote 
 a message of 104 lines which said:

> One observation has been that this desire can be done by
> pre-calculating all the augmented names, which is basically what is
> done here - with the pre-calculating done at the place where zone
> data hits the master server.

Your draft does not explain a lot *why* the pre-calculating will be
done in the name server.
 
> the augmentation are in the zone updates.

So, *most* of the functionality of STHSRC could be done with Perl /
Python / Ruby / Lua on the zone file / database.

> o The augmentation rules affect the dynamic update process 

It seems to me this is the only case where STHSRC is
useful. Everything else could be done by a program running before the
zone is loaded.

Is is worth it?

---

From: Edward Lewis <[email-masked]>
Date: Wed, 16 May 2007 07:56:06 -0400

>Your draft does not explain a lot *why* the pre-calculating will be

What was presented was not a "draft" in the sense of an Internet 
Draft, just a brush sketch of an idea.  Details are not there so that 
the point gets across.

I never said that the pre-calculating is done *in* the name server. 
It is done where the "zone data hits the master server."  As someone 
pointed out to me privately this could be implemented by a 
pre-process for zone loads and something that managed updates.

Keep in mind that my perspective is as a protocol designer, not a 
coder and not an application designer.  What I optimized for is 
compatibility with the existing protocol design.

>Python / Ruby / Lua on the zone file / database.

I never specified implementation.  As someone that cares about the 
protocol, I don't care about the coding effort.

>useful. Everything else could be done by a program running before the

Yes, that's pretty obvious (although I'd quibble with how you say 
this)[0].  But if we only do this via pre-processing, we have this 
odd corner case called dynamic update.  What I describe is something 
that turns that corner case into a feature.  And I also managed to 
dodge issues involving zone transfers (look closely, it is compatible 
with AXFR, IXFR and what ever alternative means is used for updates).

I should point out this too - if the synthesis source is updated, a 
lot of activity happens.  There's no real way around this - I assume 
that the synthesis source won't be altered all that frequently and 
when it is, the operator will be prepared for the consequences.  (The 
record definition can be classified by the IETF as experimental and 
still be useful, as only the "master" node has to run the 
experimental code.)

>Is is worth it?

This, like any other extension, means more work - more up front 
design work and more recurring operation expense.  But we are merely 
the engineers, the ones that carry out the effort to implement the 
extensions.  One of my quips when I hear this question is "should we 
let the bus drivers determine the route?"[1]

Whether it is worth it is a question for those who will make use of 
this.  Is what this offers going to solve a problem?  Is solving the 
problem of greater benefit than what it would cost to have it solved? 
We only deal with cost, they deal with budget, and a "worth it" 
question is a budget question.

What we can answer is whether the approach under consideration is the 
most efficient way to solve the problem.  There are two parts to that 
decision - one is what is most efficient and what is the problem.  As 
has been stated on this list, the problem has never been completely 
stated, so if what I presented solves the wrong problem then this 
suggestion goes no where.  As far as measuring efficiency, my metric 
was minimizing disruption to the status quo of the protocol design.

[0] - The record is not "useful" in anyway relative to dynamic 
update.  But it is because of dynamic update that I came up with the 
design I presented.  I should also add that it was the zone transfer 
problem that drove me to something that did all the work at the 
master node.  That is, if you wanted to do the generation at the 
slave servers, the slaves have to get the synthesis rules.  You would 
have to stuff these rules into the AXFR and IXFR formats ("have to" 
protocol design wise - regardless of whether AXFR or IXFR is used in 
an operational set up) and that proved to be difficult to me.

[1] As in - if the bus driver were to design a route, the bus might 
go back and forth on one straight boulevard and all passengers would 
have to walk to the boulevard to get to the bus and to the 
destination.  What's easy for the driver might inconvenience the 
paying customers.

Sarcasm doesn't scale.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 16 May 2007 14:22:22 +0200

On Wed, May 16, 2007 at 07:56:06AM -0400,
 Edward Lewis <[email-masked]> wrote 
 a message of 105 lines which said:

> I never specified implementation. 

What I meaned is that STHSRC is almost useless since a nameserver
manager can do it immediately himself (unless he requires dynamic
update), without waiting for the IETF.

Since it does not appear "on the wire" (except for dynamic updates), I
am not even sure this record type is on-topic.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 16 May 2007 12:52:19 +0000

> useful. Everything else could be done by a program running before the

no.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 17 May 2007 15:03:49 -0400

> update), without waiting for the IETF.

So it would seem that it's necessary to answer whether dynamic updates
are a condition under which this sort of feature is needed.  (I don't
think I need the feature, but someone apparently does, or we wouldn't
be having the conversation, right?)  Since some people say that zone
preprocessing isn't enough (at least, that's what I recall from the
last round on this topic), apparently some people _do_ need a feature
that works in the presence of dynamic updates.

But this all seems sort of cart before the horse, since as Ed pointed
out, he has an idea for a proposal, but he doesn't know what the
problem to be solved is yet.  If there's been a clear outline of the
problem(s) people are trying to solve, I haven't understood it.

A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

---

From: Florian Weimer <[email-masked]>
Date: Fri, 18 May 2007 10:18:55 +0200

* Stephane Bortzmeyer:

> Since it does not appear "on the wire"

But it does.  You can explicitly query for those records.  I would
like to hear the rationale for this, though.

If there isn't a compelling need for this particular behavior, instead
of a RR, a new $ directive similar to $GENERATE could be used.  And as
you said, it's not clear if there is any need for a standard.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 18 May 2007 08:59:50 -0400

>like to hear the rationale for this, though.

By permitting these records to be queried no changes are required to 
the slave servers nor the caches, no changes to the query processing 
model anywhere.  The optimization function I used in designing this 
was to be compatible with the current protocol.  For instance, slave 
servers can treat this record type as one of the "unknown" ones as it 
has not special processing except when zone changes are made (load 
and update).

>you said, it's not clear if there is any need for a standard.

Not that this proposal seems to have any support, I wouldn't promote 
it as a standard, just experimental.  If you consider that to be 
"standard" the only reason for it is to allow a server to change it's 
software build, use the same data, and get the same results.  That is 
one component of interoperability.

I am not saying that this is in support for this proposal.  But the 
general lack of happiness with the "just use a directive" seems to 
indicate something is wanted.  The reason I wrote this as I have is 
that I am convinced that we've about wrung out as much as we are 
going to get with the DNS design and implementation (evidence by the 
lack of work in this group).  So I am trying to find something that 
creeps towards a solution to the need I am hearing while not breaking 
from the design today.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Sarcasm doesn't scale.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 18 May 2007 15:35:58 +0200

On Fri, May 18, 2007 at 08:59:50AM -0400,
 Edward Lewis <[email-masked]> wrote 
 a message of 45 lines which said:

> For instance, slave servers can treat this record type as one of the
> "unknown" ones as it has not special processing except when zone
> changes are made (load and update).

I thought I understand the proposal but, now, I'm lost. Is the new
record type transmitted to slaves with AXFR/IXFR (like wildcards or
CNAME are) or not? I thought not. Now, it seems it is?

> But the general lack of happiness with the "just use a directive"

What is wrong with "Use a BIND $GENERATE or M4 or Perl"? The only
thing I see is the lack of dynamic update. Is there another problem?

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 18 May 2007 15:24:30 +0200

On 2007/05/15 14:05, "Hallam-Baker, Phillip" <[email-masked]> wrote:
>
> I was thinking mostly of a 'default' type wldcard. I am not sure
> whether binding to empty non terminals is very important. I can
> come up with lots of artificial examples, but there are rather few
> empty non terminals in conventional DNS zones. Most people have a
> suffix (example.com) and a single undifferentiated flat space beneath
> (a.example.com, b.example.com, ... )
>

Indeed.

The empty non-terminals not being matched by wildcards hit us when
doing the Austrian Infrastructure ENUM setup where we have a lot
of wildcards (long story, quick summary: yes, there is no way around
those wildcards).

I solved the issue by writing a preprocessor which adds the necessary
records to restore pre-RFC4592 bind behaviour. 

That works fine for full zone loads, but we haven't extended that solution
to dynamic updates. 

/ol

---

From: Edward Lewis <[email-masked]>
Date: Fri, 18 May 2007 14:08:39 -0400

>CNAME are) or not? I thought not. Now, it seems it is?

Yes, it is transmitted, but so are all of the "results" of its 
presence.  It is transmitted because there is no reason not to do so 
- there is no benefit in it being transmitted other than its just 
easier to limit special cases.

>thing I see is the lack of dynamic update. Is there another problem?

Well, there is dynamic update.  In so much as that dynamic update is 
part of the protocol, and we have been fighting to have a coherent 
protocol definition for so long, whatever extension that comes along 
will be more stable if it works side-by-side with dynamic update.

Sarcasm doesn't scale.