[rbldnsd] [RFD] [long[ish]] to be or not to be...

[Amos Jeffries]

Michael Tokarev wrote:
> This is a somewhat long request for comments/discussion.
> 
<snip details>
> 
> Ok.  So here are the questions, finally... ;)
> 
>   o to start with, if this whole stuff will be implemented,
>     next version will be rather incompatible, and it'll be
>     the first really incompatible version.  I don't like
>     this at all, but from another point of view this way
>     eliminates quite some ugliness and makes things more
>     strightforward and clean.
> 
>   o while at it, maybe remove glue records and combined
>     dataset entirely? :)
> 
>   o there are other ways exists to implement SOME of the
>     features.  For example, to make the chains to be a
>     property of certain dataset types, not zone property -
>     i.e., "acl" dataset will allow to "connect" some other
>     dataset to it, but not any dataset type will allow this.
>     That way, not every dataset will be "combinable",
>     ugliness will increase (in both code and documentation
>     and understanding of things) and flexibility will
>     decrease.
> 
>   o when we collecting information about a particular zone
>     (after a (re)load), we cache A records for our NS (glue
>     records, that is).  For this, we run our NS records over
>     all our datasets as if it were some client asking for
>     A ns.bl.ex.com..   But now, if an ACL is on the way,
>     what we should do?  (Currently an ACL is ignored here;
>     the difference from regular query is that there's no
>     client per se).
> 
>   o what are our choices for situations like outlined,
>     e.g. when client asks for A records and ACL is present.
> 
> Or.. something like that...
> 
> Comments, anyone?

I agree with you that the possibilities sounds great.
You are the one coding though Michael, so in the end it is up to you 
whether you are willing to put up with the code mess any longer.

If you do go ahead with this I think its the kind of change which calls 
for a major version update. A 2.x type of thing, where so far its all 
been 0.9* and 1.0 stuff.

Documented well it would be no problem for new installs. Older small 
setups like ours here can cope. If we have enough warning that the 
change is coming we can plan for upgrades. Even the large systems should 
be able to cope given a build-up.

Someone may correct me, but what I have seen of the dsbl.org setup, 
Largest I know of. Is done in a way that can cope with this type of 
change without major hiccups.

> 
> Thank you for your attention.  And please excuse me for
> this long email.  I'm quite stuck now, because I don't
> know where to go from here.  One half of me tells me
> "lets broke it all for a better world", while another
> half says "hey, think about poor users who will have
> even no way to keep their config compatible!".  Oh well...

Well, we go through major and minor config changes regularly for other 
software. Often with less warning and worse side-effects.

AYJ