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 10:49:37 -0700

> Behalf Of Andrew Newton

> If this is the source of the conflict, then BOTH experiments should  
> not use the v=spf1 records.

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.

The main objection to prefixed records is that they do not work with
wildcards. This is actually a failure of imagination rather than fact.
It is quite possible to develop a resolution procedure for prefix
records that works acceptably with legacy DNS resolvers and meets the
needs of network admins.

The first step is to address the problem that wildcards do not match an
existing node. As was demonstrated on the list this is easily solved
using a macro processor.

The second step is how to create a wildcard for _prefix.*.example.com
without changing legacy DNS servers.

The way to do this is to introduce a pointer record using CNAME as
follows:

_prefix.exists.example.com        TXT     "Policy1"
*.example.com                     CNAME   _wildcard.example.com
_prefix._wildcard.example.com     TXT     "Policy2"

The resolution algorithm for domain X is:

1) Check for a TXT record for _prefix.X if it exists, return the TXT
string and stop

2) Check for a CNAME at X, if it does not exist return 'NIL' and stop

3) Check for a TXT record for _prefix.Y where Y is the CNAME mapping. If
it exists return the TXT string, otherwise stop.

Applying these rules to the scheme above we get:

Lookup ("exists.example.com", "prefix") = "Policy1"   [cost 1 lookup]
Lookup ("empty.example.com", "prefix") = "Policy2"    [cost 3 lookups]
Lookup ("empty.example.com", "noprefix") = NIL        [cost 3 lookups]

This algorithm is 100% compatible with the deployed, legacy DNS and
meets all use cases that were proposed for wildcarding. It never takes
more than three DNS lookups. The first two can be requested in parallel,
an intelligent DNS server could return the CNAME as an additional record
for optimization purposes.

If this mechanism was adopted as policy for ALL prefixed records there
would no longer be any need to define new RRs unless there was a need to
define a new record syntax. It would also allow admins to manage their
policy records much more effectively, the default node is treated as if
it was just another node.

If folk really want to argue over the SPF=1 issue I think that they are
saying that the protocol is not really embedded enough to be beyond
change. If that is the case I think that we should fix the problem
caused by the exclusive appropriation of TXT.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: wayne <[email-masked]>
Date: Fri, 26 Aug 2005 13:34:01 -0500

In <[email-masked]> "Hallam-Baker, Phillip" <[email-masked]> writes:

> [PHB brainstorms about a new protocol...]
>
> [...]

I don't believe this will work since CNAMEs have to be the only thing
in a given node, and so a wildcard CNAME would conflict with all other
wildcard usage, such as wildcard MX records.

-wayne

---

From: Julian Mehnle <[email-masked]>
Date: Fri, 26 Aug 2005 23:20:48 +0200

Hallam-Baker, Phillip wrote:
> 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
          )