ietf
[Top] [All Lists]

Re: provisioning software, was DNS RRTYPEs, the difficulty with

2012-03-07 15:47:42
On 07/Mar/12 09:42, ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>