Subject: Re: Faux wildcards

From: John Levine <[email-masked]>
Date: 16 Jan 2005 01:47:06 -0000

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

Indeed, that's why I said repurposed.

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

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.

>> HELO's as <anything>.services.net is lying.  The other is what I
>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.

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

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.

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

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

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

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