Subject: Faux wildcards

From: "John R Levine" <[email-masked]>
Date: 15 Jan 2005 17:13:11 -0500

I've been working on CSV, a simple scheme for HELO/EHLO authentication
with Dave Crocker and some other people.  By far the knottiest question
we've been wresting with is if and how to do wildcard-like things.

For CSV we're using repurposed SRV records.  They have the fields we need,
they're widely supported by DNS software, including software written in
the Seattle suburbs, and the name prefixes that all SRV records have avoid
collisions.

If you're a mail server, and an incoming connection says EHLO
GOOD.EXAMPLE.COM, the server looks up

	_client._smtp.GOOD.EXAMPLE.COM

and if it finds it, the record tells you whether that's the name of a
valid SMTP client host, and the name part of the SRV record tells it the
name to look up if it wants to check that the name has a valid A record.

But if the SRV record doesn't exist, then what?

I see two situations where a wildcard-like facility for CSV would be
useful.  One is forgery.  I have domains that contain no MTAs, and it
would be nice to be able to say in one place that, e.g. any MTA that
HELO's as <anything>.services.net is lying.  The other is what I
generically call Big ISPs, with a large farm of hosts, such as dialup or
DHCP users, all of which exist and have names, but by policy none of which
should be sending mail directly.  Although in theory it would be possible
to add a SRV record to correspond to each A record, it would aid CSV's
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.

We went throught the usual supects.  Wildcards are out because they don't
work with prefixes, and if we got rid of the prefixes, we'd have other
problems.  There was one advocate for zone cuts but we shouted him down
with the same arguments we've recently heard here.  So we ended up with a
tree walk, not unlike the one that was proposed for WHOIS last year.

We took one of the bits in the SRV record we hadn't used yet and made it
the "explicit" bit, that says that all authorized clients in subdomains of
this one have explicit CSV records.  If the lookup above didn't work, the
MTA can walk the tree, and visit some or all of these looking for the
explicit bit:

	_client._smtp.EXAMPLE.COM
	_client._smtp.COM
	_client._smtp.

After a lot of wrangling, we decided not to specify the direction of the
walk, and decreed that if a domain's record and one of its subdomain's
records have inconsistent explicit bits, the result is undefined.
Walking down has the advantage that in the (we hope) common case that a
domain puts a record high up in the tree, it'll be found quickly, and if a
bad guy does a fake HELO x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.example, the walk
can if it wants decide that since nobody's ever seen a real HELO with more
than five components, it'll stop after five rounds and if in the future
someone wants to use an MTA with a deeper name than that, they better
publish a CSV for it.

We should add a stop rule saying that you don't walk above the first or
second level of the DNS tree to limit the number of visits to the roots,
but that's basically it.  We don't require that a host have an A or AAAA
record, because we're still seeing way too many legitimate MTAs whose
HELOs are within the proper domain but don't match an A record, with
Hotmail's HELO hotmail.com being the best known. (The name in the SRV
record is the one whose address you verify, so you can make up fake names
with A records to match the addresses of your mail hosts if you need to.)

If you accept our premise that some sort way to announce the CSV policy
for a subtree of DNS is useful, is this the best we can do?

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.

--
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: John Levine <[email-masked]>
Date: 16 Jan 2005 01:47:06 -0000

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

Indeed, that's why I said repurposed.

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

In this case, by a domain I mean a node in the DNS tree and all of its
children, not necessarily at any particular level.  I specifically do
not mean a zone.

>How about the absence of the RR as an indicator?

No, that's a classic FUSSP flaw, in that it'll only work when the
entire world deploys the scheme.  Until then, you can't tell a missing
RR due to deliberate omission from one due to not having gotten around
to doing CSV yet.

>You mean an SRV RR at each domain name that owns an address (maybe A) RR?
>Why don't you just specify that? The number of names is just a provisioning
>problem.

Because the number of names can be enormous.  For many large ISPs it's
in the hundreds of thousands.  For AOL it's in the millions.  Like I
said, in theory it's possible, in practice it's a huge burden.

>> adoption if they could say in one place that all of their authorized mail
>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?

Partly because you can't predict the fake names that people might use,
partly because the number of required RRs would be very large.  Also,
as noted before, zone boundaries are irrelevant and a record with the
explicit bit can occur at any level.

>They work perfectly well, but they just either cover more than you need or
>in case the owners exist (i.e. hosts have A RRs) the wildcards do no longer
>apply.

No, for SRV applications they don't work at all.  Names like
_client._smtp.*.example.com don't match anything useful.

>And why would you know that a CSV RR published in the e.g. Uni-Bielefeld.DE
>zone would apply to anything in TechFak.Uni-Bielefeld.DE or Biologie.
>Uni-Bielefeld.DE or anywhere else, regardless of any zone cuts in between?

Gee, we had this argument, too.  It's because subzones of
Uni-Bielefeld.DE are delegated from Uni-Bielefeld.DE, of course, and
are completely at the mercy of the operator of the higher level zone
already.  There seem to be a lot of subzone operators who wish this
weren't true, but if you want to constrain the behavior of the zones
that delegate to you, you have to do it administratively, not within
the DNS.  And for the third time, zone cuts aren't relevant to this
design.

>Or to "co.TLD", for example? (Anyone propose TLD based exception or rules
>lists (UK:2, DE:1, MUSEUM:0)?)

Yes, we're aware that the delegation rules are at many different
levels.  In CA it can be 1, 2, or 3, in US it can be 1, 3, or 4.  As I
said, this is to limit the load on the roots, not to attempt to intuit
zone structure.

>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 major advantage of SRV, as I said in my previous message, is that
all SRV records have name prefixes so you don't get the name and
semantics overloading problems you do with TXT, even if you use the
fields in the SRV to mean something new.  A smaller but I think still
meaningful advantage is that we don't require clients to do parsing
and type conversion like SPF does.  The most complicated operation you
need to interpret CSV data is bit masking on a numeric field.

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

---

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. 

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

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

---

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

> [mailto:[email-masked]] On Behalf Of John Levine
> Uni-Bielefeld.DE are delegated from Uni-Bielefeld.DE, of 
> course, and are completely at the mercy of the operator of 
> the higher level zone already.  There seem to be a lot of 
> subzone operators who wish this weren't true, but if you want 
> to constrain the behavior of the zones that delegate to you, 
> you have to do it administratively, not within the DNS.  And 
> for the third time, zone cuts aren't relevant to this design.

Here I think there is a problem. This type of argument can come unstuck
really baddly, it is close to 'as secure as' which is how http passwords got
spec'd to be sent en-clair and how WEP became a disaster etc.

I think that the problem you will find here is not so much a deliberate
attack but accidental treading on su-admin zones. 

For example MIT has a network group that manages *.mit.edu, but the LCS and
AI labs have traditionally managed *.ai.mit.edu and *.lcs.mit.edu (now
*.csail.mit.edu) independently. 

What your proposal does is to change the balance of power between the apex
operator and the subzone operator. There is no process in place to make sure
that changes at the apex do not inadvertently tread on configuration at the
leaves.

The same thing will turn up all over the place. It's a really bad plan.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 16 Jan 2005 11:30:23 -0800

> [mailto:[email-masked]] On Behalf Of wayne

> First, the folks running the in-addr tree have said "DON'T!  
> We can't deal with the extra traffic."

That is not a reason. If there is purpose to use of an infrastructure then
we should fix the infrastructure. SPF will increase the load on core DNS
significantly, that means real cost to DNS infrastructure operators but I
have not hear any complaints from there.

I mind a lot when I am being asked to spend real money and use real
electricity to no purpose at all, if it is going to be used and there is a
reason there is no problem.

> Secondly, the domain names show up in email headers, such as the
> Received: header.  Experience has shown that there is a very 
> large number of people who know enough to get their mail 
> agents to show the headers, and yet can not actually read and 
> detect forgeries in them. As a result, just having your 
> domain name show up near the top of the
> Received: headers can result in a lot of people incorrectly 
> assuming your domain is somehow responsible.

This is a much better reason. The admin of the reverse DNS is not great,
that can be improved but the admin zones are never going to match very well.

Reverse DNS is used to mean 'I am responsible for this IP address'. It is a
really good infrastructure for handing off services like INCH/RID. It is not
suitable for application level.

	Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 16 Jan 2005 11:40:59 -0800

> From: [email-masked] 

> In 
> <[email-masked]
> .vrsn.com> "Hallam-Baker, Phillip" <[email-masked]> writes:
> 
> > 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.
> 
> 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.

In which case what you really want is something like the following, a
wildcard that defaults the lookup of the entire subtree to some existing
node then a set of policy records tied off that node. Ie.

*.example.com ---> default.example.com
exists.example.com  A blahhh
_prefix.default.example.com  TXT "Default policy record"

OK so we when we do the lookup for the node that exists we hit a record that
exists, find that there is no stated policy for that node.

If we look up anything else we hit the mapping record and get directed to
default. 

Just think of it as a wildcard SOA :-)

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

These people said that there was no problem at all causing the .com zone
file to expand by about 10Gb. That was not a deployment problem that needed
to be considered so I don't think that 10,000 nodes times a few Kb is a show
stopper.

Companies such as AOL who have millions of records will simply use a DNS
server that can synthesize records on the fly if they have that much
difficulty. They probably already do something of this sort anyway.

The macro preprocessor thingie is only for folk who have smallish zone
files.

---

From: Peter Koch <[email-masked]>
Date: Mon, 17 Jan 2005 22:09:30 +0100

> said, in theory it's possible, in practice it's a huge burden.

depending on the motivation, the perceived level of urgency and the
tools/clue available, it should still be doable. Large zones already exist
and anyone at the size of AOL (just quoting your example above) would be
able to cope with it, admittedly not for free.

> _client._smtp.*.example.com don't match anything useful.

No, but *.example.com would. Combined with a dedicated, new, RR type, that
should serve your needs.

> are completely at the mercy of the operator of the higher level zone

No, they are not, that's why they are delegated their own zone. It may be
the case that in this case the principal of the University (or the
CEO/CTO of a company or ...) may demand a certain policy, but this is
out of the scope of the DNS and in particular you cannot assume this in
the general case.

> the DNS.  And for the third time, zone cuts aren't relevant to this

The zone cuts are definitely nothing the application and/or the querier
should worry about, but they are definitely relevant to the extent one
can control the namespace. That's why delegation exists.

> said, this is to limit the load on the roots, not to attempt to intuit

Obviously not only the root, otherwise you'd allow for _client._smtp.<TLD>,
which would obviously bad for TLDs other than GOV, MIL, or VA.

-Peter