Subject: RE: Faux wildcards

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 16 Jan 2005 09:47:17 -0800

> [mailto:[email-masked]] On Behalf Of Peter Koch

> "John R Levine" <[email-masked]> wrote:
> 
> > For CSV we're using repurposed SRV records.  They have the 
> fields we 
> > need,
> 
> you're not really *using* SRVs in what was 
> draft-ietf-marid-csv-csa-01.txt, they are just used as 
> containers for your data with e.g. the weight field redifined 
> or 'overloaded'.

John is using the SRV syntax and overlaying his own semantics by means of a
prefix.

It's a perfectly reasonable architectural approach. 

> > useful.  One is forgery.  I have domains that contain no 
> MTAs, and it
> 
> Same problem hare as with the recent SPF thread: RRsets are 
> associated with domain names, not with what is perceived as 
> 'a domain', i.e. everything down the tree starting usually at 
> the second level. For the latter you'd need wildcards (still 
> with a conceptual difference).

Actually the wildcards do absolutely nothing to solve any of the maintenance
issues that John is concerned with, not one.

The problem is that a wildcard only matches a node that DOES NOT EXIST AT
ALL. The only use for a DNS wildcard in the context of spam is to say THIS
NODE DOES NOT EXIST AT ALL from which the only reasonable assumption would
be DO NOT ACCEPT EMAIL FROM THIS NODE.

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.

In fact I don't even need to do that, I just put a preprocessor in front of
BIND.

> > HELO's as <anything>.services.net is lying.  The other is what I
> 
> How about the absence of the RR as an indicator?

What we need is an RR that can stand for THIS NODE DOES NOT EXIST, then all
the policy extensions that are going to be added to the DNS in the next
couple of years can make use of the same record.

Perhaps we could call it the NXT record :-)

Actually the semantics we actually need are slightly different since some
people want to be able to pretend that *.example.com really does exist when
it does not. 

__*.example.com 				Node to hang the policies
off
_client._smtp.__*.example.com		A policy within the node

> > adoption if they could say in one place that all of their 
> authorized 
> > mai client hosts have explicit records and the rest are no good.
> 
> But that's not how the DNS works. Why would one willing to 
> adopt CSV or anything similar not be able or willing to add 
> the necessary RRs below the zone apex?

What John is trying to do is to make it easier to administer a zone. It is a
reasonable feature to put in a DNS server, it is a feature that should be in
a DNS server. It is not a feature that belongs in a protocol.

The DNS configuration file need not be the same as the zone transfer file. 

> As I said in an earlier message, the _whois._tcp thing also 
> walks the tree, but that's something completely different 
> because it follows the DNS hierarchy and does not imply or 
> deduce any (policy) information further up or down the tree.
> 
> > 	_client._smtp.EXAMPLE.COM
> > 	_client._smtp.COM
> > 	_client._smtp.
> 
> Again, RFC 1535 says "don't".

This seems a reasonable recommendation to me. 

> Ex falso quodlibet. Following draft-iab-dns-choices-00 and 
> what you've described a dedicated RR type (your overloading 
> of the SRV seems almost no better or worse than using a TXT 
> to me) is the preferred choice.

The IAB draft is a ridiculous polemic which does not consider the prefix
architecture fairly. It should not progress as a standard, it is yet another
example of a group of IETF insiders using their incumbency to promote their
own pet projects to the exclusion of other equally sound architectural
views.

The prefix architecture works exactly as well as a new RR deployment and
does not depend on any DNS infrastructure changes being deployed.

That is what I will be using.

--
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: wayne <[email-masked]>
Date: Sun, 16 Jan 2005 12:41:38 -0600

> be DO NOT ACCEPT EMAIL FROM THIS NODE.

If you do not accept email from nodes that don't exist, then you will
be throwing out a lot of legitimate email.  Far too much email gets
sent using HELO domains with either domain names that are only
viewable inernally, are typos, or are due to misconfigurations for
most people to take this stand.  Spammers and phishers have taken
advantage of this situation.

> The DNS configuration file need not be the same as the zone transfer file. 

In theory, this is very true.  In practice, it has problems.  Such
features do not exist in name server software, requiring everyone to
create local modifications.  Also, if every host in your zone file
needs to have an SPF, CSV, DK, RP, etc. record added to it, you are
going to greatly increase the size of the zones.

-wayne

---

From: Danny Mayer <[email-masked]>
Date: Sun, 16 Jan 2005 22:33:36 -0500

>advantage of this situation.

All the more reason for enforcing the rules by refusing invalid names.
People will quickly fix the problem if it's preventing mail getting through.

Danny

---

From: John Levine <[email-masked]>
Date: 17 Jan 2005 04:37:31 -0000

>>most people to take this stand.

>People will quickly fix the problem if it's preventing mail getting through.

See if you can get Hotmail to fix their HELO's.  Once they do it,
then we can get everyone else to fall into line.

R's,
John

---

From: wayne <[email-masked]>
Date: Sun, 16 Jan 2005 23:09:26 -0600

> People will quickly fix the problem if it's preventing mail getting through.

Three comments:

1) This mailing list is about DNS, not about email or spam.  My
   comment was in relation to the need for a different form of DNS
   wildcards, but this is quickly drifting off topic.

2) It is wildly recognized in the email/anti-spam community that
   people have a very wide range of tolerances for false positives
   (legitimate email being falsely rejected), and false negatives
   (spam that gets through).

   What I stated was a recognition of this and, since there are no
   protocol police, trying to change how the world works is hard.  If
   you think it is worth your while to try change this, you might try
   starting with changing the IETF.

3) Let's look at the Received: headers from Danny's email:

      [Received: headers coming from the list deleted]
   
      Received: from [208.218.130.12] (helo=gis.net)
      	by psg.com with esmtp (Exim 4.43 (FreeBSD))
      	id 1CqNeH-0005VP-MC
      	for [email-masked]; Mon, 17 Jan 2005 03:33:49 +0000

   Note that Danny's MTA gave a HELO of gis.net, which doesn't have the
   IP address of 208.218.130.12.

      Received: from tecotoo.localhost ([207.7.195.195]) by
                mx04.gis.net; Sun, 16 Jan 2005 22:33:48 -0500

   Note that tecotoo.localhost is not a valid domain.

   Note that 207.7.195.195 does not have a valid rDNS PTR.

      Received: from tecotoo (tecotoo [127.0.0.1]) by
                tecotoo.localhost (NTMail 3.03.0017/1.aaaa) with ESMTP
                id va000983 for <[email-masked]>;
                Sun, 16 Jan 2005 22:33:41 +0000
   
   Note that tecotoo is not a valid domain.

   It is a good thing that Danny's MTAs don't practice what Danny
   preaches, otherwise we would never had heard from Danny.  But hey,
   don't feel too bad.  I once went and checked the quality of HELO
   domains given by people on the IETF MARID WG, a group chartered to
   find solutions to email-forgery/spam/phishing problems, and the
   results were pretty bad.[1]

-wayne

[1] http://www.imc.org/ietf-mxcomp/mail-archive/msg03102.html
    Note that that the comments involve very heavy sarcasm, much of
    which will not be recognized if you aren't very involved in email
    and the MARID WG.  Also note that since that post, I changed from
    my midwestcs.com domain to my schlitt.net domain.  Also, by
    "invalid HELO domain", I did not limit myself to just domains that
    returned NXDOMAIN.

---

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

>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,
and CSV clients could just make the one obvious query and be done.
And if it were just me, I'd do it.  I've written funky servers before;
caches and resolvers are hard, but servers turn out to be surprisingly
easy.  (There's a reason that tinydns is called tinydns.)

>In fact I don't even need to do that, I just put a preprocessor in
>front of BIND.

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.

>The prefix architecture works exactly as well as a new RR deployment
>and does not depend on any DNS infrastructure changes being deployed.

Well, it works a lot better if your servers can match a.*.b.  But you're
right that the clients will work just fine.

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.

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.

Since wildcards are invisible to DNS clients, the only place the current
definition matters is in AXFR data between servers, and in the code in
the server that matches them.  Should we be saying that if you want to
deploy SPF or CSV or DK or IIM or any other anti-spam scheme that needs
to be able to say "anything else is bogus" you'll need a better server
than BIND?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

---

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

> 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.

> because the A records for those hosts would keep the wildcard from

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.

> 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]

---

From: Paul Vixie <[email-masked]>
Date: Mon, 17 Jan 2005 06:28:35 +0000

> > > be throwing out a lot of legitimate email.  Far too much email
> > > gets sent using HELO domains with either domain names that are
> > > only viewable inernally, are typos, or are due to
> > > misconfigurations for most people to take this stand.

speaking as someone whose postfix config rejects such mail, i can tell
you that a lot of folks have pointed out that RFC 2821 allows bad HELO
behaviour and that my servers are technically noncompliant.  i agree,
and i usually just provide my fax number along with my apologies for
any inconvenience.

> > All the more reason for enforcing the rules by refusing invalid
> > names.  People will quickly fix the problem if it's preventing mail
> > getting through.
> 

it's 2005.  anyone who does something a spammer typically does will
look somewhat like a spammer, and be treated often as a spammer, no
matter what RFC 2821 allows.  in 1995 we could bask in the warmth of
"the spec".  in 2005, every sender has to revise their view of "what
kind of traffic is actually going to get through."

people on hotmail, yahoo, or any dsl or dynamic ip range can't send
me e-mail.  that's not going to change.  i am really quite glad that
i don't have a business requirement to accept such e-mail, and i am
really quite surprised that others who also lack such requirements
still accept such e-mail.  "walks like a duck, quacks like a duck,
BLAM, it's duck soup."

but i digress.  we were talking about dns?  i already pointed out in
private e-mail to dcrocker and jlevine (a while ago) that CSV was a
fine looking proposal and might be a reasonable direction forward,
BUT that the field wasn't level and the selection wouldn't be made on
the basis of technical merit.  ("or else we'd have MAIL-FROM by now.")
SPF has no technical merit that makes it compelling in any way -- it
was born in ignorance and has been muddied by subsequent bandaids.
BUT the marketing was powerful and so there is an installed base and
so SPF actually matters, but not because it's better, or even good,
or even "good enough".  microsoft and yahoo finally realized this,
and are going to use powerful marketing rather than technical arguments
to advance "senderid" and "domainkeys" respectively.  let a thousand
flowers bloom, etc.  SPF will compete on its own terms, which aren't
and never were "technical merit".  why on earth is anybody discussing
SPF's merits as if SPF weren't just a marketing driven juggernaut?
if SPF didn't have an installed base we wouldn't be talking about it
at all, and yet a number of folks here are falling into the trap of
talking about how SPF should best be expanded.  i've recommended that
the authors document SPF as it is, and let expansion come later.  this
is because the installed base deserves an RFC to look at.  whether
expansion comes in the form of rr-specific wildcards, or switching
to domainkeys, is something for others to look at, probably elsewhere.

---

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

---

From: John Levine <[email-masked]>
Date: 18 Jan 2005 17:10:58 -0000

>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?

Seems to me that particular horse left the barn five years ago when
RFC 2782 was published.  The meanings of a SRV record at
_http._tcp.foo.example and one at _whois._tcp.foo.example have always
been different.  I wouldn't think it'd take a lot of imagination to
see why a wildcard scheme that gave you the effect of
_http._tcp.*.example would be useful.

If you're going to add different kinds of data, I only see three ways
to do so.  You can add a new RR type, you can use a prefix, or you can
use something like TXT records and try to disambiguate using a unique
prefix in the contents.

If we'd been adding new RR types all along, they'd be the obvious
choice, but we didn't, we blew it, and there's far too much crud DNS
software in daily use that can't deal with new RRs.  I wish it weren't
so, but one of the few unambiguous results from the MARID mess was to
establish that a large vendor in the northwestern US ships both DNS
clients and servers that absolutely cannot handle new RRs without a
significant software upgrade.

I suspect I don't have to argue here why TXT records with a content
prefix are a bad idea, so I won't.  That leaves us with name prefixes.
It seems to me that name prefixes work great.  You can add all the new
prefixes you want without having to worry about whether clients can
handle them.  They create sub-name spaces where, if you want, you can
use any wacky record semantics you want and it won't bother anyone
else.  The only problem is that they don't play well with traditional
DNS wildcards.

A rather important difference between new RRs and new wildcards is
that I can do it unilaterally at the server, since wildcards aren't
visible to clients.

Am I missing anything here?

Regards,

---

From: Alex Bligh <[email-masked]>
Date: Tue, 18 Jan 2005 17:46:04 +0000

> Am I missing anything here?

One thing I think you might be missing is the interaction between
"new wildcards" and DNSSEC. I cannot immediately see how you can
introduce a "new wildcard" with existing NSEC based authenticated
denial, without EITHER online signing in every case, OR client side
changes as well as server side changes. I may be wrong though.

Alex

---

From: wayne <[email-masked]>
Date: Tue, 18 Jan 2005 13:31:23 -0600

In <[email-masked]> John Levine <[email-masked]> writes:

> prefix are a bad idea, so I won't.  [...]

I've stayed away from commenting on draft-iab-dns-choices, in part
because others have express my objections to it, and in part because
trying to gore the sacred cow of "new RRs are the only way" didn't
look very productive.  dns-choices can go ahead and become yet another
widely ignored RFC.

dns-choices is full of strawman arguments and omissions of problems.

For new RRs, deployment problems are downplayed.  The time it takes to
even get a new RR allocated is completely ignored.  Yeah, there are a
few experimental RR types allocated that you don't need to go through
IANA, but then you have the problem with transitioning from the
experimental RR type to an official one.  The experimental RR types
still have the problems with collisions.  You also have problems with
old/broken DNS software that doesn't support these experimental RR
types.

Also omitted is the problem of whether the usage of the new use of the
RR type is going to take off or fizzle.  One one hand, DNS is already
filled with RR types that are almost never used and now can't be used
for anything else.  This argues for only giving new RR types to those
usages that have a high probability of success.  On the other hand,
ideas whose time has come have a way of taking off without control.
If SPF was going to use a new RR type, it would have needed to have
been allocated in the summer of 2003 and deployment of new name server
software would have needed to have started by the fall of 2003.

On the strawman side, as has been pointed out by many, using a
subdomain as a selector works reasonably well.  It would work *far*
better if DNS wildcards could be upgraded to make things like
_foo.*.example.com do what most people expect it to do.  IMHO, making
wildcards more useful is a far more productive use of people's time
than forcing everyone to use new RRs.  The deployment of better
wildcards is no worse than the deployment of a new RR, and it only has
to be done once.

The re-use of existing RRs with magic numbers in the RDATA is argued
against in dns-choices because of the problems with when too many
different applications all try and use the same RR.  In the case of
SPF and TXT RRs, we did a survey of usage of TXT RRs in the
appropriate parts of the DNS trees (domains used in the RFC2821 MAIL
FROM and RFC2821 HELO).  We found the usage wasn't very high, and at
the rate of growth in usage over the last decade, the TXT usage would
last for another decade or two.

There are several reasons why using TXT with magic numbers is the
"obvious" right thing to do which are completely ignored by
dns-choices.  Experience with Unix over the last 2+ decades has shown
that magic numbers work very well in practice on Unix files.  Using
text also has the advantage that you do not need special tools to
create, look at, or debug the data.  With a new RR type, you need to
not only modify your name server software (if you don't want to have
to use hex encoding), but you also need to update things like dig (if
you don't want to have to use hex decoding).  The amount of code need
to parse and print SPF records from a binary format[1] is far larger
than I think most name server software would want to include.  Yeah,
SPF has a complicated format, but the same problem exists if you want
to add 5,000 new RR types.

Ok, so what is the solution to TXT RR sets getting too full?  Simple.
Increase the amount of TXT RRs available to be used.  There are tens
of thousands of unallocated RR types.  Instead of allocating just one
new RR type, as was considered for the SINK RR, allocate a dozen, or a
hundred, or even a thousand of them.

Create TXT00-TXT99, all with the TXT RR format.  Yeah, it will take
years to get them widely deployed, just like all new RR types, but
once that is done, people can easily pick which ever TXT## that is not
widely used and do their experiment.  If the experiment fizzles, no
problem at all.  If it takes off, then maybe someday that particular
TXT## RR should be renamed and reserved for that usage.  If it looks
like the first allocated block of records is going to get full in the
next 5 years, then go allocate a bunch more.

Yes, people would have to use a magic number in the RDATA, but as Unix
has show, that will probably not be a problem.  Yes, text encoding is
not as compact as binary but, again, in practice, that isn't as much
of a problem as deploying new tools to deal with the binary format.

Like the effort needed to deploy better wildcards so that subdomain
selectors would work better, deploying a bunch of new TXT RR types
would also be a far better use of people's time.

Forcing people to create new RR types hasn't worked in the past, and
creating a new RFC for DNS Choices isn't going to change that.

-wayne

---

From: Peter Koch <[email-masked]>
Date: Tue, 18 Jan 2005 21:10:54 +0100

> than forcing everyone to use new RRs.  The deployment of better

even more productive could be some education about what wildcards are
and how they work, me thinks. There's a draft underway doing that.

> that magic numbers work very well in practice on Unix files.  Using

Although I remember some HP-UX cluster files I haven't recently come
across a unix file where I opened the file giving a unique name and was
then presented with a set of answers to choose from. Subtyping is a problem
since you cannot make the subtype part of the query. (Well, given the level
of change some in this thread are willing to apply to the DNS infrastructure
it won't last long until this (e.g. "associative DNS queries") will be
proposed ...)

> creating a new RFC for DNS Choices isn't going to change that.

Just in case you (or anyone else) missed RFC 3597, there's also excellent work
done by Jakob Schlyter on interoperability of this spec (see San Diego's
dnsext minutes) and there have been various deployment surveys for
name server software. Can we now please declare the "new RR types won't
work" an urban legend?  The MARID problem was different and that pointless
debate should better not be rehashed here again.

What I really have a hard time to understand is that every suggestion (use
reverse, use wildcards combined with new type, ...) is rejected with some
not necessarily substantiated argument of "won't work due to some deployment
obstacle".  However, changing the basic DNS infrastructure is an option?

All it comes down to is a provisioning problem (generating "millions"
of RRs - in how many cases are there really "millions" and how do those
zone admins handle all the MX RRs? Huh, no MX at all?) that doesn't
need a protocol change, not even any change in the name server software.
And if anyone is concerned about the size of the resulting zone
they better look at how DNSSEC will increase that size - and that it's
a non issue for the vast majority. And they better be prepared to use
DNSSEC once anti spam rules make DNS even more attractive for forgery.

There's no need for "new" wildcards.

-Peter

---

From: Alex Bligh <[email-masked]>
Date: Tue, 18 Jan 2005 20:37:46 +0000

> There's no need for "new" wildcards.

I'm not (yet) sure whether "new" wildcards is a protocol change, or
an "ease of use config option" on servers (i.e. an application change)
meaning "reflect this label type to all possible QNAME queries of
this type in the zone and subdomains thereof that I am authoritative
for". If it is the latter, I'm not sure we need pronounce on it.

Alex

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 18 Jan 2005 12:53:36 -0800 (PST)

> look very productive.  dns-choices can go ahead and become yet another

I'm not going to comment much on draft-iab-dns-choices either because others
already done it, but I'd like to just note that I'm in lot less opposition 
to it then Wayne (although Wayne's opinion does seem to represent majority
view of people involved in SPF) and I do not believe SPF was right in using
TXT in anything other then localized experiment and that going further then
that with existing RR type leads to collisions and loss of meaning for RR.

> On the strawman side, as has been pointed out by many, using a subdomain 
> as a selector works reasonably well.  It would work *far* better if DNS 
> wildcards could be upgraded to make things like _foo.*.example.com do 
> what most people expect it to do.  IMHO, making wildcards more useful is 
> a far more productive use of people's time than forcing everyone to use 
> new RRs.  The deployment of better wildcards is no worse than the 
> deployment of a new RR, and it only has to be done once.

I agree, we better start soon so that we don't have the same problem as 
SPF for some other project.

> next 5 years, then go allocate a bunch more.

I think something like above maybe done with redefining use of DNS CLASS.
Currently its practically official that the only class used is IN (the use 
of Hesiod and Chaos is pretty close to 0). What we could do is redefine the
field and say that it is to be used to specify "subclass" for any type (with
say first 1024 being general types and anything above is type-specific
subclass all for use on the internet) i.e. its classification of how the 
RR type is used and multiple different ones are allowed for any domain. 
We define that instead of requirying to specify Class by name, systems 
and dns administrators can use class numbers and that all DNS servers 
and clients should support any arbitrary class number for any type. Now 
somebody who wants to reuse some dns type for something new can run his 
experiment on some random high class number and if it is usefull that 
CLASS number is registered with IANA as specific CLASS for the type.

As example, if this were used for SPF (which is not going to happen, it is
now way too late), it would mean that instead of having this in the zone:
 host	IN	TXT	"v=spf1 ..."
The administrators would instead put:
 host	2222	TXT	"v=spf1 ..."
Where 2222 could be SPF-specific subclass of TXT type. BTW - I just tested
the above and it actually works (!!), at least with bind - try:
'dig -c 2222 -t TXT sub2.etest.elan.net'

---
William Leibzon
Elan Networks
[email-masked]

---

From: David Blacka <[email-masked]>
Date: Tue, 18 Jan 2005 15:51:22 -0500

> changes as well as server side changes. I may be wrong though.

I think you are right.  DNSSEC makes wildcards very visible at the 
client, at least to the client's DNSSEC validation code.

However, it occurs to me that in some narrow cases it might be possible 
to introduce new wildcard behavior without client side changes, along 
with a few caveats.

The narrow case I am thinking of is a definition of a new wildcard 
algorithm that is a subset of the current one.  And by subset I mean 
that the new wildcard does not match where the existing wildcard does 
not match, and may not match where the current wildcard does match.

For example, let's posit a new wildcard, %, that can be deployed in the 
way close to what John Levine wishes:

    _client._smtp.%.foo.example.com IN SRV ...

will match when qname looks like 
_client._smtp.does-not-exist.foo.example.com, and when qname looks like 
_client._smtp.does.not.exist.foo.example.com, but not match 
does-not-exist.foo.example.com and does not match 
_client._smtp.exists.foo.example.com.

It is not necessarily difficult to implement this as a server-side 
feature (hack, if you will), sans DNSSEC.

With DNSSEC, you have the problem that the client's validator must be 
able to cryptographically prove the synthesized response, yet it knows 
nothing about this '%' wildcard.  So, this hacked server needs to do 
something weird in the DNSSEC case: it needs to lie.

So, when signing this zone, a 'normal' wildcard (where _blah._blah.% is 
replaced by *) is created and signed, and an NSEC proving that the 
wildcard does not exist is also created and signed.

Positive matches are handled as if the normal wildcard exists, negative 
matches are handled as if the normal wildcard did not exist:

Q:
   _client._smtp.baz.foo.example.com. IN SRV
AN:
   _client._smtp.baz.foo.example.com. IN SRV ...
   _client._smtp.baz.foo.example.com. IN RRSIG ... labels=3
AU:
    example.com. NS ..
    b.foo.example.com. IN NSEC c.foo.example.com. ... (proves that 
_client._smtp.baz.foo.example.com does not exist in the zone)
...

and,

Q:
   _http._tcp.baz.foo.example.com. IN SRV
AN: (RCODE = 3)
AU:
   b.foo.example.com. IN NSEC c.foo.example.com. ...
   foo.example.com. IN NSEC a.foo.example.com ... (proves that 
*.foo.example.com. is not in the zone)
...

It is true that this technique (if it even works at all) makes it 
possible to spoof the existence of the wildcard match away, 
undetectably, however.

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

---

From: Edward Lewis <[email-masked]>
Date: Tue, 18 Jan 2005 16:01:18 -0500

>_http._tcp.*.example would be useful.

The SRV record didn't need an alteration of section 4.3.2 of RFC 
1034.  The scheme you suggest would.  Section 4.3.2 of RFC 1034 is 
simply titled "Algorithm" and is the basic algorithm for any name 
server.  For that reason, I don't see that the SRV record has set a 
precedent that leads to this change in wildcard processing.

...
>else.  The only problem is that they don't play well with traditional

I can't imagine adding a solution that works 90% of the time to a 
critical system.

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

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

---

From: John Levine <[email-masked]>
Date: 18 Jan 2005 21:11:41 -0000

> Can we now please declare the "new RR types won't work" an urban
> legend?

Nope.

> The MARID problem was different and that pointless debate should
> better not be rehashed here again.

The specfic issue is that widely used Microsoft firewalls proxy DNS
requests using a separate RPC for each RR type.  The firewalls do not
pass native DNS packets in either direction.  To handle a new RR, it
both needs a new RPC service on the firewall, and an new RPC request
routine in the client.  That needs software upgrades all around, and
it's a major bar to deployment to tell people that they need to spend
money and change their firewalls.

Nobody, inside or outside of Microsoft, was defending this as a good
design, but there are a lot of them in the field.  Denying that they
exist or ignoring them isn't going to win any arguments.

> All it comes down to is a provisioning problem (generating
> "millions" of RRs - in how many cases are there really "millions"
> and how do those zone admins handle all the MX RRs? Huh, no MX at
> all?)  that doesn't need a protocol change, not even any change in
> the name server software.

Part of the issue here seems to be that people have difficulty
understanding what the goal is.  It's to provide a nothing-here answer
for unused names, in a way that lets clients distinguish a domain that
returns deliberate nothing-here responses from one that has no data
either way.

I realize that one response is to say "DNS doesn't do that, go away",
but if we can't offer people a plausible way to publish data in DNS,
we're going to be seeing ugly proprietary publishing schemes that are
far worse than anything that people have disparaged here.

Regards,

---

From: John Levine <[email-masked]>
Date: 18 Jan 2005 21:13:30 -0000

>an "ease of use config option" on servers (i.e. an application change)

It's only a protocol change if you use AXFR or IXFR to synchronize
servers.  It doesn't affect normal DNS client-server interactions at
all.

Regards,

---

From: "D. J. Bernstein" <[email-masked]>
Date: 18 Jan 2005 21:25:33 -0000

Peter Koch writes:
> Can we now please declare the "new RR types won't work" an urban legend?

What have you been smoking? New types are screwed up by an incredible
amount of DNS software---including BIND before version 9.1, and pretty
much everything from Microsoft.

> excellent work done by Jakob Schlyter on interoperability of this spec

Are you talking about the report several months ago where Schlyter said
that DNSJava 1.6.4, BIND 8.4.5rc4, BIND 9.3.0rc2, NSD 2.1.1, NET::DNS
0.47 patchlevel1, and ANS 2.2.1.0.d could handle arbitrary types? That's
wonderful. Now how about the fifty bazillion ancient BIND installations
that _can't_ handle new types?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Alex Bligh <[email-masked]>
Date: Tue, 18 Jan 2005 21:37:08 +0000

> to introduce new wildcard behavior without client side changes, along

I *think* there's an even narrower case which might (with adaptions) even
fit John's requirement better.

Suppose you invent a "pseudo-wildcard" '&' (as we are into typographical
symbols). This matches "any existing QLABEL for which I am authoritative".

So a zone with "RR"s (and you'll see why the quotes in a second) of the form
  &.example.com	IN	TXT "bar"
  foo.example.com	IN	A	1.2.3.4
  foo2.example.com	IN 	A 	2.3.4.5

has a response for QNAME="foo", QTYPE=TXT of "bar", but NXDOMAIN for
QNAME="baz", QTYPE=TXT.

The reason why this is so much easier is that even to prior to signing,
the server can expand the "RRs" in the zonefile into
  foo.example.com	IN	A	1.2.3.4
  foo.example.com	IN	TXT	"bar"
  foo2.example.com	IN	A	2.3.4.5
  foo2.example.com	IN	TXT	"bar"

and these real RR's can be signed in the normal way.

Clearly the server side complication is making it appear in subdomains
that are also served...

Introduce a (traditional) wildcard as well (to handle queries for
non-existent labels) with the same RHS, and you've (almost) got what
John wants, without any wire protocol mods.

> (stuff I need to think more about snipped)
>
> possible to spoof the existence of the wildcard match away, undetectably,
> however.

Hmmm... another challenge for authenticated denial review.

Alex

---

From: Peter Koch <[email-masked]>
Date: Tue, 18 Jan 2005 22:45:01 +0100

> money and change their firewalls.

I'll follow my own advice.

> returns deliberate nothing-here responses from one that has no data

Take new RR type FOO. Attach information to existing names by adding
a FOO RR (or a FOO RRset, for that matter) to those names' RRs, either
"manually" by server based macro expansion (a la $GENERATE) or via a
preprocessor external to the name server.
Attach (maybe different) information to non-existing names by using wildcards,
if necessary. Now, if a FOO query doesn't return a FOO RRset, you'll
assume that the FOO scheme is not (yet) supported.

NB: I do not say publishing the information *and* maybe its complement is a
    good idea or a clever long term strategy. It just helps to
    distinguish between 'supported' and 'unsupported'.

-Peter

---

From: Ted Hardie <[email-masked]>
Date: Tue, 18 Jan 2005 13:42:11 -0800

>returns deliberate nothing-here responses from one that has no data

That isn't the only goal I've heard.  One goal I've heard is to have
some way of saying "This is the default for members of this set;
specific members in the set may have separate declarations
that define something different".  That is different from "nothing-here
answer for unused names", since it applies to names which do exist
but have no separate declaration.

			regards,
				Ted Hardie

---

From: Paul Vixie <[email-masked]>
Date: Tue, 18 Jan 2005 21:42:25 +0000

> >> There's no need for "new" wildcards.

i disagree.  we need rrtype-specific wildcards, and nonterminal wildcards.

> servers.  It doesn't affect normal DNS client-server interactions at

it's a zone behaviour representation issue, so it's a protocol change.  if
it's to be called a protocol, then it will describe the behaviour of servers
in the presence of various kinds of authority data and in response to various
queries.  even if axfr/ixfr isn't used, then the representation needed to
cause this behaviour will still have to be signallable by dynamic updates,
and visible with maintainance queries (such as a query for a literal "*" does
in the current wildcard mechanism), and as others have noted, it will have
an impact on dnssec proofs, of both the positive and negative variety.

even if the protocol change is to say "zones using this new kind of wildcard
cannot be represented in axfr/ixfr or dynamically updated", it'd still be a
protocol change.

right now, a nonterminal "*" is meaningless to the wildcard algorythm.  it
will have to remain meaningless in case someone is using this encoding and
depending on it to be meaningless or "just an asterisk label, not special".

to add nonterminal wildcards or rrtype-specific wildcards, we will have to
define a new encoding that is currently not just meaningless but invalid.
and then we'll have to define negotiation mechanisms as necessary to ensure
that both sides of an axfr/ixfr or multiple MS-A-D masters or both sides of
a dynamic update all agree that the new encoding has a specific new meaning
and is not invalid as it would be to pre-epoch servers.  this means it's a
protocol change.  don't fear protocol changes.  we added EDNS.  we added
dynamic update.  we're adding DNSSEC.  we added TSIG.

and don't fear new rrtypes.  we added SRV and a whole lot of others.  it
takes time and that's too bad but it can be done and should be done and in
the case of SPF-like functionality, apparently it must be done.

---

From: "John R Levine" <[email-masked]>
Date: 18 Jan 2005 17:16:12 -0500

> but have no separate declaration.

Yes, that's the other goal.  I will agree that by adding enough extra
records to the DNS you can get the effect of a default by adding an
explicit RR to every name that already exists, so that's a more debatable
argument about how much glop domain owners are likely to be willing to
add.  Personally, since my DNS data file is generated by perl scripts, I'd
find it no big deal.

But the nothing-here issue is much tougher, since I don't see any way to
fake it other than by defining RRs and waiting a decade for every
Microsoft user to upgrade his firewall.

The same tree walk that handles the nothing-here case also handles the
default case, so if you can stand the first, the second is there if you
want it.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 18 Jan 2005 20:23:03 -0500

On 1/18/2005 4:11 PM, John Levine wrote:

> requests using a separate RPC for each RR type.

And they could have easily fixed this bug during the period we've been
debating the subject, but they haven't.

Designing protocols around buggy software that the vendor has empirically
abandoned is wrong.

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

---

From: "John R Levine" <[email-masked]>
Date: 18 Jan 2005 20:57:37 -0500

> debating the subject, but they haven't.

Honestly, I don't know how to respond to silly arguments like this.  The
MARID fiasco started about a year ago.  A year is a fairly short release
cycle for a commercial software product of any size.  (Been there.)
There are still substantial numbers of Microsoft customers using software
that they shipped three, four, even six years ago.  This shouldn't
surprise anyone, since there are still plenty of people using versions of
every other kind of software that were shipped years ago.

There's no question that Microsoft made some poor design decisions in
their DNS software, but even if they were dying to get everyone to upgrade
(which they certainly are for some upgrades like XP SP2), it'll be years
until you can assume that most of the users have installed it.  They're
still issuing patches for Win98, because the large number of people still
using it grouse and they can't abondon it.

Regards,

---

From: Danny Mayer <[email-masked]>
Date: Tue, 18 Jan 2005 19:49:42 -0500

>3) Let's look at the Received: headers from Danny's email:

Your points 2 and 3 (I deleted the actual analysis) shows that looking
at the names being sent is useless and confirms that you should stick
to the IP address only. I have my local system set up as a local smtp
server whose job it is to forward my mail to my ISP (as well as handle
my personal mailinglists). That's not an unusual situation. My ISP's
SMTP server is set up to only accept mail from those IP addresses
that it owns as well as to deliver to domains that it is responsible for
receiving email (like gis.net). These are the situations that antispam
protocols need to handle.

You should be able to make use of any record type that DNS supports
including PTR, SRV, TXT and any new record type that you wish to
propose to support your efforts (modulo what the DNS community thinks
should be supported and obtained through the usual IETF process.

Danny

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 18 Jan 2005 23:14:37 -0500

> until you can assume that most of the users have installed it.

This is quite the strawman circle-jerk. First of all, the complaint as
stated is that they haven't even patched the code yet, and that if they'd
patch it (as opposed to distribute it to every system that ever downloaded
a test package) this problem would go away. Second, requiring the use of
service packs and patches is common practice, and telling people that they
need to get some hotfix for their borked ~firewall is neither new nor
prohibitive. Third, designing protocols to accomodate broken software is
bad design anyway.

---

From: "John R Levine" <[email-masked]>
Date: 18 Jan 2005 23:43:07 -0500

> stated is that they haven't even patched the code yet,

No, actually, the complaint is that they screwed up the design.  It's not
at all obvious to me how you'd patch around that design other than perhaps
adding a generic pass-through-the-bits call, and even if they did that I
don't know how it might affect calls that do ANY requests.

But it hardly matters whether they've shipped an upgrade or not.  As Dan
Bernstein pointed out, even though the MS firewall is the most egregiously
broken package with respect to new RRs, there are still plenty of *IX
systems running old versions of BIND that will fall over if confronted
with new RR's, too.  I entirely agree that as a long term goal we should
try and figure out how to get people to upgrade their DNS software, but
it's nuts to do designs that you can't use until they do.

Or to put it another way, if you believe that most people update their
software, why aren't we all using IPv6?

Regards,

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 19 Jan 2005 00:01:23 -0500

On 1/18/2005 11:43 PM, John R Levine wrote:

> software

Can we stick to the points I'm actually making?

It's not unprecedented or uncommon to tell people that they have to
upgrade to use some other piece of software. This happens all the time in
MS-land in particular (cf Active Directory, DirectX, Windows XP, etc etc
ect), and this has also happened with DNS extensions as well (eg, "upgrade
BIND if you need to use SRV"). Besides which, if they aren't even patching
the software, then it's effectively abandonware and is irrelevant to the
design anyway. In either case, the shortcomings of a particular product
should be and effectively is irrelevant.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Jan 2005 07:40:40 +0200 (EET)

> every other kind of software that were shipped years ago.

Probably.  But how many of those SMTP servers which need to make these 
lookups, or how many DNS servers (providing information about that 
site's zone) are behind such firewalls?

There's no doubt there's breakage out there, but the point is whether 
we need to care about it.

I can't imagine a major mail system or DNS server would be behind such 
a firewall.  And our primary target is major mail systems and zones, I 
suspect.  In the big picture, small sites using broken and abandoned 
firewalls seem irrelevant.

The simple answer could be, "if you have a broken firewall, you can't 
use this mechanism.  Here [link] are instructions on known-bad and 
known-good implementations".

We've been there with ECN.  We're there with different DNS equipment 
breaking AAAA (or anything except A) records.  We'll continue to get 
there.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "John R Levine" <[email-masked]>
Date: 19 Jan 2005 01:49:20 -0500

> site's zone) are behind such firewalls?

DNS servers, probably not many.  SMTP servers, lots of them.  They're
running Exchange, if they weren't behind a firewall they wouldn't last
five minutes.

> we need to care about it.

As Dan B. noted, the MS firewall is the biggest single collection of RR
brokenware, but there's plenty more in the form of obsolete versions of
BIND and other DNS software that people are still running.

I'm not saying that we should give up and never ever add a new RR type,
but I am saying that requiring a new RR is in 2005 a major bar to
widespread deployment.

Regards,

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Jan 2005 07:11:11 +0000

> software, why aren't we all using IPv6?

and yet, we'll keep adding new rr types, and they'll mostly work, and
where they don't, they'll put pressure on middlebox vendors.  this is
called "progress."

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Jan 2005 07:17:13 +0000

> but I am saying that requiring a new RR is in 2005 a major bar to

we all knew that.  which is why we all recommended a new type be added in
2003.  now it appears that failure to heed will be rewarded by approval of
a bad design, and the lazy can become the victims.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Jan 2005 09:20:29 +0200 (EET)

> running Exchange, if they weren't behind a firewall they wouldn't last

Are big/significant exchange servers, receiving incoming mail, behind 
*such* firewalls?  I'd suspect most (and almost all bigger ones) 
Exchange servers would definately be behind a *real* firewall, not a 
proxy server by MS (or whatever causing the problems quoted here).

> but I am saying that requiring a new RR is in 2005 a major bar to

True, though if we're never going to use it, we're never going to get 
there...

I think the most important thing here is to recognize the scenarios 
where we absolutely want to get this deployed, versus those sites 
which would possibly want to use this thing (but can't, due to 
miscellanous brokenware).

We may need to make the deployment sufficiently easy for those we 
absolutely want to use this thing (e.g., very big mail providers, very 
big zone owners, ...?), but we *necessarily* don't need to do that for 
those who are not critical for the success of this solution.  They'll 
upgrade their brokenware if they see an incentive to do so. Otherwise, 
it's their mail that gets spoofed, or they cannot check the originator 
of the mail.  Why do we care?

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 Jan 2005 15:50:54 +0700

Date:        18 Jan 2005 17:10:58 -0000
    From:        John Levine <[email-masked]>
    Message-ID:  <[email-masked]>

  | Seems to me that particular horse left the barn five years ago when
  | RFC 2782 was published.  The meanings of a SRV record at
  | _http._tcp.foo.example and one at _whois._tcp.foo.example have always
  | been different.

Of course.   But I don't use such a thing with an undefined "foo".

  | I wouldn't think it'd take a lot of imagination to
  | see why a wildcard scheme that gave you the effect of
  | _http._tcp.*.example would be useful.

It would aid laziness to have a record generator for the DNS yes, and
if that were dynamic, it could save on memory in servers for large zones.
But nothing is needed that needs to affect the protocol (AXFR/IXFR included).

For names that don't exist (unknown "foo") there's no benefit I've yet
been able to determine.

  | It seems to me that name prefixes work great.

You mean you think it is OK for you (and the rest of the community) to
"steal" my namespace - to take names from my domain and define how they're
supposed to be used?   SRV already did that (but since it is only for use
on its specialised record type, it is comparatively harmless).   Doing it
for ant of the standard RR types is totally unacceptable.   I define what
names get allocated in my domains, you don't.

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 Jan 2005 15:45:21 +0700

Date:        19 Jan 2005 01:49:20 -0500
    From:        "John R Levine" <[email-masked]>
    Message-ID:  <[email-masked]>

  | As Dan B. noted, the MS firewall is the biggest single collection of RR
  | brokenware, but there's plenty more in the form of obsolete versions of
  | BIND and other DNS software that people are still running.

His point was just that's there's lots of ancient stuff around, which can't
handle new types.   And that's both correct, and not very relevant.

The point you keep ignoring is that the only people who need to handle the
new type are those who want to use it (as client or server).   That is,
it is irrelevant that someone's system can't handle the BOZO RR type, if
they don't add it to their servers, and don't have clients that query for it.

This may be a good test of just how real the demand for SPF (or similar)
really is, and how must of it is just hype.   If you tell people that to
use SPF they're going to have to spend $'s to upgrade (or even
totally replace with something from a different vendor) their systems,
we'll find out just how important SPF really is to them, won't we?

If they're prepared to do that, then all this noise about new types being
hard to deploy will be just irrelevant, as people would be actively
deploying it.   If they're not prepared to upgrade, then clearly the
functionality being claimed as important, isn't really all that important
after all.

  | I'm not saying that we should give up and never ever add a new RR type,
  | but I am saying that requiring a new RR is in 2005 a major bar to
  | widespread deployment.

Only if you're trying to force widespread deployment of something for
which people see no benefit to themselves.   If the end users who have
to upgrade can see a genuine benefit in the upgrade, they do it.

Note here that the whole net doesn't have to upgrade to support a new RR
type - that's what Paul V's message was trying to illustrate.   SRV records
have been added, and are used.    Yet as djb's message indicated, there
are still zillions of servers around that have no idea what an SRV record
is, and have no chance of ever processing one correctly.   Yet everything
still works - those who need SRV have servers that handle it.   Those who
don't simply don't care - if their servers are OK for other reasons, fine,
if they're not, as long as they work for their actual needs, that's also fine.

kre

---

From: Edward Lewis <[email-masked]>
Date: Wed, 19 Jan 2005 10:16:46 -0500

...
>John wants, without any wire protocol mods.

Mr. Bligh is on to something here.

Thinking (independent from his message) about this I hit:

1) The DNS is meant to be used by asking a specific question and 
getting a specific answer.

2) The DNS lacks a feature in which any query whose name is within a 
zone answers with a zone-wide record set.

3) Every time we add new features to the code of DNS, we introduce a 
new generation of obsoleted code.

The purpose of DNS has been hashed over and over (the holy Q-tuple, 
etc.) so I'll skip that.  The problem is that the mail protocols 
don't know what they want to ask, not specifically enough for DNS's 
purposes.  Mail doesn't know which entity's information is needed 
hence mail cannot translate this into a domain name and form a 
specific question.  Lacking a directory service, what mail needs is a 
more directory-like lookup service.

There seems to be commonly held belief that if DNS were to feature 
the ability to answer with data for all names in a zone (present or 
not), the mail protocol designers would be more happy than they are 
now.  (The wildcard example in RFC 1034 shows the use of wildcards 
for MX records leading me to think that perhaps wildcards were 
introduced first for mail.)

If we were to undertake an effort to add such a feature in DNS, we 
would have to make changes to the basic algorithm in RFC 1034 
(4.3.2).  In step 2, we are told to select the zone.  In conjunction 
with that we would also then have to possibly select the zone-wide 
data sets.  In step 3 we locate the name we want (substeps a,b,c are 
there), we would have to amend these steps to deal with either a lack 
of a name, a CNAME out of the zone, or even a conflict between a 
zone-wide set and a same-typed set at a found name (scope rules).  My 
point is that this is a change to the code algorithm, meaning that a 
change of this magnitude would mean that we wind up with all of 
today's DNS servers being members of the obsolete corps.  (If you 
think dealing with only yesterday's code as obsolete...)

In thinking this over, I was about to suggest what Alex already has - 
just preprocess all the data you need.  The same idea came up in 2001 
as we dumped A6 in favor AAAA (and bitstrings in favor of nibbles). 
For IPv6, the preprocessor would have to calculate AAAA's for events 
like renumbering.  For mail, the preprocessor would have to calculate 
the wildcards and specific records needed to answer.  You would need 
a tool to do this, but it's computationally feasible.

---

From: wayne <[email-masked]>
Date: Wed, 19 Jan 2005 13:04:20 -0600

> i disagree.  we need rrtype-specific wildcards, and nonterminal wildcards.

I agree with Paul here.

> define a new encoding that is currently not just meaningless but invalid.

Ok, I confess I don't understand how wildcards and DNSSEC works, but
current wildcards are server side only.  So, we could just have an
option enable expanded wildcards that defaults to "off".  So, if
someone has "foo.*.bar.example.com. IN A 1.2.3.4", that would remain
as it is.  The meaning, however, could change for those that want to
change it.  The option would need to be per-zone and there would need
to be some way of communicating this option to secondar NSs.  One
really ugly solution to this would be to create a "EWLD" RR type to
denote that this zone wishes to use extended wildcards.  Like the SOA
record, the "EWLD" RR would need to be at the zone origin.

-wayne

---

From: Alex Bligh <[email-masked]>
Date: Wed, 19 Jan 2005 19:25:26 +0000

--On 19 January 2005 13:04 -0600 wayne <[email-masked]> wrote:

> change it.

Genuine question: what is the perceived advantage of "new type of wildcard"
over preprocessing?

I know one answer: if the "new wildcard" matches non-existent LABELS,
and the preprocessing cannot decompose the directive into a selection
of traditional RR's and wildcards, then preprocessing isn't going to
work and you are stuck with synthesis (and, with DNSSEC, online signing).

But is there a current known case where this is problematic?

foo.&.bar.example.com  (for "&" = new wildcard)

such as I believe is wanted by the SPF folks could be decomposed
by preprocessing into foo.<label>.bar.example.com records for all
instances of <label> within bar.example.com. (note config subtlety
when "within" crosses a zone cut). Whilst it can generate a
*.bar.example.com RR for "the rest of the zone" as per Ed's
draft, it's not going to answer to foo.baz.bar.example.com where
baz does not exist. But is this a problem? IE I thought the tree
iteration was for where subdomains do not have SPF records, not for
where subdomains do not exist.

Alex

---

From: wayne <[email-masked]>
Date: Wed, 19 Jan 2005 13:44:04 -0600

> site's zone) are behind such firewalls?

SPF is not just used in SMTP servers.  For example, SpamAssassin does
SPF checks and it is often run after the email has been delivered.
There is at least one version that runs after POP/IMAP.

For Microsoft's CallerID/SenderID, it is my understanding that they
primarily intended it to be part of the MUA.  Imagine every future
copy of Outlook having SenderID support built into it.

So, the answer to your question is that, yes, there are a lot of
machines that would be trying to run these checks from behind these
broken firewalls.

-wayne

---

From: wayne <[email-masked]>
Date: Wed, 19 Jan 2005 13:58:42 -0600

In <a06200704be141b737280@[192.168.1.103]> Edward Lewis <[email-masked]> writes:

> There seems to be commonly held belief that if DNS were to feature the
> ability to answer with data for all names in a zone (present or not),
> the mail protocol designers would be more happy than they are now.

I think it is more than just mail that would benefit.  For example, I
think the RP RR would be more useful if it could be returned for all
names in a domain.  To a lesser extent, the LOC/GPOS RRs could also be
used.  

> [changes needed to make a new form wildcard snipped]
>                                                      My point is that
> this is a change to the code algorithm, meaning that a change of this
> magnitude would mean that we wind up with all of today's DNS servers
> being members of the obsolete corps.  (If you think dealing with only
> yesterday's code as obsolete...)

A couple of things.  Like new RRs, the only servers that would need to
be upgraded for this new form of wildcarding would be those that want
to use it.

Also, *if* the new form of wildcarding could be simulated on the
client side, the transition would be easier.  The client would do the
query, and if the query returned the data, or didn't indicate that the
server supported the new form of wildcarding, then the client could go
do the ugly stuff to simulate it.

Otherwise, yeah, it will take years (decades?) before this new form of
wildcarding could be reliably used.

-wayne

---

From: wayne <[email-masked]>
Date: Wed, 19 Jan 2005 14:05:47 -0600

In <[email-masked]> wayne <[email-masked]> writes:

> [large snip]
>
> Create TXT00-TXT99, all with the TXT RR format.

No one has objected to this idea, so I'll raise it again.

Should we create a bunch of TXT RRs so that people can use them
without worrying about filling up the 512 byte UDP packet?

Remember, *IF* the spf-classic I-D advances with the creation of the
new SPF RR type, and *IF* name server authors think it is worth while
to support the SPR record, then it would be trivial to create these
extra TXT RRs at the same time.  The SPF RR is, after all, just a
clone of the TXT RR.

We could start out small, say only TXT0-TXT9, and if those start
filling up, create TXT10-TXT99.

-wayne

---

From: wayne <[email-masked]>
Date: Wed, 19 Jan 2005 14:32:03 -0600

> Genuine question: what is the perceived advantage of "new type of wildcard"

Good question, and the answer I think is that there isn't much
different between this new kind of wildcard and preprocessing.  Call
it a new preprocessing directive, if you want and start the directive
with a $.

No matter what you call it, I think it would be quite useful to
standardize it's functionality.

One advantage of generating these on the fly ("wildcard") is that
there would be less space taken up in memory, on disk and during zone
transfers compared with preprocessing.

> But is there a current known case where this is problematic?

Not that I can think of.  

> where subdomains do not exist.

The zone cut stuff in the spf-classic draft is there for both when the
domain exists, and when it doesn't.  Paypal probably wants to be able
to say that "securty.paypal.com" should be rejected as being from
paypal, even if "security.paypal.com" exists.  This is especially a
problem when dealing with the domain used by the SMTP HELO/EHLO
commands since many people generate invalid domain names.  Email
receivers need to be able to distinguish between a "normal"
misconfiguration, and something that the domain owner says should
never happen.

-wayne

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 19 Jan 2005 21:38:19 +0100

>without worrying about filling up the 512 byte UDP packet?

Is it possible in very condensed way to describe why SPF needs such a
kludge?  That is, SPF could not by using a different naming conventions like
filtering on suffixes, obtain similar results?

Anders R

---

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

> SPF checks and it is often run after the email has been delivered.

SpamAssassin in most cases is integrated as part of MDA and in some 
instances (mimedefang) called as part of its processing.

> copy of Outlook having SenderID support built into it.

I'm heavily against this. There is no way they can reliably do path 
authentication of previous server after email was already delivered -
this is just completely against the entire concept of LMAP/MARID.

> machines that would be trying to run these checks from behind these

In addition it has been position of SPF Community that SenderID is not
part of SPF and that we should not try to acomodate in in any way because
it has way too many problems and uses SPF records incorrectly.

As such we should not be trying to accomodate situations where SID maybe
used as part of SPF Draft specification, especially where we already know
the firewall implementation itself is broken and its vendors fault. 

I still firmly believe that it would be best that SPF start moving and 
using new RR type right away and set deadline (like it was done for
6BONE) for when use of TXT would be depreciated.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 19 Jan 2005 13:33:33 -0800 (PST)

> it a new preprocessing directive, if you want and start the directive

Please dont call it that. "$" has special meaning already, for example
"$ORIGIN". As for the rest - yes its kind of like pre-processing and you 
could possibly simulate wildcard with special script before loading zone.

> standardize it's functionality.
I agree.
 
> transfers compared with preprocessing.
Agreed.
 
> > where subdomains do not exist.

That is possible because I've presented it and I'm slightly more in favor 
of having wildcard with new functionality just for when host exists but
has no RR of that type, so that would not overlap with regular '*', that
seems less prone to problems with existing dns specs and to confusion
with existing '*' to me. It also makes it easier when finding it in 
zonecut based on NODATA answer.

> domain exists, and when it doesn't. 
And there is nothing that stops somebody who wants this from entering
both new wildcard and '*' record.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 19 Jan 2005 13:48:03 -0800 (PST)

> > i disagree.  we need rrtype-specific wildcards, and nonterminal wildcards.
Same (and I'd like to emphasise again that it needs to be new wildcard 
type and not expansion of meaning of '*')
 
> Ok, I confess I don't understand how wildcards and DNSSEC works,

Entire zone is signed together and thus needs to be downloaded and
client needs to be able to interpret wildcards there.

> but current wildcards are server side only.  So, we could just have an
> as it is. 

First of all above is FQDN and not interprted/expanded as wildcard.
What I proposed for new wildcards to support prefixes is that be
interprted only at the end of host, i.e. 'sub.%'. If somebody needs
'sub.%.host' then they can do it by moving host into its own
zone and making appropriate NS deligation.

> The meaning, however, could change for those that want to

I don't see such a solution as being very good one.

--
William Leibzon
Elan Networks
[email-masked]

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 19 Jan 2005 22:53:38 +0100

Not to pick on this particular mail but we are moving out of scope 
further and further.

I've kept quiet for a long time since some discussion of SPF and its 
distant cousins are inevitable to get a clear understanding about DNS 
properties.

Please try to to keep the discussion on DNS requirements, protocol and 
properties and observe some self-dicipline.

Thanks,

--Olaf
  DNSEXT Co-Chair

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Jan 2005 16:46:08 -0800

> filtering on suffixes, obtain similar results?

SPF uses TXT RR for constructing active content.  Scripts are put into
TXT RR to instruct DNS clients where to do additional lookups. This
script offers macro expansions, redirection, includes, exists, CIDR
notation, and data-set descriptors across perhaps 10 TXT RR, which may
then necessitate any number of other lookups to resolve both addresses
and the existence of other RR records.  Essentially, these scripts offer
authorization for servers that may be in the outbound path of a mail
domain.  (Path Registration.)  This constructed data-set exceeds the
typical scope of a DNS reply.

This scope includes possible ancillary domains and may heavily load TXT
RR as indicated by the required sequence of 10 TXT RR lookups within
various domains to resolve the entire data-set.  To revise the syntax
for these scripts, having yet another TXT RR to burn becomes required,
otherwise this laden script creates overflow conditions when versions
collide.  This is just dealing with a single application usurping the
TXT RR.  Wait for this to become a popular technique.

On top of these scripting woes, the reliance upon the traditional
wildcard does not afford an assurance that a miscreant will not
purposely create a mailbox domain causing a wildcard to not return the
intended default (a closed empty set).  

I would not want to encourage use of TXT records in this manner or this
scheme in general.  There is a general need to establish policy within a
much smaller scope.  This could simply signal various supported
conventions within a single domain.  These signals may be "all emails
are signed", or "all MTAs have a valid HELO".  In the case of CSV, this
is an SRV record prefixed with label.  "Seek and ye shall find" is not
without undesired client-side overhead, but this is still no where near
the overhead being entertained.

Although some may make a case for considering TXT to be good choice for
new DNS extensibility, the use of scripting will likely lead to
inappropriate scopes for replies and create undesired risks as these
scripts inevitably expand in both size and complexity.  A good design
should have a well constrained DNS reply.  Having a means to resolve a
query with a _prefix.&.example.com type of syntax where resolvers are
assured to obtain the desired response would be a useful tool.  I am not
offering a proposal, this is simply stating an ideal.

-Doug

---

From: wayne <[email-masked]>
Date: Wed, 19 Jan 2005 20:04:12 -0600

>> filtering on suffixes, obtain similar results?

The consise answer:  SPF *doesn't* need the extra clones of the TXT
RR.  My suggestion to create them is entirely due to the strawman
argument in draft-ymbk-dns-choices that the TXT record space is
limited.  It is limited only because no one has expanded it.

Longer answer:  See my original post at:
http://article.gmane.org/gmane.ietf.dnsext/6513

> [...] and data-set descriptors across perhaps 10 TXT RR, which may
> then necessitate any number of other lookups [...]

*sigh*

This is incorrect and shows that Doug Otis has obviously not read the
draft.  Please read the draft before commenting on it.

> [more of the long rant deleted]
>
> scheme in general.  [...]

Right, instead, with CSV, you encourage the use of SRV records in a
manner totally inconsistent with the SRV RR's description.  Go ahead
and use SRV records for all I care Doug, but don't be a hypocrite.

> [...]                                                           I am not

Uh, you aren't offering CSV as a proposal?  That's news to me.

-wayne

---

From: Danny Mayer <[email-masked]>
Date: Wed, 19 Jan 2005 20:41:58 -0500

At 12:40 AM 1/19/2005, Pekka Savola wrote:

>breaking AAAA (or anything except A) records.  We'll continue to get there.

And wer're there now with EDNS0 even though it's been in the protocols
for 5 years and still firewalls don't understand the DNS UDP packets can
be larger than 512 bytes.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Wed, 19 Jan 2005 21:16:46 -0500

>but I am saying that requiring a new RR is in 2005 a major bar to

I think this is being overblown. You need to look at the interaction vector.
What DNS servers need to know about the new RRs?

The two endpoints:
one the SMTP server receiving the request and the other the domain that
is purporting to be the sender. They have every incentive to upgrade their
DNS Servers to support the new type. If they don't support it then the
query will fail anyway.
The only other ones that are involved in the lookup are:
the root servers, which really don't care about the type as they will only
hand you a referral anyway and in any case are regularly upgrade to support
new types;
the TLD's which again will just hand out a referral and are also
upgraded regularly.

  What other DNS's need to be involved and for what?

Danny

---

From: "John R Levine" <[email-masked]>
Date: 19 Jan 2005 21:33:57 -0500

> What DNS servers need to know about the new RRs?

Only the ones the serve them, but unfortunately the caches in front of
every client that want to use them need to know about them too.  In theory
caches should treat unknown RR types reasonably, in practice, a lot of
them don't.

Regards,

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 20 Jan 2005 04:06:57 +0100

>wayne wrote:

"the TXT record space is limited"

Is this really the case? I cannot find any such limitations.

Is it not rather the selection mechanisms used by various protocols
that is the culprit?  In addition to limitations in the select itself w r t wildcarding,

Yahoo's DomainKeys do not have any such problems as they selected a suffix scheme:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00150.html

It appears that creating new types because you have a "bad select" that
gives you things you do not want, is a rather unusual way of solving problems. 

Is this problem BTW for real?  That is, is POBOX.COM admitting they have a
problem with SPF?

Anders R

---

From: wayne <[email-masked]>
Date: Wed, 19 Jan 2005 22:12:37 -0600

> Is this really the case? I cannot find any such limitations.

According to dns-choices, yes, the space is limited.  See section 3.1.

> http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00150.html

The terminology used in dns-choices for this is "prefix" rather than
"suffix".  It is also argued against in dns-choices.

> Is this problem BTW for real?  That is, is POBOX.COM admitting they have a

I do not believe that there is any serious problem with SPF's use of
TXT RRs.  I have done studies (posted to the MARID list) that shows
that the vast majority of SPF records are very short and that there
are not many domains that have TXT RRsets that are already close to
the 512B UDP DNS limit.  In cases where the RRset is already pretty
full, a short SPF record of "v=spf1 redirect=_spf.%{d}" will solve the
problem, with the cost of one more DNS lookup (and therefore one less
DNS lookup that can be used on the redirected record).

Again, my suggestion to create additional TXT RRs of TXT0-TXT9 is
solely to addressed the claimed problems as found in dns-choices.  SPF
will survive just fine without them.

-wayne

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Jan 2005 20:18:23 -0800

> draft.  Please read the draft before commenting on it.

I said this to explain the desire to have more TXT records or the desire
to redefine the Class field.  This is only related to a problem created
by attempts to use the current wildcard and thus usurping a TXT RR.

pobox still lists
http://www.ozonehouse.com/mark/spf/draft-lentczner-spf-00.txt

as the current specification for the SPF record.  This draft says 10
lookups is required.  How can you say it is now less?  Did you change
the version of the record?  What draft was applied when publishing and
which is applied when reading?  I did not see a limit on the number of
sequential TXT RR in the "alternative" draft?  Hard to tell who is using
which definition.  : (

I said this to illustrate that these records may use a substantial
portion of the packet and hence the danger created attempting to use a
common label or a wildcard scheme.  The current wildcard scheme can not
be used to assert policy, so this issue of duplicate records types
should be dropped.

> > [...] I am not offering a proposal, this is simply stating an ideal.
> 

I did not want to imply I was proposing a DNS wildcard scheme.  The CSV
proposal does not utilize a wildcard.  In fact, it can not, so the CSV
proposal will not interfere with the use of this record type.  There
will never come a time when someone will be lamenting there should be
100 duplicate SRV record types, even if you don't like how something is
defined for this particular label.

Suggesting a needing more TXT RR or Class designators is fruitless.  A
new wildcard that can handle a prefix, not collide with other record
types, or empty labels, would offer less overhead.  This changes how
resolvers track the name space, how records are exchanged between
servers, and of course how things are signed.  Using a label prefix is
really the only current workable alternative.

-Doug

---

From: Danny Mayer <[email-masked]>
Date: Thu, 20 Jan 2005 00:36:34 -0500

>caches should treat unknown RR types reasonably, in practice, a lot of

Exactly which caches are you referring to? Unless you are doing forwarding
you shouldn't need to worry and if you are you should stop doing that
anyway as it really doesn't buy you much. It's the local DNS that needs to
understand the RR type as well as the clients themselves. If you are not
talking about DNS servers then it's irrelevant here.

Danny

---

From: "John R Levine" <[email-masked]>
Date: 20 Jan 2005 00:59:37 -0500

> Exactly which caches are you referring to?

Uh, the ones in front of the clients, like I said.  Surely you aren't
proposing that DNS clients should run without caches and hammer on the
servers.  The cache may well be on the same host as the client, but it's
still a cache and it can screw up.

> Unless you are doing forwarding you shouldn't need to worry and if you
> are you should stop doing that anyway as it really doesn't buy you much.
> It's the local DNS that needs to understand the RR type as well as the
> clients themselves. If you are not talking about DNS servers then it's
> irrelevant here.

If only life were that simple.  In an ideal world, everyone who wrote a
DNS cache or firewall proxy would have read and understood RFC 3597, and
caches and proxies would handle all RR types properly and transparently.
Unfortunately, in this world, things are a mess.  As I've pointed out in
several previous messages, hosts behind MS firewalls can't query for any
RR types other than the ones the firewall explictly supports, and I gather
that other caches have been known to screw up unexpected RRs as well.
That's the problem, that's why you have to be sure that the cache and, if
there is one, firewall in front of the client can handle new RRs, too.

Regards,

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 20 Jan 2005 07:14:33 +0100

>wayne wrote

>According to dns-choices, yes, the space is limited.  See section 3.1.

I believe it is talking about something else than about storing huge amounts of
properly named TXT records and then retrieving them which was my concern.

>"suffix".  It is also argued against in dns-choices.

The suffix scheme described in dns-choices is *unknown* by the development community.

No, dns-choices avoided describing this scheme as it solves most
real problems.  Prefxes are leftmost elements only.  In DomainKeys
 "_domainkey" (aka the "real" datatype) can serve as prefix AND suffix
depending on the query.

>DNS lookup that can be used on the redirected record).

I'm in no way certain on this but it is possible that SPF by using a
"midfix" scheme a la DomainKeys could do much better.

Anders

---

From: wayne <[email-masked]>
Date: Thu, 20 Jan 2005 09:16:51 -0600

In <[email-masked]> Douglas Otis <[email-masked]> writes:

> as the current specification for the SPF record.

That draft was not brought forth to be discussed on this mailing
list.  It is old.  For better or worse, I do not control Meng's
website.  I've asked Meng before to change it, and I'll ask him again.
If you are not sure what is being discussed on this mailing list,
please read the archives.

-wayne

---

From: Paul Vixie <[email-masked]>
Date: Thu, 20 Jan 2005 16:39:41 +0000

doug wrote:

> much smaller scope.  ...

i agree with this analysis, but i still don't understand why we're talking
about SPF at all.  SPF as it is today will not be changed because of the
installed base.  (in fact, without a pre-existing installed base, SPF as
it is could not, today, be created, at least not by an open standards
process.)  what's at issue here is not therefore "what should SPF have been."

SPF as it is proposed to be changed (with extra lookups to discover SOA's)
does not yet exist and has no installed base.  for various reasons covered
elsewhere in this thread, using SOA's in this way is a layering violation
and is unlikely to become an ietf standard.

that appears to be the end of the line for namedroppers, other than the
interesting side discussion of "should we create per-rrtype wildcards,
nonterminal wildcards, and name-range wildcards?" which is not likely to
produce a definitive standard in time to help the SPF people figure out
how to leverage their existing installed base by adding more functionality.

can the chairs please ask "is there a WG item lurking in all this text?"

paul

---

From: Ben Laurie <[email-masked]>
Date: Mon, 24 Jan 2005 14:15:28 +0000

> servers.  It doesn't affect normal DNS client-server interactions at

Or if you use DNSSEC.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Ben Laurie <[email-masked]>
Date: Mon, 24 Jan 2005 14:22:16 +0000

> transfers compared with preprocessing.

This clashes with DNSSEC again (since a requirement is that the signing 
key should not be needed on the server).

Cheers,

Ben.

---

From: Alex Bligh <[email-masked]>
Date: Mon, 24 Jan 2005 15:15:45 +0000

>> servers.  It doesn't affect normal DNS client-server interactions at

Even then they aren't a protocol change if they are essentially
synthesis by macro expansion (or whatever), are generated prior
to signing, and can be decomposed into a combination of existing
wildcards and existing non-wildcard RRs (those are certainly
sufficient conditions, they may not all be necessary conditions).

Alex