Re: The state of DNS support, was Deprecating SPF

On Aug 28, 2013, at 12:00 AM, Jay Daley <[email protected]> wrote:

> 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.

Isn't that just TXT with a new name?  Why not just stick to TXT type-16?


> = 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.
> 5.  Or we could add a record under each sub-domain that refers back up a level:
> _spf.sub.example.com.	POLPTR	example.com.


That requires DNS server code to change, right?  That feels like a high barrier.

Thinking out loud, why couldn't we do this:

1) The IETF asks IANA to create a registry for name tokens, for use as domain name label prefixes, and "v=<name>" in TXT RDATA.

2) We pre-reserve the token "iana", which means we reserved a label prefix of "_iana", as well as "v=iana" as the first chars of the TXT RDATA.

3) We define an IETF RFC for this new "IANA" application, such that it is intended for other TXT-using applications to use, for the purpose of wildcarding and redirection.  So future apps don't need to re-do SPF's redirection stuff, but can instead use this new RFC's ABNF and rules to get redirection as well as wildcard support.  More importantly, it prevents cluttering of the apex.  The specific apps use their own registered name tokens for app-specific RDATA, but "iana" helps them for cases as shown below...

   *.example.com.                 MX      10      a.example.com
   *.example.com.                 TXT     "v=iana wildcard=_iana.example.com"
   _qux.example.com               TXT     "<qux-specific content>"
   _foo._iana.example.com.        TXT     "v=foo <foo-specific content>"
   _bar._iana.example.com.        TXT     "v=bar <bar-specific content>"
   _zoo._iana.example.com.        TXT     "v=iana redirect=_zoo.pwned.example.net"

This second "*.example.com" wildcard record is a normal TXT wildcard record, and thus causes a synthesized TXT RR to be returned for name queries where no name exists.  The returned RR is exactly what it is today for TXT RRs: the contents of the RDATA shown above.

There is NO change to DNS servers or client libraries required whatsoever.

So a client querying for "_qux.example.com" gets back "<qux-specific content>" as today.

But a client querying "_foo.nonameexists.example.com" on the above would get back "v=iana wildcard=_iana.example.com".

The specific FOO application (not DNS) sees that, and if it supports our new RFC, knows to generate a new query for the wildcarded-to name, but with its specific application prefix added in front.  So it would now query "_foo._iana.example.com" and get its rdata content.

This would of course cause FOO to do two DNS queries, but only for cases where a wildcard is used.  DNS servers could (optionally) optimize to reduce it to one answer if they support this new "iana" RFC as well, by synthesizing the final answer.  But if they don't it sill works.

The only difference between "wildcard=" and "redirect=" is that "wildcard=<target>" makes the app prepend its name token prefix again to the identified target domain-spec, whereas in "redirect=<target>" it does not prepend its name token prefix to the target domain-spec. 

Why do all that above?  To keep too many TXT RRs from cluttering up the apex, while still letting them have wildcard support.  And by reserving our own "iana" application ABNF and use, we give sanctioned guidance on how new apps can do this without screwing it up for everyone else, and let that portion possibly be integrated in DNS servers someday.

-hadriel

_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext