Re: The state of DNS support, was Deprecating SPF
Jay Daley <[email protected]>
| Newsgroups | gmane.ietf.dnsext |
|---|---|
| Message-ID | <[email protected]> |
Hi John On 29/08/2013, at 4:12 AM, "John Levine" <[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. > > 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. That's the whole point. People are already loading up TXT with lots of stuff, we can't stop that, but we can tidy it up, make it more manageable and reduce unnecessary data being transferred. Adding this is only going to help. > 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. Not in an RFC they won't as we can control that. Perhaps in practice yes but they can omit prefixes on SRV records and that didn't stop that RR. Would you be happier if we renamed the record for PREfixed TeXT ~ PRETXT ? >> = 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. This is *exactly* the same as existing wildcard support but with a different syntax and a prefix. So not that complicated. Not trivial no, but worth the pain. It's also a mechanism that has possible use in other new RRs. > 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. Correct me if I'm wrong, but every DNS implementation already supports wildcarding. > Or if you want to open up the guts of the DNS, just make this work: > > _prefix.*.foo.example. TXT "stuff about foo" That's silly as you know. But what I do think we should open up is whether wildcarding is enough. As we know the point is to save people from the pain and waste of having to mirror RRs all over the place and the inherent dangers of missing one out. But wildcarding only flows down and stops at the zone cut. Perhaps we need to consider either a mechanism that doesn't stop at the zone cut (which radically changes server design) or a flow up mechanism. cheers Jay -- 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