> On 05/Mar/12 18:09, John Levine wrote: > >>> Sometimes an ASCII text record will be fine, in other cases, it probably won't. > >> > >>My point is as we move again towards multiple text representations of "the digit five" for example, > >>both encoding and parsing is easier and more secure if that digit is really for example eight bits > >>and not "text" that someone has to parse. > > > > Unless you provision your DNS zones with a hex debugger, the digit > > will always start out as text that someone has to parse. The question > > is who does the parsing, the DNS server or the application. As I said > > in a previous message, I can see plausible reasons to put the parser into > > the application. > > > > Would you really want to build an SPF or DKIM parser into every DNS > > server? That's a lot of code that the DNS manager doesn't care about, > > but the mail manager does. > But it would be the same code, most likely by the same author(s). It > may be generic for a kind of syntax or specific for a RR type, > according to its author's convenience. On a system that allows new RR > types without recompiling, the code would come as some sort of plugin > in both cases. There are some false equivalences floating around here. I don't think anyone is suggesting that having provisioning systems or even DNS servers themselves check for syntax errors in the contents of complex records like DKIM, SPF, DMARC, or whatever is necessarily a bad idea. (Whether or not it will actually happen is another matter; I'm dubious.) Rather, the issue is with requiring it to happen in order to deploy a new RRTYPE of this sort, which is the result you get if the DNS server returns some series of tokens instead of the original text string. That's the sort of thing that forces people to upgrade, or search around for a script to do the conversion (which won't even occur to some), and that's an extra burden we don't need to impose. > Why is it important what the DNS manager cares about? Speaking as a DNS manager myself, I care a lot about being forced to upgrade. Upgrades bring unwanted bugs in other areas. In fact I'm not entirely thrilled with the idea of plugins to do some extra syntax. More code means more possibilities of bugs. I'd actually prefer to see more cross-checking of existing stuff - less code and greater benefit. > Parsers, > including null parsers, would come with the same sub-package that > enables the new RR type definition. Their complexity would only > matter to the people who read/maintain their sources. I'm sorry, but you're being naive about this. Complexity does matter to the people who just use software because added complexity translates to more bugs. > > PS: For anyone who didn't read my previous message, I am NOT saying > > that it's fine to overload everything into TXT. I am saying that new > > RRTYPEs that are text blobs interpreted by client software wouldn't > > necessarily be bad. > Agreed. That doesn't preclude syntax checking on loading the zone, > though. As long as we stick with syntax checking I'm (mostly) OK with it. Ned _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf