On Tue, 05 Oct 2004 22:28:18 -0700
Frank Cusack <fcusack@fcusack.com> wrote:

> One no one has yet mentioned is that it doesn't
> honor TTL. This was a "dumb" implementation choice (and dumb of Linux
> to copy) although I understand the value of simple.

Too simple is dumb. Fortunately, it's easily solved by
switching host caching off in nscd.conf and installing dnscache.

--
Stefaan
--
"What is stated clearly conceives easily." -- Inspired sales droid

Roy Nielsen wrote:

> In my group we've tried to tighten up security on our Solaris systems...
>
> I was wondering if anyone had any trouble commenting everything (almost)
> out of /etc/inetd.conf...
>
> Could this cause instablility in the system?
>
> the only things uncommented on our systems are:
>
> # smserverd to support removable media devices
> 100155/1 tli rpc/ticotsord wait root
> /usr/lib/smedia/rpc.smserverd
>
> # printer daemon...
> printer stream tcp nowait root /usr/lib/print/in.lpd
> in.lpd
>
> # RWALLD - rwall daemon (allows others to post messages to users)
> walld/1 tli rpc/datagram_v wait root
> /usr/lib/netsvc/rwall/rpc.rwalld rpc.rwalld
>
>
> Thanks,
> -Roy

If you go with the idea that it is easier to "give than take away"
comment everything out use ssh to get to the system and then add in
(uncomment) only what you really need. For instance the following is
the only thing in one of our more secure servers. A back up daemon
(which is not very secure but necessary) (upasd - a home grown password
password sync daemon. That is it.

bpcd stream tcp nowait root /usr/openv/netbackup/bin/bpcd bpcd
vopied stream tcp nowait root /usr/openv/bin/vopied vopied
bpjava-msvc stream tcp nowait root
/usr/openv/netbackup/bin/bpjava-msvc bpjava-msvc -transient
100153/1 dgram rpc/udp wait root /opt/SUNWvts/bin/sunvts
/opt/SUNWvts/bin/sunvts -g
upasd stream tcp nowait root /usr/sbin/upasd upasd

Frank Cusack wrote:

> Agreed on both points, however nscd introduces its own problems w.r.t.
> host resolution. One no one has yet mentioned is that it doesn't
> honor TTL. This was a "dumb" implementation choice (and dumb of Linux
> to copy) although I understand the value of simple. This is such an
> issue at every place I've ever been that nscd for hostname caching is
> always a no-no. If we need hostnames to be cached we run a local
> caching nameserver.

man nscd.conf:

positive-time-to-live cachename value
negative-time-to-live cachename value

ok, this is not related to DNS TTL, but it's still there, you can set
short ttl for hosts/ipnodes and still rely on your named for dns TTL
handling. reading manual is sometimes useful...

toomas
--
Tomorrow will be cancelled due to lack of interest.

On Wed, 06 Oct 2004 17:16:20 +0300 Toomas Soome <Toomas.Soome@microlink.ee> wrote:
> Frank Cusack wrote:
>
>> Agreed on both points, however nscd introduces its own problems w.r.t.
>> host resolution. One no one has yet mentioned is that it doesn't
>> honor TTL. This was a "dumb" implementation choice (and dumb of Linux
>> to copy) although I understand the value of simple. This is such an
>> issue at every place I've ever been that nscd for hostname caching is
>> always a no-no. If we need hostnames to be cached we run a local
>> caching nameserver.
>
> man nscd.conf:
>
> positive-time-to-live cachename value
> negative-time-to-live cachename value
>
> ok, this is not related to DNS TTL, but it's still there, you can set
> short ttl for hosts/ipnodes and still rely on your named for dns TTL
> handling. reading manual is sometimes useful...

I'm sure that wasn't a snide comment directed at me, but anyway I
probably know more about nscd than most, as I've heavily altered the
internals of the Linux implementation. I'm intimately familiar with
these settings.

Obviously, I wasn't talking about this TTL setting. You have to set it
to either 1 minute or 5 minutes to be effective (depending on your fastest
DNS TTL) and at that setting caching isn't all that useful.

Even if you disagree (and certainly you might), my statement is
(luckily, heh) still correct. Setting a lower fixed TTL does not
honor the DNS TTL.

/fc

Frank Cusack wrote:
[ programs not noticing changes to /etc/resolv.conf ]
> Although a smarter resolver library would fix that.

http://cr.yp.to/djbdns/blurb/library.html

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Frank Cusack wrote:

> Obviously, I wasn't talking about this TTL setting. You have to set it
> to either 1 minute or 5 minutes to be effective (depending on your fastest
> DNS TTL) and at that setting caching isn't all that useful.
>
> Even if you disagree (and certainly you might), my statement is
> (luckily, heh) still correct. Setting a lower fixed TTL does not
> honor the DNS TTL.
>

yes, but it is normally quite safe to have low ttl for host/ipnode
entries in nscd - like few minutes or whatever seems to be reasonable
for you. DNS ttl values are quite high normally (few hours at least,
maybe lower for DDNS/dhcp clients), so having nscd ttl < dns ttl you
will not hurt yourself with obsolete entries and can still take
advantage of nscd cache -- and save some calls to named - if you can use
very fast IPC to nscd and not so fast IPC to named, then this kind of
two level cache is reasonable.

also, if ttl for dns RR is very small, then probably entry for it in
nscd cache will be expired before its needed in second time (if nscd ttl
is reasonably low) - this kind of situation is with personal
workstations/pc's and you probably will not need to resolve their names
too often

of course, it would be quite easy to make nscd ttl handling more
smarter, to update ttl values regarding to dns RR ttl, but this would
make nscd more complicated and IMO would only make sense to make nscd
ttl value for entry lower (to avoid consuming all memory to cache hosts
for very long time...

toomas
--
If God lived on Earth, people would knock out all His windows.
-- Yiddish saying

On Thu, 07 Oct 2004 11:14:55 +0300 Toomas Soome <Toomas.Soome@microlink.ee> wrote:
> yes, but it is normally quite safe to have low ttl for host/ipnode
> entries in nscd - like few minutes or whatever seems to be reasonable
> for you. DNS ttl values are quite high normally (few hours at least,
> maybe lower for DDNS/dhcp clients), so having nscd ttl < dns ttl you
> will not hurt yourself with obsolete entries and can still take
> advantage of nscd cache -- and save some calls to named - if you can
> use very fast IPC to nscd and not so fast IPC to named, then this kind
> of two level cache is reasonable.

agreed