Subject: RE: a suggestion for super-wildcards

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Jul 2006 08:11:26 -0700

> [mailto:[email-masked]] On Behalf Of Roy Arends

> Stephane Bortzmeyer wrote on 07/26/2006 09:44:21 AM:
> 
> > On Tue, Jul 25, 2006 at 02:25:45PM -0400,  Edward Lewis 
> > <[email-masked]> wrote  a message of 33 lines which said:
> > 
> > > >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.
> > 
> > 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.)

Which is of course exactly how I would expect legacy resolvers to handle the scheme. This part of the scheme is the same as

If it was not for zone transfers and for DNSSEC there would be no reason to have wildcards mentioned in the protocol spec at all. That is why the ambiguity could enter the system and create the need for clarification decades later.

In the context of DKIM there is a need to demonstrate that the wildcard problem can be solved by a script. Note that this wildcard problem, the fact that wildcards don't have the exact semantics you would want is an issue regardless of how the records are encoded (TXT, new record, prefixed, not).

The alternatives on offer here are 
	1) The existing heuristic search 
	2) The macro-wildcard mechanism proposed here plus a new RR
	3) The macro-wildcard mechanism plus the pointer scheme 'super-wildcards' 
		with either a new RR or a prefix label

I think that most of us here would agree that (1) is not a satisfactory solution.

> Okay, it can be preprocessed, but that is going to be a 
> helluva big zone

The expansion factor for super-wildcards is similar to the expansion factor for DNSSEC, i.e the number of new records is proportional to the number of nodes plus the number of protocol policy declarations.

The expansion factor for macro-wildcards plus a new RR is the proportional to the number of nodes MULTIPLIED BY the number of protocol policy declarations.

If we believe that DKIM is the only protocol policy record we will need then both schemes result in the same expansion of the zone.

My belief is that we are about to see a dramatic expansion in the number of Internet protocols as a result of Web services. The key here is that the variation in services for human consumption is rather small because people need consistency in their user interfaces. I don't expect there to be many new human interface protocols, the exceptions to this rule are mostly games. Machine/Machine interfaces are not constrained in that way, I expect we will have hundreds of Web Services in regular use and SOAP is sufficiently complex that a policy layer is essential for configuration.

We could develop something like UDDI or XRI. I don't like the idea of yet another registry. We could use LDAP but today LDAP stops at the firewall and that is going to be the case tommorow as well and I don't expect that to change. LDAP is too powerful and too complex for border directories to be something people get comfortable with.

--
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: Wed, 26 Jul 2006 08:12:47 -0700

> [mailto:[email-masked]] On Behalf Of Paul Vixie

> > otherwise be implemented by any preprocessor. ...
> 
> me too.  but i do want two new kinds of wildcards, which 
> cannot be done by preprocessors.  see below.  but first:
> 
> > 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.

Could you elaborate?

---

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

"Hallam-Baker, Phillip" <[email-masked]> wrote on 07/26/2006 05:11:26 
PM:

> The expansion factor for super-wildcards is similar to the expansion
> factor for DNSSEC, i.e the number of new records is proportional to 
> the number of nodes plus the number of protocol policy declarations.

Note that I was referring to preprocessing non-existant names. 
Wilder-cards (to coin yet another term) is about a directive which 
instructs a process to generate certain types at _existing_ names 
(including non-terminals).

Roy

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Jul 2006 12:38:06 -0700

OK in response to a request for clarification here:

> Hallam-Baker, Phillip

> Which is of course exactly how I would expect legacy 
> resolvers to handle the scheme. This part of the scheme is the same as

Should be "This part of the scheme is the same as we would have to do to satisfy the use cases for policy administration even with a new record"

>
> If it was not for zone transfers and for DNSSEC there would 
> be no reason to have wildcards mentioned in the protocol spec 
> at all. That is why the ambiguity could enter the system and 
> create the need for clarification decades later.

The point here is that a wildcard only ever appears on the wire in a DNS protocol exchange in two cases:

1) During a zone transfer
2) If DNSSEC is in use

If neither of these features existed there would be no reason for wildcards to be mentioned in the DNS spec at all. They would be a server configuration feature, no more. It would not matter how the wildcards were defined, there would be no interoperability issue.

The interoperability issue here has become apparent because we do have DNSSEC. I believe that the definition of wildcard we have now is the optimal one for DNSSEC. I don't suggest changing it since doing so would result in complexity being shifted to other parts of the spec.

If wildcards were a feature that appeared on the wire in contexts which required interoperation I am sure that the ambiguities in the original definition would have been discovered earlier.

> In the context of DKIM there is a need to demonstrate that 
> the wildcard problem can be solved by a script. Note that 
> this wildcard problem, the fact that wildcards don't have the 
> exact semantics you would want is an issue regardless of how 
> the records are encoded (TXT, new record, prefixed, not).
> 

To give some more context. At present a DKIM policy record can make two useful statements that we all agree are essential:

1) This mail domain originates no mail.
2) All mail that this domain originates is signed.

In case (1) the messages can simply be blocked. For example mail from ver1sign.com is all bogus without exception and should be junked, the domain is only registered to prevent cybersquatters.

In case 2 an unsigned message or a message with a failed signature might be fake or might be a legitimate message that was mangled somehow. This information plus other information may be used by spam filters, phishing detection etc.

So the problem with policy is how to declare an email signing policy for **.example.com that takes effect if there is no more specific policy. The objective being to specify policies such as:

example.com     DKIM  "ALL mail is signed"
**.example.com  DKIM  "No mail is originated"

In the case that example.com is paypal.com or bankamerica.com I think we can all agree that policies of this type are legitimate. In the case that someone has complaints about the management of *.cs.utk.edu they can take it up with their admin. Anyone who really, really wants to set their email configuration themselves should buy themselves their own domain name. Its like owning your own cell phone number, more important than you might think.

The problem is that you may have an attacker send an email from 

A.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.example.com

Checking every node for a policy record is not acceptable. This is made worse when you use a prefix convention (similar to SRV) as you can't even use a traditional wildcard.

At present the spec has a heuristic algorithm, walk up the tree three rungs from the bottom, then start at the top. That is the option (1) described.

If we define a new RR we can replace the heuristic algorithm with a scripted wildcard (macro-wildcard). This works for DKIM but doing it this way means that we have to repeat the process for every protocol that has a defined policy and the number of macro wildcards will quickly increase.

The third option is macro-wildcards plus pointers (super-wildcards). This provides a clear benefit whether you define a new RR or not.

The only impact that super-wildcards have on defining a new record are:

1) You might not want to redefine PTR for use in the forward DNS in this way and so want to define a new RR

2) The super wildcard scheme is prefix friendly and so you may not want to use a new record for the policy scheme.

If there was no legacy deployment of DNS my preferred route would be to propose defining a new RR for the pointer and a new RR which would be used in the same way as SRV, prefixed for defining policy records.

Given the DNS legacy that we have and the fact that much of it is now embedded in NAT boxes such as the netgear I just threw out as a POS I am very averse to creating new RRs unless there is a very significant change in the functionality of DNS itself.

I can imaging getting netgear and linksys to make a DNSSEC capable NAT box, I can't see people making special arrangements for DKIM. This is a problem for me because I see Secure Letterhead as the train to drive deployment of DKIM and DKIM as the train to drive deployment of DNSSEC and thus in turn the infrastructure changes necessary to support new DNS records. If deployment of DNSSEC becomes a precondition for deployment of DKIM I have a deadlock situation. In the simulation models I have run deployment takes decades rather than years with the same set of value proposition assumptions.

> 
> > Okay, it can be preprocessed, but that is going to be a helluva big 
> > zone
> 
> The expansion factor for super-wildcards is similar to the 
> expansion factor for DNSSEC, i.e the number of new records is 
> proportional to the number of nodes plus the number of 
> protocol policy declarations.
> 
> The expansion factor for macro-wildcards plus a new RR is the 
> proportional to the number of nodes MULTIPLIED BY the number 
> of protocol policy declarations.
> 
> 
> If we believe that DKIM is the only protocol policy record we 
> will need then both schemes result in the same expansion of the zone.
> 
> My belief is that we are about to see a dramatic expansion in 
> the number of Internet protocols as a result of Web services. 
> The key here is that the variation in services for human 
> consumption is rather small because people need consistency 
> in their user interfaces. I don't expect there to be many new 
> human interface protocols, the exceptions to this rule are 
> mostly games. Machine/Machine interfaces are not constrained 
> in that way, I expect we will have hundreds of Web Services 
> in regular use and SOAP is sufficiently complex that a policy 
> layer is essential for configuration.
> 
> We could develop something like UDDI or XRI. I don't like the 
> idea of yet another registry. We could use LDAP but today 
> LDAP stops at the firewall and that is going to be the case 
> tommorow as well and I don't expect that to change. LDAP is 
> too powerful and too complex for border directories to be 
> something people get comfortable with.
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' 
> in a single line as the message text body.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Jul 2006 17:20:43 -0700

The policies relate to the use of a DNS name.

Therefore they will be in the DNS

This is not negotiable. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, July 26, 2006 7:58 PM
> To: Hallam-Baker, Phillip
> Cc: Roy Arends; [email-masked]
> Subject: Re: a suggestion for super-wildcards 
> 
> 
> 	Why is the policy in the DNS in the first place?
> 	It keeps looking less and less like a good fit.
> 	Add a way to find a DKIM policy server to the DNS
> 	and let it hand out the actual policies.  This
> 	should make it very easy for per user policies without
> 	having to worry about namespace collisions which is
> 	what the underscores where trying to prevent with SRV.
> 	
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
> 
>

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Jul 2006 10:42:55 +1000

> The policies relate to the use of a DNS name.

	No.  They relate to mail domains.  We may store somethings
	about mail domains in the DNS.  We also store things about
	mail domain in NIS, and HOST.TXT files.

> Therefore they will be in the DNS

	Saying something is "not negotiable" is utter crap.

	Mark

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Jul 2006 20:27:43 -0700

> 	mail domain in NIS, and HOST.TXT files.

The only mail domains that matter are the DNS. Hosts.txt is now a serious security hazard and should be eliminated on non test machines.

NIS is not an Internet resource. If your NIS service is visible outside your firewall you have big problems. It is irrelevant to this issue.

> 	Saying something is "not negotiable" is utter crap.

The DNS is the only credible resource to distribute this information. Get over it.

If a different resource is used there will be no way for DKIM to drive DNSSEC deployment.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Jul 2006 13:33:33 +1000

> The only mail domains that matter are the DNS. Hosts.txt is now a serious sec
> urity hazard and should be eliminated on non test machines.
> 
> NIS is not an Internet resource. If your NIS service is visible outside your 
> firewall you have big problems. It is irrelevant to this issue.
> 
 
	Did you even read what I proposed?  The above comments indicate
	that you didn't or that you failed to understand the proposal.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Jul 2006 21:03:33 -0700

> 	that you didn't or that you failed to understand the proposal.

Yes, I am fully familiar with the limitations of that approach. I was the editor of XKMS which does precisely what you propose.

First you still have the discovery problem for the XKMS service. You have to have a way of discovering the policy service for each DNS node. So you end up with precisely the same set of problems only with SRV records.

Incidentally the same extension should be made to SRV and NAPTR, the idea is that superwildcards should be a generic mechanism applied to ANY prefixed lookup to a node.

If you are going to go find a policy distribution service you might as well retrieve the policy if it is as simple as 'I sign all mail' or 'I send no mail'. 

Clearly there is a balance point, I even propose retrieving longer policies via URL.

Whichever way you go though you need to employ the DNS as the signalling mechanism. There can only be one Internet name space.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 27 Jul 2006 07:38:19 -0700

> From: Doug Barton [mailto:[email-masked]] 

> On the one hand, because I have in the past wanted something 
> similar to what you're proposing, the theoretical concept of 
> these super wildcards is appealing. However, from a protocol 
> standpoint the idea gives me a serious case of the screaming 
> heebeejeebees.

Screaming? 

> So, I have a question ...
> 
> Hallam-Baker, Phillip wrote:

> > So the problem with policy is how to declare an email 
> signing policy 
> > for **.example.com that takes effect if there is no more specific 
> > policy. The objective being to specify policies such as:
> > 
> Ok, your problem statement makes total sense to me, but I 
> think you're missing a third option. I'm assuming that the 
> DKIM protocol has a way to handle total absence of a policy 
> for a domain. So, what if you added a heuristic to the DKIM 
> protocol that says, "If I do not find a policy at this node, 
> I will go down the tree until I either find a policy, or hit the TLD."

It's the heuristic that gives me the heebeejeebees of the screaming variety. Either you walk the tree and allow attackers to stick you with 60 lookups or you add in some constraints and you change the semantics of the DNS delegation as Olafur pointed out in the meeting.

If you walk the tree you allow upper level domains to control the email sending policy of lower domains even if that lower domain thinks that it has full control because it has a delegation. Debugging problems could well get ugly, even more so if you are running split DNS.

> In regards to your problem of spammers that try sending mail 
> from 1.2.3.4..99.spammer-domain.tld, if the spammers have 
> control over that domain and can add a node at that point, it 
> will eat up resources to walk that tree, no doubt. OTOH, if 
> they are playing silly buggers with a domain they don't have 
> control over, I assume DKIM is smart enough to say that if 
> there are NO records at all for a node, that it isn't 
> legitimate? 

A lot of mail originates from addresses that are not externally visible due to split DNS and the use of DNS wildcard MX records.

The problem with the heuristic is that it results in yet another set of semantics to deal with and possibly end up with conflicts.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Jul 2006 09:27:33 +1000

> It's the heuristic that gives me the heebeejeebees of the screaming variety. E
> ither you walk the tree and allow attackers to stick you with 60 lookups or yo
> u add in some constraints and you change the semantics of the DNS delegation a
> s Olafur pointed out in the meeting.
> 
> If you walk the tree you allow upper level domains to control the email sendin
> g policy of lower domains even if that lower domain thinks that it has full co
> ntrol because it has a delegation. Debugging problems could well get ugly, eve
> n more so if you are running split DNS.

	Given you only want to trust signed and validated answers.
	The signatures themselves define the search range.

	If you don't want to limit answers to signed zones only
	you seach for the zone cut in parallel to looking for the
	records.

> A lot of mail originates from addresses that are not externally visible due to
>  split DNS and the use of DNS wildcard MX records.
> 
> The problem with the heuristic is that it results in yet another set of semant
> ics to deal with and possibly end up with conflicts.
> 
> --

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 28 Jul 2006 09:44:23 -0700

There are two parts to my proposal:

1) Define a 'wilder card' ** that matches a node if the result would otherwise be NO-DATA and which acts on subdomains as well

2) The pointer mechanism.

>From a protocol point of view I think that we should do the first in any case since it will ease the transition from non-compliant wildcards to compliant wildcards when DNSSEC is in use. In particular many existing DNS implementations already implement the ** semantics since this is what administrators need to define MX records.

Wildcards only ever appear on the wire in two cases - DNSSEC and Zone transfers. It would certainly be nice if zone transfers were interoperable but empirically this has not been considered a major requirement. 

DNSSEC is a more complex issue, if we were starting the design of DNSSEC I would say we need both forms of wildcard. At this point I think that it is clear that we need a macro processor. The expansion of the wild cards must take place before the zone is signed.

The main reason for defining the ** 'wildercard' in a document is that there is a third important use which probably dominates the zone transfer issue, people swap configuration information through email. One of the nice things about DNS is that you can give someone a snippet of a zone file and they can probably use it regardless of what platform they use.

The pointer mechanism does not need to be specified in the DNS protocol unless we decide to revise the SRV specification. This mechanism is only used the protocols that use the DNS for policy discovery. Regardless of whether you think DNS policy distribution is a good or a bad thing, I think it is clear that the discovery mechanism for finding out where to find the policy has to be supported by the signalling infrastructure that supports the name space in use. On the Internet that is the DNS, not LDAP, not NIS, not X.500.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 31 Jul 2006 15:43:47 -0700

> Yeah, and they are getting worse.

Fortunately you are reading the description of the alternative.

> > It's the heuristic that gives me the heebeejeebees of the screaming
> variety. Either you walk the tree and allow attackers to 
> stick you with 60 lookups or you add in some constraints and 
> you change the semantics of the DNS delegation as Olafur 
> pointed out in the meeting.
> 
> I wasn't sure I really understood what you were asking for 
> here when I first read this. Now that you've clarified it 
> further, I am sure I don't like it.

Me neither, the idea of super wildcards is to avoid the need to do this.

> There is an enormous difference between a super-wildcard that 
> synthesizes a response for something that doesn't exist, and 
> one that _overrides_ the records in a child domain. (BTW, I 
> have a hard time following your use of "upper" and "lower," 
> you might want to stick with the DNS terms of art "parent" 
> and "child.") I could muster up support for a good 
> implementation of the former, but I cannot imagine a scenario 
> where I would support the latter.

What I want to see is the former.

**.example.com would match responses where there is no record of a given type at a node. If there is a record of the given type at the node it always take precedence, if there is a closer wildcard match it also takes precedence.

I don't see this being different in principle to existing wildcards. 

> Changing "the semantics of 
> the DNS delegation" as you describe is too revolutionary a 
> change in my mind. Not only because it breaks with the entire 
> tradition of the deployed DNS (and therefore loses on POLA 
> grounds alone), but also because I can see this type of 
> record leading to nightmare debugging problems with anything 
> other than very simple delegations.

Hence my desire to avoid the need for the heuristic altogether. 

The point to defining the ** wildcard is to make it clear that people do not need to do this type of thing even though they may think they need to.

> This is the kind of problem that needs to be solved at layer 
> 8, where the parent zone administrator makes the requirement 
> of proper DKIM records a condition of receiving the 
> delegation, and if that policy is breached, they pull the 
> delegation. I am sure that other solutions are possible that 
> do not entail radically changing "the semantics of the DNS 
> delegation." Although it has its own drawbacks, e-mail 
> headers could be used to specify where to find the DKIM 
> policy, for example.

That is pretty much what I would want to see. Not least because domain delegation itself implies a pretty substantial handover of control.

> Also, Mark gave you a really good answer on this point, which 
> TMK you did not respond to. I would really like to see an 
> explanation of why what Mark suggested doesn't help, or isn't 
> suitable.

Have not seen the post.

> I'm not sure what set of problems you're concerned with here, 
> but my concern is for the debugging nightmare that these 
> super-wildcards you propose would cause for DNS in general, 
> not specifically related to the DKIM case.

Again, you have confused super wildcards with the description of the hack around they are intended to avoid.

There is no tree walking in my scheme, every lookup takes a maximum of three queries.

> > A lot of mail originates from addresses that are not externally 
> > visible
> due to split DNS and the use of DNS wildcard MX records.
> 
> If I understand what you're saying here correctly, I would 
> suggest that this is an error in any case. If you're sending 
> me mail with the expectation that I should be able to reply 
> to it, then I need an address to reply to that is visible in 
> my view of the DNS. If your From: address isn't visible to me 
> in DNS, the message is probably spam anyways.

The folk who have done the empirics on this disagree.

> > The problem with the heuristic is that it results in yet 
> another set 
> > of
> semantics to deal with and possibly end up with conflicts.
> 
> If I understand you correctly, the conflicts you are 
> concerned about result from your premise that child domains 
> should not be able to set a DKIM policy that is different 
> from that of their parent(s). 

No that is not the concern. Again, you are tilting at the wrong opponent here.

> > 1) Define a 'wilder card' ** that matches a node if the 
> result would 
> > otherwise be NO-DATA and which acts on subdomains as well
> 
> As I said above, I do not support the latter in the way that 
> you are proposing it.
> 
> > From a protocol point of view I think that we should do the 
> first in 
> > any case since it will ease the transition from non-compliant 
> > wildcards to compliant wildcards when DNSSEC is in use.
> 
> Can you please flesh this out a bit, preferably with examples?

> > In particular many existing
> > DNS implementations already implement the ** semantics 
> since this is 
> > what  administrators need to define MX records.
> 
> Once again, can you give examples, preferably with reference 
> to documentation?

If you have the following nodes:

a.example.com   A  10.1.1.1
*.example.com   MX 1 1 email.example.com

The MX record does not match a.example.com because there is an a record at the node. So if you want to direct all mail delivery to email.example.com you have to add in explicit wildcards:

a.example.com   A  10.1.1.1
*.example.com   MX 1 1 email.example.com
a.example.com   MX 1 1 email.example.com

If you have fifty odd hosts this is a PITA. So some DNS servers actually specify wildcard semantics that have a looser match.

> > Regardless of whether you think DNS policy distribution is 
> a good or a 
> > bad thing, I think it is clear that the discovery mechanism for 
> > finding out where to find the policy has to be supported by the 
> > signalling infrastructure that supports the name space in 
> use. On the 
> > Internet that is the DNS, not LDAP, not NIS, not X.500.
> 
> So, we have to support it whether we think it's a good idea 
> or not? (And no, you don't get any points for trying to make 
> a meta-distinction between policy discovery and policy 
> discovery discovery.)

I think it is clear that the DNS will be the infrastructure chosen to support this function.

What do you mean by 'we have to support it'? The proposal is entirely compatible with the legacy deployed infrastructure. The whole point is not to need any support from DNS infrastructure providers.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 31 Jul 2006 17:13:28 -0700

> The main difference I see is that crosses delegation points, 
> which still leads to confusion and problems of the "how did 
> something get into the foo.example.com zone that is not in 
> the foo.example.com zone file?" variety, although in the more 
> limited form that you describe, those questions may be in the 
> "trainable" category.

It doesn't. Not unless you can explain to me how to do that with a macro :-)

The parent zone could send the responses but it would not get asked the question if the requestor had already seen the delegation.

> Can you give some references? I'd love to educate myself more 
> on this topic.

Its mostly on the DKIM list I am afraid, not collected in a coherent way.

> >> As I said above, I do not support the latter in the way 
> that you are 
> >> proposing it.
> >> 
> Did you intend to fill something in here?

Windows DNS already uses loose wildcards. If the cost of deploying dnssec is to redefine existing macros then dnnsec is a harder sell.

> > If you have fifty odd hosts this is a PITA.
> 
> Thanks, I'm glad to see that on this point at least I 
> understood you clearly. I solved this problem a long time ago 
> with preprocessors, so I stopped caring. :)

The idea here is to istitutionalize the principle of doing so.

> > So some DNS servers actually
> > specify wildcard semantics that have a looser match.
> 
> Which DNS servers?

Windows DNS, djbdns.