Subject: [dnsext] Deprecating SPF

From: David Conrad <[email-masked]>
Date: Mon, 19 Aug 2013 15:07:37 -0700

For those not on IETF-Announce/IETF lists:

Quoting The IESG ([email-masked]):
> The IESG has received a request from the SPF Update WG (spfbis) to
> consider the following document:
> - 'Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1'
>  <draft-ietf-spfbis-4408bis-19.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2013-09-02. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

If you have an opinion (which I believe some on this list do), might be worth providing it...

Regards,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 19 Aug 2013 18:20:38 -0400

> If you have an opinion (which I believe some on this list do), might be worth providing it...

If, however, you have an opinion about the deprecation of RTYPE 99
use, I'd appreciate it if you'd at least read the archives about how
the decision was made (no brickbats for David, who clearly did that
reading).  I seem to recall trying to get some interest in that
discussion back when it was happening, and nobody came.  Showing up
now with an opinion but not having read the arguments might not get a
friendly reception from Pete Resnick, the responsible AD.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 20 Aug 2013 08:00:56 +0200

On 20 aug 2013, at 00:20, Andrew Sullivan <[email-masked]> wrote:

> I seem to recall trying to get some interest in that
> discussion back when it was happening, and nobody came.

The problem is that people like me feel we have already stated our view, strongly, several times, and we give up.

People that support deprecation of RR 99 has just repeated their view that anything but TXT is useless and that as both TXT and 99 is in use, we can simply deprecate use of RR 99.

If that argument IS something IETF (including IAB) is listening to. Then who am I to say that that is an extremely bad architectural choice.

I.e.  the question is a fundamental architectural question on the DNS. Should we use different or same RR Types.

If we should use TXT and overload that RR, and IAB accepts that (even if IAB has written a document on Choices with DNS (which I was a co-author of), well, then lets do that fully, for everything.

I should btw also solve the problem with A+AAAA queries.

If we deprecate 99, we should also deprecate both A and AAAA and reuse TXT instead. That would make deployment of IPv6 easier. :-)

Yes, I think the discussion is that silly, and because of that I have given up this discussion. :-(

That said, I strongly support your comment Andrew that IF people want to go back and continue the argument, one should re-read the archives. Or else Pete (cc:ed -- for disclosure reasons, not because I ask for a reaction) will not be happy ;-)

   Patrik

P.S. Even their use of the TXT is silly, as they have first of all an RDATA field with separators. Then they say that one should either only use the first of the fields, or if there is more than one, concatenate them. After that they have an algorithm on how to extract separate fields out of that one field (where they already removed the field separators). The silliness does not stop...it just goes on and on and on.

---

From: Alex Bligh <[email-masked]>
Date: Tue, 20 Aug 2013 07:55:37 +0100

> If that argument IS something IETF (including IAB) is listening to. Then who am I to say that that is an extremely bad architectural choice.

+1. The same argument could be used to recommend deprecating IPv6 in favour of IPv4.

-- 
Alex Bligh

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 20 Aug 2013 10:00:56 -0400

Patrik Fältström writes:
> The problem is that people like me feel we have already stated our
> view, strongly, several times, and we give up. 

Indeed. And because it was evident that no headway was being made by
either side, some of us (me, at least) just sat out.  I read through
all of the arguments as they were happening.  I appreciate the tension
between easy pragmatism and clean design and thought that, amidst the
usual snarking, good points were made on both sides.  Personally, I
support continued migration from TXT to SPF, but openly acknowledge
that was the bias I had when the issue first arose, and the debate
didn't change my mind either.

I didn't contribute then because I didn't think there were any useful
additional points to be made.  I'm wondering now why I'm even writing
this message, because it too doesn't contribute much useful to the
discussion.  Maybe on some level it is useful to hear ongoing
frustration that the process of the Internet Engineering Task Force
does not produce good engineering.  On the other hand I have little
doubt that some people reading this think the preceding sentence is
just sour grapes from ending up on the losing side of the debate and
they think the engineering is just fine.

Net result: some of us give up before we even start.

---

From: [email-masked]
Date: Tue, 20 Aug 2013 14:03:48 +0000

> If we deprecate 99, we should also deprecate both A and AAAA and reuse TXT instead. That would make deployment of IPv6 easier. :-)

	interestingly, we find here in the DNS, the problem of multiplexing.
	historically, such use in the DNS triggers "additional section processing"
	which has been considered a very poor choice for decades.

	outside the DNS, we have IP address multiplexing and port multiplexing,
	as ways to extend the lifetime of the IPv4 space, (NAT, CGN, ad nausea)...

	so its clear that parts of the community -really- want to do things the 
	hard way, simply because the first steps look -so- easy.

	Admiral Ackbar said it best.

	That out of the way, apparently the IAB has no problems documenting use/practice.

	So there are two varients,  16 and 99.  Fine.  

	If I were to recommend any further action, it would be to insist that all SPF
	ID's/RFC's carry some boilerplate text along the lines of:

	"Type 16 (TXT) stores arbitrary text in a DNS record. Since the early 1990s, 
        this record often carries protocol specific  data, such as specified by RFC 1464, 
        opportunistic encryption, Sender Policy Framework, DKIM, DMARC, DNS-SD, etc. 
	Applications which use type 16 instead of their own RR type MUST NOT presume
	that only thier data structures are present.  They SHOULD use application specific
	RR types when available."

/bill

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 20 Aug 2013 07:10:29 -0700

Probably stupid question:

I assume that a key reason for some part of the community preferring TXT
records is that they allow to quickly adopt them because it is possible to
configure them on any existing DNS server. Are there any examples of DNS
servers that allow to define new RR types and some value encoding - without 
having to wait for a software upgrade of the DNS server software. Likewise,
are the DNS client APIs where the apps can leverage new RR types unknown at
the time the client SDK was written.

Cheers
    Toerless

On Tue, Aug 20, 2013 at 08:00:56AM +0200, Patrik F?ltstr?m wrote:
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!

---

From: [email-masked]
Date: Tue, 20 Aug 2013 14:19:24 +0000

Steve Hotz and I designed and built a DNS server platform that supported loadable
 DNS attributes including RR types.  I don't know of any production systems that support
 that however.

/bill

---

From: Jason Fesler <[email-masked]>
Date: Tue, 20 Aug 2013 07:22:39 -0700

On Tuesday, August 20, 2013, Toerless Eckert wrote:

> Are there any examples of DNS
> having to wait for a software upgrade of the DNS server software.

djbdns has a mechanism for this.  "Handy" for AAAA records...

-- 
 Jason Fesler, email/jabber <[email-masked]> resume: http://jfesler.com
 "Give a man fire, and he'll be warm for a day;
 set a man on fire, and he'll be warm for the rest of his life."

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 20 Aug 2013 10:42:11 -0400

On Tue, Aug 20, 2013 at 08:00:56AM +0200, Patrik Fältström wrote:
> 
> People that support deprecation of RR 99 has just repeated their
> view that anything but TXT is useless and that as both TXT and 99 is
> in use, we can simply deprecate use of RR 99.

I think that is a gross caricature of what the proponents of
deprecation have argued.  It's easy to knock down a straw person.

The argument is instead that the overwhelming majority of actual
deployed uses are either using TXT or are using both TXT and SPF.
Virtually nobody is using SPF only.  Therefore, regardless of what
4408bis said, it would have to continue to support TXT.  If it were
altered to require SPF lookup first, then it would, at day 1,
immediately impose almost totally useless query load for every SPF
attempt.  If it were altered to require TXT lookup first, then there
would be no reason at all ever to move to the SPF type.  Moreover,
either strategy would require additional complexity (the fallback
rules) for SPF validators, and it would require additional
specification of what a server was supposed to do in the case where
the TXT record and the SPF record didn't agree; this would make the
specification more complex, too.

For all those reasons, it seemed to the WG that the dual-RRTYPE
strategy that was used for SPF was a mistake, and that it should be
removed.  This is not a precedent or a general engineering point
(unless you mean the more general point that the IETF and IAB ought to
work hard and convincing people not to use unscoped TXT records for
application data (i.e. without an underscore label) even during
prototyping.  But the IAB has already published that advice).

> If we deprecate 99, we should also deprecate both A and AAAA and reuse TXT instead. That would make deployment of IPv6 easier. :-)

This doesn't follow, because it's merely a contingent fact that SPF
was originally developed using the TXT record at the target name.
People no longer do that, unless they're named "Google", it seems.

> P.S. Even their use of the TXT is silly, as they have first of all
> an RDATA field with separators. Then they say that one should either
> only use the first of the fields, or if there is more than one,
> concatenate them. After that they have an algorithm on how to
> extract separate fields out of that one field (where they already
> removed the field separators). The silliness does not stop...it just
> goes on and on and on.

Sure.  But the plain fact is that this protocol, with all its
stupidity and weaknesses, is widely deployed on the Internet.  Indeed,
there's a case to be made that it is at least as successful as DNSSEC
and more successful than IPv6.  For that reason, it seems churlish not
to standardize it.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 20 Aug 2013 16:41:52 +0200

Yes. I'm one of those.

	jaap

---

From: Joe Abley <[email-masked]>
Date: Tue, 20 Aug 2013 10:50:31 -0400

> having to wait for a software upgrade of the DNS server software.

Yes, including BIND9 which is probably the most widely-deployed DNS server software.

But my vague recollection is that this is not supported by Microsoft's DNS server implementation on Windows, and since many Windows environment are tied to that implementation because of requirements to use Active Directory, and since many people have mail systems running on Windows, TXT was a pragmatic path forward.

RFC 3597 may be worth a look if you are interested.

Joe

---

From: Jay Ashworth <[email-masked]>
Date: Tue, 20 Aug 2013 10:54:13 -0400 (EDT)

----- Original Message -----
> From: "Joe Abley" <[email-masked]>

> But my vague recollection is that this is not supported by Microsoft's
> DNS server implementation on Windows, and since many Windows
> environment are tied to that implementation because of requirements to
> use Active Directory, and since many people have mail systems running
> on Windows, TXT was a pragmatic path forward.

Probably worth noting, too, that *LOTS* of people interact with DNS through
webhost control panels; those, too, would have to accept as valid a new
record type: if it's not on the pull-down menu, you can't add it.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       [email-masked]
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 Aug 2013 01:00:41 +1000

> having to wait for a software upgrade of the DNS server software.

Yes.  Named has supported unknown records for over a decade now.

All the tools that ship with named support unknown records.  The
only reason there wasn't support earlier is that there wasn't a
agreeded apon master file format.

B.T.W. people have added private types to named in the past. Any
semi competant C programmer can.  Named was designed to make adding
new types easy.  You don't even need to fiddle with Makefiles.  Just
add the .c and .h files that describe how to parse and print the
text format and wire formats.  There is plenty of example code
with all the other types.

As for adding SPF to named it was:

cp lib/dns/rdata/generic/txt_16.c lib/dns/rdata/generic/spf_99.c
cp lib/dns/rdata/generic/txt_16.h lib/dns/rdata/generic/spf_99.h

change all the "txt" to "spf" in the method names.
change all the type checks to 99 instead of 16.

make clean; make; make install

Once that was done all the tools supported SPF. dig, host, nslookup,
nsupdate, dnssec-signzone etc.

> Likewise,

Libresolv/libbind written in the 1980's supported unknown types.
It is still shipped with unix based systems.  Unfortunately that
doesn't help because unless you have the mnemonic in a header
file people won't use it.

http://www.ietf.org/mail-archive/web/spfbis/current/msg00645.html

	n = res_query(name, C_IN, 99, buf, sizeof(buf));

was all that was needed for unix / linux machines to make SPF lookup
but that wasn't enough. 

The libraries named is currently built upon support unknown query
types.

Support for looking up unknown types in resolvers libraries was a
requirement of RFC 1034.

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

---

From: Pete Resnick <[email-masked]>
Date: Tue, 20 Aug 2013 10:05:14 -0500

> The problem is that people like me feel we have already stated our view, strongly, several times, and we give up.

As far as I can tell, the views that you state below (and I don't 
remember views stated earlier) have *nothing* to do with the deprecation 
of RR 99 issue. What you are saying is that the original use of TXT was 
wrong. I probably agree with that, but that's not relevant to the 
current discussion. The question is whether the deprecation of 99 is 
appropriate, and if not what the document should do instead.

> People that support deprecation of RR 99 has just repeated their view that anything but TXT is useless and that as both TXT and 99 is in use, we can simply deprecate use of RR 99.

I have not heard that argument being used, and certainly have not heard 
that this is what the chairs have based their call of consensus on. If 
you have examples of messages where this was the basis for the 
deprecation, I would like pointers to those messages.

> I.e.  the question is a fundamental architectural question on the DNS. Should we use different or same RR Types.

Again, that is not the argument. There is vast agreement that using a 
new RR and not overloading TXT is the better architectural decision.

The question is about a currently deployed protocol. It is using TXT 
records. It was written into an Experimental RFC quite some time ago 
that it should transition to SPF records. It provided a transition plan 
that, in practice, has failed to date. In fact, the transition plan 
introduced an interoperability problem. So the question is how to 
address that. There were several choices:

- Let the transition plan run longer; it will work in the end
- Fix the transition plan to a use a different algorithm and let that 
run for a while
- Declare a flag day and say that TXT is no longer supported by the protocol
- Declare failure of the transition and say that SPF is no longer 
supported by the protocol

Each of these (well, maybe except the 3rd one) was seriously considered 
and discussed in the WG. The arguments used to defend the first two were 
not convincing to the WG. The third was a non-starter. They landed on 
the last choice.

If you have a more convincing case for any of the above, you should be 
stating it. If you have an proposal that hasn't been heard, you should 
be stating it. But going back to first principles and saying the 
protocol should not have used TXT in the first place is not helpful to 
me or the chairs figuring out the consensus. I'm happy to grant that TXT 
should not have been used in the first place; so what? What does that 
tell me about what should be done now with a deployed base?

> If we should use TXT and overload that RR, and IAB accepts that (even if IAB has written a document on Choices with DNS (which I was a co-author of), well, then lets do that fully, for everything.

OK, we should not use TXT and overload it from now on. What do we do now 
with this protocol?

> If we deprecate 99, we should also deprecate both A and AAAA and reuse TXT instead. That would make deployment of IPv6 easier. :-)

<sarcasm>Oh? Is there a large deployed base of TXT records for A and 
AAAA records in use? We should figure out what to do about that.</sarcasm>

> Yes, I think the discussion is that silly, and because of that I have given up this discussion. :-(

The A/AAAA discussion is silly, but it's because it has nothing to do 
with the question on the table. The question on the table regards what 
to do with the currently deployed protocol that made a poor decision 
some time ago (and one that would likely not have to be made today 
because the ecosystem is different). What should be done *in that protocol*?

(The idea is not to "win" or "lose" the argument; this is not a debating 
society. The idea is to explain and convince people who have made an 
error in a technical choice. You seem to believe that the wrong 
technical choice was made by this WG. What was that error and why should 
they have chosen something different?)

pr

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

---

From: Carsten Strotmann <[email-masked]>
Date: Tue, 20 Aug 2013 16:57:45 +0200

Hi,

Joe Abley wrote:

> But my vague recollection is that this is not supported by
> Microsoft's DNS server implementation on Windows, and since many
> Windows environment are tied to that implementation because of
> requirements to use Active Directory, and since many people have mail
> systems running on Windows, TXT was a pragmatic path forward.
> 

I did some tests on Windows 2008 (R2) in 2009 or 2010 and found that the
Microsoft server does support RFC 3597 for zones loaded from a master
(by zonetransfer) or from a masterfile, but there is no way to add or
edit the data through the GUI (if is however possible to add the records
to a plain text DNS master file using a text editor, if I remember
correctly). I haven't tested zones stored in Active Directory.

- -- Carsten

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 20 Aug 2013 17:17:59 +0200

> deployed uses are either using TXT or are using both TXT and SPF.

Absolutely understood, as all examples in for example the RFC in question is using TXT (except one, that show how to handle the case when using TXT and SPF).

And the fact people use both TXT and SPF is to me an indication the migration plan works, and that the fix should be to clarify how to continue that migration given that we have what I would call an unclear paragraph exists in the original RFC.

YMMV, which is obvious, as the consensus in the wg is to deprecate SPF RR Type according to the wg chair. Otherwise there should not be this I-D on the table.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 20 Aug 2013 17:28:19 +0200

On 20 aug 2013, at 17:05, Pete Resnick <[email-masked]> wrote:

> You seem to believe that the wrong technical choice was made by this WG. What was that error and why should they have chosen something different?

The consensus related to how to fix RFC 4408 will be very rough. That is clear. And I feel sorry for responsible AD and IESG to be forced to make a decision that such a large rough part of the rough consensus will not be happy with. Regardless of what the decision will be.

An architectural correct solution is to change:

OLD:

   An SPF-compliant domain name SHOULD have SPF records of both RR
   types.  A compliant domain name MUST have a record of at least one
   type.  If a domain has records of both types, they MUST have
   identical content.

NEW:

   An SPF-compliant domain name SHOULD have SPF records of both RR
   types.  A compliant domain name MUST have a record of at type SPF,
   code 99.  Lookup MUST first be of type SPF and SHOULD if no response
   is received be of type TXT.

Reasoning: The use of the TXT record for SPF is not sounds for a number of reasons:

1. The TXT record already can have multiple fields, and it is very unfortunate that the SPF use of TXT records do not use that feature. Instead the SPF specification do say that the first field should be used, and if there are more than one they should be concatenated. After one have one and only one field, that field should be parsed and divided in fields.

2. It is even (compared to some other TXT related documents) pointed out in RFC 4408 that collisions as described in RFC 5507 might happen.

3. It is also pointed out that there might be size issues with the records, and experience from use of NAPTR show that selecting a preferred mechanism that potentially blows the size of the RRSet is not very wise. This is btw why the URI RR Type do not use a prefixed length "text" field in the RDATA but do set the string the URI is to the full length of the RDATA, i.e. without any 255 byte limitation.

4. DNS is by design (as pointed out in RFC 5507) created with a tuple consisting of owner, type and class for selection by the client what record set to be retrieved. This RRSet architecture is something that comes back not only in the query/response architecture of the DNS protocol, but also in the DNSSEC architecture where RRSets are the units that are signed. Not explicitly ensuring an RRSet is used for SPF (and nothing more) is an architectural choice I strongly am against.

Because of these reasons, I do believe the choice is wrong to say that TXT MUST be implemented and instead I am in favor of having type SPF be mandatory for interoperability with fallback to lookup of TXT.

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 20 Aug 2013 11:36:56 -0400

On Tue, Aug 20, 2013 at 05:17:59PM +0200, Patrik Fältström wrote:
> 
> And the fact people use both TXT and SPF is to me an indication the
> migration plan works, and that the fix should be to clarify how to
> continue that migration given that we have what I would call an
> unclear paragraph exists in the original RFC.

RFC 6686 tells us the extent to which people are "using both".  see
section 3.1.  No survey was able to find people "using both" at even
2% of all the domains surveyed.  SPF records using TXT ranged between
just under 40% to more than 50%.  I find it hard to interpret that
data as an indication that the migration plan is having any real
effect at all.

I don't think anyone can accuse me of being sanguine about the
overloading of TXT.  But the IETF is made ridiculous if it stands
around trying to tell the sea to stay back.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 20 Aug 2013 16:11:02 -0000

>the time the client SDK was written.

Most DNS servers let you stick in unknown RRs using generic hex or
octal values.  I've written preprocessors to massage zone info to
handle RRs that my server doesn't, and I'm sure I'm not the only one.

Vixie and I have a proposal to publish the syntax of new RRs in the
DNS itself, both so that DNS servers can automatically configure, but
equally importantly, so the configuration web crudware that most
people use to manage their DNS info can automatically configure as
well.  It's not a complete solution, since it can't handle major
changes like DNSSEC that require semantic changes to the DNS servers
and caches, but for the large majority of RRs that are just RRs, it
seems useful to me.

It got a surprisingly hostile reaction here, but people are interested
in appsarea.  The draft is  draft-levine-dnsextlang-06

R's,
John

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 20 Aug 2013 09:11:33 -0700

Any URL that would easily explain how to configure an "unkown" record
without having to start doing C-programming ?

Of course, if there was a stanardized definitoin file one could drop into
arbitrary DNS servers to define both name of new RR types and their 
value encoding, then new RRs could be easier to use than more obfuscated TXT
encoding of new data. As long as its not really easier to do for folks
who do not want/can-not update their DNS software, i can see the appeal
of TXT.

Cheers
    Toerless

P.S.: COmpiling new bind does certainly not fall into the ubiquitously
accepted realm of "ease-of-use", even though i'd certainly have fun with it ;-)

---

From: Joe Abley <[email-masked]>
Date: Tue, 20 Aug 2013 12:15:29 -0400

> without having to start doing C-programming ?

Yes, again, RFC 3597.

> who do not want/can-not update their DNS software, i can see the appeal

Or a trivial preprocessor which could interpret current, modern RRTypes and output 3597-compliant opaque types for any RRType that was not in the base specification.

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 20 Aug 2013 09:26:09 -0700

Thanks, John. Sounds like a necessary direction to make new record types
really easily useable.  Any summary how the programmatic API on the
client side would be abel to benefit from this approach ?

What data types did you define ? Something similar to what JSON could express ?

Cheers
    toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 20 Aug 2013 09:29:06 -0700

Thanks. I should read through that. ALways interested how operationally
difficult/easy it would be to introduce SSM channel address RRs, which would
be AA (S,G - IPv4) and AAAAAAAA (S,G IPv6) ;-))

Cheers
    Toerless

---

From: "John R Levine" <[email-masked]>
Date: 20 Aug 2013 12:51:13 -0400

> What data types did you define ? Something similar to what JSON could express ?

The draft is  draft-levine-dnsextlang-06.  It's not very long.

I went through all of the existing RRs, and defined types for all of the 
field types that seemed useful in new RRs.

R's,
John

>> in appsarea.  The draft is  draft-levine-dnsextlang-06

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 20 Aug 2013 19:06:42 +0200

> Or a trivial preprocessor which could interpret current, modern RRTypes and output 3597-compliant opaque types for any RRType that was not in the base specification.

One can also compare number of lines for this pre processor with number of lines for implementing the rest of the SPF specification.

   Patrik

---

From: Michael Sinatra <[email-masked]>
Date: Tue, 20 Aug 2013 10:16:49 -0700

> around trying to tell the sea to stay back.

There seems to be an unstated philosophical argument about what the role
of the IETF should be.  It's like the perennial prescriptive/descriptive
argument that dictionary-writers have.

Should the role of the IETF be to describe implemented standards or
should it be to prescribe new or evolved standards?  Should it be trying
to push SPF in a slightly-different direction or should it be trying to
maximize the *current* (short-term?) utility and interoperability of SPF?

As someone who is primarily an operator, I want to trust the IETF to
prescribe a standard--or be willing to prescriptively modify a
standard--that is architecturally optimal, while not ignoring
operational realities.  Maybe I am just being lazy.

There's no question that some honest mistakes have been made in previous
standards that attempted to be too architecturally "pure" and ignored
the issues that that architectural purity created with respect to
implementation and operations.  The IETF got treated unnecessarily badly
in the ops community for this, IMO.

At the same time, I don't think the answer is to err on the descriptive
side.  Some compromise between description and prescription ought to be
possible.  There may be other issues within the SPFBIS effort where
there is more of a prescriptive/descriptive balance, but in the case of
RRTYPE 99, it seems that the IETF is taking a very descriptive approach.
 In reading through the archives, both recently and last September when
this issue arose here, it's clear that many people believe that
overloading of TXT is a bad idea, but they believe that this is reality
and it's not really the IETF's job to say what should be done.  I don't
totally agree with that because that's not how I view the IETF's role.

In other words, to my inexperienced eyes, there is a lot of room between
trying to tell the sea to stay back and deprecating RRTYPE 99.  But Pete
and Andrew are much deeper in the SPFBIS effort than I am, and I don't
envy them as they try to walk the line in getting this draft shepherded
and published.

As for my own opinion, I think the use of the TXT record by SPF has
always looked kludgy to me and has made me consistently reluctant to
adopt SPF.  It has also made me push back against implementing it for
others, unless it turns out to be absolutely necessary to prevent
someone's mail from being rejected.

michael

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Aug 2013 17:33:39 +0000

> maximize the *current* (short-term?) utility and interoperability of SPF?

I don't think either of these dichotomies captures the tension that is being addressed in this particular case.   In this particular case, spfbis considered at length whether the IETF _could_ do the architecturally clean thing here, and concluded that we could not.

So the dichotomy you want here is, does the IETF propose a standard _knowing full well that nobody will ever implement it_, or does the IETF try for a substantial functional improvement to a standard that people have already shown they will implement?

The architecturally clean thing to do here is to get rid of SMTP, which is a protocol designed for a gentler time, and is ill-suited to the current Internet, with its spammers and botnets and snoops (oh my!).   If you are interested in architectural hygiene, get to work on that, and stop wasting your energy fussing about the relative ugliness of two ugly band-aids, one of which spfbis decided to deprecate, the other of which they decided to keep.

---

From: Mark Elkins <[email-masked]>
Date: Tue, 20 Aug 2013 19:37:13 +0200

> Because of these reasons, I do believe the choice is wrong to say that TXT MUST be implemented and instead I am in favor of having type SPF be mandatory for interoperability with fallback to lookup…

I agree with what you say.

I run a small ISP business. Out of 849 domain running full DNS locally, 
9 have SPF records of which 4 are TXT records only, the other 5 have
both SPF and TXT records.  Both my Virtual-Web interface control panel
(a home-grown affair) and the machines local Nameserver (BIND - for
now...) support the SPF record.
I'm now plotting to automatically create the SPF record equivalent if
the customer creates a TXT based SPF record.
-- 
  .  .     ___. .__      Posix Systems - (South) Africa
 /| /|       / /__       [email-masked]  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 20 Aug 2013 13:49:15 -0400

On Tue, Aug 20, 2013 at 05:33:39PM +0000, Ted Lemon wrote:

> The architecturally clean thing to do here is to get rid of SMTP, which is a protocol designed for a gentler time

And, while you're at it, you might want to tackle DNSng, too.  What
the heck?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Tue, 20 Aug 2013 11:12:04 -0700

> So the dichotomy you want here is, does the IETF propose a standard _knowing full well that nobody will ever implement it_, or does the IETF try for a substantial functional improvement to a standa…

Dear Ted,

Should the IETF protect current infrastructure from being degraded by expediency hacks, or should the IETF insist in having compatible (less threatening) approaches.  Otherwise, why bother with the IETF where then anything can be called authentication?

Never mind SMTP.  BGP, DNS, and CAs can't be trusted either.  Employing DNSsec, DANE, and StartTLS should help restore sanity and security.

The mess caused by SMTP will get uglier if one ineffective bandaid is applied one on another under the guise of standardization.  Frankly, the APL RR defined well ahead of SPF offers a far safer and more effective solution.  Even the "policy" asserted by SPF is often ignored due to an endless number of exceptions with typical use.  Also considering the security issues related with amount of specialized code mandated to support SPF macros used by 0.053% of the domains and ignored by  large providers means retaining this feature will degrade and not enhance interchange.  This is a process wedged on top of DNS that does not even understand the difference between a DNS message and a UDP packet.

Regards,
Douglas Otis

---

From: S Moonesamy <[email-masked]>
Date: Tue, 20 Aug 2013 11:36:55 -0700

Hi Patrik,

I am copying the message to ieft@ as there is an ongoing Last Call.

At 08:28 20-08-2013, Patrik Fältström wrote:
>The consensus related to how to fix RFC 4408 
>will be very rough. That is clear. And I feel 
>sorry for responsible AD and IESG to be forced 
>to make a decision that such a large rough part 
>of the rough consensus will not be happy with. 
>Regardless of what the decision will be.
>
>
>1. The TXT record already can have multiple 
>fields, and it is very unfortunate that the SPF 
>use of TXT records do not use that feature. 
>Instead the SPF specification do say that the 
>first field should be used, and if there are 
>more than one they should be concatenated. After 
>one have one and only one field, that field 
>should be parsed and divided in fields.
>
>2. It is even (compared to some other TXT 
>related documents) pointed out in RFC 4408 that 
>collisions as described in RFC 5507 might happen.
>
>3. It is also pointed out that there might be 
>size issues with the records, and experience 
>from use of NAPTR show that selecting a 
>preferred mechanism that potentially blows the 
>size of the RRSet is not very wise. This is btw 
>why the URI RR Type do not use a prefixed length 
>"text" field in the RDATA but do set the string 
>the URI is to the full length of the RDATA, i.e. 
>without any 255 byte limitation.
>
>4. DNS is by design (as pointed out in RFC 5507) 
>created with a tuple consisting of owner, type 
>and class for selection by the client what 
>record set to be retrieved. This RRSet 
>architecture is something that comes back not 
>only in the query/response architecture of the 
>DNS protocol, but also in the DNSSEC 
>architecture where RRSets are the units that are 
>signed. Not explicitly ensuring an RRSet is used 
>for SPF (and nothing more) is an architectural choice I strongly am against.
>
>
>Because of these reasons, I do believe the 
>choice is wrong to say that TXT MUST be 
>implemented and instead I am in favor of having 
>type SPF be mandatory for interoperability with fallback to lookup of TXT.

 From Section 3.1 of draft-ietf-spfbis-4408bis-19:

   "SPF records MUST be published as a DNS TXT (type 16) Resource Record
    (RR) [RFC1035] only.  The character content of the record is encoded
    as [US-ASCII].  Use of alternative DNS RR types was supported in
    SPF's experimental phase, but has been discontinued."

There is a message from Pete Resnick about RFC 
2119 usage ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03642.html 
).  The interpretation of "SHOULD" and MUST" in 
that part of RFC 4408 was an issue which the SPFBIS WG discussed about.

It would be better to have the discussion on the 
ietf@ mailing list as that's the venue which the 
IESG identified for last Call comments.

Regards,
S. Moonesamy

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 20 Aug 2013 20:45:23 +0200

On 20 aug 2013, at 20:36, S Moonesamy <[email-masked]> wrote:

> It would be better to have the discussion on the ietf@ mailing list as that's the venue which the IESG identified for last Call comments.

Understood, and thanks.

The reason why I did not post there at first was that a) I did not feel I had followed the rules laid out for discussions [read all messages in the mailing list archives] and b) the discussion on the dnsext list was more general on overload of TXT records [something DNS people have always been against -- see IAB document on DNS choices].

But, when having that discussion on the dnsext mailing list, to which I cc:ed Pete as responsible AD for full disclosure, Pete did ask me for a complete explanation of my view, which I posted.

Once again, without re-reading the mailing list archives.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 20 Aug 2013 20:58:10 +0200

As the bottle is opened, I hereby state my objection to Section 3.1 of draft-ietf-spfbis-4408bis-19 for the reasons explained below. I do agree (as stated below) that the section of RFC 4408 that specify how to use both SPF and TXT resource record types include an error as it does not lead to interoperability.

As the intention with use of both TXT and SPF originally was to migrate from TXT to SPF I instead of what is outlined in the draft suggest that a proper migration strategy is laid out (look up mandatory to implement SPF and fall back to TXT). This instead of deprecation of the SPF record.

In general I do believe, for example when looking at IPv6 and DNSSEC and similar technologies, that the lifetime of RFC 4408 is too short to deprecate any of the proposed records that are in use, specifically as RFC 4408 explicitly do allow use of both.

   Patrik

On 20 aug 2013, at 20:36, S Moonesamy <[email-masked]> wrote:

> There is a message from Pete Resnick about RFC 2119 usage ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03642.html ).  The interpretation of "SHOULD" and MUST" in that part of RFC 4408 was an issue which the SPFBIS WG discussed about.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 20 Aug 2013 15:23:43 -0400

> maximize the *current* (short-term?) utility and interoperability of SPF?

The question that needs to be asked but isn't is 'what role do the
governance structures permit'?

he IAB is tasked with architecture but does not solicit or build consensus
for its architectural proposals. Which is why Patrik's DNS options proposal
was stillborn.

That IAB is not elected by the IETF membership or accountable to it. So the
IETF feels no obligation to follow the guidance it attempts to give. Worse,
the old boys club method of selection ensures that members are picked for
the conformity rather than the novelty of their views. So it tends to be a
reactionary body.

In the case of Patrik's RFC, there were many problems:

1) The SPF Working Group was justifiably peeved by the attempt by the
DNSEXT group to trump their work by presenting their opinion in the form of
an IAB ultimatum.

2) The RFC is broken. It makes assertions that are demonstrably untrue and
makes erroneous conclusions.

3) The method of extension proposed is obviously unscalable as there are
only 65535 possible RRs and far more Web Services requiring discovery.

4) The draft does not acknowledge the fact that at the time it was written
one of the principle DNS servers in use could not in fact support unknown
RR types.

5) The document does not admit that the real agenda was to push through the
infrastructure needed to support DNSSEC.

The last was subject to a long dispute between the SPF group and the DNS
WG. At one point Microsoft presented the actual code for their DNS server
and showed that it absolutely does not have the ability to save a zone
file. Despite this DNSEXT members continued to insist that black was white
and Microsoft's DNS server could be used to serve unknown DNS RRs based on
the fact that one of them had written some sort of script that could
somehow wedge them into the cache. A hack that any network manager using it
should be sacked for touching since it was clearly not maintainable.

Having watched the interaction between the SPF and DNSEXT WGs, this outcome
is no surprise to me. Indeed it was inevitable.

We should have a proper IAB that comes out with architectural guidance so
we don't have six different WGs make six different decisions on how to do
the same thing. But that can only work if the process delivers a result
that has widespread consensus. Which is not going to happen if the process
is that an elite club meets in secret and issues edicts.

The IETF mission statement is botched. The mission of the IETF is not to
produce documents, they are only a byproduct. The mission of the IETF is to
produce consensus.

The reason I am peeved by the CBOR fiasco is that we have a situation where
we need a common approach but the mechanism chosen ensures that the chosen
winner has no consensus and will thus be ignored.

We do need a proper discovery architecture. One that makes it possible to
discover policy information as part of the discovery process. The DNS
options draft was a missed opportunity in that respect.

I have suggested to Patrik on several occasions that we extend his URI
discovery proposal to allow policy attributes to be included in the URI
specification. But never received an answer.

-- 
Website: http://hallambaker.com/

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 20 Aug 2013 21:29:42 +0200

On 20 aug 2013, at 21:23, Phillip Hallam-Baker <[email-masked]> wrote:

> I have suggested to Patrik on several occasions that we extend his URI discovery proposal to allow policy attributes to be included in the URI specification. But never received an answer.

My apologies for you believing the ball is on my side of the courtyard.

I did think it was up to you to "send text".

I am taking this offline. It is not related to this SPF discussion.

   Patrik

---

From: S Moonesamy <[email-masked]>
Date: Tue, 20 Aug 2013 12:30:48 -0700

Hi Patrik,
At 11:45 20-08-2013, Patrik Fältström wrote:
>The reason why I did not post there at first was 
>that a) I did not feel I had followed the rules 
>laid out for discussions [read all messages in 
>the mailing list archives] and b) the discussion 
>on the dnsext list was more general on overload 
>of TXT records [something DNS people have always 
>been against -- see IAB document on DNS choices].
>
>But, when having that discussion on the dnsext 
>mailing list, to which I cc:ed Pete as 
>responsible AD for full disclosure, Pete did ask 
>me for a complete explanation of my view, which I posted.
>

First of all, I apologize for copying the message 
to ietf@.  The advice given was to read the 
comments in the SPFBIS mailing list archives.  It 
is not a rule.  If a person did not read all the 
messages and the person raises a point or 
provides arguments which were not discussed 
previously I will ask the SPFBIS WG to address them.

I don't know whether to process your comments or 
the other comments posted on dnsext@ as part of 
the Last Call or not.  It is unclear to me as to 
whether I should only consider messages with the 
appropriate Last Call subject line.  My sense is 
that I should listen to your concerns.

Regards,
S. Moonesamy

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 20 Aug 2013 21:37:15 +0200

On 20 aug 2013, at 21:30, S Moonesamy <[email-masked]> wrote:

> First of all, I apologize for copying the message to ietf@.

No apology needed.

> I don't know whether to process your comments or the other comments posted on dnsext@ as part of the Last Call or not.  It is unclear to me as to whether I should only consider messages with the appropriate Last Call subject line.  My sense is that I should listen to your concerns.

I was the one making mistakes.

Mea culpa.

   Patrik

---

From: Michael Sinatra <[email-masked]>
Date: Tue, 20 Aug 2013 13:04:20 -0700

On Tue, Aug 20, 2013 at 05:33:39PM +0000, Ted Lemon wrote:

> So the dichotomy you want here is, does the IETF propose a standard
> _knowing full well that nobody will ever implement it_, or does the
> IETF try for a substantial functional improvement to a standard that
> people have already shown they will implement?

You're right; I was trying to proffer a false dichotomy to show that the
answer is somewhere in the middle, but that wasn't laid out in the
questions I was asking.  (It was hinted in my statement about
"architectural purity.")

The (false) dichotomy ought to represent both extremes, knowing that the
correct answer is somewhere in the middle. In other words: Should the
IETF propose a standard _knowing full well that nobody will ever
implement it_, or should it describe as a standard what lots of people
are doing now, no matter how broken or unsustainable the current
behavior is?

I am NOT arguing that SPFBIS, even as currently proposed with the RRTYPE
99 deprecation, is close to either extreme.  However, I am concerned
when I hear lots of people--here and in the SPFBIS archives--state that
they don't like the txt record, but they think that the IETF will get
laughed at/sneered at/ignored if it tries to transition to the SPF
record.  I don't quite agree with that--I think there is more middle in the
middle ground.  If that were the only consideration that the WG gave to
the topic, then I would disagree.  As it is, I am merely concerned.

I am not interested in the "architecturally clean" solution.  Apologies
if that didn't come through in my message.

michael

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 20 Aug 2013 16:23:55 -0400

My apologies, seems like we had a miscommunication and Patrick was waiting
for input from me. Taking that discussion offline.

On Tue, Aug 20, 2013 at 3:23 PM, Phillip Hallam-Baker <[email-masked]>wrote:

> That IAB is not elected by the IETF membership or accountable to it. So
> the IETF feels no obligation to follow the guidance it attempts to give.
> Worse, the old boys club method of selection ensures that members are
> picked for the conformity rather than the novelty of their views. So it
> tends to be a reactionary body.
>
> 5) The document does not admit that the real agenda was to push through
> the infrastructure needed to support DNSSEC.
>
> Having watched the interaction between the SPF and DNSEXT WGs, this
> outcome is no surprise to me. Indeed it was inevitable.
>
>
> The reason I am peeved by the CBOR fiasco is that we have a situation
> where we need a common approach but the mechanism chosen ensures that the
> chosen winner has no consensus and will thus be ignored.
>
>

---

From: David Conrad <[email-masked]>
Date: Tue, 20 Aug 2013 13:54:15 -0700

Ted,

> I don't think either of these dichotomies captures the tension that is being addressed in this particular case.   In this particular case, spfbis considered at length whether the IETF _could_ do th…

I am honestly curious how such a conclusion could possibly be reached.  

I can easily see an argument that it might take a long time or that "legacy TXT" will always be with us (just as IPv4 will always be with us), but a better migration strategy, one that numerous people including Mans, Patrik, and others have already mentioned, would, I believe, allow for a transition to SPF over time.

Can you provide a pointer to where in the 28MBytes of mailing list archives the SPFBIS working group justified that it was impossible to transition? I've read the entire archives a couple of times now and don't recall the definitive objective arguments.

> already shown they will implement?

False dichotomy.

People have already implemented SPF RRs. As far as I know, all popular name servers already support the SPF RR type in one form or another.  I am aware of multiple UIs that allow for SPF RRs to be entered and I know from personal experience that there are SPF validators that will make use of SPF RRs: not having followed the 4408{,bis} discussions, when I set up SPF on my personal domain a while back, I naively used the SPF RR (didn't occur to me to use TXT). I noticed in my logs that people were querying for my SPF records.

What folks are suggesting is that the SPFBIS working group _fix the migration strategy_.  As far as I can tell, no one thinks the 4408bis approach is a good idea, rather it is justified as being pragmatic. I'm unsure why the SPFBIS believes the time for migration is now over and that the Internet community must abandon the effort to replace TXT with SPF, permanently embedding a hack and forcing every other application that might want to use TXT at the zone apex either now or in the future to deal with strings that start with "v=spf".

> The architecturally clean thing to do here is to get rid of SMTP, which is a protocol designed for a gentler time, and is ill-suited to the current Internet, with its spammers and botnets and snoop…

I suspect it might take significantly longer to transition away from SMTP than to migrate from TXT to SPF.

Regards,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 20 Aug 2013 17:15:21 -0400

On Tue, Aug 20, 2013 at 01:54:15PM -0700, David Conrad wrote:
> I can easily see an argument that it might take a long time or that
> "legacy TXT" will always be with us (just as IPv4 will always be
> with us), but a better migration strategy, one that numerous people
> including Mans, Patrik, and others have already mentioned, would, I
> believe, allow for a transition to SPF over time.
> 
> Can you provide a pointer to where in the 28MBytes of mailing list
> archives the SPFBIS working group justified that it was impossible
> to transition? I've read the entire archives a couple of times now
> and don't recall the definitive objective arguments.
 
I believe the actual argument, which I have already repeated here
once, did not hinge on claims of impossibility or possibility.  That
would be rather an absurd bar, since it is obviously logically
possible[1] that the transition happens.  

Rather, the argument was that the transition strategy as defined in
4408 hadn't caused much use of SPF yet; that requiring SPF query first
would involve a useless lookup on day 0, which would increase network
use and might increase latency; that requiring TXT query first would
automatically provide a disincentive to any possible transition; and
that both strategies were more complicated than just picking one, and
interoperability effectively required picking TXT.  As a pragmatic
matter of protocol engineering _given a deployed base_, I'd like to
hear an argument against the above argument, because I was unable to
advance a strong, sound one despite my preference for a move away from
TXT.

Best,

A

[1] As David Lewis (the philosopher, not the politican) was reputedly
fond of pointing out, there is a logically-possible world in which I
am a mud puddle.  I'm taking it for granted that we are not trying to
optimise for such worlds, but for the actual world in which we all
subsist.  In that world, network effects are important, so that the
overwhelming preference of existing deployers is a TXT record is
significant.  I grant, however, that that same actual world is a
logically-possible world in which my name ought better to be spelled
MUD.

-- 
Andrew Sullivan
[email-masked]

---

From: Jay Daley <[email-masked]>
Date: Wed, 21 Aug 2013 09:25:21 +1200

It seems that the real problem here is that there were very many people who knew that using TXT records in the first place was the wrong idea, made their views known and were ignored.  Worse still a number of people predicted this inevitable end point, that using TXT would become the standard if was promoted as an interim step to start with.

So for me the real question now is how to prevent another poor decision like that from happening again.  Personally I think the best way is to push the pain on those that have caused the problem by deprecating the use of TXT for SPF and setting a flag day.  That's seems a fair and reasonable consequence for making such an obviously poor decision in the first place.

Jay

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
linkedin: www.linkedin.com/in/jaydaley

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Aug 2013 21:29:34 +0000

> I am honestly curious how such a conclusion could possibly be reached.  

In order to do something architecturally clean, two things have to be true.   First, you have have an architecturally clean solution in mind that you propose to deploy.   Second, you have to be able to deploy it.   The IETF could indeed meet the former requirement; the evidence though is that we can't meet the second requirement during the useful life of SPF, and hence we can't satisfy the second requirement.

This case was in fact convincingly made on the mailing list.   It can't be proven, because predicting the details of the future is not within our grasp, so if you insist that it must be proven in order to satisfy your objection, your objection can't be satisfied.   I will not answer the points you made subsequent to your above question, because these points were already answered during the spfbis discussion.

> I suspect it might take significantly longer to transition away from SMTP than to migrate from TXT to SPF.

The transition away from SMTP has already happened.   There are still legacy users of SMTP (we happen to be among them), but SMTP carries very little of the text-based interpersonal communication that occurs on the internet today, and we can expect that trend to continue.   The pity is that the IETF doesn't currently have a replacement protocol in mind; the transition has been from an open standard to a plethora of carefully and deliberately closed systems.

---

From: Jay Daley <[email-masked]>
Date: Wed, 21 Aug 2013 09:31:47 +1200

On 21/08/2013, at 4:51 AM, John R Levine <[email-masked]> wrote:

> I went through all of the existing RRs, and defined types for all of the field types that seemed useful in new RRs.

Sounds excellent and I will read it.  I did the same thing (defining all field types) in draft-daley-dnsxml-00 and I know just how much hard work that takes and the value that could come from it.

> in appsarea.  The draft is  draft-levine-dnsextlang-06

I'm not sure if you've noticed yet, but there's an often repeated pattern to innovative ideas being brought to this list when a sufficient gap is left between attempts:

1st attempt:   surprisingly hostile reaction
2nd attempt:   apathy
3rd attempt:   lament that we never did it on the 1st attempt

Jay

---

From: "John Levine" <[email-masked]>
Date: 20 Aug 2013 21:49:04 -0000

>numerous people including Mans, Patrik, and others have already mentioned, would, I believe,
>allow for a transition to SPF over time.

I did a little extrapolation, and based on adoption rates from 2006 to
now, it'd be about 200 years until we could turn off TXT records.

The people who actually use SPF have spoken, loudly.  The only large
mail system that ever checked type 99 records was Yahoo, and they
don't any more.  Google, Hotmail, AOL, Comcast, et al., all publish
and check TXT records, and have never checked type 99 (not because
they don't know how.)  The libraries that people use to check SPF
mostly have the type 99 check turned off because it just slows things
down.

This ship sailed so long ago it's fallen off the other side of the
world, particularly since switching from TXT to SPF provides no
operational benefit whatsoevever to the mail system operators that
publish ahd use them.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Aug 2013 18:19:24 -0400

John Levine wrote:
> they don't know how.)  

The irony is that there is still a huge dual TXT/TXT overhead in 
queries to get SPF information with the big boys switching to _spf 
prefix subdomain zones.  The larger ESP should optimize their calling 
requirements to a single call for the same of the rest of the 
community to support them.  For example: google.com, facebook.com

google.com
    v=spf1 include:_spf.google.com ip4:216.73.93.70/31 
ip4:216.73.93.72/31 ~all"

facebook.com:
    v=spf1 redirect=_spf.facebook.com

At least with Facebook, their SPF corporate policy is a HARD FAIL, so 
their spoof protection payoff is very high and google.com is just a 
waste in calls with its softfail policy.

> The libraries that people use to check SPF

That can all easily change once major DNS servers, like Microsoft 
support unnamed RR type processing.  Its the only reason Windows shops 
don't (could not) support it.

> operational benefit whatsoevever to the mail system operators that

So what you are saying is that TXT applications is it, its the 
acceptable record to use from now on for all future DNS applications. 
Why bother with anything else?

--
HLS

---

From: S Moonesamy <[email-masked]>
Date: Tue, 20 Aug 2013 16:07:41 -0700

Hi Jay,
At 14:25 20-08-2013, Jay Daley wrote:
>So for me the real question now is how to prevent another poor 
>decision like that from happening again.  Personally I think the 
>best way is to push the pain on those that have

This is an individual comment.  See 
http://www.ietf.org/mail-archive/web/dnsext/current/msg13086.html specifically:

   "I was the document shepherd for RFC 6686.  There wasn't any comments during
    the Last Call."

All it takes is people volunteering to review drafts instead of 
expecting Area Directors or the usual people to do all the work.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Tue, 20 Aug 2013 17:20:24 -0700

Hi David,
>and don't recall the definitive objective arguments.

The thread starts at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html 
See http://www.ietf.org/mail-archive/web/spfbis/current/msg00594.html 
too.  There is also a thread at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00533.html

I would attempt to explain the path to the RRTYPE decision as follows:

The SPFBIS effort started with a request for experimental evidence ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00255.html 
).  Murray Kucherawy asked about the SPF RR Type ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00329.html 
).  Philip Gladstone posted some data ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00354.html 
).  There was a question about what evidence was being requested ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00355.html 
).  Issue #9 about the RRTYPE was raised ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00361.html 
).  The working group was asked to comment about it ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html 
).  The SPFBIS Chairs concluded that there wasn't consensus for the 
removal of TYPE 99 ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00594.html ).

The SPFBIS Chairs noted a concern about interoperability ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00692.html ).

As it was difficult to resolve the issue of the RRTYPE the matter was 
discussed at a meeting ( 
http://www.ietf.org/proceedings/83/minutes/minutes-83-spfbis.txt ).

Regards,
S. Moonesamy

---

From: David Conrad <[email-masked]>
Date: Tue, 20 Aug 2013 19:35:36 -0700

Andrew,

On Aug 20, 2013, at 2:15 PM, Andrew Sullivan <[email-masked]> wrote:
> the argument was that the transition strategy as defined in 4408 hadn't caused much use of SPF yet;

The transition strategy was noted as broken in RFC 6686, appendix A, #4, hence this isn't really a surprise.  What is surprising to me is that instead of fixing the broken transition strategy and trying again, SPFBIS has decided to permanently embed a hack that impacts other protocols.

> that requiring SPF query first would involve a useless lookup on day 0,

RFC 6686 indicates 2% of tested sites have SPF records, so not quite useless.  And if you're going to say "2% is too small", I'll simply point to IPv6 and DNSSEC like so many others have.  Deploying something new takes time, even if the transition strategy isn't broken.  If you have a broken transition strategy, the time is infinite.  Again, no surprise.

> which would increase network use and might increase latency;

For the 98% (according to RFC 6686) that haven't deployed SPF RRs, definitely.  Easy fix for that if the transition strategy is fixed.

> that requiring TXT query first would automatically provide a disincentive to any possible transition;

Well, yes.  Not sure this is a useful argument.

> and that both strategies were more complicated than just picking one,

Undoubtedly.

> and interoperability effectively required picking TXT.  

Not really.  Interoperability requires TXT be queried. The suggestion is that it be queried last.  But you know this.

> As a pragmatic

It's obvious that no new arguments are being made here, so if you didn't consider the above convincing before, you're unlikely to consider it convincing now and this is a waste of time.  Not surprising.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 20 Aug 2013 19:39:05 -0700

Jay,

On Aug 20, 2013, at 2:25 PM, Jay Daley <[email-masked]> wrote:
> So for me the real question now is how to prevent another poor decision like that from happening again.  

My understanding is that when SPF was being developed initially, it was exceedingly difficult to get a new RR defined.  That problem has been solved.  Obviously, if someone still chooses to use TXT (for whatever reason) and then standardize a broken transition strategy, the same problem will reoccur.  Hopefully, the IESG has learned the lesson here.

Regards,
-drc

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Aug 2013 19:58:02 -0700

On 8/20/2013 10:33 AM, Ted Lemon wrote:
> The architecturally clean thing to do here is to get rid of SMTP, which is a protocol designed for a gentler time, and is ill-suited to the current Internet, with its spammers and botnets and snoops (oh my!).

The premise for this oft-voiced view is that we know what a 'safe and 
proper and equally usable' mail transfer infrastructure service should 
look like and how it is different from the current SMTP infrastructure.

The premise is comforting but false.

I have a standard response to views like this:

      1. We have a long and successful history of figuring out how to 
successfully add capabilities to Internet mail (including SMTP.)  No 
doubt, at some point, we will need to add something that we won't be 
able to figure out how to do workably.  At that point, we will have to 
replace SMTP.

      2.  Before it is reasonable to throw out SMTP, there needs to be a 
functional specification for a feature that has community consensus, and 
we need to try to implement it via SMTP, but then fail to find a way to 
do it.

      3. To date, there is no community consensus proposal.  There are 
many individuals who are certain they know the Truth for this topic, but 
they haven't developed a clear community consensus for modifying this 
global infrastructure service. Such folk are encouraged to review:

         http://craphound.com/spamsolutions.txt

         It's Cory Doctorow's purportedly humorous checklist on the 
topic, but he did a good enough job to be useful for those of us who 
regularly field claims of knowing what is known in the trade as the 
Final Ultimate Solution to the Spam Problem (FUSSP)

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 Aug 2013 12:59:21 +1000

In message <[email-masked]>, David Conrad
 writes:
> My understanding is that when SPF was being developed initially, it was
> exceedingly difficult to get a new RR defined.  That problem has been
> solved.  Obviously, if someone still chooses to use TXT (for whatever
> reason) and then standardize a broken transition strategy, the same
> problem will reoccur.  Hopefully, the IESG has learned the lesson here.
>
> Regards,
> -drc

It wasn't difficult at all.  Just no one involved with SPF would attempt
to get a record.  There was this whole mythology that it was hard with
no evidence to back it up.

I say this as someone that got much more contraversial records in the same
time period.

Mark

---

From: Jay Daley <[email-masked]>
Date: Wed, 21 Aug 2013 15:05:52 +1200

> My understanding is that when SPF was being developed initially, it was exceedingly difficult to get a new RR defined.  That problem has been solved.  Obviously, if someone still chooses to use TXT…

Thanks David.  I understood that another key issue was the lack of support in MS DNS products for unknown RRs, which I gather is still the case.  So despite the change to the process for creating new RRs we'll still have the risk of people using TXT for prototyping and then declaring a sufficiently installed base of TXT for the new usage to be formalised.  

Jay

---

From: David Conrad <[email-masked]>
Date: Tue, 20 Aug 2013 20:13:03 -0700

Ted,

On Aug 20, 2013, at 2:29 PM, Ted Lemon <[email-masked]> wrote:
> The transition away from SMTP has already happened.   

The 250ish queries per second the "L" root server is getting for MX records might suggest http://www.youtube.com/watch?v=UPatfgoNBRo.

> There are still legacy users of SMTP (we happen to be among them), but SMTP carries very little of the text-based interpersonal communication that occurs on the internet today, and we can expect that trend to continue.  

Without agreeing or disagreeing with your view on SMTP, this might suggest the SPFBIS solution of putting a TXT record at the zone apex for a dying protocol (if I'm understanding your view correctly) thereby imposing a parsing requirement to ignore "v=spf..." for all future protocols that might want to query TXT at the zone apex would make even less sense.

In any event, as I responded to Andrew, there are no new arguments here. Fundamentally, I believe the SPFBIS solution is wrong and I've provided my input reflecting my view in response to the last call on the IETF list. I encourage others to provide their input on the last call as well (regardless of whether their view is pro or con). I'll admit I feel I've wasted more than enough time tilting against this particular windmill.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 20 Aug 2013 20:28:59 -0700

Jay,

On Aug 20, 2013, at 8:05 PM, Jay Daley <[email-masked]> wrote:
> Thanks David.  I understood that another key issue was the lack of support in MS DNS products for unknown RRs, which I gather is still the case.

Yes and no (mostly no) -- see the note from Carsten Strotman below.  Sad.

Based on the fact Microsoft doesn't support unknown RR types after a decade (3 years longer than SPF RRs), I gather we should deprecate unknown RRs... :)

Regards,
-drc

Begin forwarded message:

> From: Carsten Strotmann <[email-masked]>
> Subject: Re: [dnsext] Deprecating SPF
> Date: August 20, 2013 7:57:45 AM PDT
> To: Joe Abley <[email-masked]>
> Cc: Pete Resnick <[email-masked]>, [email-masked], "[email-masked] Group" <[email-masked]>, [email-masked]
> 
> Signed PGP part
> Hi,
> 
> Joe Abley wrote:
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 20 Aug 2013 23:37:19 -0400

On Tue, Aug 20, 2013 at 07:35:36PM -0700, David Conrad wrote:
 
> RFC 6686 indicates 2% of tested sites have SPF records

Actually, I think it says that fewer than 2% of such sites have SPF
records.  

> I'll simply point to IPv6 and DNSSEC like so many others have.

But the analogy there is preposterous, because SPF is, by any measure,
a much more successful technology than either of those others.  If in
the case of either DNSSEC or IPv6 we had anything remotely resembling
the alternate path to deployment that the TXT record for SPF has, we'd
standardize it.  

Alternatively, we could say that in the case of v6 we _do_ have such a
technology: NAT44.  And indeed, long after the success of the
lalala-I-can't-hear-you crowd on NAT44, the IETF got around to trying
to figure out the least broken way to cope with this.  A whole working
group (BEHAVE) got set up for that purpose.

> Deploying something new takes time, even if the transition
> strategy isn't broken.

Yes, but if the transition strategy relies on people who get no
benefit of any sort from making the transition, the end recedes
permanently into the future.  Mail operators have voted with their
feet.

This is yet another difference with DNSSEC and IPv6.  In the case of
both of those transitions, there's at least some argument to be made
that some benefit redounds to the operator who needs to make a
transition.  A DNSSSEC signer gets assurance that at least validating
clients can determine whether the data is legit.  A DNSSEC validator
gets assurance that the validated source data is legit.  An IPv6
service offering ensures that the v6 network can get the service, and
an IPv6 client might have no other choice due to address scarcity.  

In the case of SPF, the incentive to publish TYPE99 depends entirely
on SPF validators looking it up.  The SPFBIS WG's surveys detected
almost no use of the lookup of TYPE 99, and even fewer such lookups
that appeared to be anything other than concurrent lookups of the
functionally equivalent TXT record.  Nobody is using this thing, and
there is nothing that provides an incentive to do it.  The IETF
insisting that it's a good idea would do exactly nothing to advance
that state of affairs.

I would dearly love evidence to the contrary, but unless you have some
new data to suggest why RFC 6686 is wrong, there is really no
incentive anywhere on the network to move, and if the IETF published a
standard saying, "Move, darnit," that would do nothing except make the
IETF look even more out of touch than usual.

> Not really.  Interoperability requires TXT be queried. The suggestion is that it be queried last.  But you know this.

So, you would prefer that on day 0 everyone send a query that in
almost every case offers no benefit in order to get an advantage that
is mostly a matter of architectural correctness?  What do you think
the chances are that validators will follow that reasoning?  Do you
think the chances are better than, say, deployment of BCP 38?  Why?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: joel jaeggli <[email-masked]>
Date: Tue, 20 Aug 2013 20:58:58 -0700

> My understanding is that when SPF was being developed initially, it was exceedingly difficult to get a new RR defined.  That problem has been solved.  Obviously, if someone still chooses to use TXT…
Assigning a new rr is demonstrably simple at this time (expert review),
it doesn't require stardards action, and you can do so without an rfc.

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 21 Aug 2013 08:06:32 +0200

> it doesn't require stardards action, and you can do so without an rfc.

Which was done with for example URI, which confuses people so much that we now write an RFC explaining the RR Type.

   Patrik

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 21 Aug 2013 10:13:16 +0200

On 08/21/2013 05:28 AM, David Conrad wrote:
> 
> Based on the fact Microsoft doesn't support unknown RR types after
> a decade (3 years longer than SPF RRs), I gather we should
> deprecate unknown RRs... :)
> 

SMTP is older, and unless they fixed it last year, Hotmail doesn't
follow the RFC regarding MX lookups either. So while we're deprecating
things... ;)

That doesn't give much hope for any additional use of DNS for their
mail, be it using TXT or a protocol-specific type, or a fallback
approach, TBH.

Jelte

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 21 Aug 2013 04:35:28 -0400

> I say this as someone that got much more contraversial records in the same

Apart from the wee problem of Windows Server DNS not supporting unknown
records and being 4 years off an update as demonstrated by the Microsoft
team showing the source code.

Nobody disputed the ability to get a new RR, the issue was getting support
for the new RR from DNS resolution providers who were not running recent
versions of BIND. The support for unknown records had not been defined when
the Microsoft product was launched.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Aug 2013 07:56:03 -0400

> It's obvious that no new arguments are being made here, so if you didn't consider the above convincing before, you're unlikely to consider it convincing now and this is a waste of time.  Not surpri…

What would be more convincing, I think, is if people showed the actual harm with using TXT.  That it's not what DNS folks wished for I got, but if it ain't broken it's hard to figure out why it's worth fixing or why people would pay attention.

For example, the argument's been made that because it's in the zone apex it will cause issues with other TXT RRs.

ISTM the solution to that is to put the TXT in a prefixed node like "_spf" (as some folks already do, I believe).  The "transition" strategy could be to query that prefixed name first, and only the non-prefixed TXT if the first isn't found.  After all we have evidence that 100% of clients already can and do query TXT for this stuff and can support it, including MS DNS. ;)

But the response to such a suggestion would likely be: "why would people change to doing that?!?"  Yet that's exactly the argument being made against SPF RR, isn't it?  If you believe that transitioning to SPF RR is the right thing to do, to avoid the problems of TXT RR in the apex, then it seems like you should be willing to go for a prefixed name TXT instead... unless you think a separate RRType avoids some harm that hasn't yet been identified?

-hadriel

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 Aug 2013 23:14:48 +1000

In message <[email-masked]>, Hadriel Kaplan wr
ites:
> > It's obvious that no new arguments are being made here, so if you didn't co
> nsider the above convincing before, you're unlikely to consider it convincing
>  now and this is a waste of time.  Not surprising.
> 
> What would be more convincing, I think, is if people showed the actual harm w
> ith using TXT.  That it's not what DNS folks wished for I got, but if it ain'
> t broken it's hard to figure out why it's worth fixing or why people would pa
> y attention.

One protocol using TXT isn't a real issue.  When you get to 10, 50 or 500
using TXT it becomes a real issue.  The point of having types is to be
able to split out data for one protocol from another.  We have already
had to renumber types is the DNS because the uses were too overloaded.

TXT is a great prototyping tool.  It makes a lousy long term solution
however.

Not splitting out SPF means that you can't just let someone have the
ability to update TXT records without impacting on the SPF policy.

With SPF first you can hand someone the ability to update TXT records
without risking impacts on SPF policy.

> ill cause issues with other TXT RRs.

The issues with using TXT is independent of the apex of a zone.
 
> ISTM the solution to that is to put the TXT in a prefixed node like "_spf" (a
> s some folks already do, I believe).  The "transition" strategy could be to q
> uery that prefixed name first, and only the non-prefixed TXT if the first isn
> 't found.  After all we have evidence that 100% of clients already can and do
>  query TXT for this stuff and can support it, including MS DNS. ;)

You just broke anyone that uses a wildcard SPF record to say that wildcarded
names don't send email.

Works:
	*.example.net A <address of webhoster>
	*.example.net AAAA <address of webhoster>
	*.example.net SPF "v=spf1 -all"

Doesn't work:
	*.example.net A <address of webhoster>
	_spf.*.example.net TXT "v=spf1 -all"

SPF records MUST be deployable where ever a A, AAAA or MX is deployable.
 
> But the response to such a suggestion would likely be: "why would people chan
> ge to doing that?!?"  Yet that's exactly the argument being made against SPF 
> RR, isn't it?  If you believe that transitioning to SPF RR is the right thing
>  to do, to avoid the problems of TXT RR in the apex, then it seems like you s
> hould be willing to go for a prefixed name TXT instead... unless you think a 
> separate RRType avoids some harm that hasn't yet been identified?
> 
> -hadriel
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Aug 2013 09:32:46 -0400

> had to renumber types is the DNS because the uses were too overloaded.

Yup, makes sense.

> without risking impacts on SPF policy.

Yup, makes sense (though not as big an issue one would think, but ymmv).

> The issues with using TXT is independent of the apex of a zone.

Except that the issues above seem to be solved by moving it out of the apex into a prefixed name. (not the issue below though)

> SPF records MUST be deployable where ever a A, AAAA or MX is deployable.

Right, so is that fixable in any way?  (I don't know the answer, just asking)

-hadriel

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 Aug 2013 23:35:47 +1000

In message <[email-masked]>, Hadriel Kaplan wr
ites:
> > One protocol using TXT isn't a real issue.  When you get to 10, 50 or =
> 500
> >> For example, the argument's been made that because it's in the zone =
> apex it w
> >> ill cause issues with other TXT RRs.
> >=20
> Except that the issues above seem to be solved by moving it out of the =
> apex into a prefixed name. (not the issue below though)
> 
> 
> 
> > You just broke anyone that uses a wildcard SPF record to say that =
> wildcarded
> > names don't send email.
> >=20
> > Works:
> > 	*.example.net SPF "v=3Dspf1 -all"
> >=20
> > Doesn't work:
> > 	_spf.*.example.net TXT "v=3Dspf1 -all"
> >=20
> > SPF records MUST be deployable where ever a A, AAAA or MX is =
> deployable.
> 
> Right, so is that fixable in any way?  (I don't know the answer, just =
> asking)

No.

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 21 Aug 2013 15:11:17 -0400

> had to renumber types is the DNS because the uses were too overloaded.
See also, Tragedy of the Commons. 
http://en.wikipedia.org/wiki/Tragedy_of_the_commons

As stewards of the "commons" here, the SPF folks might do well to heed 
our concerns about "overgrazing" of a shared resource (TXT RR semantic 
space).

Or, to put it another way, "get off of my lawn".

                                     - Kevin

---

From: Bruce Campbell <[email-masked]>
Date: Wed, 21 Aug 2013 21:37:58 +0000 (GMT)

On Wed, 21 Aug 2013, Kevin Darcy wrote:

> As stewards of the "commons" here, the SPF folks might do well to heed our 
> concerns about "overgrazing" of a shared resource (TXT RR semantic space).
>

RFC4408, 6.1 defines the 'redirect' attribute, which sends the client off 
to another record, commonly '_spf.same.domain' or '_spf.common.domain' in 
the case of a hosting provider with multiple zones.  To _partially_
alleviate concerns about SPF records filling up the TXT record at the zone 
apex to the detriment of other uses, 4408bis could have something similar 
to the following under 3.4:

   Where non-SPF records are also present in the domain's TXT record, the
   SPF record SHOULD be limited to a redirect to a dedicated SPF record as
   defined in Section 6.1.  Where possible, non-SPF records should also use
   similar redirects.  For example:

     example.com. IN TXT "v=spf1 redirect=_spf.example.com"
     example.com. IN TXT "Can the SPF RR-99 or TXT record be phased out?"
     example.com. IN TXT "THERE IS AS YET INSUFFICIENT DATA FOR A"
     example.com. IN TXT "MEANINGFUL RESPONSE."
     example.com. IN TXT "v=quoteref redirect=_lastquestion.example.com"

-- 
   Bruce Campbell.

   Personally I think the biggest failure of SPF was a lack of insistence
   on it using a SRV-style prefix from the start.  At the very least,
   the IETF should use SPF as a case study on why _not_ having dedicated
   record locations is a bad idea.

---

From: "John Levine" <[email-masked]>
Date: 21 Aug 2013 23:11:50 -0000

>ISTM the solution to that is to put the TXT in a prefixed node like "_spf" (as some
>folks already do, I believe).

Not really.  See RFC 4408 and 4408bis.

SPF does provide the ability to indirect to another name, and some
people use various prefixes when they indirect, but that's not part of
the protocol, nor are there any widespread conventions about what
names to use.  For some bad examples, see the TXT records at
hotmail.com, outlook.com. and microsoft.com.

If you will review the past million messages or so on this topic, you
will find broad agreement that if we were designing SPF from scratch,
we would do it differently.  But we're not, we're talking about a widely
deployed protocol which, no matter what the IETF might do, will not
appeciably change from what's deployed now.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 21 Aug 2013 23:13:34 -0000

>> correctly). I haven't tested zones stored in Active Directory.

Sounds exactly like the situation with BIND.

R's,
John

---

From: Alex Bligh <[email-masked]>
Date: Thu, 22 Aug 2013 00:18:47 +0100

On 22 Aug 2013, at 00:11, John Levine wrote:

> But we're not, we're talking about a widely

Genuine question: if a protocol is widely deployed, poorly
standardised, and poorly designed, does that mean it merits
RFC standards track? IE are standards track RFCs meant to
document what is out there and used, or should be out there
and used?

I have always been of the opinion it was the latter, but most
of this conversation has presumed the former.

-- 
Alex Bligh

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Aug 2013 16:24:01 -0700

John,

> Sounds exactly like the situation with BIND.

My impression was that it was impossible in MSDNS to add RFC 3597-style unknown RRs to the master directly, but that it was possible for a MSDNS slave to zone transfer in unknown RRs from a non-MSDNS master that allowed the insertion of RFC 3597-style unknown RRs.  However, I may have misunderstood.

Regardless, Microsoft's inability to deal with unknown RRs in any sort of reasonable fashion after a decade is surprising and unfortunate.

BIND (since early BINDv9), of course, has no problem with RFC 3597-style unknown RRs, either as master or slave.

Regards,
-drc

---

From: "John R Levine" <[email-masked]>
Date: 21 Aug 2013 19:30:59 -0400

> My impression was that it was impossible in MSDNS to add RFC 3597-style 
> unknown RRs to the master directly, but that it was possible for a MSDNS 
> slave to zone transfer in unknown RRs from a non-MSDNS master that 
> allowed the insertion of RFC 3597-style unknown RRs.  However, I may 
> have misunderstood.
>
> Regardless, Microsoft's inability to deal with unknown RRs in any sort 
> of reasonable fashion after a decade is surprising and unfortunate.
>

Right, but the web provisioning crudware that people use in front of BIND 
generally can't handle anything other than A, MX, CNAME, and TXT, so for 
anything else you have to get someone with direct access to the host to 
edit the master file.  Like I said, sounds just the same.

Regards,

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Aug 2013 23:44:28 +0000

> document what is out there and used, or should be out there

It's not a question of "merit," and even if it were, I think it would be a bit much to say that this document has no merit, or is "poorly designed," just because you don't like the use of the TXT record, which is a small part of the whole.

It is a technical standard, developed in the IETF, which has applicability on the internet.   Those are the criteria for something being standards-track.

---

From: "John R Levine" <[email-masked]>
Date: 21 Aug 2013 19:46:29 -0400

> document what is out there and used, or should be out there

It's a reasonable question.  RFC 4408 currently exists and isn't going 
away, and SPF is probably more widely deployed than most standards track 
RFCs.  We all agree that it's ugly, and we wouldn't design it this way if 
we were doing it from scratch.

The choices are to stick our fingers in our ears and pretend it'll go 
away, or to acknowledge reality and make what fixes we can, keeping in 
mind that the installed base isn't going to make changes that cause a lot 
of breakage, or that have no perceptible benefit to them.

The IETF has in the past often made the wrong choice in similar 
situations,* and I have to say it's dismaying that so many people seem 
determined to do it again.

Regards,

* - NAT

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Aug 2013 16:55:07 -0700

John,

On Aug 21, 2013, at 4:30 PM, John R Levine <[email-masked]> wrote:
> Right, but the web provisioning crudware that people use in front of BIND generally can't handle anything other than A, MX, CNAME, and TXT, so for anything else you have to get someone with direct access to the host to edit the master file.  Like I said, sounds just the same.

In one case, the backend system doesn't support something.

In the other case, the backend system does.

Sounds different to me, but I guess that depends on your agenda and the rhetorical points you're trying to score.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Aug 2013 17:25:43 -0700

On Aug 21, 2013, at 4:46 PM, John R Levine <[email-masked]> wrote:
> The choices are to stick our fingers in our ears and pretend it'll go away, or to acknowledge reality and make what fixes we can, keeping in mind that the installed base isn't going to make changes that cause a lot of breakage, or that have no perceptible benefit to them.

Except parts of the future "installed base" are waiting for a decision from the IETF, e.g.:

http://support.godaddy.com/groups/domains-management-and-services/forum/topic/spf-type-99/
http://features.cpanel.net/responses/ability-to-create-spf-type-99-records

Regards,
-drc

---

From: Andras Salamon <[email-masked]>
Date: Thu, 22 Aug 2013 12:01:18 +0100

>Based on the fact Microsoft doesn't support unknown RR types after a decade (3 years longer than SPF RRs), I gather we should deprecate unknown RRs... :)

Arguing that SPF (and other "unknown") records should be deprecated
is pushing in the wrong direction, as drc indicates via sarcasm,
assuming that the IETF is meant to have any prescriptive role at all.

The right thing seems to be to write an RFC mandating that every DNS
server connected to the public Internet MUST accept unknown RR types,
and that every system that feeds data into DNS servers SHOULD accept
unknown RR types gracefully.  Then to push for this RFC to become
a Standard.  Then to push for RFPs to mandate conformance with the RFC.

I've watched several vendors through incompetence and/or deliberate
design try to kill DNS in favour of their own directory service
"solutions" for twenty years.  They have not yet succeeded.  So there
seems no reason those who think DNS is a net win should sit back and
let them do it.  (Those who think DNS is a dead loss, or that the IETF
should simply describe what vendors have cooked up and are trying to
hawk, should just ignore all this.)

-- Andras Salamon                   [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 22 Aug 2013 17:54:57 -0000

>a Standard.  Then to push for RFPs to mandate conformance with the RFC.

How would this RFC differ from RFC 3597?

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 22 Aug 2013 18:46:10 -0000

This analysis sums up the situation pretty well:

http://dnsreactions.tumblr.com/post/58998841753/spf-txt-vs-type-99-thanks-tjeb

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 22 Aug 2013 20:14:33 +0100

> http://dnsreactions.tumblr.com/post/58998841753/spf-txt-vs-type-99-thanks-tjeb
Or this

http://en.wikipedia.org/wiki/Cnut_the_Great#Ruler_of_the_waves

Henry of Huntingdon <http://en.wikipedia.org/wiki/Henry_of_Huntingdon>, the
12th-century chronicler, tells how Cnut set his throne by the sea shore and
commanded the tide to halt and not wet his feet and robes. Yet "continuing
to rise as usual [the tide] dashed over his feet and legs without respect
to his royal person. Then the king leapt backwards, saying: 'Let all men
know how empty and worthless is the power of kings, for there is none
worthy of the name, but He whom heaven, earth, and sea obey by eternal
laws.' He then hung his gold crown on a
crucifix<http://en.wikipedia.org/wiki/Crucifix>,
and never wore it again "to the honour of God the almighty King".

The question at issue is whether the IETF is going to write specs that make
people in the IETF feel good or specs that deployers trust as the best
source of advice on how to configure their systems.

There is a technical argument to be made for keeping SPF records but it is
a small one. And the idea that there will be a transition from TXT is silly.

One of the problems here is that folk in the DNSEXT group believed what
they wanted to believe. When someone told them that the Windows DNS server
did too support unknown records they believed it because they wanted to
believe it. And so when Microsoft told them 'no it does not' they decided
they must be lying. I was accused of lying when I mentioned the fact during
the discussions of the SPF record.

The way that the SPF record was imposed on the working group to placate the
DNSEXT folk guaranteed that none of them would ever push for it being
supported in practice.

---

From: Jay Daley <[email-masked]>
Date: Fri, 23 Aug 2013 07:38:43 +1200

> One of the problems here is that folk in the DNSEXT group believed what they wanted to believe. When someone told them that the Windows DNS server did too support unknown records they believed it because they wanted to believe it. And so when Microsoft told them 'no it does not' they decided they must be lying. I was accused of lying when I mentioned the fact during the discussions of the SPF record.

I'm now really confused about what  Microsoft DNS does and doesn't support.  Does anyone have any up to date, genuine evidence to answer the following questions:

Does it support in the authoritative server:

1.  Direct provisioning of unknown RR types via its own management tools?

2.  Direct provisioning via DDNS?

3.  Indirect provisioning of unknown RR types (i.e. via AXFR/IXFR from another server)

Does it support in the caching server:

4.  Resolution of unknown RR types?

cheers
Jay

> 
> The way that the SPF record was imposed on the working group to placate the DNSEXT folk guaranteed that none of them would ever push for it being supported in practice.
>  
> --

---

From: "John Levine" <[email-masked]>
Date: 22 Aug 2013 20:35:29 -0000

>I'm now really confused about what  Microsoft DNS does and doesn't support.  Does anyone
>have any up to date, genuine evidence to answer the following questions:

If you think that's important, why don't you research it and see what
you find?

It's not germane to the SPF discussion, so there's no hurry.

R's,
John

---

From: S Moonesamy <[email-masked]>
Date: Thu, 22 Aug 2013 13:55:34 -0700

Hi Alex,
>document what is out there and used, or should be out there

That's a good question.  I cannot comment on the answer.

There was a comment from Patrik Fältström.  It 
was very insightful and it describes the issue 
clearly.  My guess is that Patrik Fältström was being nice.

Regards,
S. Moonesamy

---

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Aug 2013 07:23:37 +1000

Part of the question is whether the IETF is going to work with ICANN, IANA
and the ccTLD to audit delegations for servers that are not RFC 103[45]
compliant and suspend delegations where the servers are not compliant.

	* no responding to queries based on query type
	* not having a NS rrset at the delegation point

Enforcing that ccTLD and ICANN TLD regularly audit delegations and
have mismatches corrected.  This is REQUIRED by RFC 1034 in part to
stop the sorts of problems we are seeing today.

We don't have to put up people putting up misconfigured / broken servers.

For the non responding servers I have written
draft-andrews-dns-no-response-issue to try to capture the issues.
It was on the dnsop agenda for Berlin but didn't get covered as time
ran out.  I would like everyone to read it and comment on it.

Mark

---

From: Andras Salamon <[email-masked]>
Date: Thu, 22 Aug 2013 23:15:15 +0100

On Thu, Aug 22, 2013 at 05:54:57PM -0000, John Levine wrote:
>>Then to push for this RFC to become

It would not: the problem is that we in the IETF seem to have stopped
moving standards from Draft Standard through to Standard status.
RFC 3597 has been in Proposed then Draft standard status since 2003.
This may give RFP writers at various vendors useful wiggle room, but
undercuts the usefulness of having standards in the first place for
the majority of Internet users who are not beholden to the dynamics
of enterprise procurement.

It is clear that at least three implementations have achieved
"widespread deployment" and conform to RFC 3597.  Perhaps we could
celebrate the tenth anniversary of RFC 3597 by trying to move it
forward?

Were the oft-raised concern that "SPF records will break some servers
that are unable to handle unknown record types" to be pushed aside with
"we can ignore those since they are not standards-compliant", then we
could have a real discussion about the merits of SPF vs. TXT-for-SPF.
Until then, not so much.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 22 Aug 2013 18:43:45 -0400

On Thu, Aug 22, 2013 at 3:38 PM, Jay Daley <[email-masked]> wrote:

> I'm now really confused about what  Microsoft DNS does and doesn't
> support.  Does anyone have any up to date, genuine evidence to answer the
> following questions:
>

Well the issue is what it did support during the SPF development and the
insistence of some that it did things that the vendor swore it did not.

> 1.  Direct provisioning of unknown RR types via its own management tools?

Nope, not possible

> 2.  Direct provisioning via DDNS?

Nope

> 3.  Indirect provisioning of unknown RR types (i.e. via AXFR/IXFR from

Yes, but the config would be lost on a reboot as the server could not save
out the unknown records in the zone file.

> 4.  Resolution of unknown RR types?

The server would behave properly but the config was not supported.

> cheers
> Jay
>
> >
> > The way that the SPF record was imposed on the working group to placate
> the DNSEXT folk guaranteed that none of them would ever push for it being
> supported in practice.
> >
> > --

---

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Aug 2013 08:53:40 +1000

> could have a real discussion about the merits of SPF vs. TXT-for-SPF.

Nameservers that refuse to answer SPF queries are NOT STANDARDS
COMPLIANT.  Yes, that is FULL STANDARD.

Resolvers that don't support arbitary query types are NOT STANDARDS
COMPLIANT.

RFC 1034

   3. General lookup function

      This function retrieves arbitrary information from the DNS,
      and has no counterpart in previous systems.  The caller
      supplies a QNAME, QTYPE, and QCLASS, and wants all of the
      matching RRs.  This function will often use the DNS format
      for all RR data instead of the local host's, and returns all
      RR content (e.g., TTL) instead of a processed form with local
      quoting conventions.

---

From: "John Levine" <[email-masked]>
Date: 22 Aug 2013 23:53:29 -0000

>RFC 3597 has been in Proposed then Draft standard status since 2003.

If you think it's important to move it to full standard, why don't you
do somthing about it?  A quick look suggests that 3597 meets the
requirements in sec 2.2 of RFC 6410 I wouldn't think that it'd be hard
to persuade someone on the IESG to sponsor the required last call.

R's,
John

PS: On the other hand, I wouldn't expect it to make much practical
difference.  In the outside world, most people can't tell a full
standard RFC from and April 1.

---

From: [email-masked]
Date: Fri, 23 Aug 2013 02:26:11 +0000

having been in the pond for a few years, I'd suggest that
it is reasonable to document existing practice.  It is also
prudent to pick the best technical choice.  The use of 
multiplexing/overloading is known to be problematic.  

I would not depricate the SPF RR.  I would make the claim that
both 16 and 99 RRtypes are used for the purpose for which RRtype
99 was designed.  Absent data on rates of adoption, I'd postpone
the LC for a period of time to collect a second set of data points
(besides the ones PAF and DRC have published in the last week)

I'd suggest that SPF data MUST (in the RFC 2026 sense) be prefered
 in publication and SPF data encoding in TXT records MAY (in the RFC 2026 sense)
be included.  E.G.  RRtype 99 is mandatory to implement for compliant
servers.  The technical arguemnts for unique RRtypes are small but real.

/bill

On Thu, Aug 22, 2013 at 01:55:34PM -0700, S Moonesamy wrote:
> There was a comment from Patrik Fdltstrvm.  It 
> clearly.  My guess is that Patrik Fdltstrvm was being nice.
> 
> Regards,
> S. Moonesamy 
>

---

From: S Moonesamy <[email-masked]>
Date: Thu, 22 Aug 2013 23:04:43 -0700

Hi Bill,
>servers.  The technical arguemnts for unique RRtypes are small but real.

I'll mention:

http://www.ietf.org/mail-archive/web/spfbis/current/msg01662.html
http://www.ietf.org/mail-archive/web/spfbis/current/msg01904.html

And I'll quote Andrew ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01948.html ):

   "If I put my hat on for a moment, either SM or I would have to shepherd
    this document.  We would have to explain to the IESG that, yes, our
    charter said we wouldn't remove any features we knew to be in use, and
    yes, we had evidence that these features were sometimes, only rarely,
    in use by some people; but we decided to ditch them anyway, because we
    didn't care about those uses and thought they were dumb and decided
    not to count those people because there were too few of them.  As a
    simple process matter, that's a problem."

I need a good explanation to be able to ask the Responsible Area 
Director to suspend the Last Call.  I have to take into account that 
the explanation can be challenged and that will cause process issues.

I suggest that you make a formal request.  I can treat the message at 
http://www.ietf.org/mail-archive/web/dnsext/current/msg13339.html as 
a formal request if you wish.  Please note that I am not ignoring your comment.

Regards,
S. Moonesamy

---

From: Alex Bligh <[email-masked]>
Date: Fri, 23 Aug 2013 07:25:43 +0100

>   simple process matter, that's a problem."

This makes little sense to me.

Deprecating SPF is removing a feature we know to be in use (perhaps
less than TXT, but still in use).

Are you saying that a draft that deprecated overloading of TXT
would be out of scope because people are doing it? How would this
be different from a draft that pointed out other 'bad' things
you should not do with existing records (we've had plenty of those)
even when those things have been found in the wild?

-- 
Alex Bligh

---

From: S Moonesamy <[email-masked]>
Date: Thu, 22 Aug 2013 23:52:19 -0700

Hi Alex,
>even when those things have been found in the wild?

I was explaining it would be a process problem if every comment is 
not carefully considered. For example, if you are the only person 
making an argument, I cannot ignore it; I cannot give it less weight 
than the arguments being made by a significant number of persons.

The answers to the above questions is a matter of opinion.  I have 
not formed an opinion as it would then be difficult for me to try and 
figure out what to suggest to address the issues which have been raised.

Regards,
S. Moonesamy

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 23 Aug 2013 09:56:12 +0200

> servers.  The technical arguemnts for unique RRtypes are small but real.

++; on bill above. Some logging and a grepish snapshot: 

(background: I serve around 150 zones from my name server pair. This
is query logs from my BIND master. Not much traffic, but a 45MiB log buffer,
at least. Further, none of the nodes recurse; this is only resolvers
looking at name servers.)

$ ls -lh q*
-rw-r--r--  1 bind  wheel   4.1M Aug 23 07:21 queries.log
-rw-r--r--  1 bind  wheel    10M Aug 23 04:36 queries.log.0
-rw-r--r--  1 bind  wheel    10M Aug 22 20:22 queries.log.1
-rw-r--r--  1 bind  wheel    10M Aug 22 13:48 queries.log.2
-rw-r--r--  1 bind  wheel    10M Aug 22 06:11 queries.log.3

$ cat queries* | awk '  /TXT/ { txt++; }; 
		 	/SPF/ {spf++; }; 
			END   { printf "TXT: %d\tSPF: %d\n", 
				txt, 
				spf; }'
TXT: 2032       SPF: 396

The disclaimer of course is that all whining around my misunderstanding
of the payload in SPF records has caused the entire IETF list membership
to look up my SPF "records" to point fingers and laugh at them, thereby
skewing the numbers.

If I'm doing anything worng wrt counting the records above, please point
it out and I'll try to rectify.
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
It don't mean a THING if you ain't got that SWING!!

---

From: "Marco Davids (SIDN)" <[email-masked]>
Date: Fri, 23 Aug 2013 11:53:23 +0200

> do somthing about it? 

> standard RFC from and April 1.

In my view, that says more about us, the IETF-community, than about the
outside world. There work to be done here, for the IETF.

--
Marco

---

From: Jelte Jansen <[email-masked]>
Date: Fri, 23 Aug 2013 15:17:49 +0200

On 08/23/2013 09:56 AM, Måns Nilsson wrote:
> 
> $ cat queries* | awk '  /TXT/ { txt++; }; /SPF/ {spf++; }; END   {
> printf "TXT: %d\tSPF: %d\n", txt, spf; }' TXT: 2032       SPF: 396
> 

moar data:

I have been monitoring one of our nameservers over the last 48 hours
(disclaimers the usual: only looking at type, not qname, sender, or
content, only looking at queries, this is above the cache, txt may be
for other things as well, etc.),

Queries for type=SPF:  899349
Queries for type=TXT: 2839482

Jelte

---

From: "John Levine" <[email-masked]>
Date: 23 Aug 2013 15:14:38 -0000

I counted my queries from a few days ago and got 7086 TXT, 263 SPF, or 3.7%.

Nobody has argued that SPF usage is zero, and the reasons for
deprecating SPF have been described repeatedly here and on the ietf
list, so this exercise seems fairly pointless.

R's,
John

---

From: Andras Salamon <[email-masked]>
Date: Fri, 23 Aug 2013 17:25:14 +0100

>to persuade someone on the IESG to sponsor the required last call.

Ólafur Gudmundsson nominated RFC 3597 to advance from Proposed to
Draft Standard in message <6.1.0.6.2.20040819092046.02d2dec0@localhost>
of 19 Aug 2004.  This was based on -00 of Jakob Schlyter's draft,
of which the most recent version is from May 2005:
    http://tools.ietf.org/id/draft-ietf-dnsext-interop3597-02.txt

Since Jakob already did an important part of the work, I would
first like to understand what happened to the advancement request,
especially in light of the two revisions of the interoperability
report after the request.  Does anyone have pointers?

(I know that PS/DS were merged a couple of years ago, but would still
like to understand how the PS->DS process went, and if it failed, why.)

---

From: Hector Santos <[email-masked]>
Date: Fri, 23 Aug 2013 12:58:54 -0400

> like to understand how the PS->DS process went, and if it failed, why.)

I appreciate this level of work to see why it fell through the cracks. 
I believe it is one of the IETF growing lack of diversity issues, 
i.e., improving electronic communications, collaborations and 
networking among industry peers.

This should be a project leader(s) responsibility to make sure the 
basic technology requirements are realistic or not, i.e., consult and 
get input from the DNS industry vendors, make them aware and/or to 
find out why this has not happen yet.

For example, why hasn't Microsoft supported RFC 3597 yet?  You will be 
surprise that a well respected Microsoft DNS Expert and MVP (Most 
Valuable Player) was unaware of such needs, nor was his microsoft 
contacts and the MSDNS beta team based on a discussion with him:

http://social.technet.microsoft.com/Forums/windowsserver/en-US/5841e884-db22-42a1-8530-615a375662cc/dns-server-support-for-new-or-unamed-rr-type-records

This was back in March/April 2012.

If Microsoft isn't going to bother to add direct support for the SPF 
type99 RR, nor support RFC 3597 at the very least, I believe this 
matter is decided and closed. TXT only is proper for SPFBIF and for 
future DNS applications as well.

I am sure there are key IETF decision makers with Microsoft DNS 
product manager contacts who can find out whats going on to help 
resolve this LC issue.

--
HLS

---

From: [email-masked]
Date: Fri, 23 Aug 2013 17:03:26 +0000

> list, so this exercise seems fairly pointless.

	the reasons for not deprecating SPF have been described here
	and on the ietf list repeatedly ... yet there has been little
	concrete data regarding deployment uptake. These published
	snapshots form a baseline - 201308, and it might be worthwhile
	to look again in six months to see if the magnitude and ratio 
	have changed.  The results of a second look should bring into
	focus the prevaling trends and solidify the argument.

	Surely there is no compelling urgency to conclude the current 
	LC - given the duration of this work a six month period to 
	gain emperical insight would not be a bad thing.

	Would it?

/bill

---

From: Chris Thompson <[email-masked]>
Date: 23 Aug 2013 21:16:29 +0100

>Queries for type=TXT: 2839482

Our authoritative-only nameservers show a similar 3:1 ratio, again just
using BIND's counts of query by type. In the last 4 weeks, they show
TXT 399807, SPF 133903 and TXT 940038, SPF 340354 (the second is an
official slave for rather more forward zones, some of which even have
some SPF records).

On the other hand, our central recursive nameservers (only for clients
on the university network) show TXT:SPF over 250:1. But probably very
few clients are receiving mail and checking its origin using these
namesevers, and something else is responsible for the large count
of TXT queries.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Andreas Gustafsson <[email-masked]>
Date: Fri, 23 Aug 2013 23:27:55 +0300

> report after the request.  Does anyone have pointers?

The latest attempt at advancing 3597 was draft-ietf-dnsext-rfc3597-bis-02
in February 2010.  For the WGLC summary, see

  http://www.ietf.org/mail-archive/web/dnsext/current/msg07633.html

-- 
Andreas Gustafsson, [email-masked]

---

From: Joe Abley <[email-masked]>
Date: Fri, 23 Aug 2013 16:26:36 -0400

Hi Chris,

It would be instructive to find a way to better characterise the TXT
numbers in the counts that you and others have contributed to this
thread.

This does not seem obviously easy, since inferring the reason for a
query even with knowledge of the full response (eg including
SPF-identifying tokens or not) seems hard.

It seems vaguely ironic that part of the reason it's hard to assess
the relative use of SPF/16 and SPF/99 in queries  is that 16 is
overloaded, which is itself the root of the objection to its use.

Joe

Aue Te Ariki! He toki ki roto taku mahuna!

---

From: Mark Andrews <[email-masked]>
Date: Sat, 24 Aug 2013 07:41:23 +1000

> overloaded, which is itself the root of the objection to its use.

When you look at recursive servers you are looking at the direct
clients of that server.

When you look at authoritative servers you are seeing the world
wide population of clients.  Add to that you need to look at the
differing TTLs for the responses for the two query types as most
of these queries will be from a caching server and not the ultimate
client.  You also need to know if the SPF queries return a positive
or negative response as that will also directly impact on the ratio
of queries.  You also need to know if the responses are for a
existing name or result in name error.  You also need to ensure
that the delegations are all correct or the negative responses will
be rejected by some of the recursive servers.  You also need to
look at whether the responses TTLs are being truncated or not.

To eliminate most of the sources of bias you need to measuring on
a site that doesn't have spf records of either form (spf/txt).  Next
best you need to be measuring on a site that publishes both with
equal ttl (spf/(txt + spf)).

Mixed mode servers are too difficult to quantify.

> >> On 08/23/2013 09:56 AM, Mans Nilsson wrote:

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 Aug 2013 18:10:16 -0400

> look at whether the responses TTLs are being truncated or not.

In this SPF/TXT case, you also need to look at whether the query came
from someone named "google", "hotmail", "yahoo", and maybe another
four or five systems on the Internet; or whether it came from someone
else.

This is related to the point that I think Ted Lemon made elsewhere on
the topic: the big operators of mail are so big that if even one of
them were doing something with SPF, it would really move the needle.
The fact is that they're not, and the one who _was_ doing something
with it has given up because the additional query adds load and
latency for no benefit.

Surely this point is not obscure to the participants of this list?
Someone who pretended to do a survey about DNS that didn't contain any
queries for .com would be laughed out of the room, and everyone
interested in DNSSEC was doubtless cheered when the root and .com were
announced to be signed, because after that there was reason to suppose
that support could be useful.  We have the same sorts of 10,000 pound
gorillas in the email space.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sat, 24 Aug 2013 08:59:20 +1000

> four or five systems on the Internet; or whether it came from someone

No.  Big operators still have caches.  They actually have little
impact on authoritative server loads.  You might be sending the
millions of emails a day but if you TTL is for 1 day you may get
100 queries assuming the recursive server farm is that big.

> with it has given up because the additional query adds load and

Actually they don't move the needle much at all.  What moves the needle
is new MTAs being installed.
 
> gorillas in the email space.

Big operators only move the needle on their own servers.  For everybody
else the have little impact on the ratio of queries.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Sat, 24 Aug 2013 09:09:31 +1000

> is new MTAs being installed.

More correctly the don't have much impact on authoritative servers.
It they were to publish SPF records they would impact on the query
load directed at recursive servers that have clients that look for
both SPF and TXT.  But we were discussing loads on authoritative
servers.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 Aug 2013 19:42:41 -0400

> 100 queries assuming the recursive server farm is that big.

Clearly, I'm an idiot.  

I thought that this discussion was actually about measuring the
relative importance of SPF and TXT in the deployed environment on the
Internet.  So I was supposing that, because of the facts of the
deployed environment of the Internet, when you're counting how many
TXT or SPF records are queried, you have to consider who asked the
question.

If bobsmailandbaitshop.tld asks for an SPF or TXT record, that should
count less in the "how is this deploye?d" estimation than if
hotmail.com asks the same question.  For these each have a cache, as
you say; and there's a pretty good reason to suppose that a single SPF
or TXT query from Hotmail relates to many more actual mail deliveries
than Bob's Mail and Bait Shop.  This is along the lines of what Ted
Lemon (I think?  Sorry if I attribute wrong) was asking about "per
unit of mail delivered".

But I gather from your comments that all we're trying to measure is
the count of queries for a type at a given nameserver.  Obviously for
that, you're right: count the queries.  I don't know why in the world
would we care about that, though.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sat, 24 Aug 2013 10:09:41 +1000

> TXT or SPF records are queried, you have to consider who asked the

We are trying to measure the installed base of MTA's that support
SPF vs those that support just TXT.  DNS caches hide the volume of
email going through a MTA.  There is no one-to-one relationship between
email sent and SPF or TXT lookup.

The figures are saying between a third and a quarter of the worlds
MTAs doing spf support SPF record lookups if you neglect TTL values.

Some of those MTA's handle million of emails a day.  Others handle
hundreds.

> Lemon (I think?  Sorry if I attribute wrong) was asking about "per

Actually bobsmailandbaitshop.tld counts the same as gmail.com.
 
> would we care about that, though.

Actually I was just trying to make clear what was being measured.  What
potential biases there were in the measurements.  Figures mean nothing
unless you have a good understanding of what they are saying.
 
Mark

---

From: Joe Abley <[email-masked]>
Date: Fri, 23 Aug 2013 17:15:44 -0700

> four or five systems on the Internet; or whether it came from someone

My point was it's hard, not really to invite people into proposals. I think any real heuristic would need substantial experimentation and justification before it could be used in anger. There are many, many variables here that are difficult or impossible to quantify.

And this doesn't even touch the question about whether we're counting numbers of domains that use SPF, or numbers of users, or volume of mail, or something else.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 Aug 2013 20:57:05 -0400

On Fri, Aug 23, 2013 at 05:15:44PM -0700, Joe Abley wrote:
> My point was it's hard

Also my point.  There were people who wanted to make _much_ stronger
claims on the basis of the evidence that SPFBIS collected that I
simply couldn't subscribe to.  That's partly why the SPFBIS
conclusions are somewhat tentative, I think.  I would certainly be
delighted if we had people or (more likely) money to conduct a really
rigourous study, but that seems to me like wishful thinking.

A

-- 
Andrew Sullivan
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Fri, 23 Aug 2013 18:40:05 -0700

Andrew,

On Aug 23, 2013, at 5:57 PM, Andrew Sullivan <[email-masked]> wrote:
> I would certainly be

What would a more rigorous study show?

As far as I can tell, the issue isn't whether the SPF RR is being used (it appears to be, albeit at a tiny percentage relative to TXT currently), rather it's whether or not a handful of major mail service providers will use SPF RRs in the future if the IETF were to document a fix to the broken transition strategy in 4408. The SPFBIS WG appears to be asserting that despite no one thinking using TXT is a good idea, most DNS servers supporting SPF (Microsoft being the notable exception), DNS hosting and UI vendors saying they're waiting on the IETF to make up their mind about the SPF RR, existing DNS editors supporting the SPF RR, etc., no transition away from TXT is possible.

I'm unclear what a rigorous study of existing data could possibly demonstrate that would convince anyone who holds this view otherwise.

Regards,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 Aug 2013 22:02:19 -0400

On Fri, Aug 23, 2013 at 06:40:05PM -0700, David Conrad wrote:

> As far as I can tell, the issue isn't whether the SPF RR is being
> used (it appears to be, albeit at a tiny percentage relative to TXT
> currently)

Right, despite the fact that 4408 actually suggested that it'd be good
to use SPF.

> , rather it's whether or not a handful of major mail
> service providers will use SPF RRs in the future if the IETF were to
> document a fix to the broken transition strategy in 4408. 

How would the IETF do that?  The strategy in 4408 was roughly, "Try
both," though admittedly in a flawed way.  But this is exactly the nut
of the problem.  There is no way to create an incentive, given the
actual world we live in, for anyone either to publish or to check 99
as the primary mechanism.  As long as 16 is what everyone is already
doing, network effects say that 16 wins.  There is no advantage to
anyone in moving to 99: neither on the check side nor on the publish
side do you win.  So nobody will.

We either need something new that will make SPF worth doing -- call it
SPF v3 that expresses new policy that's even better (and I can think
of something!  Think of EAI-using domains that need better
granularity!) -- or else we need to embrace the lowest common
denominator.  Nobody in any of this has offered the slightest
incentive to anyone, AFAICT, except, "DNS is better this way."  Who
cares?  I do, you do, but we don't organize the universe.

The above is my claim: nobody cares about this hygiene.  If I'm wrong,
then I want a rigourous study to show it, because none of the
empirical evidence suggests so far that accepting and documenting the
facts as they are today is different than the effects of saying, "You
oughta like TYPE99 more."  We don't have legislative power.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sat, 24 Aug 2013 12:36:57 +1000

In message <[email-masked]>, Andrew Sullivan writes:
> How would the IETF do that?

You say MUST query for SPF and if there is a NO DATA response you
MAY query for TXT.  Modern spf libraries already do this.  Legacy
SPF checkers are no longer compliant.  Even checkers running under
Windows can meet this MUST.

You say that nameservers SHOULD synthesis SPF records from TXT
v=spf1 records.  This helps registrars stuck with broken web
interfaces.  Code for this is written.

You say that nameservers SHOULD reject loading of zones without SPF
records when there are v=spf1 TXT records.  This provides education
for everybody else.  Code for this is written.

You make all the examples use SPF not TXT.  Again more education.

You set a sunset date for the use of TXT for spf lookups.

> The strategy in 4408 was roughly, "Try

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 Aug 2013 23:17:54 -0400

Hi,

Thanks for the outline of the transition strategy.  Let me walk
through it, piece by pice, and see how it works.  I'm going to use
"SPF-99" and "SPF-16" in what follows to disambiguate the query cases.
I'll call the existing SPF implementations "SPFCheck" -- no matter
what they do -- and the new implementations that prefer SPF-99 first,
then SPF-16 "SPFCheckNG".

> Windows can meet this MUST.

I am an SPF validator.  On day 0, there are very few people publishing
SPF-99 records, and many publishing SPF-16 records.  I have a lot of
mail volume coming in.  What is my incentive to embrace SPFCheckNG?
Please address the latency effects for large mail operators.
 
> interfaces.  Code for this is written.

I'm an operator of a DNS zone.  I publish TXT and SPF records.  On day
0, there are very few people publishing SPF-99 records.  What is my
incentive to deploy code that aoutomatically increases my storage cost
and my opportunity for bugs, given that everyone who accepts my mail
is satisfied with SPF-16?

> for everybody else.  Code for this is written.

I'm an operator of a DNS zone.  On day 0, my zone works.  What is my
incentive to accept a new DNS server software update that makes my
zone broken, given that it was working on day 0-1?

I offer my thanks in advance for your investigation of the answers to
the above.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sat, 24 Aug 2013 14:14:09 +1000

> Please address the latency effects for large mail operators.

Most of the latency should be handled be handled in app / on machine
DNS caches.  Add dns hammer support in the caches and almost all
of the rest of the latency is gone.

> is satisfied with SPF-16?

Given there is code that synthesizes SPF records at query time that
is a essentially a subset of DNS64 code (only looks at answers being
retrieved from zone data).  I would say there are zero storage costs
and the code to do SPF synthesis is simple so there really is
extremely low risk of bugs here.  Would you like to audit it?

DNS64 was 100x more complicated than SPF record synthesis yet we
have RFC's for how to do that.

---

From: [email-masked]
Date: Sat, 24 Aug 2013 11:49:01 +0000

> with it has given up because the additional query adds load and

	so on one hand, you have the second query (load & latency)
	((exactly like a CA lookup))  v.  the RR demux that has to occur
	for type 16.

	sounds like the tradeoff between code complexity and network latency...

	(is there a statement from the "one who _was_ doing something" as to 
	why they changed?)

	Am I missing something?

/bill

---

From: Carsten Strotmann <[email-masked]>
Date: Sat, 24 Aug 2013 16:29:31 +0200

Hi Jay,

below are my findings from a test I did in May 2008. I'm redoing the
same test next week with the latest Windows 2012R2 and will post the
results here. The zone-transfer issue mentioned in the text below has
been reported to Microsoft and has been fixed soon after.

Jay Daley <[email-masked]> writes:

> support.  Does anyone have any up to date, genuine evidence to answer
> the following questions:
>

---- ( Text from May 2008 ) -----

I did some testing with the Windows 2008 DNS Server and if the DNS
Server can work when receiving RRs unknown to this DNS Server from an
other DNS Server by AXFR.

The Windows 2009 DNS Server supports these RRs natively from the GUI or
the Commandline tool (dnscmd.exe):

AFSDB
CNAME
ATMA
A
AAAA
HINFO
ISDN
MX
MG
MB
MINFO
NXT
PTR
KEY
MR
RP
RT
SRV
SIG
TXT
WKS
X25
WINS (link to WINS Forward lookup, non-standard)
WINS-R (link to WINS Reverse lookup, non-standard)
DNAME (only via dnscmd.exe)

Test setup:

Master-DNS: BIND 9.4.3b1
Slave-DNS: Windows 2008 Enterprise Server GA, Windows DNS Server Version
6.0.6001.18000
Queries tested with DIG 9.4.2 WINDOWS

I've only done tests with a few RRs, namely with NAPTR, DNAME, SPF, DS
and DLV.

The results vary between a normal zone refresh and a newly create slave
zone.

When creating the slave zone fresh, all unknown RRs are transferred and
stored:

- -----------
SPF:
Master (BIND):
@               IN SPF "v=spf1 +mx a:mail.strotmann.de/32 -all"

Slave (Windows 2008):
@                       86400        #99        26 76 3d 73 70 66 31 20
2b 6d 78 20 61
3a 6d 61 69 6c 2e 73 74 72 6f 74 6d 61 6e 6e 2e 64 65 2f 33 32 20 2d 61
6c
6c

- -----------

NAPTR:
Master (BIND):
_test           IN NAPTR        100 10 "u" "E2U+sip"
"!^.*$!sip:[email-masked]!" .

Slave (Windows 2008):
_test                   86400        NAPTR        100 10 "u" "E2U+sip"
"!^.*$!sip:[email-masked]!" .

- -----------

DNAME:
Master (BIND):
dname           IN DNAME        example.com.

Slave (Windows 2008):
dname                   86400        DNAME        example.com.

- -----------

DS:

Master (BIND):
dskey           IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
                                              98631FAD1A292118 )
Slave (Windows 2008):
dskey                   86400        43        ffffffec 45 05 01 2b
ffffffb1 ffffff83
ffffffaf 5f 22 58 ffffff81 79 ffffffa5 3b 0a ffffff98 63 1f ffffffad 1a
29 21 18

- -----------

DLV:

Master (BIND):
dlv             IN DLV 60485 5 1 ( 2BB183AF5F22588179A53B0A
                                              98631FAD1A292118 )

Slave (Windows 2008):
dlv                     86400        #32769        ffffffec 45 05 01 2b
ffffffb1
ffffff83 ffffffaf 5f 22 58 ffffff81 79 ffffffa5 3b 0a ffffff98 63 1f
ffffffad 1a 29 21 18

However, the situation is different when doing a incremental (AXFR style
IXFR) zone refresh from the Slave to the master (non-initial update):

NAPTR - shown as "Unknown" in GUI, but shown in correct format in the
zone file on disk. Queries from DIG for these RR are answered correct.

DNAME - shown as "Unknown" in GUI, but shown in correct format in the
zone file on disk.  Queries from DIG for these RR are answered correct.

SPF/DS/DLV - when there is an SPF/DS/DLV record (and probably any other
record unknown to the DNS Server engine) in the zone on the master, the
Windows 2008 DNS Server only stores the new SOA record and does not load
any other RR from the zone. There is no error message in the message log
on this failed attempt to transfer the zone, instead there is an log
message of type "INFORMATION" saying that the zone has been successful
transferred ans written to disk. Queries against the zone are answered
with NOERROR/NODATA except for the SOA record, which is returned as an
answer. Attempts to do an AXFR against the slave zone on the Windows
2008 server are failing.

So initially, when the zone is created, the zonetransfer including
unknown RRs works. Windows 2008 is using a standard AXFR here. However
when at a later time the zone changes, the zonetransfer fails silently
and the slave zone becomes unusable. Windows 2008 DNS Server is using an
"AXFR style IXFR" here.

BIND log entry of initial AXFR from Windows 2008 DNS Server:
25-May-2008 22:42:29.671 client 217.255.147.5#35580: transfer of
'example.com/IN': AXFR started
25-May-2008 22:42:29.673 client 217.255.147.5#35580: transfer of
'example.com/IN': AXFR ended

BIND log entry of refresh AXFR from Windows 2008 DNS Server:
25-May-2008 22:52:30.308 client 217.255.147.5#41923: transfer of
'example.com/IN': AXFR-style IXFR started
25-May-2008 22:52:30.309 client 217.255.147.5#41923: transfer of
'example.com/IN': AXFR-style IXFR ended

-----( End text from May 2008 ) ------

Carsten Strotmann

---

From: Carsten Strotmann <[email-masked]>
Date: Sat, 24 Aug 2013 16:57:13 +0200

"John R Levine" <[email-masked]> writes:

> Right, but the web provisioning crudware that people use in front of
> BIND generally can't handle anything other than A, MX, CNAME, and TXT,
> so for anything else you have to get someone with direct access to the
> host to edit the master file.  Like I said, sounds just the same.

There are some GUI tools that don't, there are some that do support SPF
(and other 'new' RR types). Good IETF standards can help customers to
make the right purchase decisions and give incentive to
vendors/programmers to implement support for 'new' RR types.

The current support in GUI tools should not be the guide for a standards
discussion.

As a teacher teaching DNS classes, I found that most of the students
coming to class have never heard of the SPF record (although most of
them deploy SPF with TXT records). The web is full of SPF tutorials
using TXT records that will never be updated.

The new warnings in BIND 9.9 (warns if TXT-SPF is in zone, but no SPF
RR) is a low cost, very effective way to inform DNS admins about the
exsistence of the SPF record, and a warning message in the logs is
incentive for many DNS admins to look up information on SPF records, and
then deploy the SPF record.

Only a few DNS admins have updated to BIND 9.9 by now, I'm curious about
the effect once BIND 9.9 will be in the big Linux server distros
(RedHat, Ubuntu-Server, SLES ...). Maybe the SPF to TXT ration will
change when that happens. 

-- Carsten

---

From: Hector Santos <[email-masked]>
Date: Sat, 24 Aug 2013 11:17:37 -0400

+1 to all your points.

Plus a visible Microsoft DNS support out of the box would also 
encourage Windows tools developers to support it.

Where is Microsoft in these IETF DNS forums? Does anyone have a direct 
contact with the current MS DNS Product Manager?

An awful lot of guessing going on when this can be resolved in no 
time.  Its not just about SPF type99 support, but also RFC3597 and 
future support for new RR type proposals.

--
HLS

---

From: "John R Levine" <[email-masked]>
Date: 24 Aug 2013 12:40:16 -0400

> The current support in GUI tools should not be the guide for a standards

The dnsext regulars have been denying for years that provisioning is an 
issue, so it's dismaying but not surprising to see that hasn't changed.

Ten years ago when SPF was new, its designers considered and rejected 
using a _spf prefix because so many of the provisioning systems that mail 
managers had to use to provision real mail systems didn't permit 
underscores in names.  That particular bug has been fixed, but support for 
type 99, seven years after the RR was defined, is where the underscores 
were a decade ago.  A few provisioning systems handle it, most don't, so 
in practice people can't use it.  You can tell your students to use it, 
but when they get back to their offices, their system managers will tell 
them sorry, can't do that.  What use is that?

Someone pointed out some mail exchanges earlier this year where users 
asked providers for type 99 support, and the providers said they'd wait to 
see what the IETF did.  This tells us two things: one is that after seven 
years, providers still consider type 99 to be entirely optional, but the 
more important is that adding new RRs to provisioning systems is still 
much too hard.  (If it were just adding three lines to a table, I expect 
the providers would have done so rather than arguing with their users.)

Regards,

PS: Something like my dns extension proposal should allow providers to fix 
the new RR configuration problem once and for all, so I've always been 
surprised at the hostile reception to it.

---

From: Hector Santos <[email-masked]>
Date: Sat, 24 Aug 2013 12:54:00 -0400

John R Levine wrote:

> PS: Something like my dns extension proposal should allow providers to 
> fix the new RR configuration problem once and for all, so I've always 
> been surprised at the hostile reception to it.

Will it or can it work with Microsoft DNS servers?  They are part of 
the world too.

--
HLS

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 24 Aug 2013 14:01:30 -0400

> 	sounds like the tradeoff between code complexity and network latency...

Except that as a matter of fact, one of them is very likely to be
needless cost.  That is, you're going to need to cope with the TXT
record _anyway_, because that's what's deployed everywhere.  So you
have to pay cost of code complexity for demuxing no matter what.  The
question is only whether we'll still have the code complexity of
handling two RRTYPEs and have the additional latency of the extra
lookup.  This is exactly the question the WG looked at, and concluded
that it was a bad trade.  This is all in the WG list archives, and you
are making no new argument.

> 	(is there a statement from the "one who _was_ doing something" as to 

Not to my knowledge.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 24 Aug 2013 14:39:39 -0400

On Aug 23, 2013, at 9:40 PM, David Conrad <[email-masked]> wrote:

> As far as I can tell, the issue isn't whether the SPF RR is being used (it appears to be, albeit at a tiny percentage relative to TXT currently), rather it's whether or not a handful of major mail service providers will use SPF RRs in the future if the IETF were to document a fix to the broken transition strategy in 4408. 

[not to counter your statement above, but rather to pile on...]

I'm just a simple email user and not involved in the email world, but ISTM it's not just what major mail service providers use, but major mail servers/MTAs as well - for example those used by the corporate world.  MS Exchange, for example, and any "front-end" spam-filtering-thingies put between it and the Internet.  And other corporate-market-focused server vendors.  No?  

My employer's email server products, for example, appear to only do type-16 TXT SPF queries. (though I could easily be wrong on that - it's just what I see in the publicly-accessible user docs)  Likewise that's what it appears to be for MS Exchange, of various versions, though again I could be wrong.

-hadriel
disclaimer: this email does not represent Oracle in any way, I am merely speaking as an individual.  Oracle products may well do type-99 checking already today, or in the near-future, for all I know.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 24 Aug 2013 14:40:06 -0400

> of the rest of the latency is gone.

I don't follow that logic.  I work for a vendor that makes an MTA.  As far as I can tell from publicly-accessible docs, it only does type-16 today.

If I were to put myself in a product manager's shoes, I don't see any reason I'd implement a type-99 check.  Obviously if type-99 was the *only* RR available from some significant population of domains, we might change our MTA to also do a type-99.  But if everyone makes TXT type-16 available in DNS as well, what motivation would we have to do type-99 first, or even at all?  Why would we bother with the additional overhead?  I mean if you didn't have a type-16 SPF in your DNS, what are the odds you have a type-99?

It's not as simple as: "but the code is easy to write".  For one thing any functional change in commercial products is far more work and cost than just a developer changing some lines of code.  For another, customers don't really care about IETF RFC conformance checklists much - they care about things working.  Adding processing or delay overhead has to provide some new real benefit, for them.  Pain for no gain makes no sense, to both vendors and their customers.

And if major MTA vendors and providers only do type-16 checks, what motivation is there for people to stop putting type-16 in their DNS?  You'd want *everyone* to be able to check your domain's SPF, I would think.  Not just those querying for type-99.  Right?

-hadriel

---

From: "John Levine" <[email-masked]>
Date: 24 Aug 2013 20:12:58 -0000

>Will it or can it work with Microsoft DNS servers?  They are part of 

I don't see why not, if Microsoft wanted to implement it.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 24 Aug 2013 20:17:43 -0000

>have to pay cost of code complexity for demuxing no matter what.

Actually, it's worse than that.  The SPF rules for handling type 16
and type 99 records are identical, so you have to make the same checks
that there's exactly one record with the SPF prefix tag for type 99
records as you do for type 16.  You pay the demux penalty, such as it
is, for both.

In practice, there are likely to be fewer type 99 records than type
16, but the CPU time for the checks is trivial compared to everything
else a mail server does. We've seen at least one live example of
invalid type 99 records that would fail the checks here in the past
week, so the checks are not wasted effort.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Sun, 25 Aug 2013 07:33:56 +1000

In message <[email-masked]>, "John R Levine" wri
> issue, so it's dismaying but not surprising to see that hasn't changed.

The problem is no one is doing maintenance on some of those tools.
The number of RR types was expected to grow from day one.  New RR
types have been added at a rate of about 1 a year for the entire
history of the DNS.

It doesn't help when companies charge 500% more to allow you to
enter a SPF record.  Yes that is bundled with a whole lot of other
stuff but if all you want is the ability to add SPF it is going to
cost you 500% more.

Part of the problem is people don't know they be being badly treated
by their registrars.  They don't know that there should be AAAA and
DNSSEC support in the GUI's.

If registrars were to lose acceditation if they didn't add support
for a record within 3 years of it being allocated you would see a
big difference.

People keep saying leave it to market forces.  Market force only really
work when the market is properly informed.  The great unwashed out there
are not informed.  The same thing can be said of many of the registrars.

> the providers would have done so rather than arguing with their users.)

It also tells us if we were to say MUST lookup up SPF then they would add
support.

> fix

---

From: SM <[email-masked]>
Date: Sat, 24 Aug 2013 15:12:24 -0700

Hi Mark,
>The problem is no one is doing maintenance on some of those tools.

Yes.

>DNSSEC support in the GUI's.

Yes.

>for a record within 3 years of it being allocated you would see a

It's unlikely that it will happen.

>are not informed.  The same thing can be said of many of the registrars.

Yes.

There are things that can be changed.

Regards,
-sm

---

From: Joe Abley <[email-masked]>
Date: Sat, 24 Aug 2013 16:10:42 -0700

> DNSSEC support in the GUI's.

You're conflating registrars with DNS providers.

Registrars are agents who maintain database records in a registry on behalf of registrants. They have no direct relationship to the DNS.

Name service providers publish zones on behalf of zone managers. Some such providers expose provisioning interfaces, and I presume those are the interfaces you are lamenting about.

> for a record within 3 years of it being allocated you would see a

The 2013 ICANN Registrar Accreditation Agreement mandates DNSSEC and IPv6 support for registries that support them, and for registrants that request them. Again, this is a database issue. The existence of novel RRTypes has no relevance here, until the time where we see RRTypes other than A, AAAA, NS and DS provisioned for registrants in the zones registries publish.

Note that the context here is gTLDs; ccTLDs make their own arrangements with registrars.

> are not informed.  The same thing can be said of many of the registrars.

DNS providers are not regulated in the sense that gTLD registrars are. If you're suggesting that they should be regulated, then I doubt this is an appropriate venue for that discussion.

People still have the ability to host their domains themselves.

Joe

---

From: "John R Levine" <[email-masked]>
Date: 24 Aug 2013 19:43:57 -0400

> It also tells us if we were to say MUST lookup up SPF then they would add

I salute your wry sense of humor.

R's,
John

---

From: Eric Brunner-Williams <[email-masked]>
Date: Sat, 24 Aug 2013 16:58:26 -0700

> for a record within 3 years of it being allocated you would see a
The word you're looking for is "accreditation", and it comes with a five 
year contract, at least w.r.t. ICANN and its contractual parties, so 
introducing an automatic, and unilateral breach condition would be 
necessary to satisfy your ... hypothetical.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 24 Aug 2013 17:29:35 -0700

> You're conflating registrars with DNS providers.

Indeed I find myself unclear about the purpose and utility of this 
rather lengthy thread.

Perhaps someone can summarize?

For example does it pertain to some sort of long-term effort at DNS 
enhancement or does it pertain to the document that triggered it, or 
both or neither?

d/

---

From: Måns Nilsson <[email-masked]>
Date: Sun, 25 Aug 2013 18:27:47 +0200

> I don't see why not, if Microsoft wanted to implement it.

Which is sort of interesting thing to read when we've heard repetitions ad
nauseam that advocate broken design because Microsoft will never implement
anything without being forced to by procurement rules. (IMNSHO the DNSSEC
"support" in 2008 Server is just there to check the boxes for USGOV
procurement rules. I think. Noone reasonably sane runs DNSSEC on that. )

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I can't decide which WRONG TURN to make first!!  I wonder if BOB
GUCCIONE has these problems!

---

From: Måns Nilsson <[email-masked]>
Date: Sun, 25 Aug 2013 19:01:39 +0200

> enhancement or does it pertain to the document that triggered it, or

Given, 

* that we're in DNSEXT, 

* that there exists a large (according to themselves) body of
  people/organisations that are unaware/unable of proper DNS 
  operation and standards,

Yes. There is, because there must be, a continous effort to channel and
guide the lemming population to the proper cliff. The current thread
can be viewed as a tactical operation in the overall strategy.

The document that trigged this is indeed relevant, because it is an
especially clear case of the ignorance that threatens DNS.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Well, here I am in AMERICA..  I LIKE it.  I HATE it.  I LIKE it.  I
HATE it.  I LIKE it.  I HATE it.  I LIKE it.  I HATE it.  I LIKE ...
EMOTIONS are SWEEPING over me!!

---

From: Jay Daley <[email-masked]>
Date: Mon, 26 Aug 2013 08:06:16 +1200

> I salute your wry sense of humor.

Sorry John I think Mark is quite right.  The position of "we're waiting for the IETF" can only be interpreted one way - if the IETF mandates the SPF record lookup then those manufacturers will implement that.  As you and others have pointed out it is most likely a trivial code change given almost all of the logic is there.  They just need a reason to do it and an IETF mandate is as good a reason as there is.

To me this debacle is a failure of will.  The will to define and stick to an architecture.  A dose of MUST every now and then in cases like this would strengthen the IETF not weaken it.

Jay

---

From: Dave Crocker <[email-masked]>
Date: Sun, 25 Aug 2013 14:08:49 -0700

> To me this debacle is a failure of will.  The will to define and stick to an architecture.  A dose of MUST every now and then in cases like this would strengthen the IETF not weaken it.

I'm sure you have plenty of examples to cite, where such changes in 
standards language have brought about changes in market behavior? 
Please do cite them.

d/

---

From: "John Levine" <[email-masked]>
Date: 25 Aug 2013 21:20:42 -0000

>  people/organisations that are unaware/unable of proper DNS 

Believe it or not, there are some people who understand the DNS
perfectly well, but see it as a tool to get work done rather than an
arena to score debating points.

R's,
John

---

From: Jay Daley <[email-masked]>
Date: Mon, 26 Aug 2013 09:23:24 +1200

On 26/08/2013, at 9:08 AM, Dave Crocker <[email-masked]> wrote:

> I'm sure you have plenty of examples to cite, where such changes in standards language have brought about changes in market behavior? Please do cite them.

The only evidence about behaviour that actually matters here was posted earlier:

Jay

---

From: Dave Crocker <[email-masked]>
Date: Sun, 25 Aug 2013 14:43:49 -0700

Jay,

Sorry my query wasn't clear enough.

I'm not asking about the excuses that a couple of implementers are 
using, many years after a specification was published -- for why they 
have not yet implemented a portion of the spec, 7 years after it was 
published.

You are proposing some language changes and you are claiming that the 
changes will produce much greater implementation.

So I am asking when this has occurred in the past, which would therefore 
provide an empirical basis for believing it likely to happen now.

The point behind the query is to solicit some actual evidence that might 
reasonably counter the 7-year adoption failure of the SPF RR.  Evidence, 
that is, that goes beyond /non-implementation/ excuses.

d/

---

From: Andras Salamon <[email-masked]>
Date: Sun, 25 Aug 2013 23:28:47 +0100

>standards language have brought about changes in market behavior? 

I don't know whether there are many examples or not, but ISC and
Nominum seem to add new RRtypes to BIND whenever an RFC is published
defining them, regardless of who employs the authors of the RFC.
Last I checked, variants of BIND ran a large proportion of publicly
visible DNS servers on the Internet.

So we do have at least an existence proof that there are vendors
that proactively respond to standards.  Perhaps this is a way
to differentiate themselves from other vendors that use "ignore"
to complement an "embrace-extend-extinguish" strategy, but I don't
really care why -- the fact is examples exist.

I agree that the dynamics of "build it and they will come" are not
always applicable.  But this dynamic is also not always completely
inapplicable.

---

From: Jay Daley <[email-masked]>
Date: Mon, 26 Aug 2013 10:30:35 +1200

On 26/08/2013, at 9:43 AM, Dave Crocker <[email-masked]> wrote:

> The point behind the query is to solicit some actual evidence that might reasonably counter the 7-year adoption failure of the SPF RR.  Evidence, that is, that goes beyond /non-implementation/ excuses.

Dave, I think you are being unfair to those implementors.  Almost all implementors I know take the approach that they only implement what they have to implement to make a "minimum viable product".  RFC4408 allowed them to only implement TXT and say "Yes, we support SPF and yes we are standards compliant".  

Seven years later and nothing has changed that makes their product any less viable so there's been no reason for them to change.  RFC6686 has even reduced any future need to change.  To me there's been no failure by implementors and no excuses are necessary because their behaviour has been *entirely rational*. And I might add, *entirely predictable*.

Issue an RFC that requires type 99 and they will be entirely rational again and ask "Do we want to remain standards compliant and how easy is it to remain so?".  The answer to the second part we know is "trivial".

Jay

---

From: Dave Crocker <[email-masked]>
Date: Sun, 25 Aug 2013 15:42:16 -0700

On 8/25/2013 3:30 PM, Jay Daley wrote:
>> The point behind the query is to solicit some actual evidence that
>> might reasonably counter the 7-year adoption failure of the SPF RR.
>> Evidence, that is, that goes beyond /non-implementation/ excuses.
>
> Dave, I think you are being unfair to those implementors.

My unfairness is in pressing you to substantiate the premise for your
original assertion. I've explained the request twice.

After two iterations, you still have not responded to that.

One last time:  when has revising a spec altered the further use of 
features that had so far gained little adoption?

d/

---

From: David Conrad <[email-masked]>
Date: Sun, 25 Aug 2013 15:52:39 -0700

On Aug 25, 2013, at 3:42 PM, Dave Crocker <[email-masked]> wrote:
> One last time:  when has revising a spec altered the further use of features that had so far gained little adoption?

3225 revising 2535 and/or 403x replacing 2535?

Regards,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 25 Aug 2013 19:00:12 -0400

> defining them, regardless of who employs the authors of the RFC.

Yes, and virtually every DNS server system actually does in fact cope
with TYPE99 records.  That is nowise an argument that saying, "Use
TYPE99, darnit," will actually change the world.

I find myself disagreeing with Dave way more often than not, but on
this point I think he's quite right.  We have a functioning system
that's actually deployed, as far as anyone has argued.  It is far from
perfect, but it works.  Those who think that the spec ought to be
changed to reflect some other desired behaviour are responsible to
provide evidence that the mere publication of an RFC -- one that
recommends against the overwhelming widely-deployed practice in favour
of something else -- are indeed responsible to show why that
publication would have the requisite effect.  Even one example would
suffice.  Like Dave, I'm having a hard time coming up with one.

As I've said before, I'm mighty unhappy about this.  But the world is
as it is.  Rather than fighting old battles, I'd like us to focus on
making this never happen again.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Sun, 25 Aug 2013 16:21:33 -0700

Andrew,

On Aug 25, 2013, at 4:00 PM, Andrew Sullivan <[email-masked]> wrote:
> We have a functioning system that's actually deployed, as far as anyone has argued.  It is far from perfect, but it works.

The original version of HTTP was a deployed, functioning system that despite being far from perfect, worked. The original protocol (the one without persistent connections) also had unpleasant side effects (see http://www.ibiblio.org/mdma-release/http-prob.html if you'd like a refresher).  

However, instead of saying "deployed systems, no server operator has any incentive to change, let's just accept the status quo and make sure it doesn't happen again", the protocol was modified and people have largely migrated to the new protocol over a large number of years (still vestiges of the old protocol out there, but definitely a minority).

> Even one example would suffice.

I suspect this won't matter. People's minds are made up.

Regards,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 25 Aug 2013 19:29:02 -0400

> 3225 revising 2535 and/or 403x replacing 2535?

Surely we're not so wedded to the in-band signalling of DNS that we
can't distinguish beween management of the DNS itself, and
applications using the DNS?  I studied the Sophists, too, but I don't
think they tell us how to work.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 25 Aug 2013 19:46:38 -0400

> I suspect this won't matter. People's minds are made up.

Actually, mine isn't.  That's an interesting example.  What would be
helpful to me is an understanding (and I really don't have any) of why
you think the analogy actually shows we ought to move to type-99
instead ot sticking with type-16.

As I understand the http/1.0 vs /1.1 trade-off, the 1.0 server
suffered latency disadvantages as opposed to 1.1.  Therefore, there
was an automatic incentive to support 1.1 as soon as possible, even if
no client supported it, because for any client that supported it there
was an automatic advantage in latency.  At the same time, there was an
incentive for every client to support 1.1, because if the server did
there was a latency advantage.  And because of the signalling
available by virtue of the header, http sessions could downgrade
without starting all over.  I'm completely prepared to be corrected on
any of this, since I wasn't involved and when it was an issue I was
only remotely involved in the effects (i.e. I was an http enthusiast
as someone who thought the web was cool, but I was a philosophy
student.  I thought smarter people than I would fix it, and they did).

The proposal in the SPF case doesn't seem to match this.  Because DNS
is connectionless, we don't have a way to downgrade depending on what
the querying agent says it can do.  The counter-examples -- DNAME and
DNSSEC are the obvious cases -- actually show what a big deal this
is.  So the transition strategy in this case involves every actor
either paying a cost up front with no direct benefit, or else a
strategy that prefers the pre-transition state with the desired state
a second-best alternative.  This seems like a significant difference
to me.  What did I miss?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Sun, 25 Aug 2013 16:47:27 -0700

> 3225 revising 2535 and/or 403x replacing 2535?

1.  Given how poor the adoption of DNSSec continues to be, are you sure 
you want to offer that as an exemplar of success?

2.  Given how problematic /any/ adoption of DNSSec was back then and 
that it only started to gain significant traction after massive 
additional work and in much more recent years, I guess I don't see how 
this qualifies as the type of example I was asking for.

On 8/25/2013 3:28 PM, Andras Salamon wrote:
 >   ISC and
...
 > that proactively respond to standards.

Please re-read my query.  This wasn't what I was asking about.

d/

---

From: David Conrad <[email-masked]>
Date: Sun, 25 Aug 2013 16:50:17 -0700

Andrew,

On Aug 25, 2013, at 4:29 PM, Andrew Sullivan <[email-masked]> wrote:
> applications using the DNS?  

Err, what?

The question posed ("one last time") was:

"when has revising a spec altered the further use of features that had so far gained little adoption?"

I was answering that question. The fact that it is specific to features of the DNS has more to do with what was off the top of my head than being wedded to "in-band signaling of the DNS" (whatever that means).

The point here is that protocols evolve all the time as we learn what's a good idea and what isn't. You (and others) appear to be arguing that protocols that get deployed and gain some level of acceptance, even as "Experimental", are cast in stone and that the IETF must be forbidden from modifying them unless there is explicit evidence that markets will _immediately_ seize upon those modifications. I think that view is broken.

Regards,
-drc

---

From: Jay Daley <[email-masked]>
Date: Mon, 26 Aug 2013 12:07:00 +1200

On 26/08/2013, at 11:46 AM, Andrew Sullivan <[email-masked]> wrote:

> [a whole bunch of stuff I've snipped that was well reasoned and surprisingly succinct for a philosophy student]
> ...
> So the transition strategy in this case involves every actor

You almost got it Andrew, it's the answer to the one question - "If we mandate type 99 then what motivates users at both ends to implement it?" with due consideration to any difficulties they might encounter.

The motivation for implementors would be to stay standards compliant and there would be few difficulties because the code changes are minor.

The motivation for end users would also be to stay standards compliant and once the implementors support it then there would be little difficulty.

There's a simple, rational, causal chain here

- users don't use type 99 because implementors don't support it
- implementors don't support type 99 because they don't have to
- they don't have to because the RFC says they don't have to

Change the root premise and the motivation is there for the rest to flow through with no real barriers in the way.

Jay

---

From: Dave Crocker <[email-masked]>
Date: Sun, 25 Aug 2013 17:26:30 -0700

On 8/25/2013 4:50 PM, David Conrad wrote:
> The point here is that protocols evolve all the time as we learn what's a good idea and what isn't. You (and others) appear to be arguing that protocols that get deployed and gain some level of acceptance, even as "Experimental", are cast in stone and that the IETF must be forbidden from modifying them unless there is explicit evidence that markets will_immediately_  seize upon those modifications. I think that view is broken.

That's not the issue here.  The issue here is a claim that merely by 
changing the normative text, a mechanism will get widely implemented, in 
spite of

    a) a long track-record of not getting implemented, and

    b) no incremental value to the implementer.

That's not 'learn[ing] what's a good idea'.

It's merely an attempt to manipulate through a documentation artifact.

d/

---

From: "John Levine" <[email-masked]>
Date: 26 Aug 2013 01:11:38 -0000

>The point here is that protocols evolve all the time as we learn what's a good idea and what isn't. You (and others) appear to be
>arguing that protocols that get deployed and gain some level of acceptance, even as "Experimental", are cast in stone and that the
>IETF must be forbidden from modifying them unless there is explicit evidence that markets will _immediately_ seize upon those
>modifications. I think that view is broken.

No, it's the converse.  When protocols are deployed and widely
accepted, if someone wants to make changes that have NO OPERATIONAL
ADVANTAGES WHATSOEVER, it's up to the proponents to explain why the
world will adopt them.  King Canute and all that.

The practical operational advantages of http/1.0 and /1.1 over /0.9
were obvious.  The advantages of SPF type 99 over type 16 were purely
hypothetical in 2006 and equally hypothetical now.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 25 Aug 2013 21:28:57 -0400

> The motivation for end users would also be to stay standards compliant and once the implementors support it then there would be little difficulty.

That's just not a motivation.  There is _no_ business case to conform
to any standard unless it's mandated in RFPs.  This very fact is what
allows the IETF to continue on its merry way despite the desire of
Official Bodies to try to legislate the value of pi and other such
things.  There is no first-, or even any-mover advantage to changing
from type-16 to type-99 in the scenario you provide, except for people
who are otherwise regulated.  

> - users don't use type 99 because implementors don't support it

Your "users" chain is wrong.  There are _two_ kinds of users, and both
ends need to do something before there is any value at all.  That's
the problem, and why the comparison to http 1.0 vs 1.1 seems to me to
be troublesome.

More generally, and not aimed at Jay in particular: without trying to
come across as impatient or dismissive, I have to say that I'm getting
worn out by arguments rehashing exactly the issues that were hashed,
mostly by me in the hot seat, on the SPFBIS list.  I tried _all_ these
arguments, and I conceded in the end because I didn't have a leg to
stand on.  If people have a new one to present, I'd be delighted to
encounter it.  But since I'm bearing all the wounds from the SPFBIS
battle, it'd be nice if erstwhile supporters of the position I tried,
with little help, to defend would at least work through the arguments
that were already presented.  This isn't religion: I'm as sickend by
this use of TXT as anyone.  But the world makes us as much as we make
the world, and I think the TXT fight _in this case_ is lost.  I also
think that NATs are a fact of the world, that NAT64/DNS64 is better
than NAT-PT, and so on.  We've reached sufficient thrust.  Do we
really want to stand around where the pig is going to land?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Dickson, Brian" <[email-masked]>
Date: Mon, 26 Aug 2013 03:36:44 +0000

At the risk of ridicule, and in the interest of potentially useful results:

Why not deprecate TXT, or at least abandon the current TXT and introduce
a new TXT code point? And, as each iteration gets trashed, move on to the
next one?

It's not like there is a shortage of type code values, and it is not like
the RDATA of TXT is complicated, or in any way is required to be unique.
SPF is, after all, exactly the same as TXT except for being different.

If SPF want to take over TXT, let them. We can all move to TXT2, until
someone ruins it, and then we can introduce TXT3, etc.

I realize it is rather silly, but if it works, and it disambiguates things,
the fact that it _is_ silly is perhaps not the greatest reason for not
doing it.

This might provide a small clue to the next group of other-protocol folk,
that using TXT instead of asking for their own RRTYPE, is foolish, unwise,
and likely to result in having a new RRTYPE lobbed at them in retaliation.
:-)

(My two cents, late to the discussion.)

Brian

On 8/25/13 9:28 PM, "Andrew Sullivan" <[email-masked]> wrote:

>> The motivation for implementors would be to stay standards compliant
>>and there would be few difficulties because the code changes are minor.
>> 
>> The motivation for end users would also be to stay standards compliant
>>and once the implementors support it then there would be little
>>difficulty.
>> 
>

---

From: Dave Crocker <[email-masked]>
Date: Sun, 25 Aug 2013 21:19:21 -0700

> a new TXT code point? And, as each iteration gets trashed, move on to the

installed base.

d/

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 26 Aug 2013 09:40:51 +0200

> arena to score debating points.

It IS a tool -- like all the other protocols. But just as my spanner
is rusty because I left it out by the pool tools that aren't cared for
will lose their usefulness. A spanner I can buy again; but the DNS is
not a stocked item.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I've got a COUSIN who works in the GARMENT DISTRICT ...

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Aug 2013 00:30:55 -0400

> visible DNS servers on the Internet.

Nominum's DNS servers (we have an authoritative server and a caching resolver, which are separate products) do not share any code with BIND.    The problem here is not DNS server vendors—it is consumers of SPF records.

---

From: [email-masked]
Date: Mon, 26 Aug 2013 20:15:40 +0000

On Sun, Aug 25, 2013 at 05:26:30PM -0700, Dave Crocker wrote:
> >The point here is that protocols evolve all the time as we learn what's a 
> >good idea and what isn't. You (and others) appear to be arguing that 
> >protocols that get deployed and gain some level of acceptance, even as 
> >"Experimental", are cast in stone and that the IETF must be forbidden from 
> >modifying them unless there is explicit evidence that markets 
> >will_immediately_  seize upon those modifications. I think that view is 
> >broken.
> 
> 

Changes in text does have an effect on implementation.  See, (for example)
The National Technology Transfer and Advancement Act (NTTAA) from about 1995 
requires all Government Agencies to use industry consensus standards.

/bill

---

From: Dave Crocker <[email-masked]>
Date: Mon, 26 Aug 2013 13:18:18 -0700

> requires all Government Agencies to use industry consensus standards.

Bill, I wasn't asking an academic question about global, theoretical 
absolutes.  I was asking about IETF experience... with IETF documents.

Let's try to stay focused on the issue at hand.

d/

---

From: Chip Marshall <[email-masked]>
Date: Mon, 26 Aug 2013 16:45:51 -0400

On 2013-08-23, Andrew Sullivan <[email-masked]> sent:
> I am an SPF validator. On day 0, there are very few people
> publishing SPF-99 records, and many publishing SPF-16 records.
> I have a lot of mail volume coming in. What is my incentive to
> embrace SPFCheckNG? Please address the latency effects for
> large mail operators.

I'm not sure I fully understand the latency argument here.
Wouldn't you just fire off the SPF-99 and TXT-16 queries
asynchronously? Waiting for two answers shouldn't be much longer
than waiting for one answer when done in parallel.

And long term, wouldn't there be benefits from not having to sift
through any other TXT records you receive for the ones that look
like SPF records?

-- 
Chip Marshall <[email-masked]>
http://2bithacker.net/

---

From: S Moonesamy <[email-masked]>
Date: Mon, 26 Aug 2013 13:53:08 -0700

Hi Chip,
>than waiting for one answer when done in parallel.

See http://www.ietf.org/mail-archive/web/spfbis/current/msg00876.html

Regards,
S. Moonesamy

---

From: "John Levine" <[email-masked]>
Date: 26 Aug 2013 21:12:46 -0000

>than waiting for one answer when done in parallel.

If your DNS library permits, sure, you can do them in parallel.  But
experience has shown that due to cruddy middleboxes or the like, type
99 queries get lost and time out more than you might think.  If the
type 16 query doesn't give you a usable SPF record, you have to wait
for the type 99 query.  People who run large mail servers tell me the
slowdown is noticable.

>through any other TXT records you receive for the ones that look

In a word, no.  The SPF rules for handling type 16 and type 99 records
were identical: there has to be exactly one record that starts
"v=spf1".  You have to look at all the records to be sure that there
aren't multiple v=spf1 records (which invalidates all of them) and
once you're doing that, ignoring the ones that don't have the right
prefix is about three lines of code in a multi thousand line library.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Tue, 27 Aug 2013 10:27:06 +1000

In message <[email-masked]>, "John Levine" writes:
> >The point here is that protocols evolve all the time as we learn what's a go
> od idea and what isn't. You (and others) appear to be
> >arguing that protocols that get deployed and gain some level of acceptance, 
> even as "Experimental", are cast in stone and that the
> >IETF must be forbidden from modifying them unless there is explicit evidence
>  that markets will _immediately_ seize upon those

They have a operational advantage especially over the long term or
if you consider the overall maintenance of DNS records for a site.
This has been demostrated several times.  Do you think we would be
having this argument if there was not a operational advantage?

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Aug 2013 10:25:34 -0400

Well if we're going to risk being ridiculed, I'll go all-in. :)

At one time I had thought along the same lines - not to deprecate TXT, but rather to just say: "let's go pre-allocate a dozen new RR Types, and tell DNS servers to implement them, with undefined-text-content, and we give them random acronym names, and future IETF mechanisms can go use them on a first-come-first-served basis; and those future IETF specs can figure out a backronym expansion for the acronyms, and define what the text-content formatting is, etc."

But from reading the problems SPF listed in RFC 6686 and the emails from SPFBIS folks, I don't think that would solve the problem, even if by some miracle all DNS servers on the planet supported the new RRs.  There're just too many other DNS-related-things involved. (DNS servers and registries, and their provisioning interfaces, and DNS resolvers/caches, firewalls, CGN middleboxes, client libraries and their APIs...)

So here's the to-be-ridiculed part...
I suggest a new strategy: let the wookie win.  Instead of denying their existence, accept that there will be more folks who want to deploy new DNS-using applications quickly and without waiting for the entire Internet of DNS-related-things to change.  It's going to happen whether we want it to or not.  So we might as well try to fix whatever problems we envision it will cause, and provide guidance of how to use TXT the best way.  Right now RFC 5507 only warns folks against it, but I don't see a "if you are going to use TXT anyway, then do it this way" type thing.  Nor do I see an IANA registry of prefix names, nor an RFC describing a general solution to the wildcarding problem when prefixing.  I think those things are possible, maybe.

We can require abstinence or we can give out condoms.  Which one do you think is more likely to prevent spread of disease?

-hadriel

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 27 Aug 2013 07:44:21 -0700

> But from reading the problems SPF listed in RFC 6686 and the emails from SPFBIS folks, I don't think that would solve the problem, even if by some miracle all DNS servers on the planet supported th…

Fortunately, for MOST such boxes, they do actually handle unknown resource records right (we've been testing that with Netalyzr for almost forever, with type 169 on transport, and 1169 on probes to configured recursive resolvers).  Namely because the protocol is actually designed right in that respect: its actually easier to handle ALL types in a generic manner after special casing the FEW types that allow name compression.

Thus it really is that the major problem is provisioning, not transport, of unknown DNS types.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 27 Aug 2013 17:10:42 +0200

> Thus it really is that the major problem is provisioning, not transport, of unknown DNS types.

This is indeed interesting data that "complicates" the IMNSHO
sweeping statements of 6686. The provisioning problem remains, but the
infrastructure is not as broken as stated.

Or? 

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
... I think I'd better go back to my DESK and toy with a few common
MISAPPREHENSIONS ...

---

From: Mark Andrews <[email-masked]>
Date: Wed, 28 Aug 2013 01:23:59 +1000

In message <[email-masked]>, Hadriel Kaplan wr
ites:
> At one time I had thought along the same lines - not to deprecate TXT, but ra
> ther to just say: "let's go pre-allocate a dozen new RR Types, and tell DNS s
> ervers to implement them, with undefined-text-content, and we give them rando
> m acronym names, and future IETF mechanisms can go use them on a first-come-f
> irst-served basis; and those future IETF specs can figure out a backronym exp
> ansion for the acronyms, and define what the text-content formatting is, etc.
> "
> 
> But from reading the problems SPF listed in RFC 6686 and the emails from SPFB
> IS folks, I don't think that would solve the problem, even if by some miracle
> all DNS servers on the planet supported the new RRs.  There're just too many
> other DNS-related-things involved. (DNS servers and registries, and their pr
> ovisioning interfaces, and DNS resolvers/caches, firewalls, CGN middleboxes, 
> client libraries and their APIs...)

There are DNS servers that completely support arbitary types.  And
have for over a decade.  Before that they could resolve and cache
arbitary types and have done so for over 20 years.  About the only
one that doesn't is that shipped by Microsoft.

There are DNS resolvers that support arbitary types and have been
able to for over 20 years.  This is basic RFC 1034 functionality.
Unfortunately Microsoft failed to read that part of RFC 1034 or
failed to understand it when they were developing their resolver
code.

Most firewalls don't care diddly squat about DNS record types.  For
those that do blocking unknown types in firewalls does diddly squat
for security and just cause problems for everyone.  Just turn the
DNS checking off.

NAT (carrier grade or otherwise) don't care about DNS message
content. 

Then there are provisioning systems which haven't been upgraded
since Noah was a boy and you don't have to use anyway.

> I suggest a new strategy: let the wookie win.  Instead of denying their exist
> ence, accept that there will be more folks who want to deploy new DNS-using a
> pplications quickly and without waiting for the entire Internet of DNS-relate
> d-things to change.  It's going to happen whether we want it to or not.  So w
> e might as well try to fix whatever problems we envision it will cause, and p
> rovide guidance of how to use TXT the best way.  Right now RFC 5507 only warn
> s folks against it, but I don't see a "if you are going to use TXT anyway, th
> en do it this way" type thing.  Nor do I see an IANA registry of prefix names
> , nor an RFC describing a general solution to the wildcarding problem when pr
> efixing.  I think those things are possible, maybe.
> 
> We can require abstinence or we can give out condoms.  Which one do you think
>  is more likely to prevent spread of disease?
> 
> -hadriel
> 
>

---

From: David Conrad <[email-masked]>
Date: Tue, 27 Aug 2013 08:43:45 -0700

> Thus it really is that the major problem is provisioning, not transport, of unknown DNS types.

I suspect one of the problems here is that in the universe of mediocrity that is the underlying infrastructure upon which applications that use the DNS rely, you have a bell curve of sorts of what works and what doesn't.  As a result, when you get into arguments about whether a protocol feature can be used, people can trot out the 5 sigma extremes and say e.g., "see, doesn't work - we have to use TXT". They're not necessarily wrong, but it does suggest that the ossification of the DNS is pretty much complete...

Regards,
-drc

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Aug 2013 11:56:01 -0400

> since Noah was a boy and you don't have to use anyway.

Actually, I know of at least one CGN that does.

But it doesn't really matter...  I think you're missing the point.  The point isn't that NONE support unknown RRs, the point is that SOME do not.  Of course a lot of things do support unknown RR types. 

So if you're a developer of some new thing, and you want everyone, everywhere, to be able to use your new thing, would you choose to use a new RR knowing some of your potential users can't use that?  Or would you choose to use something you know works for everyone everywhere?

It's a very hard thing to ignore a potential part of your target user base, or hope to force them to replace equipment or change DNS registries just to use your new thing.  It's a barrier to adoption most developers would want to avoid, I would think.

-hadriel

---

From: "John Levine" <[email-masked]>
Date: 27 Aug 2013 16:23:16 -0000

>infrastructure is not as broken as stated.

I know the guy who wrote 6686 and contributed some of the data.  We
were entirely aware that DNS servers other than Microsoft's have
little trouble with type 99, and the main problems are provisioning
software and middleboxes.

Why do you assume otherwise?

R's,
John

---

From: Jay Daley <[email-masked]>
Date: Wed, 28 Aug 2013 16:00:51 +1200

On 26/08/2013, at 1:28 PM, Andrew Sullivan <[email-masked]> wrote:

> This isn't religion: I'm as sickend by
> the world, and I think the TXT fight _in this case_ is lost.

Having thought about this for a few days I've changed my mind and I'm happy to see SPF(99)  go.  What clinched it for me was this note from Andrew above as it helped me realise my issue is with the misuse of TXT and not the solution of a new type specific to SPF.  So let's let it go and I'm sure with a bit of thought we can find a way to fix the overloading of TXT and try to sell that as a better migration path for "v=spf1" in TXT than SPF(99) ever was.

=  We know the issues can be summarised as:

1.  The key benefits people find from using TXT are
- it is well supported
- it is free form so any experimentation is possible and no standards body engagement is needed

2.  The key issues with the use of TXT are
- people not using prefixes and so conflating various uses (and as Hadriel points out, no prefix registry)
- the wildcard issue, which I'm going to restate as how to define a policy at one level that applies to lower levels, is a key reason for not wanting to use prefixes.

= So here's an example solution (and I mean an example since I'm sure there is a lot more to consider):

3.  Create a new generic record for free form policy data that must be prefixed by protocol.  For example:

_spf	.example.com.	POL	"a:mail.example.com -all"

If we provide that one record then anyone can use it for any policy info without further need to change the DNS.  To me that seems much more utilitarian than a protocol specific RR.

= A solution for the wildcard issue is a bit more complex, but here's an example

4.  Add an rdata field to the POL record that if set to "*" (asterisk) applies this policy to the next level

_spf.example.com. 	POL	*	"a:mail.example.com -all"

This record is then used to synthesise the POL record in exactly the same way that a wildcard is.

5.  Or we could add a record under each sub-domain that refers back up a level:

_spf.sub.example.com.	POLPTR	example.com.

Jay

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 Aug 2013 22:10:46 -0700

> Having thought about this for a few days I've changed my mind and I'm happy to see SPF(99)  go.  What clinched it for me was this note from Andrew above as it helped me realise my issue is with the…

Dear Jay,

The current SPF specification may require receivers to emit as many as 222 DNS transactions in an effort to aggregate required data.  In contrast, a well considered APL scheme should offer the needed data within one RRset transaction in binary form to support a store and forward protocol.

> - it is free form so any experimentation is possible and no standards body engagement is needed

Running complex scripts just above DNS is a security risk, especially when it represents experimentation where support is often limited a few advocates. 

> - the wildcard issue, which I'm going to restate as how to define a policy at one level that applies to lower levels, is a key reason for not wanting to use prefixes.

A prefix approach kills wildcard schemes.  Since overwhelming use of SPF establishes outbound address ranges for an email domain, TXT represents a remarkably inefficient approach.  Even the policy "all" is largely ignored.  DNS was never intended to offer heavily formatted textual data in the manner of HTTP.  Bulky data requires a reliable transport that introduce significant delay.  This would be silly since that is what is expected of the message transport.  In other words, bulk data is being carried by the wrong transport.

> _spf	.example.com.	POL	"a:mail.example.com -all"

Why? If POL is an alias for TXT, this disrupts _dmarc, _adsp, _atps that convey concise and small amounts of data at a prefix.

> _spf.example.com. 	POL	*	"a:mail.example.com -all"

Already being done as an "alignment" flag in other policy records.

> _spf.sub.example.com.	POLPTR	example.com.

sub.example.com could offer authoritative  policy for sub.example.com?  atps offers authorization for a list of domains using a hash label list.  Both small and fast. 

Regards,
Douglas Otis

---

From: "Jiankang Yao" <[email-masked]>
Date: Wed, 28 Aug 2013 16:07:36 +0800

From: Douglas Otis
Date: 2013-08-28 13:10
To: Jay Daley
CC: [email-masked] Group
Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF

>The current SPF specification may require receivers to emit as many as 222 DNS transactions in an effort to aggregate required data.  In contrast, a well considered APL scheme should offer the neede…

222 DNS transactions ?

any example about it?

---

From: Jay Daley <[email-masked]>
Date: Wed, 28 Aug 2013 20:08:57 +1200

Hi Douglas

> A prefix approach kills wildcard schemes.  Since overwhelming use of SPF establishes outbound address ranges for an email domain, TXT represents a remarkably inefficient approach.  Even the policy…

An interesting point of view, but orthogonal to my proposal.  People are already using TXT in the way you caution against and we aren't going to stop that except by deprecating TXT.  My proposal does not address whether or not this usage is a good idea but how we tidy split out some of that usage into a more manageable form.

> Why? If POL is an alias for TXT, this disrupts _dmarc, _adsp, _atps that convey concise and small amounts of data at a prefix.

It's not an alias for TXT, it's a semantically different record.  Disruption is prevented by use of a prefix registry.

> Already being done as an "alignment" flag in other policy records.

What are those?

> sub.example.com could offer authoritative  policy for sub.example.com?  atps offers authorization for a list of domains using a hash label list.  Both small and fast. 

The hashed list of labels is only appropriate in ATPS because a Verifier has a signature and wants to check the originator of that signature.  That's quite different from this case where the SPF verifier has an email from sub.example.com and wants to know what policy to apply.  It can't just take a punt that the policy to use is that of example.com and then construct a hash of that and check to see if it is listed.

BTW the irony of ATPS using a TXT record for this hashed label list may have escaped you.

Jay

---

From: "John Levine" <[email-masked]>
Date: 28 Aug 2013 16:12:26 -0000

>Having thought about this for a few days I've changed my mind and I'm happy to see SPF(99)  go. 

Whew!

>If we provide that one record then anyone can use it for any policy info without further need to change the DNS.
>To me that seems much more utilitarian than a protocol specific RR.

If it's prefixed, what's the advantage over TXT other than it isn't
TXT?  Once word gets out about it, I'd expect people to load it up
with all of the junk that people load into TXT.  You can be sure that
some bright bulb will use it without a prefix, arguing that's OK
because all of the other uses are prefixed so this won't collide.

>This record is then used to synthesise the POL record in exactly the same way that a wildcard is.

This seems awfully complicated, and would require non-trivial extra
code in every authoritative name server.

Seems to me that if we could provision new RRTYPEs with less pain,
they already do what we want, don't need extra demultiplexing, and
has predictable and useful wildcard behavior.  

Or if you want to open up the guts of the DNS, just make this work:

_prefix.*.foo.example.  TXT  "stuff about foo"

I figure it shouldn't take more than a decade to discover all of the
weird ways it interacts with NSEC3.

R's,
John

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 28 Aug 2013 13:52:09 -0400

> If we provide that one record then anyone can use it for any policy info without further need to change the DNS.  To me that seems much more utilitarian than a protocol specific RR.

Isn't that just TXT with a new name?  Why not just stick to TXT type-16?

> _spf.sub.example.com.	POLPTR	example.com.

That requires DNS server code to change, right?  That feels like a high barrier.

Thinking out loud, why couldn't we do this:

1) The IETF asks IANA to create a registry for name tokens, for use as domain name label prefixes, and "v=<name>" in TXT RDATA.

2) We pre-reserve the token "iana", which means we reserved a label prefix of "_iana", as well as "v=iana" as the first chars of the TXT RDATA.

3) We define an IETF RFC for this new "IANA" application, such that it is intended for other TXT-using applications to use, for the purpose of wildcarding and redirection.  So future apps don't need to re-do SPF's redirection stuff, but can instead use this new RFC's ABNF and rules to get redirection as well as wildcard support.  More importantly, it prevents cluttering of the apex.  The specific apps use their own registered name tokens for app-specific RDATA, but "iana" helps them for cases as shown below...

   *.example.com.                 MX      10      a.example.com
   *.example.com.                 TXT     "v=iana wildcard=_iana.example.com"
   _qux.example.com               TXT     "<qux-specific content>"
   _foo._iana.example.com.        TXT     "v=foo <foo-specific content>"
   _bar._iana.example.com.        TXT     "v=bar <bar-specific content>"
   _zoo._iana.example.com.        TXT     "v=iana redirect=_zoo.pwned.example.net"

This second "*.example.com" wildcard record is a normal TXT wildcard record, and thus causes a synthesized TXT RR to be returned for name queries where no name exists.  The returned RR is exactly what it is today for TXT RRs: the contents of the RDATA shown above.

There is NO change to DNS servers or client libraries required whatsoever.

So a client querying for "_qux.example.com" gets back "<qux-specific content>" as today.

But a client querying "_foo.nonameexists.example.com" on the above would get back "v=iana wildcard=_iana.example.com".

The specific FOO application (not DNS) sees that, and if it supports our new RFC, knows to generate a new query for the wildcarded-to name, but with its specific application prefix added in front.  So it would now query "_foo._iana.example.com" and get its rdata content.

This would of course cause FOO to do two DNS queries, but only for cases where a wildcard is used.  DNS servers could (optionally) optimize to reduce it to one answer if they support this new "iana" RFC as well, by synthesizing the final answer.  But if they don't it sill works.

The only difference between "wildcard=" and "redirect=" is that "wildcard=<target>" makes the app prepend its name token prefix again to the identified target domain-spec, whereas in "redirect=<target>" it does not prepend its name token prefix to the target domain-spec. 

Why do all that above?  To keep too many TXT RRs from cluttering up the apex, while still letting them have wildcard support.  And by reserving our own "iana" application ABNF and use, we give sanctioned guidance on how new apps can do this without screwing it up for everyone else, and let that portion possibly be integrated in DNS servers someday.

-hadriel

---

From: Jay Daley <[email-masked]>
Date: Thu, 29 Aug 2013 09:09:02 +1200

Hi Hadriel

> That requires DNS server code to change, right?  That feels like a high barrier.

See my answer to John for the answers to those.

> 1) The IETF asks IANA to create a registry for name tokens, for use as domain name label prefixes, and "v=<name>" in TXT RDATA.

I really don't think we should be getting into defining the structure of data inside TXT records.  What if someone wants an all binary policy inside the TXT? (Like the hashed label list already mentioned for _atps).

> Why do all that above?  To keep too many TXT RRs from cluttering up the apex, while still letting them have wildcard support.  And by reserving our own "iana" application ABNF and use, we give sanc…

That would certainly be a workable solution fi you ignore my concerns on defining the structure I mention above.  The difference between that and what I suggested is that you've moved the wildcard into the data and the processing of the wildcard into the app not the server.  However, I believe we have clear evidence with the very limited uptake of NAPTR that RRs that define complex processing paths in the client are not the way forward.

cheers
Jay

---

From: Jay Daley <[email-masked]>
Date: Thu, 29 Aug 2013 09:00:08 +1200

Hi John

On 29/08/2013, at 4:12 AM, "John Levine" <[email-masked]> wrote:

> with all of the junk that people load into TXT.  

That's the whole point.  People are already loading up TXT with lots of stuff, we can't stop that, but we can tidy it up, make it more manageable and reduce unnecessary data being transferred.  Adding this is only going to help.

> You can be sure that

Not in an RFC they won't as we can control that.  Perhaps in practice yes but they can omit prefixes on SRV records and that didn't stop that RR.  Would you be happier if we renamed the record for PREfixed TeXT ~ PRETXT ?

> code in every authoritative name server.

This is *exactly* the same as existing wildcard support but with a different syntax and a prefix.  So not that complicated.  Not trivial no, but worth the pain.  It's also  a mechanism that has possible use in other new RRs.

> has predictable and useful wildcard behavior.  

Correct me if I'm wrong, but every DNS implementation already supports wildcarding.

> _prefix.*.foo.example.  TXT  "stuff about foo"

That's silly as you know.

But what I do think we should open up is whether wildcarding is enough.  As we know the point is to save people from the pain and waste of having to mirror RRs all over the place and the inherent dangers of missing one out.  But wildcarding only flows down and stops at the zone cut.  Perhaps we need to consider either a mechanism that doesn't stop at the zone cut (which radically changes server design) or a flow up mechanism.

cheers
Jay

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 28 Aug 2013 17:31:41 -0400

>From the peanut gallery:

On Thu, Aug 29, 2013 at 09:00:08AM +1200, Jay Daley wrote:
> 
> stops at the zone cut.  Perhaps we need to consider either a
> mechanism that doesn't stop at the zone cut (which radically changes
> server design) or a flow up mechanism.

Ted Lemon asked, when we shut down the DNSEXT WG, how long it'd be
before a new one started up.  I pooh poohed this, but the above sure
sounds to me like "DNSng" and "BoF fodder".

No, I am not willing to chair the BoF.  But I'll show up if someone
organizes it.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Aug 2013 22:22:59 +0000

> sounds to me like "DNSng" and "BoF fodder".

:)

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Aug 2013 09:50:07 -0400

> sounds to me like "DNSng" and "BoF fodder".

DNS Non-Extensions = DNSNEXT

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Aug 2013 10:31:36 -0400

> I really don't think we should be getting into defining the structure of data inside TXT records.  What if someone wants an all binary policy inside the TXT? (Like the hashed label list already men…

If someone doesn't want to follow a new RFC, then they don't.  That's up to them.  It's no worse than without the RFC.  If they want to follow it, they get the benefits it provides.  Even binary-rdata folks could follow this new RFC though... "v=iana " is just a sequence of octets after all. :)

> That would certainly be a workable solution fi you ignore my concerns on defining the structure I mention above.  The difference between that and what I suggested is that you've moved the wildcard…

Yes, complex processing = bad.  NAPTR is complex, and it's motivating use-cases aren't as popular to begin with. (Although as an aside, in my particular world NAPTR gets used a lot)

I don't think this would be as complex though.  And if an app doesn't need the redirection portion, they don't implement it.  If they do need it, the SPF-style processing for it seems like a pretty simple one, and that's all I'm proposing for redirection.  The wildcarding portion is a bit more tricky, in the sense that a newly defined application can't know whether it needs wildcard support or not really, afaict; so if the app clients don't implement it then folks will continue to fill the apex with app-specific records.  But that's true no matter what we do.  At least by defining a way for it to work, we make it possible to do it in a better "standard" way, and it's possible for the DNS server folks to eventually implement support for it too and avoid double-queries.

The major advantage of keeping with TXT over a new POL RR is there's no new RR required.  Getting a new RR usable everywhere on the planet seems to be a big challenge.  And it's not under the app-developer's control to affect that type of change, or timeframe for it.

-hadriel