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

List:       djbdns
Subject:    Re: Full featured djbdns jumbo patch
From:       prj () po ! cwru ! edu (Paul Jarc)
Date:       2001-10-11 15:30:02
[Download RAW message or body]

Claudiu Costin <claudiuc@work.ro> wrote:
> If someone, make one of this patches, then he need it.

That doesn't follow.  Patches are often made when the existing tools
can already do the same job, or when whole new tools could do it.

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

Yes, but a preprocessor could do the same job without threatening to
break your tinydns-data program.

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

See above.  Keeping each tool small and simple makes them all easier
to maintain.

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

Apples and oranges.  How would you like to read three lines of text
explaining how to use someone else's script?

> Many people don't know very good to make own tools, but want to use
> djbdns.

If they're not competent enough to make their own tools, they
definitely shouldn't be messing with others' code.

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

If you think that makes a difference, then you missed the point.  The
principle applies generally.

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

If you'd prefer a unified interface, one could be provided without
altering any of the existing programs.

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

Bandwidth is not relevant to this issue.  Having a forwarder or a
local root server works just as well no matter how much or how little
bandwidth you have.  Actually, if you have little bandwidth, a local
root server is an even bigger win.

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

You can add a forwarder to avoid losing your cache.  I agree that this
particular patch could be useful, though, and it makes the SIGHUP
patch unnecessary.

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

See above about preprocessors.

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

A better solution to this is to use a log watcher.  No polling (over
the network) and no patching.

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

No, when your users' *web browsers* look up a non-existent name,
you'll redirect them.  When your users' other programs look up a
non-existent name, you'll wreak unknown havoc on them.

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

If you can miss the "nxdomain" in tinydns-get's output, you can miss
the "X" in the log just as easily.


paul

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