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. Why is it important what the DNS manager cares about? 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. > 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. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf