Subject: Re: wildcards vs. RR types, was Faux wildcards

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 16 Jan 2005 21:29:51 -0800 (PST)

On 17 Jan 2005, John Levine wrote:

> >What John really needs to address his admin issues is a DNS server macro.
> >People who need that feature can unilaterally upgrade their DNS server to
> >one that supports the feature needed. Nobody else need be affected.
> 
> Yes indeed.  If I could tell my server to serve this record for any
> request that matches _client.smtp.*.example.com I'd be a happy camper,

That is pretty much what I'm trying to propose, new wildcard that supports
prefixes and answers when host exist and not only when it does not, for
what you want you would add "_client.smtp.**" in the zone file. 

However as Paul Vixie said couple times already, we can go ahead and propose
it, have the draft discussed at namedroppers, etc. But it will take several
years for it to become a standard and to have been implemented in majority
of dns servers and people to have installed new versions of the software. 
So for immediate needs of SPF or CSV domain administrators, this would not 
exactly work.

What I had been trying to push for is to supplement it with simple algorithm
that would allow client to look for exactly same wildcard. This does mean 
additional dns lookup, but clients will not be doing lookups any more 
when dns servers are updated and can sythesize the response (and end-user 
does not even need to know about it - he just enters this new wildcard 
record and it works, either with server that understands it or if not 
with client that looks for it).

This has primarily been discussed at SPF-discuss last week and I think people
there agree that its reasonable compromise (doing both as DNS extension 
for new wildcard and directly looking for it at zonecut). And regarding 
zonecut as mentioned I checked top 10 dns servers and they all provide 
"hint" of where zonecut is in the form of SOA in the AUTHORITY section.

There is also no big deal if this hint and wildcard is not availble to 
every user, we just want it available for greater majority so that there
is not much cause for bad guys to try to abuse it and and seeing as the 
numbers would be something like 95% of users would see it (the only case I
could find is the one you wrote about with djb caching dns servers that do 
not show the AUTHORITY when serving record from cache), I think we're fine.

And as this is very simple algorithm that avoids having to "search" for
zonecut - if hint is avalable, then use it, if not not don't bother. The 
good thing about it is that at most 1 extra dns lookup is done and no 
"tree walking" (which is bad as it could result in arbitrary large number 
of dns requests) as what had proposed by CLEAR group (ietf-clear is where 
CSV is discussed).

As far as draft of all the above with introduction of new wildcard - people
at namedroppers can expect one probably by Paris meeting.

> The wildcard theory is that if you deploy new RR types, you don't need
> prefixes, so wildcards work.  As Phill and I agree (wow, alert the
> media) actually, they don't, since any RR at a node keeps wildcards
> from matching, even queries for other RR types.  So, for example, in
> my case where I want to mark a big farm of hosts all as not valid,
> even if I had a shiny new RR type, I still couldn't use a wildcard
> because the A records for those hosts would keep the wildcard from
> matching any of them.

I think its not just you and Phil but me and all others in former MARID 
also agree that current wildcards are of no use to us exactly because
of above.

> Given how many people misunderstand this point, including a couple of
> IETF greybeards I talked to at IETF 61, I think we can make a rather
> strong argument that this aspect of wildcards is just wrong.  But if
> we're going to change the way that wildcards work, I'd rather make big
> changes to make them really useful.

We should not make changes to existing wildcards - people are expecting
results they do now. They only way is to actually introduce new wildcard.
 
-- 
William Leibzon
Elan Networks
[email-masked]

--
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: Robert Elz <[email-masked]>
Date: Mon, 17 Jan 2005 14:18:11 +0700

Date:        17 Jan 2005 04:36:13 -0000
    From:        John Levine <[email-masked]>
    Message-ID:  <[email-masked]>

  | Are you sure?  Offhand I can't think of any way to fake a.*.b in a BIND
  | zone other than a terabyte of all possble bit patterns.

Why would you ever need to do that?

  | The wildcard theory is that if you deploy new RR types, you don't need
  | prefixes, so wildcards work.  As Phill and I agree (wow, alert the
  | media) actually, they don't, since any RR at a node keeps wildcards
  | from matching, even queries for other RR types.  So, for example, in
  | my case where I want to mark a big farm of hosts all as not valid,
  | even if I had a shiny new RR type, I still couldn't use a wildcard
  | because the A records for those hosts would keep the wildcard from
  | matching any of them.

Yes.   But if you know the names, you don't need wildcards, there the
macro pre-processor can generate the new records for you (it knows exactly
which names it needs to handle, after all).   It is only where you want to
(or need to) match names that you don't know in advance that you need
wildcards, and there wildcards work.

I have no idea why you believe you need _client._smtp.*.example.com to
hang a record off, just hang it from *.example.com - if someone queries
for _client._smtp.bogus.example.com (for the appropriate RR type) the
wildcard will cause the RR that you hung from *.example.com to be
returned.

If someone asks for _server._telnet.bogus.example.com they'll get the
same data, but why would you care?

That is, unless of course, the whole proposal is crazy, and is abusing an
existing RR type for a whole bunch of different purposes, and relying upon
the different prefix to get you just the precise one that you want.  Then
you'd have trouble, but no-one would stoop to that kind of thing, would they?

  | Given how many people misunderstand this point, including a couple of
  | IETF greybeards I talked to at IETF 61, I think we can make a rather
  | strong argument that this aspect of wildcards is just wrong.

I disagree.  wildcards as defined are exactly what is required in the
DNS protocol (servers can do whatever they like wrt how extra records are
populated into zone files for names that are known - including dynamic 
creation, pro-processing of the zone file, ...).

kre