Subject: a suggestion for super-wildcards

From: Edward Lewis <[email-masked]>
Date: Tue, 25 Jul 2006 14:25:45 -0400

At 9:55 AM -0700 7/25/06, Hallam-Baker, Phillip wrote:
>CC'd to namedroppers for wider discussion.

I'm addressing this reply to only namedroppers.

>So our configuration file is:
>
>**.example.com      PTR  _default.example.com
>a.example.com       A    10.0.0.1
>_dkim.example.com   TXT  "dkim record"
>
>This is then processed by a preprocessor to produce the actual DNS zone:
>
>**.example.com      PTR  _default.example.com
>a.example.com       A    10.0.0.1
>a.example.com       PTR  _default.example.com
>_dkim.example.com   TXT  "dkim record"

E.g., BIND's $GENERATE directive, on steroids.

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

Soccer/Futbol. IPv6.  Both have lots of 1's and 0's and have a hard time
catching on in North America.

--
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: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 26 Jul 2006 09:44:21 +0200

On Tue, Jul 25, 2006 at 02:25:45PM -0400,
 Edward Lewis <[email-masked]> wrote 

> E.g., BIND's $GENERATE directive, on steroids.

I'm always puzzled by proposal to add in the DNS things that could
otherwise be implemented by any preprocessor. The only advantage is to
make the transferred zone smaller (but it forces all the secondaries
to upgrade to a version supporting the new syntax).

Unless I missed another advantage, I suggest to dismiss all these
proposals with a "Learn cpp or m4 or Perl or anything". (And I'm not
sure it was a good idea to specify the file format, anyway. IETF
should be about protocols, not about file formats.)

For the same reason, I think that DNAMEs are a bad idea.

---

From: Roy Arends <[email-masked]>
Date: Wed, 26 Jul 2006 11:36:32 +0200

> For the same reason, I think that DNAMEs are a bad idea.

There is a difference in what can and can not be preprocessed. Phill's 
(Ed's) proposal can be implemented by preprocessing and out of protocol, 
i.e. adding a record type for existing names. DNAME's can not be 
preprocessed, since qname does not match at the DNAME ownername, but 
below. 

The same goes for anything that does not match an existing name.

Okay, it can be preprocessed, but that is going to be a helluva big zone 
;-)

Roy

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 26 Jul 2006 13:11:44 +0200

On Wed, Jul 26, 2006 at 11:36:32AM +0200,
 Roy Arends <[email-masked]> wrote 
 a message of 45 lines which said:

> There is a difference in what can and can not be preprocessed. 

Yes. Ordinary wildcards cannot be preprocessed.

> DNAME's can not be preprocessed, since qname does not match at the
> DNAME ownername, but below.

I did not say that DNAME could be preprocessed but that DNAME was a
bad idea because the same effect (solving the use cases in section 2
"Motivation" of RFC 2672, typically network renumbering and company
name changing) could be attained by preprocessing.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 26 Jul 2006 09:43:37 -0400

Pouring cold water on a spark you don't want is quite refreshing but 
may be giving the wrong impression.

On the one hand, it would be really cool if there was a way to expand 
the notion of record and answer synthesis in DNS.  Performing a 
mental exercise on this, eventually you realize that we could just 
throw in a full-fledged database, etc., etc.  Or perhaps LDAP and 
X.500.

The reason that isn't what is being done, why sparks of ideas to add 
things like super wildcards is that DNS offers certain advantages - 
speedy responses, a loosely coordinated management structure that 
permits wild scaling, and good-enough replication.

The cost of maintaining DNS in its original spirit, which is the key 
to retaining its advantages, is that functionality is pushed outward 
(from the "core" DNS), to things like pre-processors.  It's quite 
easy to off-load all DNS advancement to such gadgets - from the 
perspective of protocol engineers.

The net of doing this is an increase in gadgets.  There's a choice - 
in order to perform a job requiring a fixed amount of work, you can 
have lots of simple gadgets or a few complex gadgets.  We in the this 
group are gadget makers and prefer small, simple ones.  This means we 
are putting pressure on operators and applications writers to make do 
with lots of simple tools.

Perhaps that's all well and good - creating a need for a layer above 
DNS to once again make the gadgets seem as one, easier to track and 
manage.  But, on the other hand, it can be seen as just another layer 
of complexity to be offered by someone else.

The talk below is about DNAME.  But I would also lump in MX and CNAME 
as two earlier records which set bad precedents.  They were 
customizations of the DNS to appease needs at the dawn of time. 
Today we don't think of MX and CNAME as problems, but that's because 
they are like the goofy old uncle that's been around the house too 
long.  CNAME is a pain because of what it does to the algorithm in 
4.3.2 or 1034.  MX because it causes confusion of how wildcards 
operate.

(While I'm at being crotchety - if we hadn't invented the NS record, 
we wouldn't have ICANN to kick around. And the A record - oh, the 
trouble it has caused!)

Do I have a point?  Probably not, maybe it was the 45 minute drive on 
Route 28 that's prompting me to write.  (When are they going to 
finish that bridge!)  But I guess what I wanted to say is that 
although my response said to "use preprocessing" that doesn't mean to 
say that expanding answer synthesis is a bad idea.  By "pushing the 
limits" in the subject I an inferring that I have doubts that it can 
be easily done - the big problem is the zone transfer process.

I think we should not consider record synthesis a problem rooted in 
complexity nor something that is easily done by more gadgets on the 
side of the DNS operation table.  My doubts are that we are able to 
fit it into the protocol as it stands.  I'd like to see it, but we'd 
have to overhaul the zone transfer - for new followers, the AXFR 
clarify draft has been on the shelf since about summer 2002.  If we 
can't clarify it, we can't extend it.

(Oh, and I'm omitting that code to perform the synthesis is needed - 
but I figure that's the easy part - as I'm not a coder.)

Okay, maybe there was no point, but I'm no longer fuming about traffic.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 26 Jul 2006 14:52:40 +0000

> otherwise be implemented by any preprocessor. ...

me too.  but i do want two new kinds of wildcards, which cannot be done

> For the same reason, I think that DNAMEs are a bad idea.

DNAME cannot be accomplished by a preprocessor.

but two kinds of wildcards which would help SRV a lot and be generally
useful, are nonterminal and per-qtype.