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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]