Re: The state of DNS support, was Deprecating SPF

Hi Hadriel

On 29/08/2013, at 5:52 AM, Hadriel Kaplan <[email protected]> wrote:

> 
> Isn't that just TXT with a new name?  Why not just stick to TXT type-16?
> ...
> That requires DNS server code to change, right?  That feels like a high barrier.

See my answer to John for the answers to those.


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

I really don't think we should be getting into defining the structure of data inside TXT records.  What if someone wants an all binary policy inside the TXT? (Like the hashed label list already mentioned for _atps).

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

That would certainly be a workable solution fi you ignore my concerns on defining the structure I mention above.  The difference between that and what I suggested is that you've moved the wildcard into the data and the processing of the wildcard into the app not the server.  However, I believe we have clear evidence with the very limited uptake of NAPTR that RRs that define complex processing paths in the client are not the way forward.

cheers
Jay

> 
> -hadriel
> 


-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
linkedin: www.linkedin.com/in/jaydaley

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