Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 26 Aug 2005 15:40:27 -0700

As has recently been pointed out on the namedroppers list, the dual
track RR and TXT approach does not work. It leads to ambiguities when
the records do not match - which they will inevitably dur to the DNS
protocol.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Julian Mehnle
> Sent: Friday, August 26, 2005 5:21 PM
> To: [email-masked]; MARID
> Subject: Re: Appeal: Publication of 
> draft-lyon-senderid-core-01 in conflictwith referenced 
> draft-schlitt-spf-classic-02
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hallam-Baker, Phillip wrote:
> > Which would at the same time provide an opportunity to 
> address the one 
> > part of SPF/Sender-ID that does give me significant concern, the 
> > exclusive appropriation of the TXT record.
> >
> > A prefixed record would be much less likely to collide with other 
> > records.
> > 
> > A proposal has been made to cut an new RR but as the group 
> discovered 
> > 50% of the legacy infrastructure does not support new RRs despite 
> > claims to the contrary. Support in this case has to be production 
> > quality, not the ability to coax particular bits out of a server in 
> > certain limited circumstances that no network admi is ever going to 
> > accept on a production server.
> 
> What about the new SPF RR type (99) recently assigned by IANA?
> 
>   $ named -v
>   BIND 9.3.1
>   $ grep TYPE99 /etc/bind/zones/net.mehnle
>   @               IN      TYPE99  \# 15 0e763d73706631206d78202d616c6c
> 
>   $ dig -v
>   DiG 9.3.1
>   $ dig mehnle.net TYPE99 +sho
>   \# 15 0E763D73706631206D78202D616C6C
> 
>   $ host -V
>   host version 991529
>   $ host -t 99 mehnle.net
>   mehnle.net              99      # (     ; unknown type
>           0E 76 3D 73 70 66 31 20 6D 78 20 2D 61 6C 6C    ; 
> .v=spf1 mx -all
>           )
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> 
> iD8DBQFDD4ewwL7PKlBZWjsRAsJ1AJ9mS+vB3+zp5MVWTB5x5Q6N4oZK1gCgvn+e
> hOvx+pNMHSIPVU1Q9HnvzOg=
> =+/dM
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 
>

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 26 Aug 2005 16:20:14 -0700 (PDT)

> the records do not match - which they will inevitably dur to the DNS

Actually what has been pointed out is that it is incorrect to make it
a permanent error if the client when retrieving both RRs checks if
they are the same and finds they are not because in some cases due
to DNS caching the results would not be consistent even if on the
server side it is (only a problem when record was recently updated).

That does not mean you can't make it part of the spec that if both RRs
are published they MUST be the same and that client should check SPF 
(type99) RR and if its not present then look for TXT RR. For those clients 
where algorithm like that is considered too slow (i.e. spamassasin which 
does all dns queries in parallel), then it will have to be that if SPF RR 
is received, its data is to be used (no matter if TXT RR as present or not).

--
William Leibzon
Elan Networks
[email-masked]