Re: The state of DNS support, was Deprecating SPF

>Having thought about this for a few days I've changed my mind and I'm happy to see SPF(99)  go. 

Whew!

>= So here's an example solution (and I mean an example since I'm sure there is a lot more to consider):
>
>3.  Create a new generic record for free form policy data that must be prefixed by protocol.  For example:
>
>_spf	.example.com.	POL	"a:mail.example.com -all"
>
>If we provide that one record then anyone can use it for any policy info without further need to change the DNS.
>To me that seems much more utilitarian than a protocol specific RR.

If it's prefixed, what's the advantage over TXT other than it isn't
TXT?  Once word gets out about it, I'd expect people to load it up
with all of the junk that people load into TXT.  You can be sure that
some bright bulb will use it without a prefix, arguing that's OK
because all of the other uses are prefixed so this won't collide.

>= A solution for the wildcard issue is a bit more complex, but here's an example
>
>4.  Add an rdata field to the POL record that if set to "*" (asterisk) applies this policy to the next level
>
>_spf.example.com. 	POL	*	"a:mail.example.com -all"
>
>This record is then used to synthesise the POL record in exactly the same way that a wildcard is.

This seems awfully complicated, and would require non-trivial extra
code in every authoritative name server.

Seems to me that if we could provision new RRTYPEs with less pain,
they already do what we want, don't need extra demultiplexing, and
has predictable and useful wildcard behavior.  

Or if you want to open up the guts of the DNS, just make this work:

_prefix.*.foo.example.  TXT  "stuff about foo"

I figure it shouldn't take more than a decade to discover all of the
weird ways it interacts with NSEC3.

R's,
John
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext