Handy script for generating /etc/resolv.conf - SpamAssassin

This is a discussion on Handy script for generating /etc/resolv.conf - SpamAssassin ; > > Well, the code works for me. If someone has a better solution I'll > switch to yours. I just created it because I needed it and thought I'd > share it with others who might need it. But ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 26 of 26

Thread: Handy script for generating /etc/resolv.conf

  1. RE: Handy script for generating /etc/resolv.conf


    >
    > Well, the code works for me. If someone has a better solution I'll
    > switch to yours. I just created it because I needed it and thought I'd
    > share it with others who might need it. But if any of you want to
    > improve it or replace it with something better I'm always looking for
    > new tricks.


    Marc and list...

    Im confused...

    Why are you losing DNS in the first place where you would even have to worry
    about this?

    - rh


  2. Re: Handy script for generating /etc/resolv.conf

    On Sun, Aug 31, 2008 at 10:59 PM, RobertH wrote:
    >
    >>
    >> Well, the code works for me. If someone has a better solution I'll
    >> switch to yours. I just created it because I needed it and thought I'd
    >> share it with others who might need it. But if any of you want to
    >> improve it or replace it with something better I'm always looking for
    >> new tricks.

    >
    > Marc and list...
    >
    > Im confused...
    >
    > Why are you losing DNS in the first place where you would even have to worry
    > about this?
    >


    It was explained somewhere earlier in the thread that he sometimes has
    to reboot his central dns servers and he apparently doesn't run local
    caching servers on the individual MX/SA nodes.

    I have to say (as others have mentioned in this thread and elsewhere)
    that running a local caching nameserver on any busy MX or SA server
    seems to solve this issue quite well without needing any scripts. If
    you are rsyncing any zones from zen, etc. having the zone served up
    locally is awesome for quick lookups too.

    -Aaron


  3. Re: Handy script for generating /etc/resolv.conf



    Aaron Wolfe wrote:
    > On Sun, Aug 31, 2008 at 10:59 PM, RobertH wrote:
    >


    >> It was explained somewhere earlier in the thread that he sometimes has
    >> to reboot his central dns servers and he apparently doesn't run local
    >> caching servers on the individual MX/SA nodes.
    >>
    >> I have to say (as others have mentioned in this thread and elsewhere)
    >> that running a local caching nameserver on any busy MX or SA server
    >> seems to solve this issue quite well without needing any scripts. If
    >> you are rsyncing any zones from zen, etc. having the zone served up
    >> locally is awesome for quick lookups too.
    >>
    >> -Aaron
    >>
    >>

    Maybe my situation is unique. I'm running about 35 virtual servers and
    rather than run named in each one I have 3 virtual servers dedicated to
    doing caching DNS. One main one with 4 gigs allocated so that it caches
    for all of them and 2 backups in case something happens to the main one.


  4. Re: Handy script for generating /etc/resolv.conf

    On Mon, Sep 1, 2008 at 3:43 AM, Marc Perkel wrote:
    >
    >
    > Aaron Wolfe wrote:
    >>
    >> On Sun, Aug 31, 2008 at 10:59 PM, RobertH wrote:
    >>

    >
    >>> It was explained somewhere earlier in the thread that he sometimes has
    >>> to reboot his central dns servers and he apparently doesn't run local
    >>> caching servers on the individual MX/SA nodes.
    >>>
    >>> I have to say (as others have mentioned in this thread and elsewhere)
    >>> that running a local caching nameserver on any busy MX or SA server
    >>> seems to solve this issue quite well without needing any scripts. If
    >>> you are rsyncing any zones from zen, etc. having the zone served up
    >>> locally is awesome for quick lookups too.
    >>>
    >>> -Aaron
    >>>
    >>>

    >
    > Maybe my situation is unique. I'm running about 35 virtual servers and
    > rather than run named in each one I have 3 virtual servers dedicated to
    > doing caching DNS. One main one with 4 gigs allocated so that it caches for
    > all of them and 2 backups in case something happens to the main one.
    >
    >
    >


    I think it's just a memory use vs. performance thing.. running a
    nameserver in each instance might give you better performance and
    stability, but of course it will use more ram. Really though I don't
    think named in a caching configuration is too bad of a pig on ram, and
    there are high performance/low ram alternatives that just do caching.
    I have a caching name server running on my home router (a linksys
    thing that runs linux) and it has only 16MB ram total for the whole
    system. The nameserver used there is called dnsmasq and it appears to
    use about 51`2k of ram in caching only mode. Might be something to
    consider since even with your script running every minute, you still
    have (up to 60 sec)+(the time the script takes to run)+(the time it
    takes everything to use the new resolv.conf) seconds of downtime that
    could be avoided.


  5. Re: Handy script for generating /etc/resolv.conf

    > Really though I don't
    > think named in a caching configuration is too bad of a pig on ram, and
    > there are high performance/low ram alternatives that just do caching.


    I'm using pdnsd here, wich also has the capability to
    periodically check the DNS servers it forwards to and mark them
    as up/down depending on the result (so if a server is marked as
    down due to a query timeout, after a configuarble interval it's
    recheked and marked up if it responds).

    In many cases I think this might be a better solution (than
    dynamically updating resolv.conf) to the problem of multiple
    occasionally unreliable name servers.

    My guess is that there are leaner DNS proxies using less
    resources than pdnsd, with less flexibility, as well that can do
    this. (Maybe dnsmasq can, I don't know...)

    Regards
    /Jonas

    --
    Jonas Eckerman, FSDB & Fruktträdet
    http://whatever.frukt.org/
    http://www.fsdb.org/
    http://www.frukt.org/


  6. [OT] Handy script for generating /etc/resolv.conf

    Giampaolo Tomassoni wrote:
    >> -----Original Message-----
    >> From: mouss [mailto:mouss@netoyen.net]
    >> Sent: Sunday, August 31, 2008 7:23 PM
    >> Cc: users@spamassassin.apache.org
    >> Subject: Re: Handy script for generating /etc/resolv.conf
    >>
    >> Giampaolo Tomassoni wrote:
    >>>> -----Original Message-----
    >>>> From: Nix [mailto:nix@esperi.org.uk]
    >>>> Sent: Sunday, August 31, 2008 5:12 PM
    >>>> To: Marc Perkel
    >>>> Cc: users@spamassassin.apache.org
    >>>> Subject: Re: Handy script for generating /etc/resolv.conf
    >>>>
    >>>> On 28 Aug 2008, Marc Perkel told this:
    >>>>
    >>>>> Here's something I threw together to make sure the /etc/resolv.conf
    >>>>> points to a working nameserver. I run this once a minute.
    >>>> How do you arrange that all the existing programs that have already
    >>>> sucked in resolv.conf note the change? They're generally not going

    >> to
    >>>> unless you restart them: nothing polls resolv.conf looking for

    >> changes
    >>>> to it as far as I know, that would be far too inefficient.
    >>> Depending on the specific implementation of the resolver library, the
    >>> application may check for changes in the resolv.conf file. Maybe they

    >> don't
    >>> check at every and each resolv request, however: they may instead

    >> check for
    >>> changes every, say, 10 secs or maybe every 1.000 requests. This way,

    >> looking
    >>> for changes in the /etc/resolv.conf file is not that much

    >> inefficient...
    >> as you say, this is generally inefficient.

    >
    > No, I'm saying the exact opposite: I'm saying that the brute implementation
    > may be inefficient. I'm also saying that, due to this, many implementations
    > don't adopt a brute approach to the problem.


    the implementation you showed is inefficient. stat-ing the filesystem
    every now and then is silly.

    >
    > Finally, restarting a whole set of apps just because the /etc/resolv.conf
    > file changed actually *IS* inefficient.


    if the apps are only started when a change is detected and if change
    detection is correctly done, then this is better than polling. except if
    you have an unstable setup that changes every time, but then your
    problem is serious: ask a doctor ;-p

    >
    >
    >> most resolver
    >> implementations
    >> don't do that.

    >
    > No, come on: most do.


    I defy you to list systems where you _know_ this is as you say.


    > At least by when Internet started to be a mass-market:
    > most connections where dialup ones with dynamic IPs, and NAT routers were
    > expensive. You didn't have to restart all your running apps once connected
    > just because the /etc/resolv.conf was modified by pppd implementation...
    >


    what are you talking about? a system you developped? which systems have
    an /etc/resolv.conf that changes all of a sudden? and since when unix
    systems support dynamic setups? (as of today, the unix implementation
    generally relies on the horrible isc dhclient).

    >
    >> and even then, not all applications will obey that (the
    >> mozilla family is known to play bad games here).

    >
    > I don't know about mozilla, but please note that special apps may borrow
    > their own special implementation of the resolv library. While perhaps
    > Mozilla is one of them, I don't believe its own resolv library doesn't pay
    > care to changes in the /etc/resolv.conf content.


    /etc/resolv.conf was designed to be a "stable" file. in an environment
    where it changes now and then, it is simply not appropriate. many
    chrooted apps need a copy in their cage, in which case patching the
    resolver to check for resolv.conf changes doesn't help (besides being a
    horrible kiddy hack).

    >
    > Is mozilla involved in this, anyway?



    It was an example of a "long running" application. people who run to
    patch glibc should think about such apps or document their lib to
    explictely state that their API is not compatible with well known practice.

    >
    >
    >> It is better to run a dns server on the machine and do all your stuff
    >> there. you can restart it, reload the zone, ... without caring for
    >> resolver or application specific behaviour. This also "conforms" to
    >> modularity as was seen in plan9: let servers do the job.

    >
    > Right, I agree with you in this. This is a much more flexible and polite
    > solution, but it is not easy to implement by everybody: you need to know
    > what is a "zone" and a "reverse zone", how to configure it, some basic
    > knowledge of DNS server setup and, finally, even what is a DNS server...


    come on. most unix admins are capable of installing and running a basic
    dns server. filtering mail is far more difficult. the "it's difficult"
    argument is often used when it should not. I've seen "basic" $lusers do
    things that many vendors claim are too hard (but the claim is only a
    marketing defense to justify their bad choices). More generally, any
    usability argument should be justified with rigourous arguments and a
    clear evidence.


    that said, there is a better argument for your "goal". running bind adds
    a security risk. but even this argument doesn't stand. it is possible to
    minimize bind risks. and whatever you do, you rely on dsn (which is not
    very secure. nor is the internet).

    >
    > Please note a lot of Linux distributions do provide some mean to dynamically
    > update the /etc/resolv.conf file. They don't impose the use of a local DNS
    > server. And the reason to me is to avoid burdening the user with (unneeded)
    > complexity.
    >


    no. the reason to me is that
    - support for "dynamic networking" is not yet stable under unix systems
    (people are still playing with NetworkManager, avahi, dhclient, ... etc),
    - there is no "definitive" replacement for BIND
    - resolution is still primitive (/etc/hosts, resolv.conf, dns, dhclient,
    .... etc).


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2