Subject: SPF I-D for review: draft-schlitt-spf-classic-00.txt

From: wayne <[email-masked]>
Date: Mon, 03 Jan 2005 20:41:36 -0600

[ Moderators note: This post needed manual approval.

   Either it was posted by a non-subscribed address, or the posting
   was too large ( > 20000bytes ) for this list.

   With the massive amount of spam, it is easy to miss and therefore
   delete posts that need manual approval.

   Please use your subscribed address to post, or shorten your
   postings by using links instead of attachments. ]

fyi;

There is a new I-D for the SPF email anti-forgery system available for
review.  This draft tries to document the current practices of the
~~1,000,000[1] published SPF records and ~10,000[1] deployed SPF
systems that are checking 20-100million emails per day.

See: http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-00.txt

Discussions about this, and previous, drafts have been taking place on
the [email-masked] mailing list.  To subscribe or read
the archives, see http://spf.pobox.com/mailinglist.html

While I have been reading this mailing list for many months and will
note any comments posted here, sending email to the spf-discuss list
or to me personally is probably better than flooding this list.

I realize that the whole subject of SPF (and similar systems) has a
certain amount of controversy to it, but for the purposes of this
draft, I am very reluctant to try debate these issues.  The goal is to
document a de-facto standard.  Debates about better techniques, why
SPF is evil, etc. are probably best discussed on things like the IRTF
ASRG list, SPAM-L, the NANAE newsgroup, or on spf-discuss on a
separate thread/subject.

While SPF mostly deals with the [2]821 SMTP level, it also relies
heavily on DNS to communicate between the domain owner, and the email
receiver.  This I-D also makes provisions to create a new RR that is
just a clone of the TXT RR type.  While I did not make it to IETF-61,
it is my understanding that Stephane Bortzmeyer made a presentation on
this subject during the DNSEXT session.  I would like to thank
Stephane and the WG chairs for this review, and I would also like to
thank Ed Lewis for the presentation he made at the MARID Interim
Meeting last spring.

-wayne

[1] These numbers are estimates, but pretty solid ones.  I have data
to back them up and they are almost certainly underestimating the real
numbers.

--
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: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 10 Jan 2005 09:19:13 +0100

On Mon, Jan 03, 2005 at 08:41:36PM -0600,
 wayne <[email-masked]> wrote 
 a message of 47 lines which said:

> There is a new I-D for the SPF email anti-forgery system available
> for review.
...
> heavily on DNS to communicate between the domain owner, and the
> email receiver.  This I-D also makes provisions to create a new RR
> that is just a clone of the TXT RR type.  While I did not make it to
> IETF-61, it is my understanding that Stephane Bortzmeyer made a
> presentation on this subject during the DNSEXT session.

There have been apparently no reply. Does it mean that nobody see
solid problems and that there is a silent and rough consensus that
the I-D can move forward :-)

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 10 Jan 2005 01:02:56 -0800 (PST)

> the I-D can move forward :-)

I do see some problems, but I already raised them at spf-discuss. 
But since you asked about it on namedroppers, I'll focus just list
what I do not like as far as dns is concerned:

1. The draft says that if SPF record is not found for say "sub.example.com", 
that lookup should be made for zonecut record which would probably be
"example.com". This is done as a way to simulate *.example.com and provide
spf record for all subdomains (especially when they exist unlike "*"), but
I think the problem is that these default SPF record are not identified 
any difernent as with "*" and its just normal spf record for that domain 
that is always the default and one can not turn this off. I have proposed 
instead using special prefix - possibly "*spf*" or just "**" so that
such records are clearly identified, this would also allow in the future 
to add feature to dns server itself that it could substitute default on 
its own instead of forcing client to do 2nd lookup each time.

2. I'm still not perfectly happy that SPF is reusing TXT and especially 
that this draft has changed all examples to use TXT instead of SPF record 
type. In my opinion SPF draft should promote new SPF record type a lot 
more and have clearly defined "exit" strategy of moving away from TXT 
records once new DNS RR has been issued.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Mon, 10 Jan 2005 17:05:24 +0000

> 1. The draft says that if SPF record is not found for say
> "sub.example.com", that lookup should be made for zonecut record which
> would probably be "example.com". This is done as a way to simulate
> *.example.com and provide spf record for all subdomains (especially
> when they exist unlike "*"), but I think the problem is that these
> default SPF record are not identified any difernent as with "*" and
> its just normal spf record for that domain that is always the default
> and one can not turn this off. I have proposed instead using special
> prefix - possibly "*spf*" or just "**" so that such records are
> clearly identified, this would also allow in the future to add feature
> to dns server itself that it could substitute default on its own
> instead of forcing client to do 2nd lookup each time.

the SPF steamroller can't slow down or change direction, nope.  or else
we'd be using namehack-based subclassing a la the "mail-from" proposal.

however, some thought should be given to protecting the root servers.
given that a number of ill-considered SPF clientsides already do things
like look at some/all header addresses even if only envelope addresses
are indicated, thus breaking mailing list exploders who leave the headers
as they are and only rewrite the envelope, we know that SPF's clientside
will be broad, unaudited, and powerful.  it may be that given a domain
name of sub.example.com, queries will be made for TXT RRs having names

     sub.example.com
     example.com
     com
     .

which would be bad.  with specific reference to RFC 1535, i'd like this
danger to be called out in the dns-related part of the SPF document, in
case any clientside implentor ever actually reads the SPF specification.
perhaps a prohibition of the form "SPF queries must never be made for
domain names having fewer than two labels".

> records once new DNS RR has been issued.

moreover, there should be two documents.  one an FYI describing SPF as it
is (TXT RR based), and one a proposed standard recommending a new RR type.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 11 Jan 2005 15:46:17 +0100

with specific reference to RFC 1535, i'd like this
    
Although I agree with Paul about the danger (unnecessarily querying
of root and tld domains) he tries to guard against with this language,
this won't help tlds with second level or deeper level structure
such as co.uk or eu.int.

This whole idea of walking up the tree looking for an SPF record
seems to be broken to me.

	jaap

---

From: Dean Anderson <[email-masked]>
Date: Tue, 11 Jan 2005 10:47:35 -0500 (EST)

SPF has been shown not to work, and I've collected about 14 major problems
with it, posted on ietf-mxcomp.  SPF fails to achieve the goals set out,
and makes some problems worse.  The ietf-mxcomp working group (created for
SPF) has shut down.  But some people continue to push SPF ahead anyway.  
I think the reasons are financial. Some have patents and products, and
want an IETF stamp of approval for their marketing literature.

Indeed, I thought you were one of the people who wanted to push it ahead
despite the failures.  Is your post a rhetorical question?

I think the silence (and workgroup dissolution) means that people have
realized that it won't work and that no one has any solutions.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 11 Jan 2005 16:52:39 +0100

On Tue, Jan 11, 2005 at 10:47:35AM -0500,
 Dean Anderson <[email-masked]> wrote 
 a message of 47 lines which said:

> SPF has been shown not to work,

This is clearly off-topic for this group. As said by the chairs at
IETF 61, "DNS extensions" should focus on DNS issues, like Paul Vixie
did by addressing the new RR type question.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 11 Jan 2005 17:15:23 +0100

On Tue, Jan 11, 2005 at 03:46:17PM +0100,
 Jaap Akkerhuis <[email-masked]> wrote 

> this won't help tlds with second level or deeper level structure

At least, it will mitigate the problem.
 
> seems to be broken to me.

The rationale is to handle domains with subdomains (like
www.example.com or sales.example.com) which typically forget to set up
a SPF record for the subdomains. So, the phisher can just say MAIL
FROM:<[email-masked]> and defeat SPF even if example.com is
protected.

Of course, the proper solution is to have SPF records automatically
generated by the same process that creates the zone file with the
proper PTR, the MX records and so on. But some people seems to edit
large zone files by hand (they typically do not know M4 or Perl or
Ruby) and want a mechanism to help them.

---

From: Alex Bligh <[email-masked]>
Date: Tue, 11 Jan 2005 17:17:34 +0000

> Ruby) and want a mechanism to help them.

People's inability to edit zonefiles by hand properly or implement proper
macro languages does not seem to me a sufficient reason to load up the DNS
servers of those above them in the hierarchy. Seems to me you are trying to
solve a layer 8 problem at the protocol layer, when it should, if anywhere,
be solved at the application layer.

I had heard wind (possibly malicious, so I don't assign it much
credibility) that the real purpose behind the tree walk was so those who
don't like the default SPF action could lobby TLDs etc. so that the default
SPF for (say) any domains within (e.g.) co.uk could be changed by (e.g.)
Nominet (and .com by Verisign etc.). I think this is a responsibility zone
operators should not seek...

Alex

---

From: Robert Martin-Legene <[email-masked]>
Date: Tue, 11 Jan 2005 20:10:43 +0100

>operators should not seek...

I wonder how many registries would really want to do this. It sounds
very dangerous. 

However, the load on the TLD servers could be greatly diminished
by adding a TLD TXT record with a very high TTL.

I am not saying it's a solution to the problem. Just yet another hack.
The application should never query the TLD servers (nor lvl 2 for e.g.
.uk) for SPF-records of any kind.

-- 
Robert Martin-Legène
IT security manager
DK Hostmaster A/S

---

From: Alex Bligh <[email-masked]>
Date: Tue, 11 Jan 2005 19:24:38 +0000

> .uk) for SPF-records of any kind.

May be I misunderstood. How does the application know to query
for 2 levels in sales.ibm.com, but only one level for sales.co.uk?

Alex

---

From: Robert Martin-Legene <[email-masked]>
Date: Tue, 11 Jan 2005 20:28:05 +0100

>for 2 levels in sales.ibm.com, but only one level for sales.co.uk?

I was stressing that *I* dont think it should.

It probably doesn't know, and that's a problem.

-- 
Robert Martin-Legène
IT-sikkerhedschef / IT security manager
DK Hostmaster A/S

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 11 Jan 2005 20:37:20 +0100

Also note that there are TLDs out there which have a mixed system:
they allow myname.example. and myname.com.example.  If you want to
have any hack like this to work, you have to configure the whole
current and future name space structure in the hack to make it work.

	jaap

---

From: Paul Vixie <[email-masked]>
Date: Tue, 11 Jan 2005 21:23:35 +0000

> It sounds very dangerous.

yes.  see RFC 1535 (and perhaps RFC 1536) to understand the dangers
inherent in client-side dns surfing.

> However, the load on the TLD servers could be greatly diminished by
> adding a TLD TXT record with a very high TTL.

no.  enough broken dns clients out there fail to cache anything at all,
positive or negative, that the presence of a TLD TXT RR would not slow
down the rate at which these queries were generated, or needlessly and
endlessly repeated.

> .uk) for SPF-records of any kind.

i had not even considered .CO.UK (et al) when i wrote my "less than two
labels" recommendation.  there's basically no way to appropriately limit
the search based on the TLD or SLD.  since there's also absolutely no
reason to do this kind of searching from the client side -- whatever they
use to look up MX will work to look up TXT -- which means, wildcards or
masqueradenames.  this "search the parent" logic has to be removed, or
replaced with a "MUST NOT" of some kind.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 11 Jan 2005 22:43:26 +0100

On Tue, Jan 11, 2005 at 05:17:34PM +0000,
 Alex Bligh <[email-masked]> wrote 
 a message of 25 lines which said:

> credibility) that the real purpose behind the tree walk was so those
> who don't like the default SPF action could lobby TLDs etc. so that
> the default SPF for (say) any domains within (e.g.) co.uk could be
> changed by (e.g.)  Nominet (and .com by Verisign etc.).

They are not rumours, some people already requested that (not the I-D
authors, nor me). A TLD even announced its SPF record for the TLD as
an "anti-spam" service...

(Today, four TLD, all managed by the same registry, have a SPF record.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 11 Jan 2005 22:52:56 +0100

On Tue, Jan 11, 2005 at 08:37:20PM +0100,
 Jaap Akkerhuis <[email-masked]> wrote 

> current and future name space structure in the hack to make it work.

Hence the proposal to use the "zone cut" algorithm (RFC 2181) for the
lookup, which avoids any assumption about the structure or the depth
of the name space...

With the "security belt" added by Paul Vixie (never request for names
of zero or one label), it seems safe, even if there are better
solutions (like mentioned by Alex Bligh).

For the fun, do note that the zone cut algorithm can be defeated by
unusual configurations (so it is a good idea to introduce Paul Vixie's
limit). For instance, try to find the zone cut above doesnotexist.ac
(hint: some of the name servers of the TLD are recursive).

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 11 Jan 2005 14:02:10 -0800 (PST)

> name of sub.example.com, queries will be made for TXT RRs having names

That is not exactly true. They are not planning to "walk down the tree" 
but they will look authoritive zone domain (the one that holds SOA for
that domain) and then lookup record at that start (i.e. if 
sub1.sub2.example.com is a host in the zone of example.com, the lookup 
will immediately come to example.com and not first to sub2.example.com). 
That pretty much means the root servers will never see the such lookups. 
But situation is different for TLDs and SLDs, there are in fact number of 
domains used as nameservers which "A" records are registered directly in 
TLD zones and I'm afraid some implementations may incorrectly assume that 
TLD zone is start of authority for that domain (they are not supposed to 
make this assumption just because "A" record is returned in the ADDITIONAL 
section but we all know majority will not do extra dns lookup once they 
get the answer - be it from ADDITIONAL section or otherwise).

I'm also generally concerned that SPF lookups just for single host will
very often result in at least 4 dns lookups with zonecut defaults (one TXT 
lookup for sub.domain.com, one SPF lookup for sub.domain.com, one TXT 
lookup for domain.com, one SPF lookup for domain.com) and that is just
too much extra load on ISP dns servers and ISPs already have more then
enough problems with their DNS servers getting overloaded because of
other anti-spam filter and as ISP operator and dns host for 1000+ domains
I'm quite concerned.

That is why when I originally mentioned the concept of putting spf default 
at zonecut at interim MARID meeting in May, I had in mind that it would 
not be SPF client doing lookups but that instead its dns server at the ISP 
that would recognize "default wildcarded" SPF records and serve them and 
I'm of the opinion that this should be considered tool for the dns server 
operator rather then client hack. 

If you remember I in fact emailed you if BIND could implement it (i.e. 
synthetic new type of wildcard for when record does exist) and if this 
would require upgrade to DNS protocol. If I understood the answer, it
would because since zones are transfered and secondary can be running
different version of dns server - it should then also be able to
understand new symantics (i.e. just like with regular wildcards where
answer is synthesized but its done same way by every dns server).

Now what I propose is that we do focus on making these zonecut default
records something for dns server to understand (which will require update
to dns specs) and synthesize the answer automatically but in the mean time 
allow clients to simulate it and do 2nd lookup. This way even if one dns 
servers understands new semantics and secondary does not, it could still 
work but we are assuming that in the future once all dns servers are upgraded
the 2nd dns lookup will never be done. If we do want to do it this way, 
then I think it should be new type of wildcard record (and "**" seems quite
good for that purpose) so it could be applicable to more then just SPF.

> domain names having fewer than two labels".

What about example.com.uk? You can't make an assumption that TLD is correct
start of domain delegation.
 
> is (TXT RR based), and one a proposed standard recommending a new RR type.

The current draft is going for experimental status RFC and is the one 
describing what could loosely be called current practice of how SPF is
used (I note that some features are in fact implemented a lot more widely 
then others, for example lookups at EHLO are done at less then 1/10th of 
the rate the MAIL-FROM lookups are done and the mentioned wildcard default 
are almost not implemented at all, which is  why I think its not too late 
to change this). I would definitely be opposed to having used TXT RR in 
standard track document but even with experiment it should be made clear
that we want to move all lookups to SPF before it could become standard.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Don Stokes <[email-masked]>
Date: Wed, 12 Jan 2005 11:21:58 +1300

>FROM:<[email-masked]> and defeat SPF even if example.com is

What's wrong with a wildcard TXT (or better still SPF) RR for such
subdomains?  Put that in the SPF spec, rather than speculatively heading
up the three.

-- don

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 11 Jan 2005 14:45:01 -0800 (PST)

> subdomains?  Put that in the SPF spec, rather than speculatively heading

"*" wildcards are only useful for hosts that don't exist at all (no dns 
RR of any kind for that hostname), but they will not work for hosts that 
have some RR record which is what SPF people are after.

P.S. Is there some reason you have not read the Ed Lewis's wildcard draft 
that was discussed on this list just couple months ago? 
 
-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Tue, 11 Jan 2005 23:22:36 +0000

> have some RR record which is what SPF people are after.

that still doesn't make any sense.  SPF RRs will only be used when there
is an extant LHS@RHS, and the RHS has to have either an A or MX RR which
is at either a real or synthesized (wildcard) name.  put the SPF RR (or
the TXT RR) adjacent to the existing MX or A RR, either at a real name if
that's how the A or MX is found, or at a wildcard "name" if that's how the
A or MX is found.

> that was discussed on this list just couple months ago? 

i'm pretty sure that we've all read that, or helped write it, or whatever.

---

From: Alex Bligh <[email-masked]>
Date: Tue, 11 Jan 2005 23:32:40 +0000

> (Today, four TLD, all managed by the same registry, have a SPF record.)

Well I'm no fan of spam, but I believe the argument over an SPF default
should be an IETF one - I can't (and I'm involved with a registry) see a
justification for registries effectively retrospectively being able to
impose an alternative. IE I am presuming there are good reasons the SPF
default is the way it is, and it should not be within the administrative
purview of some other entity to go change it (shades of sitefinder...).
That said, the argument that tree iteration is going to cause load problems
is more serious.

Alex

---

From: Alex Bligh <[email-masked]>
Date: Tue, 11 Jan 2005 23:42:38 +0000

> that was discussed on this list just couple months ago?

Whilst wildcards may not be a perfect solution, they are just one example
of synthesized/pseudosynthesized records at the authoritative server level.
By synthesized/psuedosynthesized I mean here only that the end user did not
input all the data of the result that's looked up (so I include, for
instance, macros in this) - they might or might not be there in an AXFR.
There is nothing wrong with application level "wildcards" handling this.

EG $authoritative_server_vendor could implement the "**" record/macro to
match any existing record and append a TXT record.

Why does this need solving at protocol layer at all? (people being unable
or unwilling to configure macros, and/or authoritative nameservers
not having an automagic function to turn SPF on in all zones etc.
does not seem like a good reason to me). We don't autogenerate/strip glue
records at a protocol layer because people are too lazy/incompetent to
work out how they work.

Alex

---

From: wayne <[email-masked]>
Date: Tue, 11 Jan 2005 18:22:35 -0600

[ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subsrcibers. Please fix your 
   subscription addresses. ]

In <[email-masked]> Paul Vixie <[email-masked]> writes:

> is at either a real or synthesized (wildcard) name.

The problem is that spammers and phishers can easily use
nonexistant.subdomain.example.com to get around example.com's sender
policy.  This has to work for both the RFC2821 MAIL FROM identity and
the RFC2821 HELO identity.  Sure the email receiver can have a policy
of rejecting email from non-existant domains or domains without an A
record, but in the world of email, there is far too much garbage sent
by legitimate mailers to make such a receiver policy universal.  There
needs to be a way for example.com to publish something for the entire
zone that it controls, even the non-existant parts.

-wayne

---

From: wayne <[email-masked]>
Date: Tue, 11 Jan 2005 12:44:59 -0600

In <[email-masked]> Paul Vixie <[email-masked]> writes:

>> when they exist unlike "*"), [...]
>

Hi Paul.

Although I've been reading posts from you since the late 80s, I'm
afraid I haven't read enough to know for sure whether you are speaking
sarcastically or not, so please excuse me if I respond seriously to a
joke.

Yes, it is now very hard to slow down or change the direction of SPF.
The spec has been pretty slushy for over a year, and incompatible
changes are going to cause a lot of problems.

As far as the namehack-based subclassing thing goes, two points.

First, William was talking about where to find the SPF record that
should be used as a *default*, not where all SPF records are located.
What he was talking about had nothing to do with subtyping the TXT RR
instead using a new RR type (e.g. SPF).

As for why the (current) SPF spec doesn't use the namehack-based
subclassing, at one time the SPF spec did use _spf.domain.tld.
Unfortunately, we found too many DNS hosting services that didn't
allow the underscore to be entered into the web pages.  This is kind
of a delema for those hosting services.  Yes, an underscore is
perfectly valid for a domain name, but it isn't valid for a host
name.  Trying to explain this difference to the general public
requires more effort than I suspect most DNS hosters are willing to
do.  Making a special exception for SPF records was not something we
expected that DNS hosters would make.  At least not when this was
changed over a year ago.

> however, some thought should be given to protecting the root servers.

I agree, and I'll try to find a good spot to add some language about
this.

Things are not quite as bad as they may seem.  It is subtle, but if an
SPF implementation conforms to the draft-schlitt-spf-classic-00 spec,
it takes work to generate a DNS query with only one label.  The ABNF
requires all domain specs to end with a dot followed by a "toplabel",
or a macro variable.  So, "include:com" is already invalid.  Normally,
the macro variables will have at least two labels in them, so
"include:%{o}" isn't going to be a problem either.  Even
"include:1.2.3.4" isn't valid, so the root servers won't be hit with
lookups for IP addresses.

> [...]                                    it may be that given a domain
> which would be bad.

I agree that this would be bad, but the current SPF spec would not
allow the checking for SPF records at "com" or ".".  If an SPF record
is not found at the exact domain name, the only other location that is
checked is at the top of the zone (i.e., right under the zone cut).

-wayne

---

From: wayne <[email-masked]>
Date: Tue, 11 Jan 2005 12:49:25 -0600

> operators should not seek...

Any such rumors that you have heard are either due to ignorance or
maliciousness.  None of the various SPF specs that have existed have
ever called for an arbitrary tree-walk, let alone one all the way to
the root.  The current SPF spec calls for checking SPF records in two
places, and two places only: at the given domain, and at the top of
the zone (just below the zone cut).  As such, any conforming SPF
implementation would never know about any SPF records at co.uk, or
.com.

-wayne

---

From: wayne <[email-masked]>
Date: Tue, 11 Jan 2005 12:21:45 -0600

[note:  I've cc:'ed this to SPF-discuss because I think they will find
it useful.]

>> the I-D can move forward :-)

I wish.  ;-)

> what I do not like as far as dns is concerned:

Yes, William has made a very large number of very helpful comments
about the various SPF drafts.  I've addressed many, but not all of
them. 

> its own instead of forcing client to do 2nd lookup each time.

The idea of using a special subdomain for the default SPF record has
been kicked around before.  I know that Mark Lentczner (another I-D
author), and I talked about it a little bit.  Going back over the
comments I made to you on the SPF-discuss list, I see that I didn't
talk about it.

The reason why I didn't say anything about it was because I don't have
very strong feelings about the subject either way.  Right now, the SPF
I-D makes no mention of any special domain names or sub domains, so
I would kind of like to avoid creating one.  Also, if mandating a
special subdomain will generate complaints about "breaking wildcards",
which is another subject I don't have strong feelings on, but others
do.

Another possiblity would be to create a different record at the top of
the zone, with a different version string of, say, "v=spf1-default".
Then you could do something like "v=spf1-default redirect=%{d}" if you
want to get the current semantics, or "v=spf1-default -all" to deny
all email coming from subdomains without SPF records.  If the default
SPF record is really long and DNS packet space is limited, you could
use "v=spf1-default redirect=*spf*.%{d}" and get the semantics you
suggest.

Note:  These default SPF records are should only be used in cases
where mail claims to come from a subdomain that email normally
shouldn't come from.  The SPF spec says that domain owners should use
explicit SPF records for all other cases.  So, extra DNS lookups
shouldn't be a huge problem.  Legitimate email should never have the
overhead, and spammers would gain no advantage to using them.

> records once new DNS RR has been issued.

As I've mentioned many times, I just don't see any practical migration
strategy for DNS RR usage.  The implicit MX rule of using the A record
is still very much needed after all these years.

The language that is in the draft about using TXT RRs and SPF RRs was
something that Mark Lentczner worked out with "the DNS folks" during
the MARID WG process.  (No, I don't know exactly who "the DNS folks"
were.)   Yes, I did many (but not all) of the examples, but that is
because I don't see why deployment of name servers that support the
SPF RR type for many years.

-wayne

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Jan 2005 04:19:37 +0000

> > ...  SPF RRs will only be used when there is an extant LHS@RHS, and
> > the RHS has to have either an A or MX RR which is at either a real
> > or synthesized (wildcard) name.
> 
> policy.

an spf subscriber can trivially detect this.  and probably already is.
postfix calls this functionality by many names, such as:

        reject_unknown_sender_domain,
        reject_unknown_recipient_domain,
        reject_non_fqdn_sender,
        reject_non_fqdn_recipient,
        reject_invalid_hostname,
        reject_unauth_pipelining,
        reject_unauth_destination,
        reject_unknown_hostname,
        reject_non_fqdn_hostname,

and anyone who is interested enough in preventing forgery to install an
spf-capable mailer has the option of turning on features related to
nonexistent subdomains of spf-publishing domains.

since this can easily be handled on the client using the existing
protocol and well-tested features of common implementations, it should
not be made into an spf protocol requirement.

> This has to work for both the RFC2821 MAIL FROM identity and the
> RFC2821 HELO identity.  Sure the email receiver can have a policy of
> rejecting email from non-existant domains or domains without an A

if a legitimate mailer is going to send garbage, they shouldn't publish
spf records.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Jan 2005 04:26:39 +0000

> ... The current SPF spec calls for checking SPF records in two places,
> and two places only: at the given domain, and at the top of the zone
> (just below the zone cut).  As such, any conforming SPF implementation
> would never know about any SPF records at co.uk, or .com.

in what way are you discovering the zone cut?  it sounds as if you're
committing the "novice dns" mistake of assuming that every label cut
is also a zone cut.  if GW.HOME.VIX.COM is the mail sender (A and AAAA
exist), but its name is really GW.HOME in the zone VIX.COM (and there
is therefore no HOME.VIX.COM zone cut, NS RRset, or SOA RR), how would
you propose to discover the "zone cut" you're speaking of?

i know how i had to do it in bind8's res_findzonecut() (for RFC 2136
dynamic update clients to use when finding out where to send their
updates) and it's _hard_.  surely you aren't expecting every SMTP
listener to do this on every SMTP session they process.

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 11 Jan 2005 20:56:28 -0800 (PST)

> you propose to discover the "zone cut" you're speaking of?

By checking the authority section:
-------------------------------------------------------------------------
$ dig soa gw.home.vix.com
; <<>> DiG 9.2.4 <<>> soa gw.home.vix.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49803
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;gw.home.vix.com.               IN      SOA

;; AUTHORITY SECTION:
vix.com.                0       IN      SOA     ns.lah1.vix.com. 
hostmaster.vix.com. 2005010200 3600 1800 604800 3600
-------------------------------------------------------------------------

So zonecut is "vix.com." since that is the start of authority. Current
SPF draft would call for doing SPF and/or TXT lookup at that zonecut.
Personally I'd prefer lookup to be madeto "**".<zonecut> instead.

The are some assumptions that are not in the draft but that we talked
about, in particular its assumed that if DNS RR is not available that DNS
server would return authority info in ADDITIONAL section of dns response
packet (which all BIND servers apparently do, if some other server does
not then additional dns lookup would be needed), i.e.:

-------------------------------------------------------------------------
$ dig gw.home.vix.com
; <<>> DiG 9.2.4 <<>> gw.home.vix.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13468
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;gw.home.vix.com.               IN      A

;; AUTHORITY SECTION:
vix.com.                3600    IN      SOA     ns.lah1.vix.com. 
hostmaster.vix.com. 2005010200 3600 1800 604800 3600
-------------------------------------------------------------------------

> listener to do this on every SMTP session they process.

Personally I'd not mind with having that function becoming part of resolver,
that will sure help us out ...

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Jan 2005 05:24:36 +0000

> > ... how would you propose to discover the "zone cut" you're speaking of?
> 

did you know that the authority section is optional in positive responses?
(have you read RFC 2308?)

> > i know how i had to do it in bind8's res_findzonecut() ...
> 

it has been part of the BIND resolver library since BIND 8.2 or so.  but
you are asking that every SMTP listener possess it and call it on every
SMTP session, which is a lot of potential extra traffic for all concerned.

and none of it is necessary to your application.  just don't query for
anything except the RHS.  (see my other reply elsewhere on this thread.)

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 11 Jan 2005 22:11:30 -0800 (PST)

> (have you read RFC 2308?)

Positive responses are not a problem - if somebody queries for SPF RR and 
gets it, there is no need to do anything else. If there is no authority 
section for negative response, then client can directly query for SOA.

> SMTP session, which is a lot of potential extra traffic for all concerned.

Which is exactly why I said that we should make it special prefix that
dns server can recognize it and synthesize the answer. The client can
simulate this with zonecut method but as more dns servers begin to
support it, its no longer a problem in the long run.

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

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Jan 2005 06:24:47 +0000

> sarcastically or not, so please excuse me if I respond seriously to a

no worries.  i'm not joking.  spf has been a marketing-driven juggernaut
since its first day, and nothing anybody has been able to say has changed
its course by even a degree.

> changes are going to cause a lot of problems.

s/for over a year/since it was first proposed/, please.  i'm assuming that
you've read <http://www.circleid.com/article/634_0_1_0_C/>, and my response.

however, we've all been advised to limit our discussions about this draft
to dns-specific issues, so we should take this part offline.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Jan 2005 06:30:08 +0000

> section for negative response, then client can directly query for SOA.

it is very nearly unthinkable to me that a mail server, as a client of dns,
should ever have to make an SOA query, under any circumstances, especially
not fairly common circumstances.  ("positive" includes NOERROR/NODATA.)

> > ... are asking that every SMTP listener possess it and call it on every

i really am pretty sure that the dns servers will be changed to support SPF
other than to support a new RRtype when y'all get around to proposing that.

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 11 Jan 2005 23:10:24 -0800 (PST)

> not fairly common circumstances.  ("positive" includes NOERROR/NODATA.)

As I said, on the tests it appears that dns servers (bind 8 and bind 9 
at least) do provide this information nearly all the time including for 
NOERROR/NODATA, so I don't think querying for SOA is going to be needed 
very often. And yes it does sound weird for non-dns service to query for 
soa,  but its not breaking anything either as far as I can see and querying
for soa can be usefull for more then just dns internal communication, for 
example to find tech/hostmaster address if whois is not available (ok, you 
can go ahead and blame me for this trick and inappropriate use :)

> i really am pretty sure that the dns servers will be changed to support 
> SPF other than to support a new RRtype when y'all get around to 
> proposing that.

Should I take as that you're willing to support such a feature (synthetic
wildcard for existing hostname but without needed RR) in future versions
of bind? In that case it makes sense for this to become a new dns protocol
feature so that other dns servers would know how to support it too, so I 
think it would be good idea to write it out as ietf document (separate and
not just part of spf draft).

And to make it possible to identify dns records where such new wildcard 
does need to be supported, I think we do need special prefix (and its not 
too late as I don't even know any spf implementation that is doing zonecut  
default checks yet). 

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Peter Koch <[email-masked]>
Date: Wed, 12 Jan 2005 09:23:47 +0100

> solutions (like mentioned by Alex Bligh).

that 'belt', which I guess Paul didn't really suggest, tends to be at least as
bad as the desease. The 'tree climbing' approach is the result of a
misconception about the DNS: it tries to kind of inherit records or even policy
from higher levels in the DNS, which is not only wrong for TLD or "registry
level" zones like DE or co.uk, respectively, but also further down the tree.
The foo department of bar.example cannot be assumed to by default apply
the same policies as bar.example. In the same way we do not inherit or
deduce MX RRs or A RRs, the temptation should be resisted in this case.

Unfortunately there are some precedents (see 'wpad'), but those should not
count as justification. This is DNS, other services might be more appropriate
for the inheritance approach.

-Peter

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 12 Jan 2005 10:39:38 +0100

On Tue, Jan 11, 2005 at 02:02:10PM -0800,
 william(at)elan.net <[email-masked]> wrote 
 a message of 114 lines which said:

> They are not planning to "walk down the tree" but they will look
> authoritive zone domain (the one that holds SOA for that domain)

The SPF draft says "the SPF client MUST find the Zone Cut as defined
in [RFC2181] section 6" and RFC 2181 uses NS records, not SOA.

For a "normal" zone loaded by BIND, it does not matter. But you can
always find funny cases where it's different depending on wether you
use NS or SOA (study doesnotexist.ac).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 12 Jan 2005 10:41:09 +0100

On Wed, Jan 12, 2005 at 06:24:47AM +0000,
 Paul Vixie <[email-masked]> wrote 
 a message of 23 lines which said:

> spf has been a marketing-driven juggernaut since its first day, and
> nothing anybody has been able to say has changed its course by even
> a degree.

Not really, for instance the "DNS walking up to the zone cut" is a
very recent addition, no SPF implementation currently does it.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 12 Jan 2005 14:15:27 +0100

On Wed, Jan 12, 2005 at 03:11:38AM -0800,
 william(at)elan.net <[email-masked]> wrote 
 a message of 939 lines which said:

> but actual start of authority domain is the same no matter if you
> lookup for SOA or NS.

Not really, see later.

> I preferred SOA because that is real authority data 
...
> This all points out that using existing DNS RFC2181 as reference for
> what we want is probably not the best idea

I assume that RFC 2181 uses NS for a reason. I do not know it but we
could ask the authors or Google or the namedroppers' archive.

> and that we need new separate draft document explaining how these
> new zonecut default answer wildcards are supposed to work and how
> dns server can simulate and synthesize the answer and how dns client
> (or dns resolver) can find it if the answer was not available by
> finding correct zonecut

Good luck for the discussion on namedroppers :-)

> Below are the results of me checking .ac as Stephane suggested - as
> you can see they always provide same zonecut domain name
> answers. The difference does exist for sub.domain.com where some of
> the servers do provide the answer but majority do not.

This is because some name servers of the TLD are recursive but not all
(there is a "rd" in your flags but not always a "ra" in the
answer). Check with "dig +norecurse" and you'll see a different
picture, specially for zone cuts.

---

From: Robert Martin-Legene <[email-masked]>
Date: Wed, 12 Jan 2005 15:15:51 +0100

>down the rate at which these queries were generated, or needlessly and

Yes it would.

That there are some broken clients does not mean that all others will
misbehave. And if you are lucky they even have a cache in front of them
- but you assume that is broken too, I suppose - we have all seen
repetetive queries on our servers. Fine. But it still has an effect for
all correctly functioning implementations. So I think you are
exaggerating a little bit when you say plainly that it will have no
effect.

(and I still don't think it's a solution to a problem)

-- 
Robert Martin-Legène
IT security manager
DK Hostmaster A/S

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Jan 2005 14:36:55 +0000

> i really am pretty sure that the dns servers will be changed to support SPF

s/will/won't/.  sorry.  (though it was clear in context, i suppose.)

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Jan 2005 14:44:38 +0000

> very often.

this is namedroppers@, not bind-workers@.  how a particular implementation
behaves is of no interest to the ietf, other than if a widely implemented
protocol violation (which this is not) makes it necessary to design-around
(which this does not).

> And yes it does sound weird for non-dns service to query for soa, but
> its not breaking anything either as far as I can see and querying for
> soa can be usefull for more then just dns internal communication, for
> example to find tech/hostmaster address if whois is not available (ok,
> you can go ahead and blame me for this trick and inappropriate use :)

that's what RP RR's are for.  or did you not know that SOA was never cached?

> > SPF other than to support a new RRtype when y'all get around to 

s/will/won't/, sorry.  though i suppose it was clear in context.

> of bind?

no.  i misspoke.  BIND will implement the dns protocol as defined by the
ietf, with occasional experimental features if those do not violate the
protocol defined by the ietf.

> In that case it makes sense for this to become a new dns protocol
> feature so that other dns servers would know how to support it too, so
> I think it would be good idea to write it out as ietf document
> (separate and not just part of spf draft).

even though i misspoke, there's a path forward illuminated by the mistake.
if you want rrtype-specific wildcards, like for example an "**" label in a
zone file should be a wildcard but only for the rrtypes at the "**" node,
then go ahead and propose it.  if ietf approved such a standard, then BIND
will implement it.  i suspect that the process would be too long for SPF's
requirements.

> too late as I don't even know any spf implementation that is doing zonecut  

that's not a reason for a special prefix.  but as SOA is not cached, it is
not something that should be queried for other than as part of DNS operations
such as serial number queries governing IXFR/AXFR or UPDATE.  since SPF does
not yet do any zonecut checks, please remove that part of the draft.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Jan 2005 14:53:12 +0000

note 1: in my prior mail on this thread i referred to the meng weng interview
at <http://www.circleid.com/article/634_0_1_0_C/>, and my response there.  it
turns out the circleid folks braino'd the URL for MAIL-FROM.  i've since added
an httpd "Alias" here that makes their broken URL work.  if you tried to
follow that link and couldn't, please try again now.

note 2: i'm replying to a message that was sent to both namedroppers@ and
spf-discuss@.  this terrifies me.  i'm setting reply-to; plz honour it even
though i'm not a member of the spf-discuss@ list and won't see the rest of
this thread.  if you're replying to the DNS issues, do so on namedroppers@,
but in any case, do not bridge this thread to both mailing lists.

> could ask the authors or Google or the namedroppers' archive.

SOA is never cached.  it is only meant to be queried for as part of DNS
protocol operations like figuring out if the serial number has changed
(for IXFR/AXFR) or figuring out where to send a DNS UPDATE message.  no
normal client of DNS data should propose to query for this.  those of you
who are coders can look at my comments in bind8's res_findzonecut() for
more information about finding zone cuts, and you should be asking yourself,
why would a mail server ever do this, let alone do it on every SMTP session?

> picture, specially for zone cuts.

indeed, it is vitally unwise to depend on the behaviour of a specific zone
or a specific dns implementation when planning a protocol feature.  you have
to look at what's permitted under the existing specification, and then delete
(not add) some things based on current global practices.  sending back an
SOA is optional in many cases.  see RFC 2308.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Jan 2005 14:57:28 +0000

> >down the rate at which these queries were generated, or needlessly and

no, actually, it would not.

> misbehave.

i didn't say all others would misbehave.  i said that the rate at which
these queries were generated, or needless and endlessly repeated, would
not be affected by the presence of a TLD TXT RR.

> And if you are lucky they even have a cache in front of them - but you
> assume that is broken too, I suppose - we have all seen repetetive
> queries on our servers.  Fine.  But it still has an effect for all
> correctly functioning implementations.  So I think you are

the dominant effects will come from the people who don't cache.  for more
information on this, see all three papers at

	    http://dns.measurement-factory.com/writings/

> (and I still don't think it's a solution to a problem)

hopefully we're on the same page now.

---

From: wayne <[email-masked]>
Date: Wed, 12 Jan 2005 06:21:48 -0600

In <[email-masked]> Paul Vixie <[email-masked]> writes:

> an spf subscriber can trivially detect this.  [...]

I'm not sure what you mean by an "spf subscriber", I'm guessing you
are talking about the system that checks for SPF records.  (This is
called the "spf client" in the I-D.)

> postfix calls this functionality by many names, such as: [list snipped]

Yes, and other mailers have similar options, but those are receiver
policies, not sender policies.  

> nonexistent subdomains of spf-publishing domains.

I don't see how you can detect if a domain owner has published SPF
records without checking for them in the DNS.  Nonexistant subdomains
won't return SPF records.  Hence, the default at the zone cut.

I really don't see how the email receiver (SMTP server) options that
you mentioned above will work for the "spf subscriber".

-wayne

---

From: wayne <[email-masked]>
Date: Wed, 12 Jan 2005 05:57:57 -0600

In <[email-masked]> Paul Vixie <[email-masked]> writes:

>> (just below the zone cut).
>
> in what way are you discovering the zone cut?

See: http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-00.html#version

>                                                it sounds as if you're
> is also a zone cut.

It sounds as if you're assuming instead of reviewing the I-D.

> listener to do this on every SMTP session they process.

Actually, res_findzonecut() is what I've based my code on.  See this
post I made to spf-discuss almost a year ago:

http://archives.listbox.com/[email-masked]/200403/0026.html

I don't claim to be an expert on DNS.  As others have pointed out, the
zone cut is one of the newest features of SPF (introducted about May
'03).  I certainly could be convinced to drop it and/or modify it to
make it work better.

-wayne

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Jan 2005 17:24:45 +0000

> called the "spf client" in the I-D.)

ok, s/subscriber/client/, i'll try to remember.

> policies, not sender policies.  

so far so good.

> > and anyone who is interested enough in preventing forgery to install
> > an spf-capable mailer has the option of turning on features related
> > to nonexistent subdomains of spf-publishing domains.
> 

this is still asking the recipient to pay for the sender's sins.  if an
SPF publisher wants their SPF data to be relevant then you have to deal
with the fact that SPF clients will, in addition to checking for SPF,
reject mail that has nonexistent RHS's or HELO names.

the way this would look in your draft is something like:

"SPF Clients should take precautions to reject e-mail containing
nonexistent domain names; SPF Publishers should be aware that this
will occur, and avoid emitting legitimate e-mail containing such
domain names."

> you mentioned above will work for the "spf subscriber".

see above.  with this simple rule, SPF Clients and SPF Publishers can
cooperate reliably in matters of e-mail authenticity, yet shift none of
the costs of this cooperation onto those who do not publish or consume
SPF data.  a forger who tried to use a nonexistent domain name as a way
to defeat the SPF checking would find their mail rejected due to the
nonexistence of the domain name rather than due to the presence of SPF.

i'm aware of dns installations who conform to rfc1034/rfc1035 in every
way, even though they only answer SOA queries from locally trusted hosts
such as dynamic update clients or IXFR/AXFR slave servers.  not even the
logic and commentary in BIND8's res_findzonecut() will save you from that.
it is well and truly too late to mandate that SOA's be sent, and even if
we could mandate it, we wouldn't want every mail server querying for them
since they aren't cached.  the performance and information-leak problems
from that would scream "bad engineering" even if the protocol could be
changed to require that zone cuts be visible to outsiders.

on a personal note, i'm struck by the similarity of this discussion to
others i've had about SPF in the past.  there's a "proof by vigorous
assertion" feeling about all this.  so let me play rough for a minute:

	   "DNS doesn't work the way you want it to.  Get over it."

---

From: Florian Weimer <[email-masked]>
Date: Wed, 12 Jan 2005 21:23:18 +0100

* william elan net:

> Positive responses are not a problem - if somebody queries for SPF
> RR and gets it, there is no need to do anything else.

SPF lookup for domains used in Internet mail *always* result in
positive responses because there exists an MX or A record for that
domain.  Conforming resolvers do not return an error code in this
case, but an empty data section.

---

From: Matt Larson <[email-masked]>
Date: Wed, 12 Jan 2005 15:24:17 -0500

On Wed, 12 Jan 2005, Paul Vixie wrote:
> but as SOA is not cached,

This statement is contradicted by RFC 1034, section 4.3.4:

  Name servers and resolvers should never attempt to add SOAs to the
  additional section of a non-authoritative response, or attempt to infer
  results which are not directly stated in an authoritative response.
  There are several reasons for this, including: cached information isn't
  usually enough to match up RRs and their zone names, SOA RRs may be
  cached due to direct SOA queries, and name servers are not required to
  output the SOAs in the authority section.

and RFC 2182:

  7.2. TTLs on SOA RRs

     It may be observed that in section 3.2.1 of RFC1035, which defines
     the format of a Resource Record, that the definition of the TTL field
     contains a throw away line which states that the TTL of an SOA record
     should always be sent as zero to prevent caching.  This is mentioned
     nowhere else, and has not generally been implemented.
     Implementations should not assume that SOA records will have a TTL of
     zero, nor are they required to send SOA records with a TTL of zero.

FWIW, my BIND 9.2.4 recursive name server clearly caches SOA records,
as do a few other BIND recursive servers of random or unknown version
numbers that I queried.

Matt

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Jan 2005 21:03:46 +0000

> as do a few other BIND recursive servers of random or unknown version

i stand corrected.  i usually don't think of RFC 2182 when i think of dns,
and the "throw away line" in RFC 1035 has governed both my thinking, and
various early coding efforts.  (matt has corrected me on this point before.)

---

From: wayne <[email-masked]>
Date: Wed, 12 Jan 2005 15:14:15 -0600

> 	   "DNS doesn't work the way you want it to.  Get over it."

I'm quoting last things first to get this out of the way.

No problems playing rough, I've around the net since the late 80s and
have a very thick skin.  I will, however, assume the same for you and
say that there are a lot of similarities with what you are saying now
with previous comments I've seen from you about SPF.  A lot of what
you have been saying smacks of condescension, sour grapes and, yes,
ignorance.

In your reply to Meng's interview on CircleID[1], you said you very
much wish you would have jumped on this idea back in 1998.  I agree,
you should have.  You didn't.  Get over it.

Your claim last fall[2] that "he" (Meng?  me?  someone else?) didn't
know any better than to use TXT RRs is blatantly false and shows your
ignorance.  Meng started out by merging RMX and DMP, and RMX tried to
use a new RR.  We investigated and discussed using a new RR and
decided that trying to get a new RR would take years, would hurt
deployment, and in our humble opinions, we could design SPF records so
that problems with using TXT (as outline in, e.g. dns-choices) could
be largely avoided.

Your question[3] about how we intend to find the zone cut again shows
your ignorance and that you have not even bothered to read the draft.
I thought there was a rule in the IETF that those that haven't read
the drafts shouldn't comment on them.  Even if there isn't, I think we
would be a lot more productive if you did.

The people involved in developing SPF are not world experts in all
things email, DNS and/or spam.  Many of us, however, are very
knowledgeable about several of these areas.  In general, our overriding
goal has been to create a good (but not necessarily perfect) system
to slow email forgery and get as rapid a deployment as possible.
Rapid deployment has, for better or worse, influenced many of our
decisions, including using DNS instead of a new protocol, using TXT
RRs, not using a subdomain for subtyping, not requiring upgrades to
DNS servers, etc.  We have concentrated on the practical, rather than
*just* the theoretical.

We are trying to give domain owners a voice that email receivers can
listen to and determine if a given email is forged/authorized.  Many
of us feel that it is important to be able to easily give the domain
owner a voice about their entire domain.  The zone cut idea is one
possibility, creating a new kind of DNS wildcard system is another.
The zone cut stuff is working, in practice, for me in my beta-code.
If it can't be made to work, or we can find another idea that would
work better, I'm all for dropping it.

Ok, sorry for the long rant, but I think it is important for the
namedropper folks who have not been involved with email/spam to the
degree that Paul or the SPF folks to understand where SPF is coming
from. 

> will occur, and avoid emitting legitimate e-mail containing such

Again, always rejecting email from non-existent domains doesn't solve
all of the problem that the zone cut tries to solve.  You are
requiring that all email senders fix their systems to not issue bad
MAIL FROM/HELO domains, rather than just those domain owners that want
to use SPF.  (Or, another way to look at it is that you are requiring
SPF clients to reject legitimate email just because they check SPF
records.)

That won't fly, deployment wise.

Also, the zone cut language doesn't just deal with cases of
non-existent domains.  It also means that you don't have to publish
SPF records for all the hosts in your domain.  You just need to
publish the ones that are involved with non-forged email.

This is getting somewhat out of the area of DNS and into email.  What
would be extremely useful for SPF, and other anti-forgery systems such
as Yahoo's DomainKeys or Cisco's IIM, is the ability for a domain
owner to be able to speak for their entire domain.  Can we find a DNS
way of doing that?

> changed to require that zone cuts be visible to outsiders.

I have not hit those cases that you speak of in my, admittedly,
limited testing.  I think it would be reasonable to require domain
owners that wish to use the zone default SPF record to have a working
zone.  As long as broken zones don't cause problems for SPF checkers,
that shouldn't be too bad.

-wayne

[1] http://www.circleid.com/article/634_0_1_0_C/
[2] http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01923.html
[3] http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00028.html

---

From: wayne <[email-masked]>
Date: Wed, 12 Jan 2005 15:29:02 -0600

> various early coding efforts.  (matt has corrected me on this point before.)

minor nit:  That's RFC2181, not 2182.

It happens to be the same RFC that I reference in the spf-classic
draft for the definition of a zone cut.  I found it quite educational,
and if there is misinformation in it, I would be quite interested in
learning about the errors.

-wayne

---

From: Edward Lewis <[email-masked]>
Date: Wed, 12 Jan 2005 16:35:32 -0500

Thanks for the prompt.

>that was discussed on this list just couple months ago?

Note to self: work on this document soon.

I can see why the doc hasn't been read - apparently the version from 
last October didn't enter the ID repository correctly.  I wouldn't 
blame anyone for not seeing it.  I should do something about it.

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

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Jan 2005 08:52:54 +1100

> various early coding efforts.  (matt has corrected me on this point before.)

	named negative responses to SOA queries as if they had a
	zero TTL.  This is done to allow a client to query for the
	SOA record to find the zone cut and if the query domain
	didn't exist to not leave a negative cache entry that would
	slow the visibility of changes made by subsequent UPDATE
	requests.

	This is not in any RFC though perhaps it should be.
	This only applies to releases of named that support UPDATE.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Jan 2005 22:08:36 +0000

i'm trying hard to limit my comments on this thread to the dns-relevant bits.

> Rapid deployment has, for better or worse, influenced many of our decisions

if you're basically just pandering to your installed base, why not admit this,
tell the IETF what you've done in the form of an FYI, and give yourself a rest?

> work better, I'm all for dropping it.

anything can be made to work in beta-code.  when you seek universal deployment,
the size of that universe dictates that you work within the letter and spirit
of the spec rather than within the loopholes and enforceability limits.

> to use SPF.

i have been running this way for a couple of years.  rarely i'll get a phone
call from somebody who tried to HELO me from a NAT'd host whose hostname was
not visible in external dns.  i always apologize and then give them my "fax"
number.  this hasn't happened since spring 2004, and i get a LOT of mail from
a LOT of places.  are you sure your information on this is as current as mine?

> (Or, another way to look at it is that you are requiring SPF clients
> to reject legitimate email just because they check SPF records.)

here, we're quibbling over what it means for e-mail to be "legitimate".  the
spirit of HELO is "this is my hostname".  while "HELO localhost" is legitimate
under the letter of RFC 2821, i'd argue that it's a violation of the spirit of
RFC 2821.  given that you're asking RFC 2821 server-side implementations to
consider rejecting e-mail for reasons not contemplated by RFC 2821, it's hard
for me to understand you when you say...

> That won't fly, deployment wise.

but whatever.  let's move on.

> publish the ones that are involved with non-forged email.

i was thinking that you'd publish SPF records for things that had MX
records, or at worst, from things that had (MX or A or AAAA) records.
if you're having trouble doing this, take a look at the "m4" or "cpp"
preprocessors, or ask your DNS vendor for a built in macro processing
facility.

> owner to be able to speak for their entire domain.  Can we find a DNS

ultimately your concern is about nonexistent subdomains.  if a forger can
get more value out of spoofing nonexistent subdomains than from spoofing
nonexistent unrelated domains, then i've been out of the anti-spam world
longer than i thought.  here's what it sounds like you ought to do.

1. codify current behaviour (not the beta-code behaviour; the global one)
2. explain the good and bad aspects of the current dns wildcard features
3. launch a separate effort to add a rrtype-specific wildcard dns feature

> ...  I think it would be reasonable to require domain owners that wish
> to use the zone default SPF record to have a working zone.  As long as
> broken zones don't cause problems for SPF checkers, that shouldn't be
> too bad.

i'm thinking of all dns queries that will be received by nonparticipants,
and sent by SPF Clients to those nonparticipants upon every inbound SMTP
session.

(one non-dns-related side note: somebody around here told me recently that
they had had to delete their SPF records because one or more SPF Clients
had implemented SPF improperly, and were rejecting mailing list e-mail
based on the mismatch between the header From: and the list exploder.  all
this proves is that no matter how careful a specification is authored, it
still has to run the gauntlet of wide scale implementation.)

---

From: Chris Thompson <[email-masked]>
Date: Wed, 12 Jan 2005 22:25:29 +0000 (GMT)

> case, but an empty data section.

Despite the RCODE=NOERROR setting, such responses are most naturally 
classified as "negative": see RFC 2308. In particular, an SOA record 
would be in the authority section if the _recommendations_ of that RFC 
are followed, allowing the stab-in-the-dark at the zone boundary being
proposed for SPF.

Disclaimer: this isn't meant to indicate approval for the I-D being
discussed, or indeed for anything whatsoever associated with SPF. :-(

Chris Thompson
Email: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Jan 2005 22:45:24 +0000

one more thing, because i'm feeling a sheepish need to explain my confusion.

> FWIW, my BIND 9.2.4 recursive name server clearly caches SOA records, ...

BIND 8.4.5, which is the last nameserver i personally worked on, does not.

---

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

> protocol violation (which this is not) makes it necessary to design-around

BIND is not the only dns server that returns SOA in authority section for 
NODATA. Verisign's server does the same too and ULTRADNS is doing same.

The point is that if in 99% of cases dns servers already return an answer 
that we're looking for, then trying to use that is certainly not stupid or
bad idea (as long as we know how to get the answer in the remaining cases).

> that's what RP RR's are for. 

How many RPs have you seen in the wild lately? Its practicly a dead RR...

> or did you not know that SOA was never cached?

I believe SOA responses are not cached only if its for non-existing domains.
Its possible that RFCs say that SOA lookups may or may not be cached, but
the same is true for all other DNS RR lookups too and I do believe that
direct queries for SOA are in fact cached.

But it is certainly true that you might expect special treatment for 
piece of data that is carrying caching information.

> s/will/won't/, sorry.  though i suppose it was clear in context.

No wonder I got surprised that it was so easy to get a yes answer ...

> protocol defined by the ietf.

The slow process of adding new features to dns (both protocol and to 
implementation) is why most in SPF community want to simulate wildcard 
with user-level queries on zonecut for default record. Same is why they 
chose to use TXT RR instead of new RR.

I believe the solution lies in the middle - we should proceed with both 
user-level queries and with process of adding new zonecut-default wildcard 
to DNS system. This way the currently proposed system of user-level queries
for zonecut records will become absolute and not used in the future any more.

The above is similtar to what was proposed by Ted Hardie at MARID meeting -
allow to use TXT temporarily (maybe 5 years) and get new RR and  provide 
ways to use both with in the future moving towards new RR and changing 
from SHOULD check both records to MUST check SPF RR first and then 
absoluting TXT 10 years down the road.

> will implement it.  i suspect that the process would be too long for SPF's

I maybe willing to wait and go through the process, but I certainly dont 
expect that majority of spf community would (i.e. considering that they 
did not even agree to use prefix for placement of data with primary argument
againt being that it was not always correct character in the dns user
interface that they get to use with the web hosting company). Good 
technical reasons and arguments and trying to follow proper standards 
process don't appear to always work the right way when dealing with spf ...

In any case for more practical question. Do youthink getting draft like 
this to experimental status be possible within say a year (not necessarily
just for spf reasons)?

> that's not a reason for a special prefix. 

There are several reasons for it that I discussed at SPF (current situation
requires special handling with complex redirects when somebody does need it
to be different; with introduction of EHLO checks and without scoping it 
has larger chance for confusion and incorrectly blocked email, etc). And
with prefix it has a chance to accomondate protocols other then just SPF.

> but as SOA is not cached, it is not something that should be queried for 
> other than as part of DNS operations such as serial number queries 
> governing IXFR/AXFR or UPDATE. 

I do not believe that there is any documents that specifically limits SOA
use in this way. But I'll investigate further if doing NS checks instead 
of SOA has any difference in the result, however if it turns out that 
doing SOA provides correct information all the time or faster then I'll 
advocate for that (and if I remember right your own code for finding 
zonecuts is in fact using SOA!) 

> since SPF does not yet do any zonecut checks, please remove that part of 
> the draft.

Not up to me, I've already asked for it to be removed or modified twice
at spf-discuss as I'm not willing to support it the way it is now because
it will lead to way too many queries to ISP mail servers and to much 
cofusion for dns administrators.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: John Levine <[email-masked]>
Date: 13 Jan 2005 02:48:53 -0000

>> work better, I'm all for dropping it.

I would surmise that none of your clients use djbdns as their DNS
software.  Its cache does correct negative caching, but it doesn't
return SOA records as additional or authority data.  You don't have to
like djbdns, but enough people use it that you can't wave it off.

The only halfway reliable ways to find zone cuts are either to build
your own resolver into your application and follow the chain of NS
records from the root, which seems a lot to ask an application to do,
or as an approximation walk up the DNS tree looking for SOA records.
If you're going to walk up the tree anyway, you might as well look for
the data you really want rather than SOAs and permit domain-wide data
at any DNS node.

Beyond the faux wildcard issue, there are some other DNS issues with
SPF that I'm wondering about.  The most serious is the blizzard of
requests that interpreting SPF records can require.  I realize that
CNAME has many of the same issues, but SPF introduces not just long
chains but bushy trees.  For a contrived example, check the SPF for
very.slow.sp.am, which takes about half an hour to resolve.  When I
pointed out this DOS opportunity to Meng, he "fixed" it by setting
arbitrary limits on the number of indirect references allowed when
interpreting an SPF record, thereby introducing a variety of ways to
make make working SPF mysteriously fail as domains down the tree add
an extra reference or two.  Based on other experience with DNS, is
there anything helpful one could say other than suggesting that they
take the bushiness out?

Another question is the big record problem.  Some SPF descriptions are
complicated enough that they won't fit in 512 bytes.  What's the best
thing to do?  Hotmail.com broke theirs up into four chunks named
spf-a.hotmail.com through spf-d.hotmail.com, with the main hotmail.com
SPF including the four.  The total amount of data is only about 1K so
a UDP transaction with the truncation bit followed by a TCP
transaction would probably be fewer packets than the five queries the
split version needs.  Other than reminding people that EDNS0 is
available for their large packet needs, any suggestions on artificial
subdivision vs. TCP?

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

---

From: wayne <[email-masked]>
Date: Thu, 13 Jan 2005 02:02:34 -0600

> like djbdns, but enough people use it that you can't wave it off.

It is likely that my code has not been tested on djbdns, but doing
digs by hand, I could not find any problems.  Pobox.com uses tinydns
and checking ns1.rightbox.com seems to return SOA records just fine.

Could you please give me some more details?

> requests that interpreting SPF records can require.

This is also a large concern of mine.  Have you read the current I-D?
In particular, the processing limits for the number of DNS requests?

>                          For a contrived example, check the SPF for
> very.slow.sp.am, which takes about half an hour to resolve.

Is this the same example as you gave here?

http://www.imc.org/ietf-mxcomp/mail-archive/msg02436.html

If so, my response is pretty much the same as last time:

http://www.imc.org/ietf-mxcomp/mail-archive/msg02438.html

Since then, I *have* been allowed to add a time to SPF checks and I
have also added process limits similar to the ones found in the
libspf2 SPF implementation that I mentioned in my reply.

I also brought up the subject of SPF and DDoS attacks in this message.
http://www.imc.org/ietf-mxcomp/mail-archive/msg02440.html
There is a URL to a another message in there which is munged.  It
should be:
http://archives.listbox.com/[email-masked]/200312/0393.html

>                                                              When I
> interpreting an SPF record,

I'm not sure when you pointed this out to Meng but the SPF specs have
had limits on the number of include: and redirect= references for a
year.

> [...]                       thereby introducing a variety of ways to
> an extra reference or two.

I'm not sure if anything can be done about that.  Either you have
limits, in which case you can run into those limits, or you don't have
limits, in which case you have DNS DoS and DDoS problems.

In practice, very few domains come even close to the process limits.
(I have done surveys of all SPF records in the .com, .net and .org
domains.  Results from the surveys were posted on the MARID list.)

>                             Based on other experience with DNS, is

You mean by removing the include: and redirect= mechanisms?  That
would be a huge incompatiblity, and wouldn't by itself solve the DoS
problems.

> available for their large packet needs, any suggestions on artificial

Hotmail has some of the largest SPF records that I know of, most SPF
records are fall smaller.  (Again, survey results were posted to
MARID.)  It is my understanding that MS has listed every IP address
that they own in their SPF records, instead of listing the ranges that
send email.  My initial reaction to hotmail's records is that they
should put a little effort into making their records smaller.

As far as DNS over TCP goes, there are a lot of (broken) firewalls out
there that have been configured to reject TCP port 53.  Any SPF
publisher that wishes to have their records available to everyone
needs to avoid falling back to TCP.

As far as the total amount of traffic caused by hotmail's 5 SPF
records vs one TCP DNS lookup, I'm not sure that TCP would be
cheaper.  You would generate one UDP lookup anyway, and then you have
the three-way TCP startup handshake and the four-way TCP teardown.

-wayne

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 13 Jan 2005 15:43:30 +0100

On Wed, Jan 12, 2005 at 10:08:36PM +0000,
 Paul Vixie <[email-masked]> wrote 
 a message of 94 lines which said:

> somebody around here told me recently that they had had to delete
> their SPF records because one or more SPF Clients had implemented
> SPF improperly, and were rejecting mailing list e-mail based on the
> mismatch between the header From: and the list exploder.

I know at least one program which is broken enough to do so, a Mozilla
Thunderbird extension:

http://www.extensionsmirror.nl/index.php?showtopic=1338

(Checking the RFC 2822 From: has nothing to do with SPF.)

But the adventure of your somebody proves nothing: after all, I had to
change my email configuration several times because people were
implementing stupid checks, too (see the thread "fixing insecure email
infrastructure" today on NANOG).

> all this proves is that no matter how careful a specification is
> authored, it still has to run the gauntlet of wide scale
> implementation.)

We all agree there are broken software and hasty implementors. But the
bug in the mentioned program is so huge, there is nothing the draft
authors could have done against it.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 13 Jan 2005 15:14:07 +0000

> authors could have done against it.

the lesson, though, is that if something should or should not be done, a
"good spec" will say exactly what that is, rather than just saying lots
of other things such that if you read it carefully you'll know everything
you need to know.  as an occasional spec author myself i have been rather
guilty of this offense.  rfc2136, for example, contains this little gem:

   1.2 - Glue RRs

   For the purpose of determining whether a domain name used in the
   UPDATE protocol is contained within a specified zone, a domain name
   is "in" a zone if it is owned by that zone's domain name.  See
   section 7.18 for details.

this predates the discussion of "in-ballywick" by almost a decade.  and to
me, "owned by" had a very specific and obvious meaning.  some others scratched
their heads, knew it was true and right, but didn't understand it at all.
(it means "at or below, even if it's in a subzone," in case you're curious.)

the caution this suggestions for SPF is that if this SOA-surfing idea goes
forward, something has GOT TO BE SAID about protecting TLD and root servers
from queries about these names.  (note that the SOA-surfing idea should not
go forward, in my view, i'm just saying, if it does in spite of my view.)

---

From: Edward Lewis <[email-masked]>
Date: Thu, 13 Jan 2005 10:43:24 -0500

Time for a periodic rant.

>authors could have done against it.

Why isn't such a situation brought to the attention of the IETF?

The IETF is supposed to design "good" protocols and to develop 
"clear" documents.  ("Good" manifested in achieving Proposed 
Standard, "clear" manifested in achieving Draft Standard.)

The way I look at it - there is a balance between documents 
(representing design) and code (representing implementation).

The documents represent strategy or design for solving a problem, 
considering all the angles (and "corner cases").  E.g., data model, 
management model, congestion management of the transport, IDN 
compatibility, etc.  The value of the IETF is that so many different 
kinds of expertise can be called on to review a solution.

Code represents the muscle of the Internet, the pragmatic view of the 
world.  It is how the network works.  Code deals with physical 
limits, I/O speed, data transmission speed; it deals with user 
nuances and legal issues too.

Code without design is a mess.  We know that.  Design without code is 
useless.  Evidently we need to do a better job preventing that.

If implementers (or interoperability testers) find a document to be 
inaccurate they should be encouraged to say so.  The IETF would be 
strengthened by such feedback.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: wayne <[email-masked]>
Date: Thu, 13 Jan 2005 09:47:38 -0600

In <[email-masked]> Paul Vixie <[email-masked]> writes:

> from queries about these names.

I have already said that I thought that putting an something in about
never querying domains with less than two labels is a good idea.  I
think it is a good idea whether the zone cut stuff remains or not.

-wayne

---

From: Peter Koch <[email-masked]>
Date: Thu, 13 Jan 2005 17:20:24 +0100

> think it is a good idea whether the zone cut stuff remains or not.

as has been pointed out, there is no magic about the *two* labels. There
are registries operating at SLD level, like the various co.XX ones
and, more importantly, the basic concept of inheriting the data from
one level up is not the DNS school of thought.

-Peter

PS: Someone might now remember the _whois._tcp.foo.bar.example thing, which
    also relies on tree walking. Since it works with and in DNS data, it's
    a different issue.

---

From: Alex Bligh <[email-masked]>
Date: Thu, 13 Jan 2005 16:34:48 +0000

> think it is a good idea whether the zone cut stuff remains or not.

(not that that protects ccTLDs)

I still don't understand *why* this has to be solved at the SPF client
end through recursion at all, rather than at the SPF publisher's end,
either by
i)   writing the records right in the first place, or
ii)  software/macros/text/documentation to help them do so, or
iii) modification of the server software (does not require an IETF
     protocol change) to run a different default (e.g. a config
     option for (say) $vendorware that says "incorporate an SPF record
     from the parent zone into a child, if I am running both and
     the parent zone has one but the child doesn't").

This puts the burden of the problem on the nameservers and systems
of those implementing SPF, not on "innocent bystanders" further up
the tree. It also ditches a whole pile of unnecessary network traffic.

You appear to be trying to engineer a protocol layer solution to user level
problems, and risk causing collateral damage (as well as some ugliness).
Applications (not protocols) are there to help users out with difficult
configuration problems. Sometimes the proposed cure for "difficult user
config" is worse than the disease. I am reminded of Microsoft Office
Assistant. [No jokes please long the lines of: "You appear to be
trying to write an Internet Draft - can I help you remove unnecessary
tree recursion?"]

Alex

---

From: Paul Vixie <[email-masked]>
Date: Thu, 13 Jan 2005 16:45:47 +0000

> think it is a good idea whether the zone cut stuff remains or not.

in the time since i first proposed the two-label rule, someone pointed out
CO.UK to me, where it's actually a three-label rule.  i don't think this
kind of rule can work.  i don't think that anything like this can work.  if
someone can force you to query for F(name) simply by mentioning a nonexistent
"name", where F() is a function returning the parent, grandparent, child,
brother, or indeed any name other than "name", then it's a new DDoS vector.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 13 Jan 2005 18:18:10 +0100

in the time since i first proposed the two-label rule, someone pointed out
    CO.UK to me, where it's actually a three-label rule.

And not only that. If example.org is not only a domainname but also
the name of the mx host for this tiny example organisation it should
be a one-label rule :-).  And then I thought about 1.3.e164.arpa...

But the basic lesson is that the number of labels don't tell you
anything about the structure og the name space.

	jaap

---

From: wayne <[email-masked]>
Date: Thu, 13 Jan 2005 12:13:27 -0600

In <[email-masked]> Peter Koch <[email-masked]> writes:

> as has been pointed out, there is no magic about the *two* labels.

I'm very much aware of that.

This is a safety-net, designed to catch situations that shouldn't
happen, rather than something that is intended to be used regularly.
To the best of my knowledge, it is the root and TLD name servers that
have to deal with most of the crap thrown at the DNS.  While some
applications may have good reasons to check for "com." or "uk.", I
can't see that for SPF and therefore the spec should not allow it.

Paul's suggestion is good and useful.  Paul's suggestion is not
perfect and doesn't guarentee that every DNS query that every SPF
client makes is valid.

-wayne

---

From: Dean Anderson <[email-masked]>
Date: Fri, 14 Jan 2005 04:04:32 -0500 (EST)

> Standard, "clear" manifested in achieving Draft Standard.)

How about "good" as in SOLVING PROBLEMS, not just making patent holders
money selling defective products?

I was told that the fact that discussing that SPF standarization is dead
(dead for good technical reasons) is off-topic.  In some sense, the debate
of that point is off-topic. That conclusion was made by another working
group and it is certainly off-topic to try to rehash that conclusion.

And supposing SPF _email_operation_ is offtopic, then about 50 of the last
75 messages are also off-topic. This group isn't here to solve SPF bugs,
but rather to determine if SPF has negative impact on DNS operation.

Certainly, this discussion is worthy of a dilbert cartoon...

Pretty obviously, there are several "on-topic" issues:

1) DNS cache impact
2) DNS server load issues
3) Is SPF a gratuitous change to DNS if SPF won't be standardized

There has been almost no discussion of the above.

What is off-topic to DNS is:

1) mail client bugs which reject email
2) implementation of mail clients
3) implemenation of mail servers.
4) mail protocol issues
5) whether the SPF Working group made a mistake

Here are some relevant facts that shouldn't be ignored:

	1) THE SPF WORKING GROUP CONCLUDED THAT SPF HAS INSURMOUNTABLE
TECHNICAL PROBLEMS
	2) THAT THE SPF WORKING GROUP HAS DISSOLVED AS A RESULT OF THESE 
TECHNICAL INSURMOUNTABLE PROBLEMS

These facts, particularly the last one, are of relevance to the DNSEXT
working group. It is not topical to debate the merits of the IETF-MXCOMP
(SPF) working group findings. However, they cannot be ignored.  It is not
the purpose of this group to consider the merits of SPF.  However, this
working group should respect the findings of other working groups.  The
conclusions of other working groups are relevant to this groups' work.

That being the case, there is little point in considering its impact on
DNS, as its not part of the IETF protocol suite.

We know by the continued zeal of SPF proponents in spite of the
dissolution of the SPF working group, that these SPF zealots will have no
interest in any negative DNS effects, anyway.  Any inconvenient findings
will be ignored.

With that in mind, I'm interested to know what the "hoped-for" outcome of 
this discussion is going to be?  What's the best that could happen?

Is it just that proponents of SPF hope to reverse their failure in the SPF
working group and get this working group to standardize their proposals
(without analyzing them in detail)?

		--Dean

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 14 Jan 2005 11:29:35 +0100

On 13 Jan 2005 02:48:53 -0000

>  available for their large packet needs, any suggestions on artificial

The main argument against TCP is not a traffic argument (although if
one is volume charged it could be a consideration) but the amount of
state the OS the nameserver runs on needs to maintain.

-- Olaf

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Jan 2005 18:01:41 +0700

Date:        Tue, 11 Jan 2005 22:52:56 +0100
    From:        Stephane Bortzmeyer <[email-masked]>
    Message-ID:  <[email-masked]>

  | Hence the proposal to use the "zone cut" algorithm (RFC 2181) for the
  | lookup,

Huh?

I wrote 2181 - there is no "zone cut algorithm" in it.

It does describe what a zone cut is, and gives some properties,
but most certainly doesn't pretend there is some piece of magic
by which clients can discover where a cut exists.

Dynamic updates do something like that, but only from inside the
zone.

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Jan 2005 18:39:04 +0700

Date:        Tue, 11 Jan 2005 22:11:30 -0800 (PST)
    From:        "william(at)elan.net" <[email-masked]>
    Message-ID:  <[email-masked]>

  | If there is no authority 
  | section for negative response, then client can directly query for SOA.

That's impossible.   You cannot find a zone but by making an
SOA query, that would beg the question - that is, you have to
know what name to query, that's the name at the zone cut, which
is what you were seeking in the first place.

kre

---

From: Paul Vixie <[email-masked]>
Date: Fri, 14 Jan 2005 16:21:19 +0000

> is what you were seeking in the first place.

robert, i've directed the authors of this draft at the bind8 sources for
"res_findzonecut()" several times; if they wanted to know why finding a
zone cut is hard, they could.  the fact that they continue to assert that
it's easy, should tell you that they already know what to believe, and
will not be listening to contrary input.

here, for the ".tar.gz" challenged, is the code in question, which i wrote.
in my considered opinion, any application who wants to know where a zone
cut is has to do AT LEAST AS MUCH WORK as what's described as follows:

---

#if !defined(lint) && !defined(SABER)
static const char rcsid[] = "$Id: res_findzonecut.c,v 8.23 2004/09/16 07:09:33 marka Exp $";
#endif /* not lint */

/*
 * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
 * Copyright (c) 1999 by Internet Software Consortium.
 *
 * Permission to use, copy, modify, and distribute this software for any
 * purpose with or without fee is hereby granted, provided that the above
 * copyright notice and this permission notice appear in all copies.
 *
 * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES
 * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR
 * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
 * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
 * OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 */

/* Import. */

#include "port_before.h"

#include <sys/param.h>
#include <sys/socket.h>
#include <sys/time.h>

#include <netinet/in.h>
#include <arpa/inet.h>
#include <arpa/nameser.h>

#include <errno.h>
#include <limits.h>
#include <netdb.h>
#include <stdarg.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <isc/list.h>

#include "port_after.h"

#include <resolv.h>

/* Data structures. */

typedef struct rr_a {
	LINK(struct rr_a)	link;
	union res_sockaddr_union addr;
} rr_a;
typedef LIST(rr_a) rrset_a;

typedef struct rr_ns {
	LINK(struct rr_ns)	link;
	const char *		name;
	unsigned int		flags;
	rrset_a			addrs;
} rr_ns;
typedef LIST(rr_ns) rrset_ns;

#define	RR_NS_HAVE_V4		0x01
#define	RR_NS_HAVE_V6		0x02

/* Forward. */

static int	satisfy(res_state, const char *, rrset_ns *,
			union res_sockaddr_union *, int);
static int	add_addrs(res_state, rr_ns *,
			  union res_sockaddr_union *, int);
static int	get_soa(res_state, const char *, ns_class, int,
			char *, size_t, char *, size_t,
			rrset_ns *);
static int	get_ns(res_state, const char *, ns_class, int, rrset_ns *);
static int	get_glue(res_state, ns_class, int, rrset_ns *);
static int	save_ns(res_state, ns_msg *, ns_sect,
			const char *, ns_class, int, rrset_ns *);
static int	save_a(res_state, ns_msg *, ns_sect,
		       const char *, ns_class, int, rr_ns *);
static void	free_nsrrset(rrset_ns *);
static void	free_nsrr(rrset_ns *, rr_ns *);
static rr_ns *	find_ns(rrset_ns *, const char *);
static int	do_query(res_state, const char *, ns_class, ns_type,
			 u_char *, ns_msg *);
static void	res_dprintf(const char *, ...) ISC_FORMAT_PRINTF(1, 2);

/* Macros. */

#define DPRINTF(x) do {\
		int save_errno = errno; \
		if ((statp->options & RES_DEBUG) != 0U) res_dprintf x; \
		errno = save_errno; \
	} while (0)

/* Public. */

/*
 * int
 * res_findzonecut(res, dname, class, zname, zsize, addrs, naddrs)
 *	find enclosing zone for a <dname,class>, and some server addresses
 * parameters:
 *	res - resolver context to work within (is modified)
 *	dname - domain name whose enclosing zone is desired
 *	class - class of dname (and its enclosing zone)
 *	zname - found zone name
 *	zsize - allocated size of zname
 *	addrs - found server addresses
 *	naddrs - max number of addrs
 * return values:
 *	< 0 - an error occurred (check errno)
 *	= 0 - zname is now valid, but addrs[] wasn't changed
 *	> 0 - zname is now valid, and return value is number of addrs[] found
 * notes:
 *	this function calls res_nsend() which means it depends on correctly
 *	functioning recursive nameservers (usually defined in /etc/resolv.conf
 *	or its local equivilent).
 *
 *	we start by asking for an SOA<dname,class>.  if we get one as an
 *	answer, that just means <dname,class> is a zone top, which is fine.
 *	more than likely we'll be told to go pound sand, in the form of a
 *	negative answer.
 *
 *	note that we are not prepared to deal with referrals since that would
 *	only come from authority servers and our correctly functioning local
 *	recursive server would have followed the referral and got us something
 *	more definite.
 *
 *	if the authority section contains an SOA, this SOA should also be the
 *	closest enclosing zone, since any intermediary zone cuts would've been
 *	returned as referrals and dealt with by our correctly functioning local
 *	recursive name server.  but an SOA in the authority section should NOT
 *	match our dname (since that would have been returned in the answer
 *	section).  an authority section SOA has to be "above" our dname.
 *
 *	however, since authority section SOA's were once optional, it's
 *	possible that we'll have to go hunting for the enclosing SOA by
 *	ripping labels off the front of our dname -- this is known as "doing
 *	it the hard way."
 *
 *	ultimately we want some server addresses, which are ideally the ones
 *	pertaining to the SOA.MNAME, but only if there is a matching NS RR.
 *	so the second phase (after we find an SOA) is to go looking for the
 *	NS RRset for that SOA's zone.
 *
 *	no answer section processed by this code is allowed to contain CNAME
 *	or DNAME RR's.  for the SOA query this means we strip a label and
 *	keep going.  for the NS and A queries this means we just give up.
 */

int
res_findzonecut(res_state statp, const char *dname, ns_class class, int opts,
		char *zname, size_t zsize, struct in_addr *addrs, int naddrs)
{
	int result, i;
	union res_sockaddr_union *u;

	opts |= RES_IPV4ONLY;
	opts &= ~RES_IPV6ONLY;

	u = calloc(naddrs, sizeof(*u));
	if (u == NULL)
		return(-1);

	result = res_findzonecut2(statp, dname, class, opts, zname, zsize,
				  u, naddrs);

	for (i = 0; i < result; i++) {
		addrs[i] = u[i].sin.sin_addr;
	}
	free(u);
	return (result);
}

int
res_findzonecut2(res_state statp, const char *dname, ns_class class, int opts,
		 char *zname, size_t zsize, union res_sockaddr_union *addrs,
		 int naddrs)
{
	char mname[NS_MAXDNAME];
	u_long save_pfcode;
	rrset_ns nsrrs;
	int n;

	DPRINTF(("START dname='%s' class=%s, zsize=%ld, naddrs=%d",
		 dname, p_class(class), (long)zsize, naddrs));
	save_pfcode = statp->pfcode;
	statp->pfcode |= RES_PRF_HEAD2 | RES_PRF_HEAD1 | RES_PRF_HEADX |
			 RES_PRF_QUES | RES_PRF_ANS |
			 RES_PRF_AUTH | RES_PRF_ADD;
	INIT_LIST(nsrrs);

	DPRINTF(("get the soa, and see if it has enough glue"));
	if ((n = get_soa(statp, dname, class, opts, zname, zsize,
			 mname, sizeof mname, &nsrrs)) < 0 ||
	    ((opts & RES_EXHAUSTIVE) == 0 &&
	     (n = satisfy(statp, mname, &nsrrs, addrs, naddrs)) > 0))
		goto done;

	DPRINTF(("get the ns rrset and see if it has enough glue"));
	if ((n = get_ns(statp, zname, class, opts, &nsrrs)) < 0 ||
	    ((opts & RES_EXHAUSTIVE) == 0 &&
	     (n = satisfy(statp, mname, &nsrrs, addrs, naddrs)) > 0))
		goto done;

	DPRINTF(("get the missing glue and see if it's finally enough"));
	if ((n = get_glue(statp, class, opts, &nsrrs)) >= 0)
		n = satisfy(statp, mname, &nsrrs, addrs, naddrs);

 done:
	DPRINTF(("FINISH n=%d (%s)", n, (n < 0) ? strerror(errno) : "OK"));
	free_nsrrset(&nsrrs);
	statp->pfcode = save_pfcode;
	return (n);
}

/* Private. */

static int
satisfy(res_state statp, const char *mname, rrset_ns *nsrrsp,
	union res_sockaddr_union *addrs, int naddrs)
{
	rr_ns *nsrr;
	int n, x;

	n = 0;
	nsrr = find_ns(nsrrsp, mname);
	if (nsrr != NULL) {
		x = add_addrs(statp, nsrr, addrs, naddrs);
		addrs += x;
		naddrs -= x;
		n += x;
	}
	for (nsrr = HEAD(*nsrrsp);
	     nsrr != NULL && naddrs > 0;
	     nsrr = NEXT(nsrr, link))
		if (ns_samename(nsrr->name, mname) != 1) {
			x = add_addrs(statp, nsrr, addrs, naddrs);
			addrs += x;
			naddrs -= x;
			n += x;
		}
	DPRINTF(("satisfy(%s): %d", mname, n));
	return (n);
}

static int
add_addrs(res_state statp, rr_ns *nsrr,
	  union res_sockaddr_union *addrs, int naddrs)
{
	rr_a *arr;
	int n = 0;

	for (arr = HEAD(nsrr->addrs); arr != NULL; arr = NEXT(arr, link)) {
		if (naddrs <= 0)
			return (0);
		*addrs++ = arr->addr;
		naddrs--;
		n++;
	}
	DPRINTF(("add_addrs: %d", n));
	return (n);
}

static int
get_soa(res_state statp, const char *dname, ns_class class, int opts,
	char *zname, size_t zsize, char *mname, size_t msize,
	rrset_ns *nsrrsp)
{
	char tname[NS_MAXDNAME];
	u_char *resp = NULL;
	int n, i, ancount, nscount;
	ns_sect sect;
	ns_msg msg;
	u_int rcode;

	/*
	 * Find closest enclosing SOA, even if it's for the root zone.
	 */

	/* First canonicalize dname (exactly one unescaped trailing "."). */
	if (ns_makecanon(dname, tname, sizeof tname) < 0)
		goto cleanup;
	dname = tname;

	resp = malloc(NS_MAXMSG);
	if (resp == NULL)
		goto cleanup;

	/* Now grovel the subdomains, hunting for an SOA answer or auth. */
	for (;;) {
		/* Leading or inter-label '.' are skipped here. */
		while (*dname == '.')
			dname++;

		/* Is there an SOA? */
		n = do_query(statp, dname, class, ns_t_soa, resp, &msg);
		if (n < 0) {
			DPRINTF(("get_soa: do_query('%s', %s) failed (%d)",
				 dname, p_class(class), n));
			goto cleanup;
		}
		if (n > 0) {
			DPRINTF(("get_soa: CNAME or DNAME found"));
			sect = ns_s_max, n = 0;
		} else {
			rcode = ns_msg_getflag(msg, ns_f_rcode);
			ancount = ns_msg_count(msg, ns_s_an);
			nscount = ns_msg_count(msg, ns_s_ns);
			if (ancount > 0 && rcode == ns_r_noerror)
				sect = ns_s_an, n = ancount;
			else if (nscount > 0)
				sect = ns_s_ns, n = nscount;
			else
				sect = ns_s_max, n = 0;
		}
		for (i = 0; i < n; i++) {
			const char *t;
			const u_char *rdata;
			int rdlen;
			ns_rr rr;

			if (ns_parserr(&msg, sect, i, &rr) < 0) {
				DPRINTF(("get_soa: ns_parserr(%s, %d) failed",
					 p_section(sect, ns_o_query), i));
				goto cleanup;
			}
			if (ns_rr_type(rr) == ns_t_cname ||
			    ns_rr_type(rr) == ns_t_dname)
				break;
			if (ns_rr_type(rr) != ns_t_soa ||
			    ns_rr_class(rr) != class)
				continue;
			t = ns_rr_name(rr);
			switch (sect) {
			case ns_s_an:
				if (ns_samedomain(dname, t) == 0) {
					DPRINTF(
				    ("get_soa: ns_samedomain('%s', '%s') == 0",
						dname, t)
						);
					errno = EPROTOTYPE;
					goto cleanup;
				}
				break;
			case ns_s_ns:
				if (ns_samename(dname, t) == 1 ||
				    ns_samedomain(dname, t) == 0) {
					DPRINTF(
		       ("get_soa: ns_samename() || !ns_samedomain('%s', '%s')",
						dname, t)
						);
					errno = EPROTOTYPE;
					goto cleanup;
				}
				break;
			default:
				abort();
			}
			if (strlen(t) + 1 > zsize) {
				DPRINTF(("get_soa: zname(%lu) too small (%lu)",
					 (unsigned long)zsize,
					 (unsigned long)strlen(t) + 1));
				errno = EMSGSIZE;
				goto cleanup;
			}
			strcpy(zname, t);
			rdata = ns_rr_rdata(rr);
			rdlen = ns_rr_rdlen(rr);
			if (ns_name_uncompress(resp, ns_msg_end(msg), rdata,
					       mname, msize) < 0) {
				DPRINTF(("get_soa: ns_name_uncompress failed")
					);
				goto cleanup;
			}
			if (save_ns(statp, &msg, ns_s_ns,
				    zname, class, opts, nsrrsp) < 0) {
				DPRINTF(("get_soa: save_ns failed"));
				goto cleanup;
			}
			free(resp);
			return (0);
		}

		/* If we're out of labels, then not even "." has an SOA! */
		if (*dname == '\0')
			break;

		/* Find label-terminating "."; top of loop will skip it. */
		while (*dname != '.') {
			if (*dname == '\\')
				if (*++dname == '\0') {
					errno = EMSGSIZE;
					goto cleanup;
				}
			dname++;
		}
	}
	DPRINTF(("get_soa: out of labels"));
	errno = EDESTADDRREQ;
 cleanup:
	if (resp != NULL)
		free(resp);
	return (-1);
}

static int
get_ns(res_state statp, const char *zname, ns_class class, int opts,
      rrset_ns *nsrrsp)
{
	u_char *resp;
	ns_msg msg;
	int n;

	resp = malloc(NS_MAXMSG);
	if (resp == NULL)
		return (-1);

	/* Go and get the NS RRs for this zone. */
	n = do_query(statp, zname, class, ns_t_ns, resp, &msg);
	if (n != 0) {
		DPRINTF(("get_ns: do_query('%s', %s) failed (%d)",
			 zname, p_class(class), n));
		free(resp);
		return (-1);
	}

	/* Remember the NS RRs and associated A RRs that came back. */
	if (save_ns(statp, &msg, ns_s_an, zname, class, opts, nsrrsp) < 0) {
		DPRINTF(("get_ns save_ns('%s', %s) failed",
			 zname, p_class(class)));
		free(resp);
		return (-1);
	}

	free(resp);
	return (0);
}

static int
get_glue(res_state statp, ns_class class, int opts, rrset_ns *nsrrsp) {
	rr_ns *nsrr, *nsrr_n;
	u_char *resp;

	resp = malloc(NS_MAXMSG);
	if (resp == NULL)
		return(-1);

	/* Go and get the A RRs for each empty NS RR on our list. */
	for (nsrr = HEAD(*nsrrsp); nsrr != NULL; nsrr = nsrr_n) {
		ns_msg msg;
		int n;

		nsrr_n = NEXT(nsrr, link);

		if ((nsrr->flags & RR_NS_HAVE_V4) == 0) {
			n = do_query(statp, nsrr->name, class, ns_t_a,
				     resp, &msg);
			if (n < 0) {
				DPRINTF(
				       ("get_glue: do_query('%s', %s') failed",
					nsrr->name, p_class(class)));
				goto cleanup;
			}
			if (n > 0) {
				DPRINTF((
			"get_glue: do_query('%s', %s') CNAME or DNAME found",
					 nsrr->name, p_class(class)));
			}
			if (save_a(statp, &msg, ns_s_an, nsrr->name, class,
				   opts, nsrr) < 0) {
				DPRINTF(("get_glue: save_r('%s', %s) failed",
					 nsrr->name, p_class(class)));
				goto cleanup;
			}
		}

		if ((nsrr->flags & RR_NS_HAVE_V6) == 0) {
			n = do_query(statp, nsrr->name, class, ns_t_aaaa,
				     resp, &msg);
			if (n < 0) {
				DPRINTF(
				       ("get_glue: do_query('%s', %s') failed",
					nsrr->name, p_class(class)));
				goto cleanup;
			}
			if (n > 0) {
				DPRINTF((
			"get_glue: do_query('%s', %s') CNAME or DNAME found",
					 nsrr->name, p_class(class)));
			}
			if (save_a(statp, &msg, ns_s_an, nsrr->name, class,
				   opts, nsrr) < 0) {
				DPRINTF(("get_glue: save_r('%s', %s) failed",
					 nsrr->name, p_class(class)));
				goto cleanup;
			}
		}

		/* If it's still empty, it's just chaff. */
		if (EMPTY(nsrr->addrs)) {
			DPRINTF(("get_glue: removing empty '%s' NS",
				 nsrr->name));
			free_nsrr(nsrrsp, nsrr);
		}
	}
	free(resp);
	return (0);

 cleanup:
	free(resp);
	return (-1);
}

static int
save_ns(res_state statp, ns_msg *msg, ns_sect sect,
	const char *owner, ns_class class, int opts,
	rrset_ns *nsrrsp)
{
	int i;

	for (i = 0; i < ns_msg_count(*msg, sect); i++) {
		char tname[MAXDNAME];
		const u_char *rdata;
		rr_ns *nsrr;
		ns_rr rr;
		int rdlen;

		if (ns_parserr(msg, sect, i, &rr) < 0) {
			DPRINTF(("save_ns: ns_parserr(%s, %d) failed",
				 p_section(sect, ns_o_query), i));
			return (-1);
		}
		if (ns_rr_type(rr) != ns_t_ns ||
		    ns_rr_class(rr) != class ||
		    ns_samename(ns_rr_name(rr), owner) != 1)
			continue;
		nsrr = find_ns(nsrrsp, ns_rr_name(rr));
		if (nsrr == NULL) {
			nsrr = malloc(sizeof *nsrr);
			if (nsrr == NULL) {
				DPRINTF(("save_ns: malloc failed"));
				return (-1);
			}
			rdata = ns_rr_rdata(rr);
			rdlen = ns_rr_rdlen(rr);
			if (ns_name_uncompress(ns_msg_base(*msg),
					       ns_msg_end(*msg), rdata,
					       tname, sizeof tname) < 0) {
				DPRINTF(("save_ns: ns_name_uncompress failed")
					);
				free(nsrr);
				return (-1);
			}
			nsrr->name = strdup(tname);
			if (nsrr->name == NULL) {
				DPRINTF(("save_ns: strdup failed"));
				free(nsrr);
				return (-1);
			}
			INIT_LINK(nsrr, link);
			INIT_LIST(nsrr->addrs);
			nsrr->flags = 0;
			APPEND(*nsrrsp, nsrr, link);
		}
		if (save_a(statp, msg, ns_s_ar,
			   nsrr->name, class, opts, nsrr) < 0) {
			DPRINTF(("save_ns: save_r('%s', %s) failed",
				 nsrr->name, p_class(class)));
			return (-1);
		}
	}
	return (0);
}

static int
save_a(res_state statp, ns_msg *msg, ns_sect sect,
       const char *owner, ns_class class, int opts,
       rr_ns *nsrr)
{
	int i;

	for (i = 0; i < ns_msg_count(*msg, sect); i++) {
		ns_rr rr;
		rr_a *arr;

		if (ns_parserr(msg, sect, i, &rr) < 0) {
			DPRINTF(("save_a: ns_parserr(%s, %d) failed",
				 p_section(sect, ns_o_query), i));
			return (-1);
		}
		if ((ns_rr_type(rr) != ns_t_a &&
		     ns_rr_type(rr) != ns_t_aaaa) ||
		    ns_rr_class(rr) != class ||
		    ns_samename(ns_rr_name(rr), owner) != 1 ||
		    ns_rr_rdlen(rr) != NS_INADDRSZ)
			continue;
		if ((opts & RES_IPV6ONLY) != 0 && ns_rr_type(rr) != ns_t_aaaa)
			continue;
		if ((opts & RES_IPV4ONLY) != 0 && ns_rr_type(rr) != ns_t_a)
			continue;
		arr = malloc(sizeof *arr);
		if (arr == NULL) {
			DPRINTF(("save_a: malloc failed"));
			return (-1);
		}
		INIT_LINK(arr, link);
		memset(&arr->addr, 0, sizeof(arr->addr));
		switch (ns_rr_type(rr)) {
		case ns_t_a:
			arr->addr.sin.sin_family = AF_INET;
#ifdef HAVE_SA_LEN
			arr->addr.sin.sin_len = sizeof(arr->addr.sin);
#endif
			memcpy(&arr->addr.sin.sin_addr, ns_rr_rdata(rr),
			       NS_INADDRSZ);
			arr->addr.sin.sin_port = htons(NAMESERVER_PORT);
			nsrr->flags |= RR_NS_HAVE_V4;
			break;
		case ns_t_aaaa:
			arr->addr.sin6.sin6_family = AF_INET6;
#ifdef HAVE_SA_LEN
			arr->addr.sin6.sin6_len = sizeof(arr->addr.sin6);
#endif
			memcpy(&arr->addr.sin6.sin6_addr, ns_rr_rdata(rr), 16);
			arr->addr.sin.sin_port = htons(NAMESERVER_PORT);
			nsrr->flags |= RR_NS_HAVE_V6;
			break;
		default:
			abort();
		}
		APPEND(nsrr->addrs, arr, link);
	}
	return (0);
}

static void
free_nsrrset(rrset_ns *nsrrsp) {
	rr_ns *nsrr;

	while ((nsrr = HEAD(*nsrrsp)) != NULL)
		free_nsrr(nsrrsp, nsrr);
}

static void
free_nsrr(rrset_ns *nsrrsp, rr_ns *nsrr) {
	rr_a *arr;
	char *tmp;

	while ((arr = HEAD(nsrr->addrs)) != NULL) {
		UNLINK(nsrr->addrs, arr, link);
		free(arr);
	}
	DE_CONST(nsrr->name, tmp);
	free(tmp);
	UNLINK(*nsrrsp, nsrr, link);
	free(nsrr);
}

static rr_ns *
find_ns(rrset_ns *nsrrsp, const char *dname) {
	rr_ns *nsrr;

	for (nsrr = HEAD(*nsrrsp); nsrr != NULL; nsrr = NEXT(nsrr, link))
		if (ns_samename(nsrr->name, dname) == 1)
			return (nsrr);
	return (NULL);
}

static int
do_query(res_state statp, const char *dname, ns_class class, ns_type qtype,
	 u_char *resp, ns_msg *msg)
{
	u_char req[NS_PACKETSZ];
	int i, n;

	n = res_nmkquery(statp, ns_o_query, dname, class, qtype,
			 NULL, 0, NULL, req, NS_PACKETSZ);
	if (n < 0) {
		DPRINTF(("do_query: res_nmkquery failed"));
		return (-1);
	}
	n = res_nsend(statp, req, n, resp, NS_MAXMSG);
	if (n < 0) {
		DPRINTF(("do_query: res_nsend failed"));
		return (-1);
	}
	if (n == 0) {
		DPRINTF(("do_query: res_nsend returned 0"));
		errno = EMSGSIZE;
		return (-1);
	}
	if (ns_initparse(resp, n, msg) < 0) {
		DPRINTF(("do_query: ns_initparse failed"));
		return (-1);
	}
	n = 0;
	for (i = 0; i < ns_msg_count(*msg, ns_s_an); i++) {
		ns_rr rr;

		if (ns_parserr(msg, ns_s_an, i, &rr) < 0) {
			DPRINTF(("do_query: ns_parserr failed"));
			return (-1);
		}
		n += (ns_rr_class(rr) == class &&
		      (ns_rr_type(rr) == ns_t_cname ||
		       ns_rr_type(rr) == ns_t_dname));
	}
	return (n);
}

static void
res_dprintf(const char *fmt, ...) {
	va_list ap;

	va_start(ap, fmt);
	fputs(";; res_findzonecut: ", stderr);
	vfprintf(stderr, fmt, ap);
	fputc('\n', stderr);
	va_end(ap);
}

---

---

From: "D. J. Bernstein" <[email-masked]>
Date: 14 Jan 2005 18:18:06 -0000

Let's assume, for the sake of argument, that

   (1) we want the information communicated by the deployed SPF
       protocol---does the administrator of X want IP address Y to be
       able to send mail with return addresses @X?---but

   (2) we've decided that we'll have to change how this information is
       retrieved through DNS---leaving the current software alone would
       be nice but the protocol design is simply too painful.

How, then, should the administrator of X use DNS to publish information
about various IP addresses Y? How can we handle the problems of large
packets, subdomains, etc.? I'd like to see this how-to-use-DNS question
discussed separately from questioning assumption #1 (and #2).

Most of the problems of the current protocol design appear to be caused
by crunching information about all the Y's into a single DNS record for
X. The client is actually interested in a particular Y, and can simply
ask about, say, Ztruncto63.reverse(Y).spfidentifier.X for return address
Z@X. The hotmail administrator, for example, would have records such as

   *.spf63784604719468285133.hotmail.com. TXT "n"
   *.137.2.199.spf63784604719468285133.hotmail.com. TXT "y"
   ...

rather than the current multiple-level spf-*.hotmail.com structure. The
63784604719468285133 tag serves the same function as an underscore and a
new record type, without the interoperability problems of an underscore
and without the interoperability problems of a new record type.

This initial spreading of queries appears to remove the need for other
forms of indirection, so clients become much simpler and the efficiency
problems of the current SPF protocol go away.

Comments?

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

---

From: wayne <[email-masked]>
Date: Fri, 14 Jan 2005 13:33:11 -0600

> will not be listening to contrary input.

Paul, I only know of *once* that you have directed me to the
res_findzonecut() function, and that was in:
http://article.gmane.org/gmane.ietf.dnsext/6438

> cut is has to do AT LEAST AS MUCH WORK as what's described as follows:

I am not ".tar.gz" challenged.  As I said in the post referenced
above:

| Actually, res_findzonecut() is what I've based my code on.  See this
| post I made to spf-discuss almost a year ago:
| 
| http://archives.listbox.com/[email-masked]/200403/0026.html

So, I was quite capable of finding that function, I did it a long time
ago, I've studied it and while it may have been hard for you to
create, life is much easier for those of us who have followed.
Especially since you have kindly used a very liberal copyright.

Yes, that code can cause a lot of DNS lookups in the worst case, but
it seems ok to me in the typical case.

Please, we are trying to solve problems here.  Your exaggerations and
not even reading my replies to you isn't helping.  Going around saying "I
told them so!", when, really, you didn't is kind of tacky.

The real-world problem that we are trying to solve is:

    Domain owners want to have a voice in how the domain name that
    they have bought gets used.  Others would like to hear what the
    domain owners have to say. The particular case we are dealing with
    is email in conjunction with SPF, but there are other cases too.

DNS seems to be a good way of communicating, considering that the
communication is about their domain.  Unfortunately, DNS wildcards
(currently) don't allow the domain owner to cover all of their domain.

Using zone cuts to simulate a different kind of DNS wildcarding is not
pretty and is not as cheap as it could be, but is the best solution I
know of that exists today.

Even last fall, when I started working on this particular SPF-classic
draft, I said that I would be flexible on how this stuff worked.  I am
looking for a solution to a problem.  Help would be appreciated.

thanks

-wayne

---

From: wayne <[email-masked]>
Date: Fri, 14 Jan 2005 13:54:24 -0600

In <[email-masked]> "D. J. Bernstein" <[email-masked]> writes:

> Let's assume, for the sake of argument, that [snip]
>

Hi Dan.

Yes, the "how to use DNS?" question has been asked in relation to this
subject many times.  I found the discussion quite interesting, but I'm
not sure that it would be a good idea to rehash it here.  The answer
is one in which I believe that reasonable people can disagree on.
There are a lot of trade-offs involved and depending on how you
consider the various costs, you can end up with very different
answers.

A good overview of this subject was written up by the IRTF's ASRG WG.
See:
http://asrg.kavi.com/apps/group_public/download.php/31/draft-irtf-asrg-lmap-discussion-00.txt

In particular, look at section 4.

>    *.spf63784604719468285133.hotmail.com. TXT "n"

Minor nit, but unless I'm very much mistaken, you also need:

     *.199.spf63784604719468285133.hotmail.com. TXT "n"
     *.2.199.spf63784604719468285133.hotmail.com. TXT "n"

>    *.137.2.199.spf63784604719468285133.hotmail.com. TXT "y"

This arrangement has a lower cost when you only want to find the
answer once, but has a higher cost if you get a lot of email claiming
to be from hotmail.com.  Spoofed email claiming to be from hotmail.com
gets sent by hundreds of thousands of zombied boxes.

If you like this form, however, you can do it right now with SPF via:

hotmail.com.  TXT  "v=spf1 exists:%{ir}.spf63784604719468285133.%{d} -all"
*.137.2.199.spf63784604719468285133.hotmail.com. A 127.0.0.2

-wayne

---

From: Florian Weimer <[email-masked]>
Date: Fri, 14 Jan 2005 22:46:53 +0100

> problems of the current SPF protocol go away.

I think the indirection/macro expansion capability is actually needed
in practice.  For example, T-Online might want to use DARTmail's bulk
mailing capabilities, and want them to use a @t-online.de addresses
(in order to avoid customer confusion).  With SPF, DARTmail publishes
an SPF record, which T-Online includes (by reference) in its SPF
record for t-online.de.  The effect is that DARTmail can send mail
under the t-online.de domain, and T-Online doesn't have to maintain a
list of DARTmail's mail relays.

I don't think this property is preserved in your proposal.  T-Online
would have to generate responses dynamically, or keep a list of IP
addresses DARTmail's server.

(This message should not be read an endorsement of SPF or similar
technologies.)

---

From: John Levine <[email-masked]>
Date: 15 Jan 2005 04:40:05 -0000

>(in order to avoid customer confusion).

My ex-client Orbitz uses Dartmail to send its newsletter, although
they send their other mail themselves. The newsletter comes from
@email.orbitz.com rather than @orbitz.com.  They delegate
email.orbitz.com to Dartmail which publishes SPF data for it.  Check
it out.

The problem that indirection is intended to solve is the little domain
that sends through its ISP's mail servers and wants to say "my SPF is
the same as bigisp.net."  One could argue that's not the recipient's
problem to figure out.

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