Subject: consensus call of RR prefix

From: Andrew Newton <[email-masked]>
Date: Fri, 3 Sep 2004 17:32:22 -0400

From the discussion on prefixes for the DNS record, there seems to have 
been no discernible outcome regarding the use of prefixes for the 
purposes of avoiding collisions with other DNS records (thus avoiding 
fallback to DNS over TCP).

Naturally, this issue wraps itself into both the versioning/scoping 
issue and the wildcard issue.  Based on the comments received so far, 
it is the opinion of the co-chairs that there is no consensus on how to 
handle wildcards and that most participants seem to agree that 
wildcards present a problem no matter the solution.  Based on the 
comments received so far, it is the opinion of the co-chairs that there 
is consensus on placing the "scope" in the RDATA of the record and no 
consensus on the scope being in the prefix.

Therefore, that leaves one under-discussed question: should a prefix be 
used to avoid collision with other records as one measure of preventing 
the requirement of DNS over TCP?

Incidentally, the co-chairs note that many examples of the prefix have 
used "-marid".  We would note that "MARID" is the name of this working 
group and likely not meaningful beyond the context of discussions and 
process of this working group.  Therefore we recommend a more 
meaningful label such as "_rmx": the deduction of its meaning is easier 
and it references the genesis of the MARID idea.

-your co-chairs

---

From: Daniel Quinlan <[email-masked]>
Date: 03 Sep 2004 15:23:27 -0700

> the requirement of DNS over TCP?

No.

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/

---

From: Rand Wacker <[email-masked]>
Date: Fri, 3 Sep 2004 16:14:09 -0700 (PDT)

> the requirement of DNS over TCP?

The include workaround proposed to the list seem to work for the major
cases I outlined, and leaving the TXT records in the domain.tld dataspace,
while ugly, seems like a good bit of parallelism for the SPF records that
will be published in the same place.

I would suggest that the document be ammended to remind people that *all*
TXT records published for domain.tld should fit in 480 bytes (mentioning
spfv1 and spfv2), and perhaps also suggest the include workaround for
sites that will need to publish really large records.

-Rand

---

From: Max Kanat-Alexander <[email-masked]>
Date: Fri, 03 Sep 2004 16:59:26 -0700

> fallback to DNS over TCP).

	I suspect that I missed some of the comments on this possibly earlier,
as I only recently was able to get to this list. (I thought that perhaps
my developers were on it, but it turns out that they aren't, I think.)
Anyhow, here's my thoughts:

	Any requirement (or even expectation) of DNS over TCP will probably
kill widespread adoption of Sender ID, as DNS over TCP does not work
over a large number of networks. Either it's blocked at a firewall, or
it's disabled on the DNS server.

	If we use a record in domain.tld, we have a higher chance of collision
with some other record than if we use _senders (or some other prefix).
Granted, wildcards are a problem, but they're not really significant,
because obviously the admins who enable wildcards expect spurious DNS
hits and are willing to accept that strange things might happen. Also,
whether I get a collision (or too large of a DNS reply) from querying
*.domain.tld, or domain.tld, it makes no difference to me. The only
thing about using a prefix is that I get to choose to avoid that
collision.

	I don't think it's a huge issue -- what are sysadmins currently using
TXT records in domain.tld for, and how many of them also have wildcards
enabled? I don't know of an extensive number of uses of those things
combined.

	Personally, as a sysadmin, potential implementor, and the fellow who
will have to deal with any angry customers, I'd probably prefer having a
prefix, as I suspect that it will clear up more problems that it will
create.
-- 
Maxwell Kanat-Alexander
2nd Level Tech Support Engineer, USA
Kerio Technologies, Inc.
2041 Mission College Blvd. Suite 100
Santa Clara, CA 95054
Phone: (408) 496-4500
Fax: (408) 496-6902
Web: http://www.kerio.com/support.html

---

From: <[email-masked]>
Date: Fri, 3 Sep 2004 20:12:08 -0400

> the requirement of DNS over TCP?

My understanding from discussing uses of the PRA is that the PRA
doesn't need to be a functioning mailbox, and that its domain doesn't
even need to have an MX or A record.

So can't people just use a prefix anyway?  Sites concerned about
conflicts with other large TXT records can still use a prefix.  They
just need to add a header field like:

Resent-Sender: [email-masked]

Presumably most Sender-ID compliant MTAs will have facilities for
automatically adding such headers anyway.

Thus, I support not mandating any prefix.

David

---

From: "Scott Kitterman" <[email-masked]>
Date: Sat, 4 Sep 2004 00:24:12 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Andrew Newton
> Sent: Friday, September 03, 2004 5:32 PM
> To: IETF MARID WG
> Subject: consensus call of RR prefix
>
>
>
One possibly small point with respect to deployment in this area...

At least some (and I understand it to be many) DNS providers do not
currently allow underscore characters.  Even if other issues that might
prevent my deployment of Sender-ID records are resolved, I would currently
be unable to publish records if they are prefixed with an underscore due to
such limitations.

Scott Kitterman

---

From: [email-masked]
Date: Sat, 4 Sep 2004 15:19:13 +0200

> the requirement of DNS over TCP?

As there is almost no other use for TXT records as we speak (perhaps
someone could be so kind to repost the survey carried out on a large
list of domains, which stated how many domains with non-spf1 txt records
were found) and added to that the problems with wildcards, my opinion is
that prefixes are not preferable.

However, problems might start to exist in the future, when several
competing versions of spf-derived protocols will be in effect. However,
this might also be a pro, as it limits the proliferation of possible
spf-derived protocols and therefore will force the community to converge
on a standard sooner.

Koen Martnes

-- 
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, embedded systems, unix expertise, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/

---

From: <[email-masked]>
Date: Sat, 4 Sep 2004 09:20:18 -0400

No, don't make prefixes required (this is an oversimplication but I believe to cover the reasons for
common deployment):

-not all dns servers support "_"
-domains with potential collision issues can explicitly use a small redirect to move the spf query
result elsewhere
-many dns providers do not allow subdomains (or not easily via an interface, and we need to keep
publishing easy or it won't get done)(yes I know many ISPs don't support TXT RR either, but that
*is* changing and it *is* an RFC compliant DNS standard, even if SPF abuses it)

Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
[email-masked]
Fax: (416) 441-9085

---

From: John Levine <[email-masked]>
Date: 4 Sep 2004 15:12:25 -0000

>the requirement of DNS over TCP?

No, for two reasons.

The first is that it is not a very effective way to keep multiple TXT
records out of the same DNS node.  Based on what I've read, there
aren't a whole lot of other TXT records at the same nodes where MARID
records need to live.  The bloat problem occurs when you use
wildcards.  Since no DNS server I know supports wildcards of the form
_marid.*.phoo.com, you have to put all of your wildcards at *.phoo.com
and that's where you get overlap and bloat.  If specific nodes do get
overloaded, SPF and Sender-ID both let you use a short record pointing
to a longer record somewhere else as a band-aid.

The other is to keep in mind that using TXT records is a botch.  DNS
was designed to have a separate record type for each separate
application.  Type numbers are 16 bits so number assignments are not
particularly precious, and queries by type number are the right way to
get the records you want and not the records you don't want in a small
DNS response.  It's a historical accident, and arguably a historical
mistake, that there haven't been hundreds of types assigned in the
past two decades.

I realize that short-sighted implementation decisions by some DNS
software authors and vendors make it difficult to deploy new record
types in the near term.  The right response to that is to permit TXT
records as a transition measure (no doubt for a very long transition),
but to keep in mind that it's a transition and in the longer term, we
should deploy new record types as needed to support new services and
applications.

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

---

From: Rand Wacker <[email-masked]>
Date: Sat, 04 Sep 2004 09:28:12 -0700

John Levine wrote:

> Based on what I've read, there
> records need to live. 

spfv1 records live here right now.

> The bloat problem occurs when you use
> and that's where you get overlap and bloat. 

This means that domainkeys records are going to get caught by these 
wildcards as well.  Wildcards just aren't going to work when we're 
publishing TXT records, period.

> If specific nodes do get

That's a fine workaround, but even *those* records will get caught by 
wildcards.  Wildcards won't work.

-Rand

---

From: "John R Levine" <[email-masked]>
Date: 4 Sep 2004 12:36:56 -0400

> publishing TXT records, period.

At this point it appears that the most likely format for DK records is
some version of SPF records, so the band-aid works for them, too.

> wildcards.  Wildcards won't work.

I don't see how repeating this claim makes it any more persuasive.  All
the records I know about can use the short pointer band-aid, and it looks
easy enough to have five or six band-aid records and still fit in a UDP
packet.  What am I missing?  I realize that a hundred TXT records won't
fit, but I don't see more than about four TXT record applications showing
up any time soon.

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

---

From: Roy Badami <[email-masked]>
Date: Sat, 4 Sep 2004 18:21:43 +0100

>>>>> "Rand" == Rand Wacker <[email-masked]> writes:

    Rand> I would suggest that the document be ammended to remind
    Rand> people that *all* TXT records published for domain.tld
    Rand> should fit in 480 bytes 

The current drafts mandate support for EDNS0 so the 480 byte limit
goes away.

I really think we shouldn't get to caught up in this 480 byte limit.

  -roy

---

From: Roy Badami <[email-masked]>
Date: Sat, 4 Sep 2004 18:20:23 +0100

>>>>> "Rand" == Rand Wacker <[email-masked]> writes:

    Rand>  and leaving the TXT records in the domain.tld dataspace,
    Rand> while ugly, seems like a good bit of parallelism for the SPF
    Rand> records that will be published in the same place.

I concur.  Purely pragmatically, many people will want to check both
SPF and IETF-compliant Sender ID.  Being able to fetch both with a
single query is therefore beneficial.

(Of course it doesn't matter if I use separate pieces of software to
check SPF and Sender ID, both of which make their own queries; my
local caching nameserver will still ensure that only one query is made
to the authoritative nameservers.)

   -roy

---

From: Roy Badami <[email-masked]>
Date: Sat, 4 Sep 2004 18:41:27 +0100

I wrote:

    Roy> I concur.  Purely pragmatically, many people will want to
    Roy> check both SPF and IETF-compliant Sender ID.  Being able to
    Roy> fetch both with a single query is therefore beneficial.

I replied without thinking it through; compliant implementations will
check SPF2 first, so the gain I was envisaging does not exist.  In
fact, there's a loss in that you potentially fetch the Sender ID data
twice, once in the SPF2 lookup, and once in the TXT lookup needed for
SPF checks.

However, I'm against using a prefix with SPF2 records.  It would be
pointless as an attempt to avoid a clash with other uses of SPF2
records, and as others have said, wildcards are unlikely to be useful
in either case...

I'm neutral as to whether TXT records should have a prefix, but it's
probably simpler to put SPF2 records and TXT records at the same
place.

	-roy

---

From: Hadmut Danisch <[email-masked]>
Date: Sat, 4 Sep 2004 21:34:49 +0200

> the requirement of DNS over TCP?

There are still good reasons to have a prefix. 

A method like MARID (whatever it will be) is not limited to 
e-mail only. It can be used for other services (e.g. chat) as 
well to verify identity descriptors derived from domain names.

If there ever will be another use of MARID, collision should be 
avoided (which could be resolved by omitting the prefix for 
e-mail and using a prefix for any other service, but this is not
a good design).

On the other hand, in about 10 years of handling DNS I can remember 
only a single case where someone actually used wildcards. DNS server
also need to support the underscore for the SRV RR type. 

So I'd prefer a prefix. 

regards
Hadmut

---

From: Mark Lentczner <[email-masked]>
Date: Sat, 4 Sep 2004 12:55:01 -0700

My position on the prefix issue is that, since the right way to do 
things is to publish SPF2 RR records at the domain itself, we should 
put the TXT records there as well.

While it might make for less clutter to put the TXT records at some 
sub-domain such as _spf, it would be inconsistent with where the SPF2 
RR goes.  Further, using sub-domains appears to be a significant 
barrier to publishing for domains that use existing domain hosting 
services.  Lastly, from previous technical discussion, it is clear that 
use of a sub-domain doesn't improve the wild-card situation at all, nor 
allow any information to be removed from the version string.

	- Mark

Mark Lentczner
http://www.ozonehouse.com/mark/
[email-masked]

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 4 Sep 2004 14:25:59 -0700 (PDT)

> the requirement of DNS over TCP?

I'm not very strongly in favor or against using dns prefixes for TXT record
placement (my preference as indicated at the very end of message and it 
depends on other factors), but I'd like to summarize current arguments 
and points for and against using subdomain prefixes and explain how it 
all works so that others that are new to this can decide on their own.

As a reminder, in these posts:
 http://www.imc.org/ietf-mxcomp/mail-archive/msg03726.html 
 http://www.imc.org/ietf-mxcomp/mail-archive/msg03762.html
I sucessfully argued that because of how wildcards work (or don't work :) 
scoping can not rely on prefixes alone and version and scope must be part
of data portion (this chairs agree with as per their statemenet above).

It can be noted that original thread discussion about using or not using 
prefixes started from problems that may exist when user does want to publish
two types of SPF records (with presumably different version strings), like:
(*1*)  	  example.com. IN TXT   "v=spf1 ..."
  	  example.com. IN TXT   "spf2.0/pra ..."  

------------------------------
Option1
------------------------------

Since total size of RDATA space in udp dns packet is limited to approximately
480 bytes, each of the records from (*1*) would have to be smaller and be 
half that (up to say max 200 bytes to be safe), it has been said that is 
too small and hence using dns prefixes/subdomains was proposed, like:
(*2*)     _mfrom._rmx.example.com. IN TXT   "v=spf1 ..."
          _pra._rmx.example.com.   IN TXT   "spf2.0/pra ..."  

However same wildcard problem I have pointed out applies here, names that 
in case of wildcards, no matter if there are prefixes or not, you would 
have to put wildcard records in the root of the domain and thus have 
this limitation with size of records:
(*3*)     *.example.com. IN TXT   "v=spf1 ..."
          *.example.com. IN TXT   "spf2.0/pra ..."  

But as has been pointed out to me by David Blacka, that prefixes dont work 
with specific case of wildcards, doesnt mean its bad for everyone else
and use of wildcards is in general pretty rare, so we should not discard
usefullness of scenario (*2*) just because of wildcards. 

I agreed with that in this message:
  http://www.imc.org/ietf-mxcomp/mail-archive/msg03963.html
But have pointed out that there is another problem that we may have and 
that has to do with number of dns requests. In case like (*1*) when all
SPF records are located in the root of zone, in order to see all the
mail policies for different identities/scopes. a verification client 
program would only need to make one dns request for TXT record under that 
domain. But if we go with different prefixes for each scope as with (*2*), 
then client program would have to normally make two dns requests for each 
of those identities (i.e. for _pra._rmx and for _mfrom._rmx).

It can be noted that if identities have the same SPF record (and Mark 
Lentczner has pointed out that for most situations SenderID/PRA and 
SPF-Classic/Mail-From records are likely to be the same) then we maybe
able to deal with this by having records like:
(*4*)     _mfrom._rmx.example.com. IN TXT   "spf2.0/pra,mfrom ip4:10.0.0.0/24
          _pra._rmx.example.com.   IN TXT   "spf2.0/pra,mfrom ip4:10.0.0.0/24  

In that case a program looking pra or mailfrom identity scoping record 
(which it does first does not matter if records are the same) would
get the record indicating that the other identity is equivalent and would
presumably not have to do an extra dns lookup.  However this does lead to 
situation of having to enter and maintain two different but completely 
equivalent (as far as RDATA) TXT records. 

I'll note that to support programs checking SPFv1 records, additional record
may have to be added (also equivalent), so we would have:
(*5*)     _mfrom._rmx.example.com. IN TXT   "spf2.0/pra,mfrom ip4:10.0.0.0/24
          _pra._rmx.example.com.   IN TXT   "spf2.0/pra,mfrom ip4:10.0.0.0/24  
	  example.com.		   IN TXT   "v=spf1 ip4:10.0.0.0/24 ~all"

------------------------------
Option2
------------------------------

Another option maybe to place SPF TXT records in the same prefix no matter
what identity/scope this is, which allows to avoid collision with other 
TXT records that may exist for the domain/host:
(*6*)     _rmx.example.com. IN TXT   "spf2.0/mfrom ..."
          _rmx.example.com. IN TXT   "spf2.0/pra ..."  

In that case it is not necessary to make an extra dns lookups for multiple
identity records, nor is it necessary to have two separate records when
they are the same, as the following will work just fine:
          _rmx.example.com. IN TXT   "spf2.0/pra,mfrom ..."

However, this does mean that in case the two records are seriously different
size limitations would apply (since records share the same prefix) and records
would have to be limited to half of what they could have been. Solution
to this involves doing redirection, which would lead to 2nd dns lookup:
(*7*)  _rmx.example.com. IN TXT "spf2.0/pra redirect=_pra._rmx.example.com
       _rmx.example.com. IN TXT "spf2.0/mfrom redirect=_mfrom._rmx.example.com
       _pra._rmx.example.com. IN TXT "spf2.0/pra ...."
       _pra._mfrom.example.com. IN TXT "spf2.0/pra ...."

Additionally I'll note that there exist another possible plus side that
applies to how wildcards are entered. Because of how wildcards work normally
you need to have two separate records when using wildcards - one for domain
itself and one wildcard for all subdomains:
(*8*)     example.com.   IN TXT   "v=spf1 ..."
          example.com.   IN TXT   "spf2.0/pra ..."  
          *.example.com. IN TXT   "v=spf1 ..."
          *.example.com. IN TXT   "spf2.0/pra ..."  
In above the first two records apply to example.com itself while the 2nd
two apply to any subdomain under it (i.e. xxxx.example.com or even futher
down the tree like a.b.c.example.com) and normally these two would be the 
same, but entering wildcard seems to lead to duplicate entries.

But when using prefixes (and this applies to option 1 as well), we only need 
to have one record:
(*9*)     *.example.com. IN TXT   "v=spf1 ..."
          *.example.com. IN TXT   "spf2.0/pra ..."  

And this record would equially apply to both _rmx.example.com and to 
_rmx.xxx.example.com or to _rmx.a.b.c.example.com, etc.

------------------------------
Summary
------------------------------

So we have several options:
  Option1 is using prefixes with different one for each scope/identity
  Option2 is using prefixes but with same prefix no matter what spf scope
  Option3 is not using prefixes at all (SPF2 TXT record in zone root)
  Option4 is not using prefixes, nor even using new SPF2 version (in that 
  case scoping is achieved by using scope modifier with v=SPF1 record)

For Option1 the PROs are:
 1. Avoids collision with other TXT records for domain
 2. Avoids collision with different TXT records (except for wildcards)
    and thus avoids record size limit for different spf scope records
 3. Allows to specify wildcard entry for subdomain & domain using one record
The CONs are:
 1. Requires multiple dns lookups if SPF records for different scopes
    are different (no matter what size these records are)
 2. Requires multiple dns records if SPF records for different scopes
    are the same (no matter what size these records are)
 3. Requires separate SPFv1 records and dns lookup to support existing
    SPVv1 resolvers and libraries

For Option2 the PROs are:
 1. Avoids collision with other TXT records for domain
 2. Allows to specify wildcard entry for subdomain & domain using one record
 3. Allows to specify multiple scopes together in one record when they are same
 4. Does not require separate dns lookups for different scope records no
    matter if they are different or the same
The CONs are:
 1. Requires multuple dns lookups to avoid size limitations if multiple
    scope SPF records are different and are large
 2. Requires separate SPFv1 records and dns lookup to support existing
    SPVv1 resolvers and libraries

For Option3 the PROs are:
 1. Allows to specify multiple scopes together in one record when they are same
 2. Does not require separate dns lookups for different scope records no
    matter if they are different or the same
 3. Does not require separate dns lookups for SPFv1 records
    (but normally you would not need to do it anyway)
The CONs are:
 1. Collision problems with other (non-SPF) TXT records for the domain
 2. Requires multuple dns lookups to avoid size limitations if multiple
    scope SPF records are different and are large
 3. Requires multiple records to specify wildcard for domain & subdomains
 3. Requires separate SPFv1 records and dns lookup to support existing
    SPFv1 libraries and resolvers

For Option4 the PROs are:
 1. Allows to specify multiple scopes together in one record when they are same
 2. Does not require separate dns lookups for different scope records no
    matter if they are different or the same
 3. Does not require separate dns lookups for SPFv1 records and fully
    supports existing SPVv1 libraries and resolvers with one record
The CONs are:
 1. Collision problems with other (non-SPF) TXT records for the domain
 2. Requires multuple dns lookups to avoid size limitations if multiple
    scope SPF records are different and are large (*)
 3. Requires multiple records to specify wildcard for domain & subdomains

(*) I note that when using scoping modifier, different scope records can
    have shared data parts all in one SPF record and this allows for smaller
    size of records and avoids size limitations and necessity to do 2nd
    dns lookup in majority of situations. For more info see:
      http://www.imc.org/ietf-mxcomp/mail-archive/msg03677.html
      http://www.imc.org/ietf-mxcomp/mail-archive/msg03716.html
      http://www.imc.org/ietf-mxcomp/mail-archive/msg03731.html

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

In my opinion a lot depends on if we consider supporting existing installed
SPF v1 base important or not and consider that people using existing libraries
and publishing spfv1 records can upgrade quickly to new spf2 records or not.

If we do want to support SPFv1 base as much as possible and think that new 
scope for mailfrom will be deployed along with SPF1 records (and hence 
programs like spamassasin would do lookups for both for considerable time), 
then option4 is the best one and completely avoids these issues.

On the other hand if we think that transition to SPF2 records would be quick
and nobody would do SPF1 lookups in say one year time, then to me option2
(common prefix for all spf records) looks like the best one because compared
to option3 (no prefixes) it has the following advantages:
 1. Avoids collision with other TXT record for domain
 2. Allows to specify wildcard entry for subdomain & domain using one record
As far as everything else it is pretty much same as option3, with exception
that possibly some bad dns gui programs do not allow to enter "_" records
(but all dns servers support this just fine).

And in my opinion option1 (separate prefixes for different scopes) is the 
worst one because it leads to either multiple dns records or multiple
dns lookups and those exist no matter if record is large or small and so
would effect absolutely everybody.

> and it references the genesis of the MARID idea.

I have no strong preference as far as prefix name, but I would like to 
note that _rmx has meaning if we're talking about MAIL-FROM identity
SPF scope records but in general SPF records might apply to different
identities (for example PTR scope from unified SPF) and might not not be 
related to mail-from or RMX at all. So I think general prefix such 
as _spf might be better. But I have complied with chair's request and 
have used _rmx in all above examples.

---
William Leibzon, Elan Networks:
 mailto: [email-masked]
Anti-Spam Research Worksite:
 http://www.elan.net/~william/asrg/

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 4 Sep 2004 14:46:25 -0700 (PDT)

Also I would like to add that I support having common "mail policy" prefix
for SPF RR type refords as well. As with arguments for option2, this helps
with wildcards (no extra duplicate entries) and it allows to in the future
extend use of SPF to be general policy language for other protocols but
would avoid collision with existing mail policy base (except in case of 
wildcards, but there redirection can be used if records get too large
all together). So in this case, we need to use protocol specific name
as part of prefix, something like:
   
   _smtp.example.com. IN  TXT  "spf2.0/pra,mfrom ..."
   _smtp.example.com.  IN  SPF  "spf2.0/pra,mfrom ..."

Or possibly:

   _smtp._spf.example.com. IN  TXT  "spf2.0/pra,mfrom ..."
   _smtp.example.com.  IN  SPF  "spf2.0/pra,mfrom ..."

---

From: Yakov Shafranovich <[email-masked]>
Date: Sat, 04 Sep 2004 21:43:59 -0400

> fit, but I don't see more than about four TXT record applications showing

If Sender-ID sucessfully uses a combination of TXT records and new RR 
type, then other new protocols may follow the same advice. That can 
quickly add up.

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Sat, 04 Sep 2004 21:48:18 -0400

> e-mail and using a prefix for any other service, but this is not

I would add to that that others in the IETF may use MARID as a 
precendent to argue for the use of TXT record. This may quickly increase 
the possible number of them. Therefore, I am for the prefix as well.

Yakov

---

From: "Michael R. Brumm" <[email-masked]>
Date: Sat, 4 Sep 2004 23:17:17 -0600

No.

Michael R. Brumm

---

From: Hadmut Danisch <[email-masked]>
Date: Sun, 5 Sep 2004 09:20:05 +0200

> the possible number of them. Therefore, I am for the prefix as well.

Correct. The reason to use a prefix is basically the same as to use
the _service._tcp prefix for SRV records (which are used for good
reasons).

regards
Hadmut

---

From: "Michael R. Brumm" <[email-masked]>
Date: Sun, 5 Sep 2004 03:54:35 -0600

> the possible number of them. Therefore, I am for the prefix as well.

This is a good point, however:

- MARID has an immediate (emergency-like) need for widespread deployment
like few other standards, and thus the precedent is limited. Most (if not
all) other standards can depend on RFC 3597 (unknown RR types) and/or
underscored prefixes.

- The IETF is capable of determining whether standards now and in the future
have this special need or not.

- Requiring an underscored prefix to prevent this (likely non-existent)
future problem prevents and slows adoption of MARID by those whose DNS
providers do not allow underscores.

It would seem strange if MARID provided TXT publishing to improve
deployment, but then placed it in an underscored prefix which impedes
deployment.

Michael R. Brumm

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 5 Sep 2004 03:30:47 -0700 (PDT)

> all) other standards can depend on RFC 3597 (unknown RR types) and/or

The "immediate need" or emergency is in the eye of the beholder. What may 
seem urgent for us may not seem so urgent for somebody else and similarly
what may seem like not so important matter to us maybe very important
and seemingly an emergency for somebody else.

The precident will be there, that one is certainly right, so don't be 
surprised if somebody else wants to use it for their "emergency".
As such we better show good understanding of such emergency situation
and good example for that to follow in our technical solution.

> providers do not allow underscores. It would seem strange if MARID 
> provided TXT publishing to improve deployment, but then placed it in an 
> underscored prefix which impedes deployment.

I have a question for Michael here: 
  Is "_" as part of the prefix name the only problem you see (or the 
primarily one) as far as what you see wrong about introduced idea of
using prefixes for placement of SPF TXT records?

Similarly if others here who have so far spoken against using prefix also
see underscore as the main problem, please also speak up as I believe it 
is important issue for chairs to recongnize as far as arguments against it 
and how strong technically these arguments are.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: <[email-masked]>
Date: Sun, 5 Sep 2004 08:13:40 -0400

I voted against a prefix.

I did this not just because of the "_" character support issue, but also because:
-implementing a prefix adds complexity (comprehension complexity if nothing else)
-many dns providers do not support users adding subdomains (or not through the UI anyway)
-prefix does not solve the wildcard issue
-one can use redirect in a small record to a subdomain (simulating prefix) if one really wants
prefix

Anything that hinders deployment needs to be considered for benefit and lack of alternatives.

Terry Fielder

> [mailto:[email-masked]]On Behalf Of
> william(at)elan.net
> Sent: Sunday, September 05, 2004 6:31 AM
> To: Michael R. Brumm
> Cc: IETF MARID WG
> Subject: RE: consensus call of RR prefix
>
>
>

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 5 Sep 2004 06:33:26 -0700 (PDT)

> -implementing a prefix adds complexity (comprehension complexity if 
You know, if a person went through SPF protocol draft and understood
the syntax and how these records work, I would imagine same person could
take 2 more seconds to understand about prefix placement of the record...

> (or not through the UI anyway)
These are not truly subdomains, prefix is more like a host record for specific
domain. And actually if you place records at the root of the domain, its
more GUI that will not let you do it (or make it difficult to do it) as
many programs will not let you add records with empty host record.

> -prefix does not solve the wildcard issue
Actually prefix helps wildcard issues and solves at least one of them.
It allows to avoid necessity to enter separate records for both "example,com"
and for "*.example.com" while with prefix one record for "*.example.com"
would suffice and cover both _prefix.example.com and anything else like
_prefix.subdonain.example.com.

The rest of wildcard issues are the same no matter if prefix is used or
not but. But having solved at least one wildcard issue does mean that use 
of prefix is preferable when considering wildcards.

> -one can use redirect in a small record to a subdomain (simulating 
> prefix) if one really wants prefix
Which dies not completely avoids collision with other records while 
requirying multiple dns lookups. 

> Anything that hinders deployment needs to be considered for benefit and 

Ok, then I have the following objection:

We should stop working on MARID and SPF completely because they use dns 
TXT records and entering TXT records is not supported by large number of 
GUI dns configuation tools and not supported by majority of registrars 
that offer dns service hosting directly to end-users.

P.S. If you do a comparision, you may find that there are more GUI dns
systems that don't support TXT then there are those that don't support
"_" in the host name. At the same time you may actually find that majority
of DNS GUI systems that have one of these problems have the other one too.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: David Blacka <[email-masked]>
Date: Sun, 5 Sep 2004 09:46:44 -0400

> -many dns providers do not support users adding subdomains (or not 

I don't yet understand this.  Are you saying that there are DNS 
providers who allow you to host your "example.com" domain, but then 
only allow you to add DNS records named "example.com"?  They wouldn't 
allow you to add a record for, say, "www.example.com"?  Are there DNS 
providers who do not allow this but would allow the addition of a TXT 
record?

> -prefix does not solve the wildcard issue

What, precisely, is "the wildcard issue"?

--
David Blacka    <[email-masked]>
Sr. Engineer    Verisign Applied Research

---

From: Matthias Leisi <[email-masked]>
Date: Sun, 05 Sep 2004 16:41:28 +0200

> -not all dns servers support "_"

Just for clarification: Which DNS servers do /not/ support underscores?

I know from testing that BIND 9 is happy with them; since Microsoft uses 
them for some AD stuff, I guess that at least newer implementations of 
their DNS services will not choke on them.

Local DNS libraries seem to be able to handle it - at least I haven't 
heard of resolver-library incompatibility with products that use Apple's 
Rendezvous, which is based on kind-of-SRV records and also use SRV's 
_<service>._<proto> scheme.

Of course, further testing would be fine, but technically most relevant 
pieces of DNS software around should not have issues underscores.

> *is* changing and it *is* an RFC compliant DNS standard, even if SPF abuses it)

Which DNS providers do (not) allow subdomains and/or TXT records?

Adding something a record for "_spf" should not be any different from 
adding a "www" record to a domain.

(Adding TXT records to the admin GUI of my non-profit ISP took me a 
couple of minutes.)

IMO, there are no technical or admin issues for or against RR prefixes. 
Having said that, there are of course policy reasons to consider - eg if 
we go for a dedicated record type for "MARID", there is no need for a 
prefix (after all, we don't have a prefix for MX records).

Still IMO, a prefix would only make sense if the TXT record workaround 
were a long-term solution. As this quite possibly is not the intention 
of this working group, using a prefix does not offer any benefits other 
than possibly keeping the DNS response size below the magical 418 bytes, 
a restriction which can be easily worked around using redirects by those 
few(?) that would need it.

-- Matthias

-- 
Brain-Log                               http://matthias.leisi.net/

---

From: Rand Wacker <[email-masked]>
Date: Sun, 05 Sep 2004 09:27:26 -0700

> enabled? I don't know of an extensive number of uses of those things

spfv1, supposedly tens of thousands of them are doing it, and they are 
making no indication that they will replace those records w/ Sender ID.

-Rand

---

From: Rand Wacker <[email-masked]>
Date: Sun, 05 Sep 2004 09:31:17 -0700

> I really think we shouldn't get to caught up in this 480 byte limit.

The 480 byte limit is a limit of UDP.  The potential to have to fall 
back to a TCP call-back connection is pretty scary to sites that receive 
billions of messages a day.

Again though, I'm fine with the draft the way it is as long as we tell 
people to be wary of the aggregate limit on TXT records and the 
suggested include: workaround.

-Rand

---

From: Roy Badami <[email-masked]>
Date: Sun, 5 Sep 2004 17:51:19 +0100

>>>>> "Rand" == Rand Wacker <[email-masked]> writes:

    Rand> The 480 byte limit is a limit of UDP.  The potential to have
    Rand> to fall back to a TCP call-back connection is pretty scary
    Rand> to sites that receive billions of messages a day.

It's not a limit of UDP, though it stems from the 512 byte limit that
RFC1035 places on DNS over UDP.

EDNS0 (RFC2535) provides a mechanism for sending larger DNS
transactions over UDP.  RFC3226 (which is also referenced by Sender
ID) says that EDNS0 implementations MUST allow at least 1220 bytes,
and SHOULD allow at least 4000 bytes.

       -roy

---

From: "Scott Kitterman" <[email-masked]>
Date: Sun, 5 Sep 2004 13:16:15 -0400

> [mailto:[email-masked]]On Behalf Of Matthias Leisi
> Sent: Sunday, September 05, 2004 10:41 AM
> To: 'IETF MARID WG'
> Subject: Re: consensus call of RR prefix
>

For me, the issue isn't BIND, but the web front end that my DNS provider
uses to enable me to enter data.  For the record, www.pairnic.com currently
does the following:

TXT support: Yes.
CNAME support (in my case www is always a CNAME for the base domain): Yes.
Add sudomains: Yes.
Underscore support: No.
SRV support: No.

Underscore and SRV support are both on their list of things to do, but are
not currently available.  If the IPR issue is satifactorily resolved, then I
would like to publish records for both SPF and Sender-ID.  If an underscored
prefix is required, then I'll be unable to do so.  The marginal benifit to
me for publishing records for both SPF and Sender-ID (instead of just SPF as
I currently do) is not sufficient for me to consider changing DNS providers.

Speaking for myself, as a very small fish in this pond, if the IPR issue is
resolved and there is no underscored prefix requirement, I'll publish
immediately.  Otherwise, maybe someday.

Scott Kitterman

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 05 Sep 2004 13:26:05 -0400

> and how strong technically these arguments are.

Doesn't SRV use _?

---

From: Peter Koch <[email-masked]>
Date: Sun, 05 Sep 2004 20:24:24 +0200

> and SHOULD allow at least 4000 bytes.

this reference is questionable at best (read: DOC-BUG). RFC 3226 specifies
behaviour of RFC2874-conformant DNS implementations (A6 is kinda dead now)
and for DNSSEC-aware DNS implementations. None of both is relevant to the draft
in question and, more importantly, it is suboptimal to reference a
requirements document for DNS server implementations this way.
If at all, the requirement would have to be specified explicitly for the
'SPF' RR type, e.g.: all DNS servers and resolvers implementing 'SPF' are
required to support EDNS0 and ... size requirements ...
But then, please note that RFC 3226 is rather old and especially it predates
RFC 3597, so usually we do no longer assume that DNS implementations need
to explicitly support a certain RR type. And, you can't just 'require'
conformance for the intermediaries.

However, based on deployment surveys you may *assume* RFC 3597 conformance.
There has been work made available to this list (by Roy Arends, I guess),
showing which SW versions are conformant. An example survey for the distribution
of DNS server(!) versions can be found at
http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-survey.pdf
Also, Jakob Schlyter has done an extensive interoperability test for
RFC 3597 implementations. Details can be found in the minutes of the DNSEXT
meeting of IETF60.

Bottom line: Size does matter. However, EDNS0 is there. Today on a moderate-
size server (~5000 zones, non-representative sample, of course) 2/3 of all
incoming queries (speaking of resolvers, not servers now) used EDNS0.

-Peter

---

From: "jpinkerton" <[email-masked]>
Date: Sun, 5 Sep 2004 21:56:24 +0200

----- Original Message ----- 
From: "Matthias Leisi" <[email-masked]>
To: "'IETF MARID WG'" <[email-masked]>
Sent: Sunday, September 05, 2004 4:41 PM
Subject: Re: consensus call of RR prefix

> Which DNS providers do (not) allow subdomains and/or TXT records?

A list of ones that do,   is at

http://www.spf.idimo.com

It's not a complete list, but I will update it with information sent to me.

Kind regards,

John Pinkerton.
[email-masked]
ICQ 313355492

---

From: Mark Lentczner <[email-masked]>
Date: Sun, 5 Sep 2004 14:01:45 -0700

Three items to respond to:

[-1-]
> _prefix.subdonain.example.com.
Usually, the use of the wild-card record is to say "-all" for anything 
in a subdomain, and hence this record is would not be the same as the 
domain's record:

	with prefix:
	_prefix.example.com IN SPF2 "spf2.0/pra +mx +a -all"
	*.example.com       IN SPF2 "spf2.0/pra -all"

	without prefix:
	example.com         IN SPF2 "spf2.0/pra +mx +a -all"
	*.example.com       IN SPF2 "spf2.0/pra -all"

There is no savings and no difference.  On rare occasion when you want 
the same record, a prefix fails to help:

	with prefix:
	*.example.com       IN SPF2 "spf2.0/pra +mx:mx.example.com -all"

	without prefix:
	example.com         IN SPF2 "spf2.0/pra +mx:mx.example.com -all"
	*.example.com       IN SPF2 "spf2.0/pra +mx:mx.example.com -all"

It still makes no difference over-the-wire: Only one record would be 
ever returned, so this savings is only one administrative entry.  Not a 
ringing endorsement in my mind.

[-2-]
On Sep 5, 2004, at 9:31 AM, Rand Wacker wrote:
> The 480 byte limit is a limit of UDP.
As has been pointed out, this limit is not in UDP, but in the original 
DNS spec, which was later removed with EDNS0.  You can check what a 
server's limit is with a dig command like:
	dig +bufsize=1000 example.com txt
You will find a line in the results like:
	; EDNS: version: 0, flags:; udp: 4096
The 'udp' number gives the maximum size the server can support before 
falling over to TCP.  If the resolver querying also does EDNS0, then 
the min of the two numbers can be used.  Finding a resolver's 
advertised EDNS0 can be a bit tricky, involving tcpdump.  On my 
servers, running several year old Linux distributions, the EDNS0 sizes 
were all either 2048 or 4096.

[-3-]
> requirements document for DNS server implementations this way.

The actual text from the current draft is:
"Sender-ID compliant sites MUST use DNS recursive  servers that support 
EDNS0 [RFC2671] and [RFC3226] in order to be able to receive large DNS 
RR sets."

This text, including the reference to RFC3226, came directly from 
Ólafur of DNS-EXT.

	- Mark

Mark Lentczner

---

From: <[email-masked]>
Date: Sun, 5 Sep 2004 17:52:34 -0400

> Just for clarification: Which DNS servers do /not/ support
Sorry, that should read: DNS providers whose UI on the server does not support "_".

> Which DNS providers do (not) allow subdomains and/or TXT records?
Again, its not just about whether the DNS provider refuses.  My personal DNS provider does not
support, TXT, so I had to wade through a support call (which turned into emails) to get them to set
my vanity domain with an SPF record.  But not everyone (most?) with domains (vanity or otherwise)
would go to that effort.

I expect many/most DNS providers will enhance their UI to allow TXT records (all I have contacted or
heard about have said "coming soon").  But at least some (including mine) are not allowing
subdomains or extensions beyond the usual www, ftp etc.  (Course, the subdomain could become one of
"the usual", if its ratified)

> adding a "www" record to a domain.
Agreed.  But its not me that needs convincing, its the DNS providers.

> (Adding TXT records to the admin GUI of my non-profit ISP took me a
Agreed it can be done (providing the backend DNS server can do it).  But some DNS providers have big
fancy (aka crappy) integrated (often flash based, ugh!) UI's (e.g. look.ca)  Changing those UI's can
be non trivial.

> IMO, there are no technical or admin issues for or against RR
Provided you don't consider deployment/adoption technical, and you never have to explain to a "*
Certified * Engineer" how/why things actually work.  You really cannot just look at technical
issues, you have to look at all that are reasonably relevant and can have an actual impact.

> prefix (after all, we don't have a prefix for MX records).
Agreed.  And that *is* where I think (and believe) we are going, our own RR type.

> were a long-term solution.
I suspect within about 4 years of dedicated RR type approval the significant majority of published
domains would have switched.  (Or at least published new type, hence the second lookup on the TXT
type becomes unnecessary).  This opinion is based on the idea that those who published TXT would be
just as willing/eager to adopt the RR type, and that the new RR type is approved and deployed BEFORE
SPF publishing becomes a "standard requirement" before sending email.

> As this quite possibly is not the intention
Agreed.

Terry

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 6 Sep 2004 00:15:52 +0200

On Sat, Sep 04, 2004 at 09:20:18AM -0400, [email-masked] wrote:
> publishing easy or it won't get done)

I don't understand this statement.

Why should 

  _marid	   IN	TXT	"blabla"

be a subdomain and not supported while

  www	           IN   A       1.2.3.4

is a normal entry not causing a subdomain? Where's the difference?

I believe this is easier and more supported than placing the 
TXT record directly in the domain name. Not all interfaces support

	   IN TXT "..."
or
@	   IN TXT "..."

and many users don't understand that. A TXT record for _marid 
is plain, strait forward, and simple.

regards
Hadmut

---

From: <[email-masked]>
Date: Sun, 5 Sep 2004 19:18:35 -0400

> From: Hadmut Danisch [mailto:[email-masked]]
> Sent: Sunday, September 05, 2004 6:16 PM
> To: [email-masked]
> Cc: 'IETF MARID WG'
www is already built in (visibly or implied) for DNS providers UI.  Non standard subdomains often
are not.  I am not saying this is correct (its not) or acceptable (that's a business model decision
of DNS provider) but I believe it to be a reality for at least some DNS providers.

> TXT record directly in the domain name. Not all interfaces support
I disagree, I have seen more UI's that support TXT records (albeit very few, but apparently more and
more every day) then support adhoc (beyond the standard www, ftp, etc) subdomains.

> is plain, strait forward, and simple.
I agree *if* one understands how DNS works.  I would hazard a guess that a significant number of
owners of domain names wouldn't.  This alone does not constitute grounds for non-deployment of
_marid, but it is still a valid point against.

Terry Fielder

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 5 Sep 2004 17:04:19 -0700 (PDT)

On Sun, 5 Sep 2004, Mark Lentczner wrote:

> > It allows to avoid necessity to enter separate records for both 
> > "example,com" and for "*.example.com" while with prefix one record for 
> > "*.example.com" would suffice and cover both _prefix.example.com and 
> > anything else like _prefix.subdonain.example.com.
>

That depends on the use of wildcards. When wildcards are used in parallel 
with wildcard MX entries, then the SPF record for domain and widlcard
subdomains will most likely be the same. 

Different situation is for somebody who just wants to say that there are 
no working subdomains under his domain, then "-all" can be used. But do 
remember that wildcard will actually not work for any subdomain that is 
deligated (i.e. ones that have their own direct "A", "MX" or any other 
record) so this might not have much value as I don't think spoofing 
non-existing hosts is very common and these can be quickly cought by just 
checking if the host actually exists...

> 	*.example.com       IN SPF2 "spf2.0/pra -all"

I assert that if you have wildcard MX record, then you would actually want
wildcard subdomain record to be exactly the same, see above.

> ringing endorsement in my mind.

I agree with above, there is no difference in the wire, the difference is 
only that administrator needs to enter one record instead of two.

And yes, this is not very strong reason to do it, but it does mean
that on at least one issue (be it a small one), the prefix does help
with wildcards where as every other issue is exactly the same no
matter if prefix is used or not. So really we should not put any
statement like that "-prefix does not solve the wildcard issue",
as not using prefix does not solve these issues either!

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "Scott Kitterman" <[email-masked]>
Date: Sun, 5 Sep 2004 21:55:49 -0400

> [mailto:[email-masked]]On Behalf Of Hadmut Danisch
I can't tell you why, but today, I can do all of those you list through my
DNS provider except, _marid.  I could do marid without the _, but without
the _, you lose some of the collision avoidance potential.  Trying to add an
A record for _marid gets me this error:

"Host names may only contain 0-9, A-Z, or hyphen (-) characters."

Is that incorrect?  Yes.

Is that common?  Yes.

Scott Kitterman

---

From: <[email-masked]>
Date: Sun, 5 Sep 2004 22:07:53 -0400

> Sent: Sunday, September 05, 2004 8:04 PM
> To: Mark Lentczner
> Cc: IETF MARID WG

Please relax, "-prefix does not solve the wildcard issue" does *not* mean/imply "lack of prefix
solves the wildcard issue", because if it did, then the statement would be "-prefix causes an issue
with wildcards".  There are wildcard issues that exist without prefixes, if they didn't, there
wouldn't be any issue for us to discuss...
There are wildcard issues that are as yet unresolved (albeit rare).  I thought that prefixes were
proposed as a solution (weren't they?) and were found not to be a resolution.  If that was not the
case my mistake.  But either way, the statement is accurate as having a prefix does not actually
*solve* a wildcard issue.

Terry Fielder

---

From: Mark <[email-masked]>
Date: Mon, 06 Sep 2004 03:42:25 GMT

>> is a normal entry not causing a subdomain?

If we require an underscored _marid prefix to prevent potential collisions 
with existing namespace, are we then not dealing with a circular reasoning 
here?

I mean, if the underscore prefix is not widely deployed because few DNS 
providers support it, then choosing an underscored prefix to avoid collision 
leads to having to make world-wide changes to providers' User Interfaces, so 
that the _marid prefic can be widely deployed; after which time you lost the 
advantage again of not running the risk of collision.

In that case, we might as well drop the underscore requirement to begin 
with.

- Mark

---

From: Bill McQuillan <[email-masked]>
Date: Sun, 5 Sep 2004 22:47:25 -0700

> advantage again of not running the risk of collision.

I believe the reason for the underscore is that it is, in fact, NOT a valid *hostname* character, but it IS valid in a domain name. It seems to be a common, but incorrect, belief that DNS is only for hostnames.

-- 
Bill McQuillan <[email-masked]>

---

From: Daniel Senie <[email-masked]>
Date: Mon, 06 Sep 2004 02:31:52 -0400

At 01:47 AM 9/6/2004, Bill McQuillan wrote:

>I believe the reason for the underscore is that it is, in fact, NOT a 
>valid *hostname* character, but it IS valid in a domain name. It seems to 
>be a common, but incorrect, belief that DNS is only for hostnames.

So let me get this straight.

Folks are worried about the companies some people outsource their DNS to 
(instead of running their own servers) not handling _marid or _foo or 
whatever the tag would be. But folks are not worried about updating name 
server software to support a new RR type and getting that software 
deployed, and are not worried about getting MTA software updated to handle 
new a new capability and get that deployed.

Am I the only one who thinks this is looney? If SPF or SenderID become 
accepted, then people will update MTA software to make it work. They will 
update DNS server software to make it work. And if outsourced DNS providers 
wish to remain competitive, they'll add capabilities to their GUIs. Let the 
market handle it.

It sure seems like folks are getting hung up over what's probably the 
EASIEST thing to deal with, that being finding a DNS outsourcer (if you 
even need one) that'll publish the records you request.

Let's get back to deciding what's right at the protocol level, and leave 
the business decisions of web-interfaced DNS providers out of the discussion.

I, for one, would like to hear more on the technical merits of using _spf 
or _marid or _foo vs. not using it.

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 6 Sep 2004 00:34:32 -0700 (PDT)

> new a new capability and get that deployed.

Folks are worried about both cases. The two cases are different and 
require different handling. First of all with new RR type, it is not
only dns servers but some resolvers that may need to be updated, this
is a process that takes quite a bit longer and requires recompiling
dns servers and/or resolvers, people installing new software, etc.

On the other hand with "_" prefix, all dns servers and resolvers can 
handle it. It is only that to managed these servers, number of providers
have deployed custom GUI interfaces. In some cases, these interfaces set
correct characters to be used and they have disallowed use of "_". It
would not be hard to correct it - most of these GUI are interpted scripts
(perl cgi, php, asp, etc) and to disallow those characters they have a 
filter function (that function checks if all characters in hostname or 
domain name are alphanumeric or "-") which is the only one that will need 
to be updated to allow "_" character. Not very hard to do and they really
should have done it by now considering SRV records have existed for 
several years now.

> wish to remain competitive, they'll add capabilities to their GUIs. Let the 
I agree with you. If MARID becomes popular within a year all GUI will
be able to handle underscores if its part of the standard. Its just a very 
easy fix for those who dont - see above.

> or _marid or _foo vs. not using it. 

Using it allows to avoid collisions with other TXT records or with any other
possible use of SPF in the future. And it gives a good example for anybody
else who is considering temporarily using TXT records for their experiment.

BTW - I now support that both TXT and SPF RR records be done in SRV way:
 _smtp._tcp.example.com.  IN   TXT   "SPF2.0/PRA ..."
 _smtp._tcp.example.com.  IN   SPF   "SPF2.0/PRA ..."

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "jpinkerton" <[email-masked]>
Date: Mon, 6 Sep 2004 09:39:19 +0200

----- Original Message -----
From: "Daniel Senie" <[email-masked]>
To: "MARID" <[email-masked]>
Sent: Monday, September 06, 2004 8:31 AM
Subject: Re: consensus call of RR prefix

> or _marid or _foo vs. not using it.

Me too - I am lost now - would someone like to summarise the requirement for
a sub-domain at all.  The reasoning has got lost in the chaff of whether
it's possible - which it is, or will be once the standard hits the streets.

I will happily add the names of DNS providers that have this facility to the
list at www.dns.idimo.com so that there is the beginnings of a reference for
people who want to experiment.  Please see the notes on the website.

Slainte,

JohnP.
[email-masked]
ICQ 313355492

---

From: David Blacka <[email-masked]>
Date: Mon, 6 Sep 2004 22:34:25 -0400

> 	*.example.com       IN SPF2 "spf2.0/pra -all"

This is not a valid use of DNS wildcards, assuming I understand the problem 
you are trying to solve.

In your example, "*.example.com  IN SPF2 "spf2.0/pra -all", would only match 
names in example.com that do not exist (actually, the matching behavior is a 
bit more subtle that that).  But, as has been pointed out on this list more 
than once, saying "-all" for non-existent names is unnecessary.

What I think you are really after is to put a "-all" SPF2 record for every 
(other) existing A, AAAA, and MX record.  There is no convenient DNS 
construct for this behavior.

> This text, including the reference to RFC3226, came directly from

I have a hard time seeing how using EDNS0 rises to the level of MUST.  Since 
querying for and publishing SPF2 or TXT records will not, in the typical 
case, cause truncation without EDNS0, this should be a SHOULD, not a MUST.  
That is, using EDNS0 is a good idea, but hardly a requirement.

---

From: John Levine <[email-masked]>
Date: 7 Sep 2004 03:43:32 -0000

>and SHOULD allow at least 4000 bytes.

An acquaintance who's tried out EDNS0 tells me that it is surprisingly
hard to deploy and has worse interoperation problems than I would have
expected.

The first category of problems is what one might call the braindead
firewall problem -- a whole lot of firewalls know that a DNS packet
can never ever be bigger than 512 bytes, so they throw bigger packets
away.  While there are well-documented configuration fixes for them
all, there are a whole lot of firewalls with this misfeature, to the
extent that the folklore among Windows admins (Windows has a widely
available EDNS0 client) is not to turn on EDNS0.

The second is the probe problem.  An EDNS0 client sends a request with
a pseudo-RR asking for a big response, and then falls back to regular
queries if the server doesn't grok EDNS0.  But servers un-grok EDNS0
in a remarkable number of unfortunate ways, including sending back
responses without the request's sequence number or any other way to
figure out what request it's responding to, or sending no response at
all.  Since the number of EDNS0 servers is small, even with well
behaved servers EDNS0 clients send roughly twice as many requests as
they would otherwise, one to probe and then one to do the actual
request.  Clients can try to keep a cache to remember the results of
prior probes but even that runs into trouble when you have a bunch of
servers responding to the same IP and they're not all the same.

The point of all this is that big responses will continue to be a
problem probably forever.  I think that the way to keep the response
size down is to deploy new RR types as quickly as possiblee.  Prefixes
are less helpful since as soon as you have wildcards (which really do
exist in mail domains) all the records all end up in all the nodes
anyway.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I shook hands with Senators Dole and Inouye," said Tom, disarmingly.

-- 
John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 330 5711
[email-masked], Mayor, http://johnlevine.com, 
Member, Provisional board, Coalition Against Unsolicited Commercial E-mail

---

From: Max Kanat-Alexander <[email-masked]>
Date: Tue, 07 Sep 2004 14:20:54 -0700

> uses to enable me to enter data.  For the record, www.pairnic.com currently

	Frankly, with the momentum and requests I've been seeing from my
customers, I suspect that most large DNS providers will work on
supporting anything that Sender ID requires, provided that the IPR
issues are resolved and it can be included in SpamAssassin.

	-Max

---

From: Max Kanat-Alexander <[email-masked]>
Date: Tue, 07 Sep 2004 14:20:29 -0700

> -implementing a prefix adds complexity (comprehension complexity if

	For me as a system administrator, I would say that it simplifies
keeping track of my DNS records.

> -many dns providers do not support users adding subdomains (or not

	Those same DNS providers probably don't support TXT records (and
certainly won't support SPF records).

> -prefix does not solve the wildcard issue

	Though wildcards are rarely used.

> prefix) if one really wants prefix

	That's true. Do most DNS servers support this easily, and are the
admins who would need it aware? Probably, but I don't actually know.

> and lack of alternatives.

	In my experience (we were the first company with a commercial MTA to
implement Caller ID), no customer who talked to me has ever had a
problem with the prefix. The TXT record was a more common problem.

	-Max

---

From: Ryan Ordway <[email-masked]>
Date: Tue, 07 Sep 2004 14:56:21 -0700

No. 

1) Inconsistent with SPF RR that doesn't use a prefix
2) Causes deployment headaches for those who use
   DNS providers whose web-based tools cannot handle
   sub-domains or underscore characters.

-- 
HELO, my name is root... you have SIGKILLed my father... prepare to vi!

---

From: Ryan Ordway <[email-masked]>
Date: Tue, 07 Sep 2004 15:44:19 -0700

>    sub-domains or underscore characters.

	Granted, said providers probably can't handle SPF
RRs or TXT records either.

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 07 Sep 2004 18:52:15 -0400

> 1) Inconsistent with SPF RR that doesn't use a prefix

We could move the RR into the same address space.

>    sub-domains or underscore characters.

I don't know how wide spread that would be. Based on the comments on the 
lists, there are already issues with TXT records and provider support.

Collissions with other TXT records worry me more which is why I would 
rather see a prefix or use SRV. I can almost bet you that within a year 
of MARID someone else will use us as precedent for another RR/TXT 
experiment.

Yakov

---

From: Mark Lentczner <[email-masked]>
Date: Wed, 8 Sep 2004 13:21:49 -0700

> This is not a valid use of DNS wildcards, assuming I understand the 
I'm not sure what you mean by 'valid' here -- certainly the domain file 
is legal and works.

> than once, saying "-all" for non-existent names is unnecessary.
The use of the wildcard with -all is an attempt to catch all e-mail 
which someone might send with forged malicious intermediate names:

	[email-masked]

It has been claimed that MTA software is generally configured to reject 
e-mail that comes from a domain that doesn't exist.  While this is true 
at my site, I have seen no stats to back the claim up.  Unless the 
numbers were very high (>95%), I'm not sure relying on other people's 
MTAs to catch this for one's domain is a good idea.

Nonetheless, many sites have wildcard MX records so that they can catch 
mail sent to any address.  This means that they want to receive mail, 
not matter how it is addressed within their domain, but they don't 
authorize sending with such addresses.  In theses cases, all domains 
exist (due to the wildcard MX record), and so other people's MTAs won't 
reject based on domain non-existance.

> construct for this behavior.
One needs to do this as well.

	- Mark

---

From: David Blacka <[email-masked]>
Date: Wed, 8 Sep 2004 17:46:22 -0400

> I'm not sure what you mean by 'valid' here -- certainly the domain file

I meant that it wouldn't work as I thought you were describing it, not that it 
wouldn't load.

> MTAs to catch this for one's domain is a good idea.

Well, you are relying on them to do the Sender-ID check, right?

> reject based on domain non-existance.

This wasn't the case that you were describing (as I read it, anyway).  This is 
a case where a wildcard SPF2 or TXT record *would* work.

> One needs to do this as well.

You would need to put a wildcard "-all" record below each existing name in 
your zone as well (except delegations).  Again, if I understand your problem 
correctly.

For the record, I think that RECOMMENDING that people publish wildcard "-all" 
records (in the absence of a wildcard MX) is not a good idea at all.

--
David Blacka    <[email-masked]> 
Sr. Engineer    VeriSign Applied Research

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 8 Sep 2004 17:56:25 -0700 (PDT)

> reject based on domain non-existance.

You're making an assumption that to check if domain exist one would make
an "A" or "AAAA" query on that domain and if no record is received assume
that domain is invalid, that is not correct. 

There is important difference that should be made by implementors about 
dns error codes. If domain does not exist the correct error code is RCODE3 
(NXDOMAIN) and in that case you can safely assume there is no such domain 
and reject the email. 

However if subdomain is defined by wildcard MX record (or any other wildcard 
record for that matter), the query for "A" on that domain would return 
RCODE 0 (NO ERROR), but there would not be an an ip address available for 
query in the ANSWER section, which would cause normal dns resolver to 
answer with its own error code (NODATA for bind-based resolver).
(Actually to be more precise NODATA should be given if answer section is 
 empty, but dns resolvers can't make this assumption because of other 
 problems; for example if direct name does not exist but there is a CNAME
 or DNAME record for the same name, the answer section given by dns
 server should contain that - unfortunetly I sometimes see CNAMEs listed
 in Additional section. At the same time query for A when there is an AAAA
 on some servers would cause an AAAA to be addded to additional section,
 or possible that is the other way around...)

P.S. I recently wrote my own dns resolver, so these things had to be 
looked up in RFCs and sometimes found just by direct testing. Also
I'm of the opinion that DNS RFCs are inconsistant with some of the
existing implementations (bind, djbdns, etc), the responses are
different for example between various versions of bind if domain is
not deligated (and when its deligated authoritive NS servers appear in 
different sections depending on bind dns server version). Its still
amazes me that dns works so well with so much difference in responses;
the credit goes to dns resolvers, that try to account for all these 
differences and always use Postel's principal to be very liberal in what 
you accept.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 10 Sep 2004 23:16:40 +0200

Mark Lentczner wrote:
 
> many sites have wildcard MX records so that they can catch
> mail sent to any address.  This means that they want to
> receive mail, not matter how it is addressed within their
> domain, but they don't authorize sending with such addresses.

-all is not the only application of wildcards, for me it's a
redirect=claranet.de doing the trick.

                     Bye, Frank

---

From: Jonathan de Boyne Pollard <[email-masked]>
Date: Mon, 13 Sep 2004 17:10:34 +0100

[...] leaving the TXT records in the domain.tld dataspace, while ugly, seems like a good bit of parallelism for the SPF records that will be published in the same place.

I concur. Purely pragmatically, many people will want to check both SPF and IETF-compliant Sender ID. Being able to fetch both with a single query is therefore beneficial.

... but also impossible if the resource records are, as here, of two
different types - TXT and SPF,
respectively.  (Before someone says it: No, "any" is not the
same as "all".)  In the general case, which applies here, to look up
two resource record sets of different types always requires two DNS
transactions.

(Of course it doesn't matter if I use separate pieces of software to check SPF and Sender ID, both of which make their own queries; my local caching nameserver will still ensure that only one query is made to the authoritative nameservers.)

That is not what will happen.  Front-end transactions to
proxy DNS servers only combine at the back-end if they are looking up
the same resource record set keyed by the same <owner,class,type>
tuple.

---

From: Jonathan de Boyne Pollard <[email-masked]>
Date: Mon, 13 Sep 2004 19:19:37 +0100

It has been claimed that MTA software is generally configured to reject e-mail that comes from a domain that doesn't exist. [...]

[...] many sites have wildcard MX records so that they can catch mail sent to any address. This means that they want to receive mail, not matter how it is addressed within their domain, but they don't authorize sending with such addresses. In theses cases, all domains exist (due to the wildcard MX record), and so other people's MTAs won't reject based on domain non-existance.

You're making an assumption that to check if domain exist one would make an "A" or "AAAA" query on that domain and if no record is received assume that domain is invalid, that is not correct.

No.  He's making the assumption that if an "MX" lookup returns a
non-empty resource record set, the SMTP Relay server infers that the
domain name does exist.  And he's entirely correct.

There is important difference that should be made by implementors about dns error codes. [...]

The distinction between a "no such name" error and an empty resource
record set isn't relevant to what he is discussing here.  The wildcard
transforms the "no such name" error into a non-empty MX
resource record set, just
as Verisign's wildcards did for A resource record sets.

Actually to be more precise NODATA should be given if answer section is empty, [...]

Wrong.  RFC 2308 shows several response forms comprising complete
answers with empty resource record sets, that do not have
empty "answer" sections.  Not only is an empty "answer" section not
the definition of an empty resource record set answer, it actually
doesn't convey the empty resource record set properly (because of a
schema mismatch between the DNS protocol and the DNS database).  It
doesn't convey the TTL information for the empty resource record set.

but dns resolvers can't make this assumption because of other problems;

They cannot make that assumption because it is a wrong one to make.

At the same time query for A when there is an AAAA on some servers would cause an AAAA to be addded to additional section, or possible that is the other way around...

Either way around is perfectly legitimate.  The well-known problem with
some (broken) content DNS server softwares and AAAA
resource record sets is that they'll answer with the data for an A
query but give a "no such name" answer to an AAAA query,
making the apparent existence of the name in IP6-aware applications
dependent from the exact relative order in which the A
and AAAA lookups are done.

---

From: Jonathan de Boyne Pollard <[email-masked]>
Date: Mon, 13 Sep 2004 16:56:29 +0100

Any requirement (or even expectation) of DNS over TCP will probably kill widespread adoption of Sender ID, as DNS over TCP does not work over a large number of networks. Either it's blocked at a firewall, or it's disabled on the DNS server.

If DNS/TCP is blocked at a firewall, then that firewall is badly
configured.  (People often come to DNS discussion fora asking what
shape of holes they should knock into their firewalls.  The
frequently given answer on the subject clearly states that such holes
will encompass DNS/TCP for the back-ends of resolving proxy DNS servers.)
And if you think that resolving proxy DNS server softwares have the
capability of disabling the use of DNS/TCP, then you are confused.  No
mainstream resolving proxy DNS server has such a capability (and quite
rightly so, given RFC 1123 section 6.1.3.2).  Only content
DNS server softwares provide anything remotely like such a
capability, and only one mainstream DNS server software package, djbdns, actually has the
ability to selectively disable the use of DNS/TCP for its content DNS
service.  Other content DNS server softwares have the capability of
disabling the "zone transfer" database replication mechanism; but that
is not the same as disabling the use of DNS/TCP, old wives
tales to the contrary notwithstanding.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 14 Sep 2004 08:38:03 +0200

On Mon, Sep 13, 2004 at 04:56:29PM +0100,
 Jonathan de Boyne Pollard <[email-masked]> wrote 
 a message of 32 lines which said:

>    and only one mainstream DNS server software package, [2]djbdns,
>    actually has the ability to selectively disable the use of
>    DNS/TCP for its content DNS service.  Other content DNS server
>    softwares have the capability of disabling the "zone transfer"
>    database replication mechanism; but that is not the same as
>    disabling the use of DNS/TCP, old wives tales to the contrary
>    notwithstanding.

I am not sure you know what you are talking about. nsd
(http://www.nlnetlabs.nl/nsd/), which is used for k.root-servers.net
and for our ns2.nic.fr, has such a capability (just run it with -n 0).

---

From: John Levine <[email-masked]>
Date: 14 Sep 2004 16:23:26 -0000

> configured.

No doubt, but if we had all agreed to disregard problems due to
misconfiguration, we'd be having a very different discussion.

The people who run UltraDNS tell me that they've observed a widespread
resolver library bug that fails unpleasantly when a DNS TCP
transaction doesn't fit in a single TCP segment.  The client
incorrectly concludes that the other end aborted the session and it
tries again immediately.  They discovered this when an apparent DDOS
attack turned out in fact to be a whole lot of buggy resolvers trying
to fetch an RR set that had recently grown beyond 512 bytes.

You don't need to tell us that this shouldn't be a problem.  But the
reality appears to be that we won't be able to use widespread DNS over
TCP for a long time, if ever.  It's probably easier to roll out EDNS0,
even with all its problems.

Regards,