[prev in list] [next in list] [prev in thread] [next in thread] 

List:       djbdns
Subject:    Re: Full featured djbdns jumbo patch
From:       Claudiu Costin <claudiuc () work ! ro>
Date:       2001-10-11 11:37:51
[Download RAW message or body]

                   Dear Dan,

  First of all, none of this patches are mine. It just happen to put them 
together. If someone, make one of this patches, then he need it. The only 
missing is IPV6. But I can't test it because I don't have to much knowledge.
Someone will send me a PATCH14 if have enough time or other people.
   These improvements are _cookies_: if you like you can eat, if don't, then
don't.

On Thursday 11 October 2001 11:38, you wrote:
> >     - add support modify SOA email contact address from tinydns-data
>
> Putting global macro features into the data format, rather than into
> higher-level tools, is a horrible idea: it makes the higher-level tools
> substantially more difficult to write.
   Well, for a little unexperienced guy with little domains then this can help.   
I don't know if I'll this feature, but someone can feel else.

>
> >     - add support to tinydns-data to load multiple data files
> >     specified on command line
>
> Merging multiple AXFR results properly is more complicated than this. It
> should be handled by a separate tool. Note that sites with many zones
> can't even fit the list into the command line.
       Who can say this? This is handy for some handy made scripts and for 
people with small number of sites. djbdns is not only used in entreprise, 
but even at home.

>
> >     - add support to dnsfilter replace IP-s with names
>
> Typical uses of dnsfilter need preprocessing and postprocessing anyway,
> so there's no point to this wart. Read Gancarz's book.
   Well, for me is handy, instead to run sed in pipe with it. It's just 
another option.

>
> >     - add support to dnscache to responde queries from everywhere
> >     clients when OKCLIENT envar is set.
>
> Why? This configuration is (1) extremely rare and (2) already doable in
> a few seconds with a three-line script.
   Yes, but I like to read three line of text explaining how to do OKCLIENT
instead to write 3 line scripts. Many people don't know very good to make
own tools, but want to use djbdns. I have so many friends and coleages in
this situation...

>
> This is what Brooks was talking about when he said ``The besetting
> temptation for the architect of a general purpose tool such as a
> spreadsheet or a word processor is to overload the product with features
> of marginal utility ... The loss of ease of use sneaks up insidiously.''
    This is not wordprocessor. I don't wanna to program my StarOffice papers in 
StarBasic, but I'm happy to press a button.

>
> >     - add support to dnscache to listen on multiple IP's
> >     listed on IP envar and seperated by slashes.
>
> Why? Accessing the same cache through a second address is (1) extremely
> rare and (2) already doable with a second cache forwarding to the first.
    This argue is realy bad. I don't like to have another dnscache process
to monitor or to send signals.

>
> >     - add support to tinydns to listen on multiple IP's
> >     listed on IP envar and seperated by slashes.
>
> Same issue.
  Same issue.

>
> >     - add support to dnscache reload servers files
> >     when it receive SIGHUP signal
>
> You can achieve the same effect with forwarding. However, ISPs that want
> top performance should use a local root server instead.
   You probably don't have a dialup line. Try it before.

>
> >     - add support to dnscache to dump cache from memory and load it
> >       from file when it start, or when it receive SIGALRM signal
>
> Any ISP that cares this much about performance will make sure that its
> caches stay up.
     Well, ISP's can use vanilla djbdns. At home I'll use every time.
When my conection die I don't wanna loose my cached records (using restarting
dnscache to listen for my internal tinydns or external cache when on-line).
So, this option is a must in internal DNS caches when I reboot my machine.
An tens of users start DNS request after geting up again.

>
> >     - add support for SRV record for tinydns-data and axfr-get
>
> I don't understand. Are you actually typing SRV records? Why?
   Well, some one do it if this patch exists. It don't hurt.

>
> >     - add support to tinydns to react on notify queries and
> >     log 'N'.
>
> I don't understand. Why not simply try an AXFR once a minute?
   Ha, ha, ha. It's funny. Just be secondary for 100 zones and do this.

>
> >     - add support to dnscache to return a special IP address
> >     for NXDOMAIN type A responses when NXDSPECIAL envar is set.
>
> I don't understand. What's wrong with wildcards?
   Nothing, are very good. But I don't want to fill all the Internet
with wildcards. ***This is in dnscache, but not in tinydns***
Here is the point. When my users contact an inexistent  host, I'll
redirect to a web page or else etc etc. Your imagination is the sky.

>
> >     - add support to tinydns to log 'X' instead of '+'
> >     when it return NXDOMAIN in answers.
>
> I don't understand. What's wrong with tinydns-get?
   It's not online. Some user can make your tinydns to return NXD.
Maybe you miss when use tinydns-get.

>
> >     - add support to server round-robined records when are
> >     many A records in answer.
>
> The order of A records is the client's responsibility.
   Well, maybe are somewhere broken resolvers. It don't hurt, it don't
break performance at all, and it can be activated _only_ when you want.

>
> ---Dan
   
   I wonder if some patch missed your shotgun fire :) First of all these are 
not mine, but of your happy djbdns users which still want to shape it where
their need make them do this.


P.S. Thank you for your beautifull qmail & djbdns

kind regards,
-- 
Claudiu Costin
<claudiuc@work.ro>

[prev in list] [next in list] [prev in thread] [next in thread]