Subject: TECH-ERROR: DNS Record Types

From: "Jim Lyon" <[email-masked]>
Date: Mon, 23 Aug 2004 17:09:13 -0700

I believe that the latest Protocol draft (draft-ietf-marid-protocol-03)
contains changes that don't correctly reflect the consensus of the group
concerning DNS record types. Briefly, it states:

1. Publishers MUST publish using the new SPF2 record type.
2. Publishers MAY also publish using TXT records.
3. Consumers MUST do lookups using the new SPF2 record type.
4. Consumers MAY also do lookups using TXT records.
5. Consumers MAY do both lookups (3 and 4) in parallel.
6. If consumers receive records from both lookups, they SHOULD use
   the SPF2 record and ignore the TXT record.

These are all in section 2.1.1 of the Protocol doc.

The problems with the above are:

a. It's not what was previously debated / agreed to.
b. Anyone who can't publish an SPF2 record cannot comply with this spec.
c. Anyone who can't look up an SPF2 record cannot comply with this spec.
d. Publishers who take the "MAY" in step 2 above to heart and don't
   publish TXT records will have their record be completely invisible
   to consumers that can't query for the new record type.

I respectfully request that the above requirements be replaced with:

1.Pushblishers SHOULD publish using the new SPF2 record type,
  if they are able to do so.
2. Regardless of whether they published using the SPF2 record
   type, publishers MUST publish a TXT record.
2a.The contents of the SPF2 record and TXT record MUST be identical.
3. Consumers SHOULD check for the new SPF2 record type, if they
   are able to do so.
4. Consumers who either cannot query for SPF2 records or who find
   that a domain hasn't published any SPF2 records MUST query for
   a TXT record.
5. Consumers MAY do both lookups (3 and 4) in parallel.
6. If consumers receive records from both lookups, they SHOULD use
   the SPF2 record and ignore the TXT record.

Brief Discussion:

It's undisputed that the world would be a better place if everyone uses
the new record type. However, it's also undisputed that many players
won't be able to publish and/or consume the new record type until new
software is installed. The updated requirements as I've spelled them out
above will me that:
  a) Everyone can work before new DNS software is installed.
  b) After new DNS software is installed, there will be minimal harm to
the DNS system.

I think that (a) is obvious. There are four sub-cases:

i. Publisher and consumer both have out-of-date DNS software:

If the publisher and consumer both have out-of-date DNS software, the
publisher will only publish a TXT record. The consumer will only query
for a TXT record, and get the right information.  All of the oft-debated
issues of packet size and TCP fallback apply.

ii. Publisher has up-to-date DNS software and consumer has out-of-date
DNS software:

If the publisher has up-to-date DNS software, he'll publish both an SPF2
record and a TXT record. The consumer will only query for a TXT record,
and get the right information. All of the packet size and TCP fallback
issues apply.

iii. Publisher has out-of-date DNS software and consumer has up-to-date
DNS software:

If the publisher has out-of-date DNS software, he'll only publish a TXT
record. The consumer will query for a DNS2 record, and receiving no
records will query for a TXT record, yielding the right information. All
of the packet size and TCP fallback issues will apply.

iv. Publisher and consumer both have up-to-date DNS software.

If both the publisher and the consumer have up-to-date DNS software, the
publisher will publish both an SPF2 and a TXT record. They consumer will
query for the SPF2 record, and get the right information.  The
packet-size issues will generally not apply, because the SPF2 record
won't be mingled with other irrelevant records.

So in all four cases, the updated requirements work. Contrast this with
the currently specified requirements, which cause cases (ii) and (iii)
to fail to discover the record.

b. Note that after up-to-date DNS software is widely deployed, only SPF2
record will be queried for. The TXT records will still exist, but will
not be the subject of queries by SenderID software. As such, the only
harm that the TXT records cause is that they will take up space in
packets when other applications query for TXT records for a domain.
However, as there aren't any such widely-deployed other applications,
this harm is minimal and largely theoretical.

-- Jim Lyon

---

From: [email-masked]
Date: Mon, 23 Aug 2004 18:03:25 -0700 (PDT)

FWIW, I fuly support making this change.

				Ned

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 23 Aug 2004 18:13:57 -0700 (PDT)

> a. It's not what was previously debated / agreed to.
It has been debated, but it may not have been agreed to by all.

> b. Anyone who can't publish an SPF2 record cannot comply with this spec.
That will case those who can not publish SPF2 record to make their service 
compliant to be able to fully supportthe spec. However you maybe right 
that its too strong to say they are can not comply with spec at all.

> c. Anyone who can't look up an SPF2 record cannot comply with this spec.
Same as above, but here I feel more strongly that everyone should provide 
ability to read the records and those that dont are not compliant. And
even with microsoft system dns problems (which btw means microsoft software
is not compliant with some dns specs...), I've not seen any argument
that microsoft software can not read new/unknown record types - it can do 
it given DNS type number, it just does not know how to interprete it as part
of the library and that would be up to software to do, which I dont think 
is that hard given text format of SPF records. 

>   if they are able to do so.
This seems acceptable to me.

>    type, publishers MUST publish a TXT record.
This is not acceptable. If somebody can publish SPF2 record, they MUST do 
it and MAY publish TXT record.

> 2a.The contents of the SPF2 record and TXT record MUST be identical.
Agreed. This is reasonable to avoid problems for those who requested both 
TXT and SPF2 records and got TXT first.

> 3. Consumers SHOULD check for the new SPF2 record type, if they
I would be ok with SHOULD here, although I feel slightly better if it was 
MUST. 

>    that a domain hasn't published any SPF2 records MUST query for
I remind that its optional for consumer to decide to use or not use MARID.
record. So I do not believe that we should force them to query second time
(just like they are not forced to do it the first time and do it by their
own choice) for TXT if they dont want to and are willing to leave with 
consequences and consider the domain as if it did not publish MARID record. 
I don't think this would be norm though and I think most will for considered
period of time will choose to query both SPF2 and TXT records.

> 5. Consumers MAY do both lookups (3 and 4) in parallel.
Agreed.

>    the SPF2 record and ignore the TXT record.
Agreed.
 
> software is installed.

As such everybody should be encoraged to upgrade their software to be 
fully compliant with the specs (as well as for many other reasons it also 
good to regularly do os and major packages upgrades), but for those who 
did not they can still rely on TXT records for considerable time
understanding however that they are not fully compliant and may possible 
loose some records the longer they continune to use non-ugpraded software.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Mark Lentczner <[email-masked]>
Date: Mon, 23 Aug 2004 22:25:19 -0700

On Aug 23, 2004, at 5:09 PM, Jim Lyon wrote:

> concerning DNS record types.

The changes you cited were all made in response to review by the people 
of DNS-EXT.  In particular, Olafur Gudmundsson, co-chair of DNS-EXT 
provided much of the wording you see verbatim.  He and I discussed the 
changes and in particular the very points you bring up.  He said he'd 
like to see this version of the wording go to last call, and that he'd 
be willing to be involved in discussions.

Andy: Can we get him in?

	- Mark

---

From: Margaret Olson <[email-masked]>
Date: Tue, 24 Aug 2004 07:37:25 -0400

On Aug 24, 2004, at 1:25 AM, Mark Lentczner wrote:

> The changes you cited were all made in response to review by the 
> people of DNS-EXT.  In particular, Olafur Gudmundsson, co-chair of 
> DNS-EXT provided much of the wording you see verbatim.  He and I 
> discussed the changes and in particular the very points you bring up.  
> He said he'd like to see this version of the wording go to last call, 
> and that he'd be willing to be involved in discussions.
>
My comment about the current wording is that either senders or 
receivers who do not implement the "MAY" clauses are acting against 
their own best interests. This is misleading at best. As a sender, I am 
going to publish all record types that receivers might look up as soon 
as I can. As a receiver who is interested in discarding as much forgery 
as possible as quickly as possible, I'm going to look up whatever 
records I can look up as quickly as I can.

As a practical matter, I'll be publishing and checking TXT records very 
shortly, and the SPF2 record type at some point in the future. As the 
spec is written, a new reader has to study carefully and work this out 
for themselves. This is not helpful to the email community and it will 
slow down adoption.

Chairs: This has become a DEPLOY comment - do you want me to resubmit 
it under that heading?

Margaret.

---

From: Andrew Newton <[email-masked]>
Date: Tue, 24 Aug 2004 13:33:23 -0400

> Andy: Can we get him in?

Olafur,

Can you please provide comment on the DNS record type language in 
draft-ietf-marid-protocol and the last call comments made by Jim Lyon 
regarding compliance.

-andy

---

From: Margaret Olson <[email-masked]>
Date: Tue, 24 Aug 2004 15:40:17 -0400

I am strongly in favor of Sender ID, and would like to see it deployed 
as quickly as possible.

Margaret.

---

From: Mark Lentczner <[email-masked]>
Date: Tue, 24 Aug 2004 13:51:11 -0700

On Aug 24, 2004, at 12:40 PM, Margaret Olson wrote:

>  As the spec is written, a new reader has to study carefully and work 
> this out for themselves. This is not helpful to the email community 
> and it will slow down adoption.

[ This is a little off-topic, but... ]
I'm not so concerned that a reader has to study the document to work 
out what a best practice should be.  The eventual specification 
document needs to clearly and concisely state the technical parameters. 
  It does not serve as a How-To document.  I should hope that the vast 
majority of the e-mail community will never read this document, and 
will learn what to do from helpful web sites and record generating 
wizards.  I already fear that the protocol document has far too much 
exegesis in it.

If you have a tighter, clearer and more concise way of saying what is 
allowed and what must be done, then I'm all ears.  I'm going to resist 
adding paragraphs of explanation, best practices, expository examples 
and helpful hints.

	- Mark

---

From: Margaret Olson <[email-masked]>
Date: Tue, 24 Aug 2004 20:47:44 -0400

> adding paragraphs of explanation, best practices, expository examples 
Here are my suggested changes, working from Jim Lyon's simplification. 
The goal is to both moving the world to the new resource record and to 
allow everyone to be compliant in the very short term.   I dislike the 
idea of having a spec with which most people in fact won't be able to 
comply. Coupled with the significant forgery/spam reduction incentive 
of implementing Sender ID the current wording ultimately works against 
the goals of the DNS folks by making a spec violation "standard 
practice".

Change this to SHOULD

Leave as is

Change this to SHOULD

Leave as is

Leave as is

6. If consumers receive records from both lookups, they SHOULD use
    the SPF2 record and ignore the TXT record.
Change this to MUST, since we want the world to move to the SPF2 record

Margaret.

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Sat, 28 Aug 2004 22:55:38 -0400

>    to consumers that can't query for the new record type.

Standards documents are supposed to be long lived, and everyone
knows there is going to be a period during which b. and c. are facts
of life. The question is how to overcome that hurdle in the shortest
time possible.

In my dealings with operational people the only thing that will
get them to upgrade is clear violation of standards, "MUST" or "MUST NOT"
violation. "SHOULD" "SHOULD NOT" "MAY" are brushed under the table
or join the long queue of things to fix when time is available.
For this reason I pushed for the strong text in the draft.

Your point d. is a good one but still runs counter to the philosophy
above as when SPF (I do not like the name SPF2) RR has died or become
prevalent there is no reason publish spf policies in TXT records.

As for a. is concerned I can not find an statement from chairs
that is the consensus of the working group. One of the reasons that Mark
agreed to the text was exactly to find out if a rough consensus on this
issue could be formed.

>   if they are able to do so.

This is an operational guidance not a definition of a standard.
If this text is accepted by the WG then none has to ever deploy
the new type.

>    type, publishers MUST publish a TXT record.

This is counter to a long term strategy and unless the WG intents to
be around for a long time there will never be a time when publishing
only SPF RR is acceptable.

>2a.The contents of the SPF2 record and TXT record MUST be identical.

This I agree with and the current document says so (at least
that is my reading of section 2.1 paragraph 3).
But I agree with you that putting in a MUST there is a good idea.

>   b) After new DNS software is installed, there will be minimal harm to

The fundamental difference between your position and mine is
you: want everyone to be compliant at all times.
me: Specify clearly fully compliant state and tolerate non compliance
     during phase-in.

>issues of packet size and TCP fallback apply.

This is the stage we all are trying to keep to absolute minimum,
What the text in the ID is trying to do is to get as publishers to
publish SPF records as soon as possible, while giving the consumers
more flexibility in how the information is accessed:
          via TXT or SPF records.

The issue we need to keep in mind is test and traceability.
It is simple and quick to check if a publisher is compliant,
thus the MUST's.
It is simple to check if a consumer MTA issues queries for SPF,
thus the MUST.
It is hard to check which type is used, if both are available thus
the SHOULD.

Once the records are available and consumers have
started to ask for them then it is publishers choice to either
continue to publish TXT records or risk failures when dealing with
the laggard consumers.

>ii. Publisher has up-to-date DNS software and consumer has out-of-date

<snip>

>iii. Publisher has out-of-date DNS software and consumer has up-to-date

<snip>

>to fail to discover the record.

I humbly disagree, the ID documents the state everyone will (hopefully)
migrate to, in your analysis you assume the worst behavior possible by
both sides. For the publisher in the short term it is in their
interest to publish both RR types with spf information.
Similarly the consumer by asking for both types maximizes its chance of
getting an answer.

Once the MARID RR type has been in use for some time it is possible
to assess if it is worth while, then there are two optimizations possible:
         cut out the TXT query from the MTA's
         Tear out all the SPF processing from the MTA's.

At this point I do not know which one will be the one done, I hope it
is the first one.

In conclusion, I recommend the WG keep the text as is.

         Olafur

---

From: Mark Lentczner <[email-masked]>
Date: Tue, 31 Aug 2004 13:29:39 -0700

First, two minor points:

> ... as when SPF (I do not like the name SPF2) RR ...
Several people have made this suggestion to me, on and off list.  I 
have seen only one argument against.  Unless I hear more, I will rename 
the RR type from 'SPF2' to 'SPF'.

> But I agree with you that putting in a MUST there is a good idea.
I will add the MUST.

Then:
> me: Specify clearly fully compliant state and tolerate non compliance
I think this is a good summary of the two positions presented.

I agree with Ólafur on this, since I think this document is a standard, 
not a how-to manual.  The How-to's and web wizards will make it clear 
to people that they need to publish the TXT form for now.

	- Mark