Suresh,

   I've looked at a few alternatives because of v6 but 
   it looks like that's still 10 years away from mattering.  

   What real-world website that you actually care about 
   will have an IPv4 only address?   That's the sad truth 
   about ipv6 -- it's a parallel stack instead of an embedded 
   address space, so the uptake has been negligible, even 
   with the spectre of address exhaustion.

   My guess is that when the time comes, consumers will get 
   IPv6 addresses from their ISPs, and "destinations" on 
   the web will continue to use IPv4 more or less forever.
   If that's true, then IPv6 DNS will probably never matter
   in terms of web browsing. 
   
   In any event, that's my reason for sticking with dnscache.
   It works, and the only reason I have for moving off of
   it is maybe needing to apply a patch 10 years from now.

   It did require a bit of fiddling at first though, 
   that's for sure.  The setup I finally settled with 
   was an /etc/inittab entry like this:

  #--------------------------------------------------------------
  # Wanted to start all the DJB services (e.g.: djbdns)
  # using multilog rather than readproctitle
  # See: http://thedjbway.org/svscanboot.html
  #
  # Therefore, svscanboot is now defunct:
  # SV:123456:respawn:/usr/bin/svscanboot
  #
  # Now using svscan-start instead, which just uses
  # multilogger (rather than readproctitle).
  #
  # To see svscan service log:
  #  % cat /var/log/multilog/svscan-service/current | tai64nlocal
  #
  #
  # NOTE: Unlike the typical svscan setup, I made /service
  #       empty on startup, and then allows svscan to start things
  #       up by making /etc/init.d scripts that crete the appropriate
  #       symlink (e.g.:   /service/dnscache -> /etc/dnscache )
  #       at the rignt runlevel.   This allows daemontools to
  #       mesh more cleanly with "the djb way";  it allows me to
  #       have a conventional start/stop script yet provides
  #       the monitoring via svscan.  Another nice feature is that
  #       it lets me start stuff like tinydns right after the
  #       network devices are up.   This was harder to do in the
  #       conventional djb setup, and avoids having to hard-code
  #       IP addresses in other init.d scripts.   For example of
  #       how the generic start/stop scripts work with svscan, see:
  #       /etc/init.d/tinydns
  #
  #--------------------------------------------------------------
  SV:123456:respawn:/usr/local/bin/svscan-start
  #--------------------------------------------------------------


  I also wrote a start/stop script for a DJB "daemontools" style daemon.

  When the machine boots up, /service is emptied, and svscan is run.
  Then whenever you want, a generic daemontools start/stop script 
  The daemon this script runs is determined by its filename. 

  For example, if this file is  /etc/init.d/tinydns
  then /etc/tinydns is linked to /service/tinydns,
  which causes svscan to run tinydns. 

  This arrangement allows daemontools to live in harmony with
  the more standard /etc/init.d way of doing things.   As a benefit,
  you also get to start/stop daemons by hand w/o needing to remember
  the syntax for the 'svc' program.

   

                -Jon




* Suresh Ramasubramanian ([email protected]) [120328 18:49]:
> Jon Cox [28/03/12 18:34 -0700]:
>>   By default dnscache gives you a 1M cache, which is
>>   configurable via /service/dnscache/env/CACHESIZE
>>   and even gives you tools to see how effective it is
>>   (see: http://cr.yp.to/djbdns/cachesize.html ).
>
> It is very nice, useful - except that djb has weird and wonderful ideas
> about dns, it needs a lot of patching (and idiosyncratically written
> patches at that) for v6 etc etc.
>
> You might try this -
>
> Package: pdns-recursor
> Priority: extra
> Section: net
> Installed-Size: 1344
> Maintainer: Matthijs Mohlmann <[email protected]>
> Architecture: i386
> Version: 3.2-4
> Replaces: pdns
> Depends: libc6 (>= 2.3.6-6~), libgcc1 (>= 1:4.1.1), liblua5.1-0, libstdc++6 
> (>= 4.4.0), lsb-base (>= 3.0-6), adduser
> Recommends: pdns-doc
> Filename: pool/main/p/pdns-recursor/pdns-recursor_3.2-4_i386.deb
> Size: 548202
> MD5sum: 076639760dd9753a711774f30cdc8fdc
> SHA1: 3ab18085e7d3b6130996276226306ab47ab569c5
> SHA256: 9e0121bbbf513b457457d7c58220841694cf0f8e5d2ab0040df1cd453a215108
> Description: PowerDNS recursor
>  PowerDNS is a versatile nameserver which supports a large number
>  of different backends ranging from simple zonefiles to relational
>  databases and load balancing/failover algorithms.
>  PowerDNS tries to emphasize speed and security.
>  .
>  This is the recursive nameserver that goes out to the internet and
>  resolve queries about other domains.
> Tag: interface::daemon, network::server, network::service, protocol::dns, 
> role::program
>
>

Reply via email to