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

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.

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

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?

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

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.

--
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: Paul Vixie <[email-masked]>
Date: Thu, 13 Jan 2005 15:14:07 +0000

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

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