> On 07/Mar/12 09:42, ned+ietf@xxxxxxxxxxxxxxxxx wrote: > > > >> It would still be possible to work around the need for a plugin, e.g. > >> by depending on some wizard web site, as in John's thought experiment. > > > >> For the rest of us, the possibility to install a plugin that takes > >> care of all the nitty-gritty details, instead of having to wait for > >> the release and distribution of the next version of BIND, can make the > >> difference between deploying a new RR type right away and > >> procrastinating endlessly. > > > > You're still not separating the two cases. > I think I did, however badly. Let me try by example, assuming my > server doesn't recognize SPF. As it's unrecognized, I have to write > it as such, e.g. > TYPE99 \# 12 0B 763D73706631 20 2D613131 OK, now I'm completely confused. What does lack of SPF record support in your server input format have to to with syntax checking of the *content* of the SPF record? I can write the record as text or in hex or base64 or whatever format I want; the issue is looking *inside* the data and either (a) just checking it's syntax versus (b) checking it and turning it into some kind of tokenized stuff the DNS server actually serves out. > > Again, an *optional* plugin to check syntax of a record but not > > produce any sort of tokenized result is fine, > Now the plugin can check the syntax and spot the error. I may correct > it or not. If I don't, I'll just serve bad data. In any case, my > zone source still contains the line above. Thus the plugin is optional. > > a plugin that's *mandatory* to deploy is going to be almost as much > > of an impediment to deployment as requiring an upgrade. Code is > > code, and people don't install new code willy-nilly. Any plugin that's necessary to transform a nontrivial input format into a tokenized result is effectively mandatory. Sure, you can substitute a preprocessing script that does the transform and spits out hex or whatever, but no matter how you do it there's an essential translation component involved in provisioning those records. You may be able to avoid having that component cause the entire server fail, but it's still in the critical path for setting up those records. > Possibly, I can also run, say: > echo 'SPF "v=spf1 -a11"' | plugin --dump-hex --silent > and have it dump the TYPE99 line above (without signalling the error, > since I said --silent). Then I copy its output and paste it into the > zone source. Let's please stop talking about what you can do manually. This isn't about people whose main provisioning tool is emacs or bind, and who operate their own servers with full autonomy and report to nobody. This audience doesn't have issues with any of this stuff. > Finally, I can enable automatic invocation of the plugin. That way, I > can write the SPF record directly in the zone source and have my > DNS-fictional server do the copy and paste on the fly for me. > I wouldn't call such thing "mandatory". Again, it depends on whether or not it's in the critical provisioning path. A syntax checker isn't, a parser and tokenizer is. Ned _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf