Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE

From: Hector Santos <[email-masked]>
Date: Wed, 01 May 2013 06:14:44 -0400

The problem I have is not so much with the decision to deprecate SPF 
rrtype, it will remove this particular SPF protocol dual SPF/TXT call 
overhead in the network, but more so about what it says for future 
applications.

There will no incentive to design DNS applications with specific types, 
or it will always be a specific sub-domain TXT record.  Is that good or bad?

In many ways, the industry has gotten "comfortable" with overall 
non-compiled, non-binary, text-based applications. Improvements in 
hardware and software has made it all feasible.

Consider that once upon a time Microsoft's Caller-ID Policy (now 
SenderID) considered XML-formatted TXT record before merging with SPF. [1]

Consider that a SMTP receiver is now faced with new overheads and 
redundancy with at least 4-8 DNS Calls, and except for one, they are all 
TXT:

o RFC5321 SMTP level (before DATA state)

   - Growth in PTR requirement (rDNS) for connecting SMTP client,
   - SPF HELO/EHLO domain check (optional) (RFC4408),
   - SPF MAIL FROM domain check (RFC4408)
     - SPF MAIL FROM SUBMITTER domain check (RFC4405)

o RFC5321 SMTP level (DATA) or RFC5322 Post Acceptance processing:

   - DKIM Trust Domain public key check (RFC6376)
      - ADSP Author Domain Policy check (RFC5617)
      - VBR Trust Domain Check (RFC5518)
   - SenderID PRA domain check (RFC4406/4407)
   - Possible future new fast track DMARC proposal [2]

And they all have one common application need; get domain 
attributes/information.

Lets consider that these new TXT applications are authored by the same 
few folks with the same engineering mindset to use TXT since it is the 
most practical and offers the fastest entry point to the market and 
proof of concept.

There are many integration issues to consider.  We should look at a 
better solution where minimal calls can be made to extract domain 
operational information. I have a few ideas in this area and have even 
drafted yet another TXT-based solution.  What the above redundant domain 
information lookup did do was force us to redesign, update and single 
source our DNS resolutions across all components in our 
application/service servers.  That is because many of the above open 
source protocols come with libraries with their own DNS resolvers 
clients software. So we wrote our own and implemented each of the above 
protocols to use a single DNS API.  This allowed us to offer a local DNS 
cache to remove all overhead in the redundancy.  This also remove most 
of any doubt with customer's uplink DNS resolvers which can be behaving 
differently - a big savings in support cost.

I would like to have the option to support the SPF rrtype when and if we 
implement RFC4408BIS as deployment options to customers.  There are 
already new changes to the spec that will promote implementation changes 
(Accepting SPF Failed Message deployment option and a new 
Authentication-Result: trace header).

I believe the decision to pull SFP rrtype at this time (for RFC4408BIS) 
was premature and would like to see the design opportunity to support 
not only SPF rrtype but others.  I suggest to keep the migration path in 
RFC4408BIS with new implementation details.

I would also like to believe that the IETF can help get the DNS 
infrastructure updated to help support these modern DNS application 
requirements.  To my surprise, Microsoft DNS v5.0 which is what we have 
for our primary DNS server on a Windows 2003 machine, does not support 
RFC 3597 "Handling of Unknown DNS Resource Record (RR) Types" and it did 
not offer a method to add new ones.

Why is that?  Don't they have a stake in all this too? Are they reading 
these IETF forums?

Maybe this could be a plenary topic for you guys to talk about at these 
IETF meetings - "Supporting new DNS Applications: Improving the Quality 
of the DNS infrastructure."

--
HLS

[1] nslookup -query=txt _ep.hotmail.com

Non-authoritative answer:
_ep.hotmail.com text =

"<ep xmlns='http://ms.net/1' 
testing='true'><out><m><indirect>list1._ep.hotmail.com</indirect><indirect>list2._ep.hotmail.com</indirect><indirect>list3._ep.hotmail.com</indirect></m></out></ep>"

[2] http://www.dmarc.org/draft-dmarc-base-00-02.txt
[3] http://tools.ietf.org/html/rfc3597

On 4/30/2013 8:45 PM, Sam Hartman wrote:
> I think I understand this issue well enough to comment and so I will.
>
> 1) I totally believe it is reasonable to consider operational challenges
> when designing protocols. "Just upgrade your infrastructure, just use
> another registrar, just upgrade the infrastructure of the people you
> communicate with," are not generally reasonable advice to give people;
> ingoring these concerns tend to lead to things that cannot be deployed.
>
> 2) I think it's fine to come up with a solution that   is harder to
> implement because it is easier to deploy given the sorts of concerns in
> 1.
>
> 3) having reviewed the DNS arguments, I generally would recommend txt
> records with distinct owner names over new RR types for most
> protocols. I understand there are residual issues with that approach.
>
> 4) Using txt RRs the way SPF does--where the owner name is shared
> potentially with other applications is kind of unfortunate.  I don't
> know it's unfortunate enough to push for the SPF RR. But the issues
> people have brought up with regard to updates and RR order are very
> real.
> But so are the operational issues with SPF.
>
> So my personal opinion is that this is a valid discussion to be having
> even if we're having it again in IETF LC.  However, to be successful we
> need to get new participants and to ad more respect for arguments to the
> discussion.
>
>

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 01 May 2013 13:54:34 +0200

On Tue 30/Apr/2013 21:54:11 +0200 David Conrad wrote:
> On Apr 30, 2013, at 11:12 AM, Dave Crocker <[email-masked]> wrote:
>>> What is the IETF-approved timeframe in which "the market" is
>>> allowed to accept/reject a particular technology?
>>
>> I've no idea what the lower limit is or should be, but I'm quite
>> sure that 7 years exceeds it by a very comfortable margin.
> 
> By that logic we should abandon IPv6, DNSSEC, EDNS0, etc.

If it is possible to get exactly the same functionality without using
them, I guess we should.

The DNS community would do SPFBIS a favor if they try and understand
the current status of email authentication, and regard SPF as a set of
(missed) requirements rather than a means to trace a path that is not
paved yet.

If the next version of the SPF protocol (v=spf{>1}) will ever come
out, a better use of the DNS will be possible if the DNS will have met
those requirements by then.  That does not depend on whether we insist
on an unworkable specification in the -bis of the current version.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 01 May 2013 15:05:48 +0200

On Tue 30/Apr/2013 19:11:15 +0200 Doug Barton wrote:
> On 04/30/2013 09:28 AM, Alessandro Vesely wrote:

>> While it's too late for SPF, we can learn this lesson.
> 
> As has been repeatedly pointed out in the discussion on both dnsext
> and spfbis, it is NOT too late for SPF. The way forward is simple:

The results of 4408 indicate we erred.  To persist is diabolical.

> 5. When the next version of the SPF protocol (v=spf{>1}) comes out
> make it SPF/99 only.

Why should a record of type SPF have the string "spf" in it?  Are
there precedents?

---

From: Pete Resnick <[email-masked]>
Date: Wed, 1 May 2013 08:44:00 -0500

On 4/30/13 7:45 PM, Sam Hartman wrote:
> even if we're having it again in IETF LC.

Folks,

This document is *not* in IETF LC. A particular WG member, who was 
apparently upset with the tone of the argument on the SPFBIS and DNSEXT 
list, expressed his upset by cross-posting to the IETF list, claiming 
this had something to do with the "IETF Diversity" topic.

Then a bunch of other SPFBIS and DNSEXT folks blindly used "Reply-All", 
resulting in us all seeing this discussion.

I will leave it to the chairs/sergeants-of-arms of the respective lists 
to decide how they want to deal with this, but personally I think this 
discussion is not useful to have on the IETF list at the moment and 
suggest that folks be more careful of their use of "Reply-All". I also 
suggest that cross-posting to a new list without noting that in the body 
of the message is bad netiquette.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 02 May 2013 11:00:52 +0200

On Tue 30/Apr/2013 20:02:11 +0200 Edward Lewis wrote:
> On Apr 30, 2013, at 12:28, Alessandro Vesely wrote:
>> ...The basic fact that killed the SPF type is the ability to use
>> TXT as a replacement.  There must be an analogous of Gresham's
>> law:  "Bad types drive out good ones."
> 
> I disagree with the assertion that what killed SPF is "the ability
> to use TXT as a replacement."   It has nothing to do with one
> option being superior to the other, it was the lack of technical
> incentive to switch from one to the other.

I'm not following:  Either one option is superior to the other, or
they are more or less equally fit.  In the latter case, it becomes a
question of taste and there is no technical incentive.

> I post this in the sense that if the root cause is not understood,
> no solution will stick.  Here is a message with my recounting of
> what led us to this point:
> 
> http://www.ietf.org/mail-archive/web/dnsext/current/msg12681.html

I agree that security shackles are different from provisioning.  Yet,
their effects on deployment are similar:  They are part of those minor
problems that always have to be faced when introducing something new.
 Such problems are only faced and overcome if the new type provides
some added value, which SPF over TXT does not.

> I don't see the death of SPF has a harbinger of things to come.
> There's a strong case to be made the failure happened before 2004
> and the root cause has since been corrected by changing the RRTYPE
> type allocation policies.  Still that fix was too late to ever let
> SPF sprout wings.

Type allocation policy isn't but one requirement for new types.  To
check the syntax and the semantics of data records, and to
conveniently format them on the wire would make for real added value.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 02 May 2013 11:20:22 +0200

On Wed 01/May/2013 03:04:52 +0200 Mark Andrews wrote:
> In message <[email-masked]>, Alessandro Vesely writes:
>> On Tue 30/Apr/2013 01:07:42 +0200 Mark Andrews wrote:
>>> 
>>> SPF is techically superior to TXT is lots of ways.
>>> 
>>> [...]
>>> 
>>> For TXT you need to lookup the existing RRset, extract
>>> the v=spf1 record from it.  You then need to create a
>>> UPDATE message to delete just that record as well as add
>>> the new TXT record.   You then have to hope that no one
>>> else is performing a simultaneous update as you may get
>>> two TXT v=spf1 records in the RRset.
>> 
>> That's true, except that one has TXT records anyway.
> 
> 	nsupdate
> 	update del example.com SPF
> 	update add example.com 3600 SPF v=spf1 ....
> 	send
> 
> [intricacies of doing so in the face of multiple TXT records elided]

Thanks for the examples.

> I'm sure I could come up with a more compact way of identifying
> a spf record but it wouldn't be needed if people published type
> SPF.

You must mean "if people published SPF _only_".

What percentage of NS servers use dynamic updates primarily?  (I only
happened to use nsupdate occasionally, e.g. to fix dhcp hiccups.)

Switching to fully dynamic management would be a major evolutionary
step for DNS, and it will certainly make the arguments for strong DNS
typing more stringent.

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 2 May 2013 12:53:47 +0200

> happened to use nsupdate occasionally, e.g. to fix dhcp hiccups.)

Every Active Directory installation is using dynamic DNS. And while the
unwillingness of that particular vendor to handle unknown RRtypes or add
specific support for SPF is a baffling mystery to the rest of the world,
they can and do change -- they have a prototype DNSSEC implementation
in recent versions complete with a large bunch of new RRtypes.
 
> step for DNS, and it will certainly make the arguments for strong DNS

Since year 2000 and the initial release of Active Directory that has
as a matter of fact happened. The typing argument has always been valid
from a design perspective; now there is an operational requirement.

/Måns, whose $dayjob includes running AD DNS, but using BIND and Unbound. 
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Does someone from PEORIA have a SHORTER ATTENTION span than me?

---

From: Eliot Lear <[email-masked]>
Date: Thu, 02 May 2013 16:53:09 +0200

And here we come to a conflict between what we as a community would
like, versus what the market decides.  This leads to a few questions:

1.  Do we have to make a decision at any point from a protocol
standpoint that the market has in fact made a decision?  I ask this
question because I performed an experiment along these lines some years
ago, finding quite a number of proposed standards that were nowhere to
be seen on the 'net.  Earlier we saw discussion about simplifying code
bases, but generally a developer  makes that decision, not the IETF.

2.  What are the timescales involved?  Is it fair to treat IPv6 the same
as a new DHCP option or a DNS RR?  What are the parameters?  One could
reasonably argue with the benefit of hindsight that there was no way we
would see IPv6 adoption until we ran out of IPv4 addresses.  For DNS
RRs, there are some common inhibitors.

3.  What can be done by the IETF to improve likelihood of adoption, and
conversely what should we not bang our heads against?

Eliot

On 5/1/13 7:03 AM, Murray S. Kucherawy wrote:
> On Tue, Apr 30, 2013 at 12:52 PM, David Conrad <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     SPF using TXT and hence, SPFBIS forces the uniquification of the
>     DNS response into the application instead of in the DNS library.
>     Given the ordering of individual TXT RRs within an RRset is not
>     guaranteed, I suspect the chances that every application is going
>     to do that parsing correctly is relatively low (btw, the example
>     in 3.3 in spfbis-14 is a bit misleading: assuming "second string"
>     is in a separate TXT RR (which is implied), the concatenation
>     might be "second stringv=spf1 ..... first").  The more interesting
>     bit is if/when another protocol uses TXT at the same ownername.
>
>
> Yes, I understand all of that, and I've written code to deal with it. 
> It's not rocket science.
>  
>
>     The RR has been allocated and it is supported in most DNS servers
>     and resolver libraries in one form or another.  Provisioning
>     systems take much longer, but that isn't surprising and shouldn't
>     be an argument to deprecate (if it is, we might as well close the
>     RRtype registry for new entries).
>
>
> We're not only talking about provisioning systems here.  We're also
> talking about interference with queries and replies at the DNS
> protocol level.  The survey work done for RFC6686 showed that
> something on the order of thousands of domains in the sample set
> suffered from this.  It is a very real issue for a deployed protocol.
>  
>
>     In the past, the IETF used to make decisions based on long-term
>     technical/architectural correctness, even in the face of pragmatic
>     complications (e.g., the choice to mandate strong crypto despite
>     real world challenges some companies faced in exporting that
>     crypto in products). In this particular case, there seems to be an
>     argument to explicitly disallow the long-term
>     technically/architecturally correct approach because some folks
>     choose not to add an RR to their zone files or support that RR in
>     their provisioning systems.  As I said in DNSEXT, this seems like
>     the wrong approach to me.
>
>
> All things being equal, I would agree with you.  And if SPF were
> starting anew today, I suspect I might have a different opinion.  The
> question, then, is the weight of the mitigating circumstances, which
> obviously the two communities evaluate quite differently.
>
> -MSK

---

From: Hector Santos <[email-masked]>
Date: Thu, 02 May 2013 11:13:16 -0400

Mr. Resnick,  for the record, I wasn't upset. Believe it or not, I was 
actually applying an suggestion posted last month or so here with the 
IETF diversity talks to help get a major WG issue resolved, one with a 
near surety of an appeal, resolved and addressed much faster and hence 
avoid a waste of time on the behalf of all.

How appropo, that a topic of "balancing of process" as being considered. 
   It is one thing I believe the IETF needs and can be actually apply 
today. Yes, I don't agree with the negative tone taken in SPFBIS where 
in effect, an attempt to shut down communications and indirectly 
personally attack posters occurred and the advocates of the SPF RRTYPE 
removal (incidentally, a SPEC change which I believe was prohibited by 
the charter), basically blowing off advocates of a RFC4408 status quo. 
If you believe that was proper, I think we have a WG problem.

Overall, I believe this (keep the migration path) is the proper 
compromise to resolve the issue, and I believe that this particular 
issue is industry-wide important to resolve with across the board 
engineering input. It *SHOULD NOT* be reserved only to the applications 
SPFBIS group especially when we know what the DNS community will say 
about this and has said so since MARID 2003 and again last year in IETF 
and DNSOPs. I was simply hoping to help "Balance the process" then as I 
was attempted to do again.  If I was in error for trying to get a 
serious issue resolve, then please accept my apology.

Sincerely,

Hector Santos

---

From: S Moonesamy <[email-masked]>
Date: Thu, 02 May 2013 09:02:08 -0700

Hi Alessandro, Doug,

My task is to keep draft-ietf-spfbis-4408bis moving forward and to 
maintains a critical and technical perspective of the draft.  The two 
weeks Working Group Last Call for draft-ietf-spfbis-4408bis-14 was 
announced on April 9, 2013 [1].  The document shepherd review was 
posted to the SPFBIS mailing list on April 23 [2].

I wasn't sure about some text in Section 5 of the draft.  I posted a 
question to the 6MAN mailing list [3].  I posted another question 
about the DNS Parameters registry to the DNSEXT mailing list 
[4].  The replies to that question generated about 200 messages on 
the DNSEXT and SPFBIS mailing lists.  I read all these messages while 
following up on the document shepherd review.  In my individual 
opinion there was a concern about "Obsoleting SPF RRTYPE".  A message 
[5] about the topic was posted to the [email-masked] mailing list on 
April 29 while the topic was being discussed on the SPFBIS mailing 
list.   There was a message about shutting down the thread on the 
SPFBIS mailing list.  I humbly suggested [6] leaving the matter to 
the SPFBIS WG Chairs.  I discussed the matter with Andrew Sullivan on 
April 30.  A message [7] was posted to the SPFBIS mailing list after that.

I read the message posted by Doug Barton about an IETF Last Call 
objection [8].  I'll comment about the path of the 
draft-ietf-spfbis-4408bis.  There are issues which were raised during 
the Working Group Last Call.  There are also three directorate/team 
reviews.    If the issues and reviews are addressed there will be a 
publication request for draft-ietf-spfbis-4408bis.  The Responsible 
Area Director will likely review the draft.  If that step is cleared 
there will be a Last Call announcement for 
draft-ietf-spfbis-4408bis.  If anyone has any objection I suggest 
raising it during the Last Call.

If you have any questions about the above please let me know so that 
we can talk about it.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg03347.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg03414.html
3. http://www.ietf.org/mail-archive/web/ipv6/current/msg17638.html
4. http://www.ietf.org/mail-archive/web/dnsext/current/msg13025.html
5. http://www.ietf.org/mail-archive/web/ietf/current/msg78927.html
6. http://www.ietf.org/mail-archive/web/spfbis/current/msg03663.html
7. http://www.ietf.org/mail-archive/web/spfbis/current/msg03681.html
8. http://www.ietf.org/mail-archive/web/ietf/current/msg78955.html

---

From: Doug Barton <[email-masked]>
Date: Thu, 02 May 2013 12:22:03 -0700

On 5/2/2013 9:02 AM, S Moonesamy wrote:
> If anyone has any objection I suggest raising it during the Last Call.

Given that you can be 100% confident that the issue will be raised 
during IETF LC, wouldn't it be better to hash it out in the WG (as we 
have attempted to do)? Or is the WG's position, "we have no intention of 
dealing with this unless we're forced to?"

I'm fully sympathetic with your collective desire to move the process 
forward, and finish your document. The problem is that as it stands the 
document contains a course of action that is not only bad on its face, 
but contrary to a basic architectural principle adopted 4 years ago in 
5507.

Doug

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 2 May 2013 15:50:16 -0400

Doug,

No hat.

On Thu, May 02, 2013 at 12:22:03PM -0700, Doug Barton wrote:
> during IETF LC, wouldn't it be better to hash it out in the WG (as
> we have attempted to do)? Or is the WG's position, "we have no
> intention of dealing with this unless we're forced to?"

We _have_ hashed this out in the WG.  As I have noted to you -- now on
three separate lists -- the problem is that we have an actual
interoperability bug in RFC 4408, and we need to fix it.  The WG
evaluated the various alternatives for how to solve that, and having
performed the evaluation the group came to the conclusion that, _in
this specific case_, deprecating RRTYPE 99 is the most reasonable
course of action.

I am not happy about this, but other analyses do not seem to be
supported by any facts, nor by any argument that leads to the
conclusion that an arrangement we would all like better has any chance
of deployment.  This is just a plain fact of the Internet, I think,
and if you think it's not I would like some evidence, please.

A

-- 
Andrew Sullivan
[email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Thu, 02 May 2013 16:29:07 -0700

Hi Doug,
>intention of dealing with this unless we're forced to?"

This is an individual opinion.  It has been mentioned on the SPFBIS 
mailing list that:

   If someone provides an argument together with a good explanation it is not
   going to be ignored no matter how vocal other SPFBIS WG participants are.

The SPFBIS WG Chairs mentioned that:

   "There has been an enormous number of messages lately discussing the
    planned deprecation of the SPF RRTYPE and whether TXT is an appropriate
   thing to use and if it is whether the SPF use of it is ok."

and

   "If you are tempted to say more, we ask that you identify the specific
    point that you think has not been addressed and talk only about
    that.  Other arguments have been made clearly, we believe, and do not
    need additional repetition."

My intent is not "I have no intention of dealing with this unless I 
am forced to".

>I'm fully sympathetic with your collective desire to move the 
>process forward, and finish your document. The problem is that as it 
>stands the document contains a course of action that is not only bad 
>on its face, but contrary to a basic architectural principle adopted 
>4 years ago in 5507.

I have read RFC 5507.  My desire is not to move the draft forward no 
matter what.  If I merely wanted to finish the draft I would have 
done a cursory review.

Several WG participants, including you if I am not mistaken, have 
attempted to hash out the issue in the working group.  It's not that 
there weren't any good arguments.  A Last Call can sometimes help 
bring in fresh perspectives.

Regards,
S. Moonesamy

---

From: Mark Andrews <[email-masked]>
Date: Fri, 03 May 2013 11:56:20 +1000

> serious issue resolve, then please accept my apology.

One of the questions is how to deal with vendors that claim to ship
a product which is in compliance with the protcol when they are
not.

The DNS protocol has a error code for when you do not understand a
query, FORMERR.  It also has a error code for when you do not
implement part of the protocol, NOTIMP.

With RFC 103[45] you have three choices as a developer when you get
a query type you don't know about.

1. Treat it as a FORMERR.
2. Treat it as a NOTIMP.
3. Treat it as a opaque data.

Now in my book it isn't a FORMERR as you can understand the question
even if you can't deal with it.  NOTIMP is a reasonable response
though I believe the intent in RFC 103[45] was to treat it as opaque
data query which is what RFC 3597 says to do.

Nowhere in RFC 103[45] does it say DO NOT RESPOND to the query yet
we have DNS vendors that ship products that do just that and are
claiming that they conform to the protocol.

For a example of a set of servers that does this see earthlink.net's
servers.

Query for HINFO/earthlink.net at the authoritative servers for
earthlink.net (itchy.earthlink.net and scratchy.earthlink.net) and
you will not get a response.  A RFC 103[45] compliant server should
know about HINFO.  It should also be capable of returning a NOERROR
NODATA response for that query and it fact will if you ask for a
non-existent TXT record at a name it serves.

How do we deal with sites?
How do we deal with vendors that ship such product?

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 3 May 2013 02:07:21 +0000

> How do we deal with vendors that ship such product?

I say we punch 'em.

Seriously, the IETF doesn't have an enforcement arm.   It's up to buyers to check to see that what they are buying is protocol compliant, and often they either fail to even try, or don't really know how.

What you can do as a DNS vendor, if you want to beat up other vendors with non-compliant products, is to produce a validation test suite and start promoting it.   Is there a vendor that does this now?   If so, you could just use theirs, assuming it's free.   Start boasting in your advertising that your product is standards compliant.

Now that you're done with that, get started on all the middleboxes that are made by vendors who are not "DNS vendors".

The good news is that the ocean is warmer than it was even ten years ago, so boiling it is somewhat less work than it used to be.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 03 May 2013 12:48:05 +1000

In message <[email-masked]>, Ted Lemon writes:
> Seriously, the IETF doesn't have an enforcement arm.   It's up to buyers
> to check to see that what they are buying is protocol compliant, and
> often they either fail to even try, or don't really know how.

When the literature says it is a DNS server how is the buyer to
know it isn't a complete DNS server?  And even if they know it is
not a complete DNS server would they know the impact of deploying
it?

> What you can do as a DNS vendor, if you want to beat up other vendors
> with non-compliant products, is to produce a validation test suite and
> start promoting it.   Is there a vendor that does this now?   If so, you
> could just use theirs, assuming it's free.   Start boasting in your
> advertising that your product is standards compliant.

Which just adds more noise.  Now if a recognised standards body was
to do the tests then it might have some effect.

Should we be using RFC 1033's complaint's procedures?  How can
we get TLDs to do step 5 when steps 1 though 4 fail?

COMPLAINTS

   These are the suggested steps you should take if you are having
   problems that you believe are caused by someone else's name server:

   1.  Complain privately to the responsible person for the domain.  You
   can find their mailing address in the SOA record for the domain.

   2.  Complain publicly to the responsible person for the domain.

   3.  Ask the NIC for the administrative person responsible for the
   domain.  Complain.  You can also find domain contacts on the NIC in
   the file NETINFO:DOMAIN-CONTACTS.TXT

   4.  Complain to the parent domain authorities.

   5.  Ask the parent authorities to excommunicate the domain.

> Now that you're done with that, get started on all the middleboxes that
> are made by vendors who are not "DNS vendors".

Middle boxes are a little easier to deal with as they are usually at the
client end not the server end.
 
> The good news is that the ocean is warmer than it was even ten years ago,
> so boiling it is somewhat less work than it used to be.

---

From: Randy Bush <[email-masked]>
Date: Thu, 02 May 2013 20:44:21 -0700

seems to me that
  o spf is still used, whether we think it is a good idea or not
  o spf is using the spf rrtype
  o we don't shoot an rrtype which is still being used
  o overloading txt with a whole lot of things we don't like is
    stupid++ for soooo many reasons

if you don't like spf, then *convince* folk to use something better.
until then, find something better to do with your copious spare time.

randy

---

From: Warren Kumari <[email-masked]>
Date: Fri, 3 May 2013 13:01:55 -0400

> How do we deal with vendors that ship such product?

Unless the caffeine just hasn't sunk in yet, it works for me:

wmbt-macbookair:Preferences wkumari$ dig HINFO earthlink.net @scratchy.earthlink.net

; <<>> DiG 9.8.3-P1 <<>> HINFO earthlink.net @scratchy.earthlink.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1906
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;earthlink.net.			IN	HINFO

;; AUTHORITY SECTION:
earthlink.net.		1800	IN	SOA	itchy.earthlink.net. hostmaster.earthlink.net. 2013042602 3600 300 2592000 1800

;; Query time: 51 msec
;; SERVER: 207.69.188.197#53(207.69.188.197)
;; WHEN: Fri May  3 12:59:50 2013
;; MSG SIZE  rcvd: 84

So, maybe the way you fix such sites / deal with vendors that ship such products is you post to [email-masked] and cc hostmaster@site?

:-P
W

--
Hope is not a strategy.
      --  Ben Treynor, Google

---

From: Noel David Torres Taño <[email-masked]>
Date: Fri, 3 May 2013 18:54:46 +0100

> conversely what should we not bang our heads against?

Amend the Wikipedia article about SPF, where it states that it is TXT only?

-------------------------
A: Because it breaks the logical flow of discussion.
Q: Why is top posting bad?

---

From: Doug Barton <[email-masked]>
Date: Fri, 03 May 2013 16:19:39 -0700

Andrew (and Pete, since he raised a similar issue),

> this specific case_, deprecating RRTYPE 99 is the most reasonable

I understand the conclusion the WG has come to, and I have a pretty good 
understanding as to why. At Pete's request I reviewed the threads 
related to this issue in the spfbis archive. I also understand that the 
WG (which you co-chaired, although I will accept your "no hat" statement 
above at face value) desperately wants this issue to go away.

The problem is that the WG came to a very bad conclusion. A conclusion 
that is not only bad for SPF, it's bad for the future of innovation in 
the DNS, contrary to 5507, and arguably contrary to the group's own 
charter.

I am not saying that the WG members (or chairs) should be given the 
wet-noodle treatment over having reached a bad decision, but what is 
cross-area review for if not to catch cases where the WG echo 
chamber/tunnel vision/what have you -- resulted in a bad outcome?

It would be different if the right solution were hard, or if I were the 
only one objecting. But neither is true.

> supported by any facts,

I'm not sure what facts you're looking for beyond what I've already 
provided. But in no particular order:

1. "Deprecate SPF/99" is in violation of 5507
2. Numerous people smarter than I have pointed out detailed technical 
reasons why overloading TXT generally, and particularly at the zone 
apex, is a horrible idea.

Furthermore, 2 of us presented detailed analyses of the arguments raised 
in spfbis, and found them severely lacking. In summary, "We tried doing 
SPF/99 10 years ago and it didn't work, so we stopped." I (and others) 
have several times now offered detailed responses explaining that in a 
post-3597 world that shouldn't be an issue anymore. "There are still 
some firewalls or other middleboxes that don't handle DNS properly" is a 
truism, but as pointed out by myself and Mark Andrews the value of 
"some" has been reduced to the margins by IPv6 and DNSSEC. Both that 
issue, and the issue of updating provisioning systems are things that 
need to be dealt with, but they are going to be true for whatever 
advances we want to make in the DNS. As an organization we have stated 
that we're not willing to be held hostage to those issues (5507), a 
position with which I maintain full agreement and support.

Further-furthermore, after I suggested that the way forward is to query 
SPF/99 first, it came to light that 2 of the major implementations 
(Mail::SPF and libspf2) _already do that_. A fact that the WG seems to 
be conveniently ignoring.

Frankly at this point I'm wondering what the fuss is about.

> nor by any argument that leads to the
> of deployment.

If your argument here is, "The SPF literati have spoken, don't intend to 
change, and wish you to stop bothering them by pointing out that they've 
come to the wrong conclusion," I'm sure you can imagine my response. 
However, given that 2 of the major implementations _have already 
switched to doing what I suggested_, what we're really talking about 
here is winning over the hearts and minds of "the masses" who do this 
stuff, write up the docs, etc. Personally I can't think of a better way 
to continue that ball rolling than to publish an spfbis document that 
documents how to do v=spf1 the way it should have been done in the first 
place, and specifies that future versions of SPF will be SPF/99 only.

Doug

---

From: Mark Andrews <[email-masked]>
Date: Sat, 04 May 2013 10:49:34 +1000

In message <[email-masked]>, Warren Kumari writes:
> earthlink.net.		1800	IN	SOA	itchy.earthlink.net.
> hostmaster.earthlink.net. 2013042602 3600 300 2592000 1800
>
> ;; Query time: 51 msec
> So, maybe the way you fix such sites / deal with vendors that ship such
> products is you post to [email-masked] and cc hostmaster@site?
>
> :-P
> W

Did you see the bounce that came back from [email-masked]?

You follow the link in that email and there is no where to report
the problem.  None of the options offered was really sensible though
I did open a chat window and report the problem.  I doubt it will
have much effect.

Whois doesn't help.  Same bouncing email address or one needs to
make a international phone call to report the problem.

And no it still doesn't work, below, from where I am in the world
not that ietf@ is the right place to diagnose this specific issue.

Earthlink.net isn't the only zone, it is just a example.

The ones in a position to make a difference are the registries and
registrars.  They can test the nameservers when they are registered
and annually there after.  They can also remove the delegation if
a detected problem is not fixed in a timely manner.

One shouldn't be allowed to register a non compliant nameserver,
where not responding to arbitary query types is a form of non
compliance.  Similar non compliance is returning a SOA record other
that that for the delegated zone in a negative answer.

These are the two errors that most impact on the ability to deploy
new types.  They are also things that are not usually checked for.

Yes this is a attempt to clean up the commons.

Mark

[drugs:~/git/bind9] marka% dig soa earthlink.net @scratchy.earthlink.net

; <<>> DiG 9.9.3-S1rc2 <<>> soa earthlink.net @scratchy.earthlink.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39882
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;earthlink.net.			IN	SOA

;; ANSWER SECTION:

;; AUTHORITY SECTION:
earthlink.net.		1800	IN	NS	itchy.earthlink.net.
earthlink.net.		1800	IN	NS	scratchy.earthlink.net.

;; ADDITIONAL SECTION:
itchy.earthlink.net.	1800	IN	A	207.69.188.196
scratchy.earthlink.net.	1800	IN	A	207.69.188.197

;; Query time: 241 msec
;; SERVER: 207.69.188.197#53(207.69.188.197)
;; WHEN: Sat May 04 09:49:15 EST 2013
;; MSG SIZE  rcvd: 164

[drugs:~/git/bind9] marka% dig hinfo earthlink.net @scratchy.earthlink.net

; <<>> DiG 9.9.3-S1rc2 <<>> hinfo earthlink.net @scratchy.earthlink.net
;; global options: +cmd
;; connection timed out; no servers could be reached
[drugs:~/git/bind9] marka% traceroute  scratchy.earthlink.net
traceroute to scratchy.earthlink.net (207.69.188.197), 64 hops max, 52 byte packets
 1  192.168.191.233 (192.168.191.233)  1.498 ms  1.435 ms  1.139 ms
 2  10.72.0.1 (10.72.0.1)  30.066 ms  18.106 ms  19.995 ms
 3  bla2-ge0-0-1.gw.optusnet.com.au (198.142.160.185)  26.258 ms  26.529 ms  21.209 ms
 4  * * *
 5  bla5-ge13-0.gw.optusnet.com.au (211.29.125.249)  27.672 ms  34.851 ms  38.224 ms
 6  203.208.131.57 (203.208.131.57)  181.029 ms  161.411 ms  181.544 ms
 7  las-b3-link.telia.net (80.239.167.189)  163.015 ms  177.855 ms  189.488 ms
 8  las-bb1-link.telia.net (213.155.131.84)  179.306 ms  179.604 ms
    las-bb1-link.telia.net (213.155.134.252)  226.815 ms
 9  ae8.edge1.losangeles.level3.net (4.68.70.129)  169.711 ms  171.338 ms  174.650 ms
10  vlan90.csw4.losangeles1.level3.net (4.69.144.254)  234.904 ms
    vlan60.csw1.losangeles1.level3.net (4.69.144.62)  246.798 ms  228.503 ms
11  ae-62-62.ebr2.losangeles1.level3.net (4.69.137.17)  227.185 ms
    ae-82-82.ebr2.losangeles1.level3.net (4.69.137.25)  237.125 ms  229.297 ms
12  ae-3-3.ebr3.dallas1.level3.net (4.69.132.78)  242.771 ms  244.128 ms  231.012 ms
13  ae-7-7.ebr3.atlanta2.level3.net (4.69.134.22)  311.533 ms  230.136 ms  235.348 ms
14  ae-63-63.ebr1.atlanta2.level3.net (4.69.148.242)  225.662 ms
    ae-73-73.ebr2.atlanta2.level3.net (4.69.148.254)  273.549 ms
    ae-63-63.ebr1.atlanta2.level3.net (4.69.148.242)  239.239 ms
15  ae-26-52.car2.atlanta2.level3.net (4.69.150.70)  242.421 ms
    ae-16-51.car2.atlanta2.level3.net (4.69.150.6)  237.273 ms
    ae-26-52.car2.atlanta2.level3.net (4.69.150.70)  238.109 ms
16  earthlink-i.car2.atlanta2.level3.net (4.71.254.14)  251.459 ms  335.603 ms  239.819 ms
17  cor01-vl-10.ga-atlanta0.ne.earthlink.net (207.69.223.158)  240.427 ms  270.848 ms  228.444 ms
18  * * *
19  * * *
20  * * *
21  * * *
^C
[drugs:~/git/bind9] marka%

---

From: S Moonesamy <[email-masked]>
Date: Sat, 04 May 2013 11:36:43 -0700

Hi Doug,
>chamber/tunnel vision/what have you -- resulted in a bad outcome?

I'll try explain the problem as I saw it.

  (a) You should have both X and Y

  (b) You must have either X or Y

  (c) If you have X and Y they must be identical

  (d) I can ask you for either X or Y, or for both X and Y

Regards,
S. Moonesamy

---

From: Mark Andrews <[email-masked]>
Date: Sun, 05 May 2013 08:13:29 +1000

>   (d) I can ask you for either X or Y, or for both X and Y

The DNS does not guarentee that the result of 2 consecutive
queries for the same data will be the same even to the same
server (cache or authoritative).

RFC 4408 says that *data* MUST be the same if both records are
present in the zone.  It the operator breaks that MUST then you get
inconsistent results.  Note this is no different to changing the
contents of the record.  You will get inconsistent result while the
record are in transition.

For the client side you assume the MUST is being honoured as there
is no way (other than to ask a * query directly to the authoritative
servers) to check that this is so.  You take the first result which
returns *data* and use it.

This was never a real problem.  Not all MUSTs need to be checked.

Note DNSSEC also has MUSTs about what the server side need to do
which the client side cannot check.  This is the nature of DNS.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Sun, 05 May 2013 08:57:48 +1000

> >   (d) I can ask you for either X or Y, or for both X and Y

      (e) X is only for backwards compatibility.

> > S. Moonesamy 

The publisher can choose to interoperate with everyone by publishing
both.

The client side can choose to interoperate with everyone by looking
for both.

Both side can choose their level of interoperability.  There is no
bug.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Sun, 05 May 2013 09:26:16 +1000

> Both side can choose their level of interoperability.  There is no

Additionally it supports all implementions from pre RFC 4088 through
to the desired end state of type SPF only.

B.T.W. the next point releases of named (at rc2 now) warns if SHOULD
have both is not being done.

Mark

---

From: S Moonesamy <[email-masked]>
Date: Sun, 05 May 2013 08:58:21 -0700

Hi Mark,
>Both side can choose their level of interoperability.  There is no

Thanks for the feedback.

Based on the quoted text I would write the text as:

   (i)  you must have X and Y where X and Y are identical.

   (ii) I ask you for both X and Y (see [1] for example).

Item (i) is a combination of the previous items (a) and (c).  Item 
(ii) is the last part of previous item (d).

>have both is not being done.

Noted.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/ietf/current/msg79114.html

---

From: Hector Santos <[email-masked]>
Date: Sun, 05 May 2013 15:01:56 -0400

On 5/5/2013 11:58 AM, S Moonesamy wrote:
> Item (i) is a combination of the previous items (a) and (c).  Item (ii)
> is the last part of previous item (d).

Overall, IMV, this is common sense migration path logic used in many 
concepts:

    Try X first,
    Fallback to Y second;

Where X is the preferred protocol *PATH*.  It is implicit that the data 
is functionally equivalent. I have used a nomenclature of X/Y to signify 
this logic. I thought it was implicit.  In fact, for BIS, I posted an 
issue [1] suggesting a clarification on its tip of using a "Parallel" 
method.  Ultimately, and in theory, this complexity would not be 
necessary, but it may be the only practical solution if there is slow 
resolutions on the existing DNS query barriers.

I guess there is no concern about having dual SPF/TXT calls, either in 
series or in parallel, if there are no delays. The way I long time 
viewed it, the SPF overhead, high redundancy and waste is based on:

   - NXDOMAIN
   - NOERROR
   - Relaxed SPF policies (No Payoff)

I expected the overhead would be short term as more records as published 
and more domains began to switch to -ALL operations.  After 10 years, 
with a slow growth climb, today, I see a 20% SPF rejection rate at our 
support site:

    http://www.winserver.com/SpamStats

Our implementation does not perform HELO/EHLO SPF checking by default 
since it is historically high incorrect value, and the return path SPF 
domain checking is done after the RCPT TO field is validated. This delay 
in SPF processing lowers the SPF DNS overhead by 60%.

--
HLS

---

From: Mark Andrews <[email-masked]>
Date: Mon, 06 May 2013 08:13:38 +1000

In message <[email-masked]>, S Moonesamy write
> (ii) is the last part of previous item (d).

That was not the intent.  Having choice here is very important here.
In fact it is essential to reach the end goal of Y only when starting
with X only.

There is nothing wrong with failing to catch every possible forgery
possible if both sides are using SPF.  Unfortunately the SPF WG
seem to think that unless the RFC does catch every possible forgery
that it is broken.  The SPF WG appears to not want to allow operators
to have the choice.  This is the case "pefect" being the enemy of
"good enough".  We need "good enough" here not "perfect".

Mark

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 05 May 2013 18:54:26 -0400

>"good enough".  We need "good enough" here not "perfect".

If we publish a 4408bis that suggests the normal way to publish an SPF record is in type SPF, then it'll get about 98% less effective based on the data we've collected. What you are suggesting is more like 'ignore the deployed base and start over'.  That's not wgat the WG was chartered to do.  

Additionally, I'm personally against publishing documents that require special external knowledge (if 4408bis prefers SPF over TXT deployers will have know to ignore that part of the RFC if they actually want the protocol to be useful. To promote interoperability there has to be a MUST publish and a MUST check format in common.  Given the lack of type SPF deployment, it's crazy to suggest that it should be the required type.

Scott K

---

From: Mark Andrews <[email-masked]>
Date: Mon, 06 May 2013 10:10:40 +1000

In message <[email-masked]>, Scott Kitt
erman writes:
> If we publish a 4408bis that suggests the normal way to publish an SPF
> record is in type SPF, then it'll get about 98% less effective based on
> the data we've collected. What you are suggesting is more like 'ignore
> the deployed base and start over'.  That's not wgat the WG was chartered
> to do.

No one said "ignore deployed base".  Firstly normal != only.

Secondly one could quite easly add "fixup SPF" functionality to
nameservers/zone signers by having the master server/signers add
type SPF records if they are not present when there are v=spf1 TXT
records.  This would also require fixing some DNSSEC records but
it is doable.

Name servers/signers fixup DNSSEC records all the time.  Adding
another type of record to fixup is a relatively trivial change.

For unsigned zones one could do this on slave servers as well.

You have already mentions you have a script that does it.  A script
needs someone to install it and run it so it is not comparable,
other than a proof of concept that it can be done, to getting
nameservers to do the fixup.  This get done installed and run
automatically.  Installation happens as part of OS upgrades / new
server installs.  It gets run as it is part of the default behaviour.

> Additionally, I'm personally against publishing documents that require
> special external knowledge (if 4408bis prefers SPF over TXT deployers
> will have know to ignore that part of the RFC if they actually want the
> protocol to be useful. To promote interoperability there has to be a MUST
> publish and a MUST check format in common.  Given the lack of type SPF
> deployment, it's crazy to suggest that it should be the required type.

What external knowledge.  4408 already effectly says that you need
to publish SPF records.  TXT records are described as "for backwards
i compatibilty".  It says you SHOULD publish both.

You are worrying about it not been "perfect" when it was in fact
what was in 4088 was "good enough".

Mark

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 05 May 2013 23:01:02 -0400

On Monday, May 06, 2013 10:10:40 AM Mark Andrews wrote:
> In message <[email-masked]>, Scott
> Kitterman writes:

None of this happened in 8 years.  There's no basis for the next 8 years being 
any different.

> what was in 4088 was "good enough".

What was in 4408 turned out to be pointless and complicating.  There are also 
a few pour souls out there who published type SPF records only and are 
probably wondering why it's not working very well.

Personally, I'm quite surprised that doubling the DNS queries associated with 
SPF for the foreseeable future is a "meh" issue to DNS people.  

If you're going to query for type SPF, then you have to do an asynchronous 
query of some kind due to broken DNS servers that return either nothing 
(meaning you end up waiting for a timeout) or SERVFAIL for unknown types.  You 
still have to do type TXT queries and performance will suffer badly if you do 
them serially.  Additionally, we'd need to special case SERVFAIL for type SPF 
so that in appropriate temperrors weren't returned.  It adds a significant 
amount of complexity if you want to implement both types without poor 
performance (Mail::SPF does the queries sequentially and will fail on a bad 
DNS server, it's not really the model one would want).

I get the theory of type SPF, but dual types adds a lot of complexity for 
minuscule benefit.  A single type is much simpler and more reliable.  
Unfortunately, if it's only going to be one, TXT is the only one that makes 
any sense operationally.

Scott K

---

From: Mark Andrews <[email-masked]>
Date: Mon, 06 May 2013 13:51:37 +1000

> None of this happened in 8 years.  There's no basis for the next 8 years being 

Sorry that mantra doesn't cut it.

Add words to say "Namesservers SHOULD add SPF records if they
discover v=spf1 TXT records without SPF records." and it gets dead
easy to add code like this below which does it for dnssec-signzone.

The nameserver is a little more complicated but not much more.  Add
some code to UPDATE processing.  Add some code when a master zone
gets loaded.

diff --git a/bin/dnssec/dnssec-signzone.c b/bin/dnssec/dnssec-signzone.c
index 5be654d..cfb3f8c 100644
--- a/bin/dnssec/dnssec-signzone.c
+++ b/bin/dnssec/dnssec-signzone.c
@@ -1677,6 +1677,67 @@ remove_sigs(dns_dbnode_t *node, dns_rdatatype_t which) {
 	dns_rdatasetiter_destroy(&rdsiter);
 }
 
+static isc_result_t
+spfify(dns_db_t *db, dns_db_t *version, dns_dbnode_t *node) {
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_rdataset_t rdataset;
+	isc_boolean_t have_txt = ISC_FALSE;
+	isc_result_t result;
+
+	dns_rdataset_init(&rdataset);
+
+	result = dns_db_findrdataset(db, node, NULL, dns_rdatatype_spf,
+				     0, 0, &rdataset, NULL);
+	if (result == ISC_R_SUCCESS) {
+		dns_rdataset_disassociate(&rdataset);
+		return (ISC_R_SUCCESS);
+	}
+
+	result = dns_db_findrdataset(db, node, NULL, dns_rdatatype_txt,
+				     0, 0, &rdataset, NULL);
+	if (result != ISC_R_SUCCESS)
+		return (ISC_R_SUCCESS);
+
+	result = dns_rdataset_first(&rdataset);
+	while (result == ISC_R_SUCCESS) {
+		dns_rdataset_current(&rdataset, &rdata);
+		have_txt = dns_rdata_isspf(&rdata);
+		if (have_txt)
+			break;
+		dns_rdata_reset(&rdata);
+		result = dns_rdataset_next(&rdataset);
+	}
+
+	if (have_txt) {
+		dns_rdata_t spf = DNS_RDATA_INIT;
+		dns_rdatalist_t rdatalist;
+		dns_rdataset_t spfset;
+
+		dns_rdataset_init(&spfset);
+
+		dns_rdata_clone(&rdata, &spf);
+		spf.type = dns_rdatatype_spf;
+	
+		rdatalist.rdclass = spf.rdclass;
+		rdatalist.type = spf.type;
+		rdatalist.covers = 0;
+		rdatalist.ttl = rdataset.ttl;
+		ISC_LIST_INIT(rdatalist.rdata);
+		ISC_LIST_APPEND(rdatalist.rdata, &spf, link);
+		result = dns_rdatalist_tordataset(&rdatalist, &spfset);
+		if (result == ISC_R_SUCCESS) {
+			result = dns_db_addrdataset(db, node, version, 0,
+						    &spfset, 0, NULL);
+			dns_rdataset_disassociate(&spfset);
+		}
+	} else
+		result = ISC_R_SUCCESS;
+
+	dns_rdataset_disassociate(&rdataset);
+
+	return (result);
+}
+
 /*%
  * Generate NSEC records for the zone and remove NSEC3/NSEC3PARAM records.
  */
@@ -1798,6 +1859,10 @@ nsecify(void) {
 			fatal("iterating through the database failed: %s",
 			      isc_result_totext(result));
 		dns_dbiterator_pause(dbiter);
+
+		result = spfify(gdb, gversion, node);
+		check_result(result, "spfify()");
+
 		result = dns_nsec_build(gdb, gversion, node, nextname,
 					zone_soa_min_ttl);
 		check_result(result, "dns_nsec_build()");
@@ -2353,6 +2418,10 @@ nsec3ify(unsigned int hashalg, unsigned int iterations,
 		 * We need to pause here to release the lock on the database.
 		 */
 		dns_dbiterator_pause(dbiter);
+
+		result = spfify(gdb, gversion, node);
+		check_result(result, "spfify()");
+
 		addnsec3(name, node, salt, salt_length, iterations,
 			 hashlist, zone_soa_min_ttl);
 		dns_db_detachnode(gdb, &node);
diff --git a/lib/dns/include/dns/rdata.h b/lib/dns/include/dns/rdata.h
index 89ecaf8..d15b589 100644
--- a/lib/dns/include/dns/rdata.h
+++ b/lib/dns/include/dns/rdata.h
@@ -769,6 +769,9 @@ dns_rdata_makedelete(dns_rdata_t *rdata);
 const char *
 dns_rdata_updateop(dns_rdata_t *rdata, dns_section_t section);
 
+isc_boolean_t
+dns_rdata_isspf(const dns_rdata_t *rdata);
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_RDATA_H */
diff --git a/lib/dns/rdata.c b/lib/dns/rdata.c
index 2bed961..bbc2a4a 100644
--- a/lib/dns/rdata.c
+++ b/lib/dns/rdata.c
@@ -2174,3 +2174,31 @@ dns_rdata_updateop(dns_rdata_t *rdata, dns_section_t section) {
 	}
 	return ("invalid");
 }
+
+isc_boolean_t
+dns_rdata_isspf(const dns_rdata_t *rdata) {
+        char buf[1024];
+        const unsigned char *data = rdata->data;
+        unsigned int rdl = rdata->length, i = 0, tl, len;
+
+        while (rdl > 0U) {
+                len = tl = *data;
+                ++data;
+                --rdl;
+                INSIST(tl <= rdl);
+                if (len > sizeof(buf) - i - 1)
+                        len = sizeof(buf) - i - 1;
+                memcpy(buf + i, data, len);
+                i += len;
+                data += tl;
+                rdl -= tl;
+        }
+
+        if (i < 6U)
+                return(ISC_FALSE);
+
+        buf[i] = 0;
+        if (strncmp(buf, "v=spf1", 6) == 0 && (buf[6] == 0 || buf[6] == ' '))
+                return (ISC_TRUE);
+        return (ISC_FALSE);
+}

> SPF for the foreseeable future is a "meh" issue to DNS people.  

You just don't get it.  If you ask nameserver developers to HELP
you they will.

Getting code to modify zone content without a RFC saying to do it
is a uphill battle.  With a RFC it becomes a trivial exercise, "We
need to make our nameserver compliant with RFC XXXX".

> (meaning you end up waiting for a timeout) or SERVFAIL for unknown types.

And TXT is almost as equally bad as SPF.

> You 

You need to add failure code for TXT as well.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 06 May 2013 15:31:59 +1000

And if one is worried about keeping automatically generated records
in sync add "auto=yes" as the first modifier to the automatically
generated record.  The two records will remain semantically identical.

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 6 May 2013 08:06:30 +0200

> SPF for the foreseeable future is a "meh" issue to DNS people.  

Infrastructure is generally better at scaling to meet increased load
than it is at compensating for protocol ignorance.
 
Yow!  Am I in Milwaukee?

---

From: Doug Barton <[email-masked]>
Date: Sun, 05 May 2013 23:41:32 -0700

> than it is at compensating for protocol ignorance.

Not to mention that as I pointed out previously doubling the queries for
SPF (during the transition period) is in the noise when compared to all
the other DNS queries for each message received.