Re: The state of DNS support, was Deprecating SPF

On Aug 28, 2013, at 5:09 PM, Jay Daley <[email protected]> wrote:

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

If someone doesn't want to follow a new RFC, then they don't.  That's up to them.  It's no worse than without the RFC.  If they want to follow it, they get the benefits it provides.  Even binary-rdata folks could follow this new RFC though... "v=iana " is just a sequence of octets after all. :)


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

Yes, complex processing = bad.  NAPTR is complex, and it's motivating use-cases aren't as popular to begin with. (Although as an aside, in my particular world NAPTR gets used a lot)

I don't think this would be as complex though.  And if an app doesn't need the redirection portion, they don't implement it.  If they do need it, the SPF-style processing for it seems like a pretty simple one, and that's all I'm proposing for redirection.  The wildcarding portion is a bit more tricky, in the sense that a newly defined application can't know whether it needs wildcard support or not really, afaict; so if the app clients don't implement it then folks will continue to fill the apex with app-specific records.  But that's true no matter what we do.  At least by defining a way for it to work, we make it possible to do it in a better "standard" way, and it's possible for the DNS server folks to eventually implement support for it too and avoid double-queries.

The major advantage of keeping with TXT over a new POL RR is there's no new RR required.  Getting a new RR usable everywhere on the planet seems to be a big challenge.  And it's not under the app-developer's control to affect that type of change, or timeframe for it.

-hadriel

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