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

> 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.

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.

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".

>> Correct, but when you publish a complex record you are calling forth
>> that complexity.  I don't see much difference if the bug is at mines
>> or at the remote site, since their effects are comparable.
> 
> They most certainly are not. A bug in my client only affects me, a bug
> in the server can easily kill the entire zone.

Ooops, yes, that's right.
_______________________________________________
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]