Bug#1778: Zombies from Cern-Httpd (solved)
eckes <[EMAIL PROTECTED]> writes: > Package: cern-httpd > Version: 3.0-4 > > There is an error in the Signal handling of the cern-httpd, which makes > zombies hang around, especially on heavy loaded WWW Server. The following > Patch may solve this: > > --- WWW/All/linux/Makefile.include.org Sun Oct 29 07:15:44 1995 > +++ WWW/All/linux/Makefile.include Sun Oct 29 07:16:32 1995 > @@ -9,7 +9,7 @@ > > # -DLINUX_FSSTND makes the default log file /var/run/httpd-pid > #rather than /tmp/httpd-pid > -CFLAGS = -O2 -DPOSIXWAIT -DLINUX_FSSTND > +CFLAGS = -DUTS2 -fomit-frame-pointer -O2 -DPOSIXWAIT -DLINUX_FSSTND > LFLAGS = -s > CC = gcc That should be "/var/run/httpd.pid" according to FSSTND 1.2. Dan
forwarded message from CERT Bulletin
Here's another CERT advisory. I'm not sure what to do about this, apart from grepping the logs for access control failures and using a crowbar to investigate anyone I catch attacking my server. The XFree86 people have clearly decided that Linux isn't worth their while and so they haven't bothered to build a fixed version for us. (Oh, and when it says "systems with poor pseudo-random number generators", it means "all systems". Using the C library rand() function to generate random numbers is simply not good enough for security purposes. I ran the "rand-test" program they refer to, and it claims that we only have 9 bits of randomness available, which is truly dire even by the standards of rand() &c.) Ian. --- start of forwarded message (RFC 934 encapsulation) --- Article: 81 of comp.security.announce Newsgroups: comp.security.announce Path: lyra.csx.cam.ac.uk!sunsite.doc.ic.ac.uk!agate!howland.reston.ans.net!tank.news.pipex.net!pipex!newsfeed.internetmci.com!chi-news.cic.net!uwm.edu!math.ohio-state.edu!cis.ohio-state.edu!nntp.sei.cmu.edu!news.sei.cmu.edu!cert-advisory Message-ID: <[EMAIL PROTECTED]> Originator: [EMAIL PROTECTED] Keywords: security CERT Reply-To: [EMAIL PROTECTED] Organization: CERT(sm) Coordination Center - +1 412-268-7090 Approved: cert-advisory@cert.org Lines: 245 From: CERT Bulletin Sender: [EMAIL PROTECTED] (Netnews) Subject: CERT Vendor-Initiated Bulletin VB-95:08 - X Authentication Vul Date: Thu, 2 Nov 1995 18:55:14 EST CERT Vendor-Initiated Bulletin VB-95:08 November 2, 1995 Topic: X Authentication Vulnerability Source: X Consortium To aid in the wide distribution of essential security information, the CERT Coordination Center is forwarding the following information from the X Consortium. The X Consortium urges you to act on this information as soon as possible. X Consortium contact information is included in the forwarded text below; please contact them if you have any questions or need further information. FORWARDED TEXT STARTS HERE Two widely used X Window System authorization schemes have weaknesses in the sample implementation. These weaknesses could allow unauthorized remote users to connect to X displays and are present in X11 Release 6 and earlier releases of the X11 sample implementation. There are reports that systems have been broken into using at least one of these weaknesses and that there are now exploit programs available in the intruder community. MIT-MAGIC-COOKIE-1 Description: On systems on which xdm is built without the HasXdmAuth config option, the MIT-MAGIC-COOKIE-1 key generated by xdm may be guessable. If you use MIT-MAGIC-COOKIE-1 to authenticate X connections, and your keys are generated by xdm, and xdm does not also support XDM-AUTHORIZATION-1 authentication (that is, your X tree was not built with the HasXdmAuth config option), you may be at risk. On systems with poor pseudo-random number generators, the key may be guessable by remote users. On other systems, users with access to the file system where xdm stores its keys for use by local servers may be able to use information in the file system to guess the key. If your xdm program was built with HasXdmAuth set to YES (the compiler command line includes the -DHASXDMAUTH flag), MIT-MAGIC-COOKIE-1 keys generated by xdm are not vulnerable; the DES code is used to generate cryptographically secure keys. Impact Remote users anywhere on the Internet may be able to connect to your X display server. It is NOT necessary that they be able to snoop your key first. XDM-AUTHORIZATION-1 Description: The X server does not correctly check the XDM-AUTHORIZATION-1 data and can be fooled into accepting invalid data. A user who can snoop the encrypted authorization data of a valid connection can create fake auth data that the X server will accept. If you do not use XDM-AUTHORIZATION-1, you are not vulnerable. Determining whether your server is vulnerable: this problem is fixed in X servers from the X Consortium with a vendor release number of 6001 or higher. Impact Remote users may be able to connect to your X display server. SOLUTIONS A. Install a vendor supplied patch if available. B. If your site is using X11 built from X Consortium X11R6 sources, install public patch #13. This patch is available via anonymous FTP from ftp.x.org as the file /pub/R6/fixes/fix-13. It is also available from the many sites that mirror ftp.x.org. Apply all patches not already applied, up to and including fix-13. The file xc/bug-report shows what public patches have been already applied to your source tree. The MD5 checksum of fix-13 is as follows: MD5 (fix-13) = 0d81d843acf803a8bedf90d3a18b9ed6 C. If your site is using an earlier version of the X Consortium's X11, upgrade to X11R6. Install all patches up to and including fix-13. D. Work arounds. 1. Building with HasXdmAuth will eliminate the first vulnerability. The necessary DE
Bug#1796: missing call to ntohs in X server
Package: xs3 Version: 3.1.2-1 I see: AUDIT: Fri Nov 3 09:21:37 1995: 23964 X: client 15 rejected from IP 127.0.0.1 port 32517 Auth name: MIT-MAGIC-COOKIE-1 But, from netstat we can see that the port wasn't 32517 (0x7f05) but 1407 (0x057f): tcp1 0 localhost:6000 localhost:1407 TIME_WAIT There are probably other places where the server should convert port numbers between host and network byte order. Ian.
Re: Telnetd Environment Vulnerability (fwd)
Matthew Bailey wrote: > FYI > > If this has been covered already ignore me I am behind on mail again.. :) > Matt The bug has been fixed 11 days ago. There was no Changlog entry for this bugfix (only the words "security bugfixes") because the bug should not be made public at this point. Netstd versions 1.21-1 and above are ok (or 1.20 and above if you use ld.so v1.7.x). Peter -- Peter TobiasEMail: Fachhochschule Ostfriesland [EMAIL PROTECTED] Fachbereich Elektrotechnik und Informatik [EMAIL PROTECTED] Constantiaplatz 4, 26723 Emden, Germany
Re: packaging X things
In article <[EMAIL PROTECTED]> "Andrew D. Fernandes" <[EMAIL PROTECTED]> writes: > I am in the process of packaging up x3270 for debian, and while I have built > X-stuff via imake before, I have never had to modify things. > > Until now. > > Is there an easy way of modifying the (i)makefiles to install the software in > a non-root subdirectory, but make sure that these paths don't get compiled > into the program, or am I going to have to bite the bullet and comb the > source by hand and by grep? The Makefiles made by imake use the symbol DESTDIR, which is a prefix to all file names and not defined by default. You can use this similiar to the prefix symbol in autoconf-generated Makefiles: $ make ... $ make DESTDIR=`pwd`/debian-tmp/ install If some paths get compiled into the program, this should happen in the make stage. If the program does this in the make install stage, you still have to change the Makefile (or the Imakefile). (The xonix-1.4 package could be helpful as an example.) Sven -- Sven Rudolph ([EMAIL PROTECTED]); WWW : http://www.sax.de/~sr1/
Bug#1794: bin/sh is shell when none specified in /etc/passwd
Bruce Perens writes: > [EMAIL PROTECTED] said: > > [empty shell fields in /etc/passwd mean /bin/sh] > > This is common practice, and perhaps important if you are using > a Yellow Pages password database that originates on a different > system. I see. I don't really approve, but such things are too late to change at this late stage of Unix's development ... > Use "/dev/null" as the shell if you want to disable the login. Perhaps this should be done for all the non-login accounts in /etc/passwd, by default ? Ian.
Re: FTP Installation & Package Naming Conventions
(Crosspost to debian-user removed.)
Bruce Perens writes ("Re: Autorename packages/add a filename field in
packages-master "):
> [EMAIL PROTECTED] said:
> > add Filename: field in Packages-Master
>
> I think the script that generates the Packages and Packages-Master files has
> all of the information it needs to add a "Filename:" field to the database,
> probably with no more than a one-line modification. The filename should be
> relative to the "binary" directory.
>
> This is necessary to make the FTP method of "dpkg" work. The alternatives are
> all _much_ more ugly. Could you put this feature in?
Thanks everyone for coming up with a good solution. I've now
implemented this, and a test run seemed to do the right thing. It was
about 6 lines' modification, in all, because I'm paranoid :-).
The filename is *not* relative to the `binary' directory, because it
would then be unhelpful in the Packages-Master file. It's relative to
the root of the archive. So, for example, we have
Package: dpkg
Filename: debian-0.93/binary/base/dpkg-1.0.5.deb
This is in both Packages and Packages-Master (Packages-Master is a
simple concatenation of the debian-0.93, contrib and non-free Packages
files).
See below for how I think the `ftp' method should handle things.
> If you wanted to be ultra-generic you could add a "Filename" and a
> "DOS-Filename" field, but this is probably not necessary.
I agree, and in any case this would be a lot more work, because I
don't currently scan the msdos tree.
brian white writes ("Re: FTP Installation & Package Naming Conventions "):
> How about another field in "Packages-Master" called "Filename: ..."?
>
> Of course, the "Packages-Master" file is usually missing descriptions
> of some packages that are available. This would have to be fixed.
> Also, because it is a derived work, it would have to be generated
> after all changes have been made for the day and _before_ the mirror
> sites drop by to gather the newest image. If not, you end up with a
> list that is a day behind and the fetch program could fail due to the
> inconsistancies.
Ah, but there is a solution to this: only use the Packages file as an
optimisation to avoid downloading files you know you don't need.
Conceptually your algorithm should be:
For each .deb file found under the binary directories being searched,
check whether the file is listed in the relevant Packages file.
If so: Download and process it only if the package, version and
status information from dpkg's database and from the FTP site mean
that dpkg would process it if the file corresponded to the entry in
the Packages file.
If not: Download and process it anyway.
I have code in the dpkg source tree that can be used to process fields
in the Packages/control-file format that all these programs use to
talk to each other. If Brian would like to tell me what order he'd
like to feed the data in and how he'd like the results to be
communicated (eg, run dpkg- to cache the Packages data
somewhere and then run dpkg- and test the exit status
to see if a particular filename warrants inclusion, or run
dpkg- to turn a Packages file into a list of filenames to
be skipped, or whatever) I can easily write the programs for this in
C.
I think the FTP installation method should ask you whether you want to
try the `bleeding-edge' tree or the `stable' tree, and should use the
appropriate links on the FTP site together with the `PWD' command to
find out which trees to process.
brian white writes ("Re: FTP Installation & Package Naming Conventions "):
> I'd prefer to standardize the filename, but I don't think people are willing
> to do that.
I think that's a lost cause, I'm afraid.
Kai Henningsen writes ("Re: FTP Installation & Package Naming Conventions"):
> Incidentally, I've been meaning to ask - how do you make a Packages file?
There's a script on the FTP site that does it.
> Wouldn't it be a good idea if one could regenerate one locally?
One can do almost the same thing: you can use dpkg -A on a directory
full of .deb files to update the `available packages' info in
dselect. I don't know if anyone actually uses that option ...
Generating a Packages file is not that easy, because it contains
information not found in the .deb files (such as packages' actual
priorities and sections). However, concatenating the control files of
the .deb files (extract them with dpkg-deb --info) would produce
something looking remarkably like a Packages file.
Ian.
Re: packaging X things
Sven Rudolph writes ("Re: packaging X things"):
> Andrew D. Fernandes <[EMAIL PROTECTED]> writes:
> > I am in the process of packaging up x3270 for debian, and while I have
> > built
> > X-stuff via imake before, I have never had to modify things.
> >
> > Until now.
> >
> > Is there an easy way of modifying the (i)makefiles to install the software
> > in
> > a non-root subdirectory, but make sure that these paths don't get compiled
> > into the program, or am I going to have to bite the bullet and comb the
> > source by hand and by grep?
>
> The Makefiles made by imake use the symbol DESTDIR, which is a prefix
> to all file names and not defined by default. [...]
In general the best advice in your situation is to look at the
Makefiles and see if you can set a variable of some kind - that's how
it's done with the example package, GNU hello.
If there isn't a suitable variable and adding one is too hard and
likely to cause failed patches in the future you may have to resort to
seddery on the Makefiles - I had to do this for trn. Believe me, you
do not want to go this way unless you don't have any other way :-).
Ian.
Re: Release management and package announcements
Ian Murdock writes ("Re: Release management and package announcements"):
> I agree with Ian--putting the debian-1.0 tree under private makes it
> difficult for it to double as our bleeding edge a.out distribution.
> (If we had a separate a.out bleeding edge tree, I'd agree with Bruce.
> I'm not sure what we've decided to do about it.)
I'm not convinced that we can maintain a separate a.out bleeding edge
tree, nor am I convinced that it would be useful if we could. ELF is
the bleeding edge nowadays ...
As to what we've decided ? Ian M., you get to decide :-).
Ian.
Re: FTP Installation & Package Naming Conventions
brian white writes ("Re: FTP Installation & Package Naming Conventions "):
> >brian white writes ("Re: FTP Installation & Package Naming Conventions "):
> >> Also, while the versions are not choosen by Debian, the format in which
> >> they are written could be. It really makes little difference whether it
> >> is called "bison-A2.5-0.deb" or "bison-2.5A-0.deb".
> >
> >The sorting implications are very different, and this is important
> >because dpkg and dselect can be reluctant to downgrade packages.
>
> Ah, so these version num...er...strings are lexigraphically ordered? I never
> saw that documented anywhere.
That's because there's not much dpkg documentation. I've had a draft
manual from Juho A Vuori <[EMAIL PROTECTED]>, who hasn't
responded yet to the comments I sent him.
I don't recall that that manual documented the ordering convention for
version numbers.
If you would like to write a manpage fragment (examine the dpkg source
code to see what it does), please do so - send it both to Juho and to
me.
Thanks,
Ian.
Unanswered problem reports
The following problem reports have not yet been marked as `taken up' by a message to [EMAIL PROTECTED] OVER 9 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Submitter 379 mount Repeatable mount(1) problem wi Bill Mitchell <[EMAIL PROTECTED] OVER 8 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Submitter 416 wenglish perl doesn't flush output auto [EMAIL PROTECTED] 421 term unreasonable restriction on te Raul Miller <[EMAIL PROTECTED]> 563 tartar -x fails to overwrite or c [EMAIL PROTECTED] (Ian Jackso 579 image (?) missing /usr/man/man8 manpages Bill Mitchell <[EMAIL PROTECTED] OVER 7 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Submitter 660 gdbGDB gets address of structure [EMAIL PROTECTED] (Ian Jackso 662 procps top doesn't behave sensibly if [EMAIL PROTECTED] (Ian Jackso 691 textutils textutils package, fmt(1) prog Bill Mitchell <[EMAIL PROTECTED] 702 findutils locate crash with large db Ernie Elu <[EMAIL PROTECTED] 710 xs3X server problem with hardware [EMAIL PROTECTED] (Ian Jackso 713 mh mh should pause after printing [EMAIL PROTECTED] (Ian Jackso 723 xconfigX server default configuration [EMAIL PROTECTED] (Ian Jackso 725 xbase twm places windows incorrectly [EMAIL PROTECTED] (Ian Jackso 729 procps Bizarre corrupted output from [EMAIL PROTECTED] (Ian Jackso 731 ncursesncurses wgetnstr doesn't work [EMAIL PROTECTED] (Ian Jackso 737 gawk gawk references to `$0' in END [EMAIL PROTECTED] (Ian Jackso 740 xbase xclock leaves `droppings' in i Ian Jackson <[EMAIL PROTECTED] 746 cpio mt doesn't support setblk (and [EMAIL PROTECTED] (Ian Jackso OVER 6 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Submitter 759 kbd, xbase /usr/bin/X11/showfont conflict [EMAIL PROTECTED] (Raul Miller) 773 xbase xmh falls over if mh is not in [EMAIL PROTECTED] (Richard K 775 xbase twm reports errors on incorrec [EMAIL PROTECTED] (Richard K 783 tartar --same-order doesn't work [EMAIL PROTECTED] (Ian Jackso 784 manpages Infelicities in fopen manpage [EMAIL PROTECTED] (Ian Jackso 785 cpio mt problems[EMAIL PROTECTED] (Bill 786 syslogdsyslogd gone awol [EMAIL PROTECTED] (Ian Jacks 797 (base) /etc/termcap console keydefs f Bill Mitchell <[EMAIL PROTECTED] 798 svgalibsvgalib gets control key mucke [EMAIL PROTECTED] (Raul Miller) 808 emacs Info anchors not active in ema [EMAIL PROTECTED] 817 tartar -T /dev/null extracts whol [EMAIL PROTECTED] (Ian Jackso 818 bash bash builtin `echo' doesn't ch [EMAIL PROTECTED] (Ian Jackso 819 tartar should have null-separated [EMAIL PROTECTED] (Ian Jackso 820 tcsh tcsh builtin `echo' doesn't ch [EMAIL PROTECTED] (Ian Jackso 821 shellutils /bin/echo doesn't check write [EMAIL PROTECTED] (Ian Jackso 822 tartar -t doesn't check write err [EMAIL PROTECTED] (Ian Jackso 824 cpio cpio should have non-verbose, [EMAIL PROTECTED] (Ian Jackso 825 trntrn warning messages corrupt t [EMAIL PROTECTED] (Ian Jackso 827 libc or sh who reports wrong hostname (wa [EMAIL PROTECTED] (Christian 835 sysklogd syslogd dies, leaves system un [EMAIL PROTECTED] (William 836 (base) Possible bugs in termcap syste "Emilio C. Lopes" <[EMAIL PROTECTED] 841 ncursesdselect from dpkg 0.93.34 says [EMAIL PROTECTED] (Bill 844 manpages readdir(3) should document str [EMAIL PROTECTED] (Ian Jackso 845 manpages access(2) is ambiguous [EMAIL PROTECTED] (Ian Jackso 850 indent [indent] option mentioned in d [EMAIL PROTECTED] (J.H.M 853 shellutils `nice' does not do anything[EMAIL PROTECTED] (Ian Jackso 857 gs_bothgs (2.6.1pl4-4) doesn't use /e [EMAIL PROTECTED] (Ian Jackso 860 mount `only root can mount' can mean [EMAIL PROTECTED] (Ian Jackso OVER 5 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Submitter 864 make make gets MAKEFLAGS wrong [EMAIL PROTECTED] (Ian Jackso 887 xarchieR6 xarchie barfs when ftp closes [EMAIL PROTECTED] 889 info Info 3.1-6 [EMAIL PROTECTED] (Emilio C. 902 lprlpr can't print a PostScript f [EMAIL PROTECTED] (Ian Jackso 903 (base) /dev miscellaney Bill Mitchell <[EMAIL PROTECTED] 911 libc libc causes rsh to fail on com [EMAIL PROTECTED] (Ian Jackso 918 miscutils mkboot and image packages [EMAIL PROTECTED] (Bill 923 xbase xdm failed with `unknown sessi [EMAIL PROTECTED] (Ian Jackso 927 ncurses? dselect display bugBill Mitchell <[EMAIL PROTECTED] 932 pine Pine over-encodes files and au [EMAIL PROTECTED] (Ian Jackso 933 pine Pine wants to post my email re [EM
Bug#1798: /etc/login has no effect when using xdm from other machines
Package: xdm Instead of testing for "/etc/nologin" in "/etc/X11/Xstartup", the testing should be done in "/etc/X11/Xsession". And a "-geometry +100+100" will make it look nicer; probably a "-bg yellow" will wake up the user ... Winfried
Bug#1799: smail nameresloving problems
smail: 3.1.29.1 rev 13.
I'm having a problem with smail. It was recently working just fine. But
for some reason unknown to me, it has stopped working.
Here is a summary of the problem:
My fdqn is aij.st.hmc.edu. Foo.st.hmc.edu is a another member of the domain
st.hmc.edu. I have no problems using 'host' or nslookup to discover the
ip address of 'foo.st.hmc.edu', nor do I have a problem using nslookup or
host to find the ip address of 'foo', the short hostname by itself.
Sending mail to [EMAIL PROTECTED] results in a returned message from the mailer-
daemon, host unknown. Mail to [EMAIL PROTECTED] gives the same error.
Sending mail to [EMAIL PROTECTED] (the fdqn) is ok.
Here's my /etc/resolv.conf:
domain st.hmc.edu
search st.hmc.edu hmc.edu
nameserver 134.173.53.8
nameserver 134.173.32.20
nameserver 134.173.42.2
The nameservers all work correctly.
Here is /etc/host.conf
order hosts,bind
multi on
Here is /etc/smail/routers
# This is the Smail routers file, which says what to do with mail destined for
# remote hosts. This configuration is for Internet and satellite systems.
# It was originally generated by `smailconfig', part of the Smail package
# distributed with Debian, but it may edited by the mail system administrator.
# This file originally generated by smailconfig at Tue Oct 31 23:49:46 PST 1995
# See smail(5) for details of the things that can be configured here.
inet_addrs:
driver=gethostbyaddr, transport=smtp;
check_for_local, fail_if_error
inet_hosts:
driver=bind, transport=smtp;
defer_no_connect, -local_mx_okay, +defnames, +dns_search,
gateways=hmc.edu:uucp:bitnet
Using any options of +/-defnames and +/-dns_search do not change the
behavior in any way.
Removing the file '/etc/smail/routers' fixes the problem. However, as I'd
like to use a smarthost for uucp and bitnet mail, this is very inconvient.
All operations involving doing something with 'foo' work correctly, for
instance 'telnet foo' works fine, so does something like 'finger @foo'.
Here is an included message from another debian smail user with the
same problem.
---
Ack, I have been at this an hour, and I have come to the conclusion
that I am missing something -- probably something completely obvious.
Ok, the situation is as follows.
I have a new nameserver set up at 198.112.200.8
This nameserver has an "MX" record for our domain
This nameserver has "A" records for _all_ hosts
Using the new nameserver:
I can nslookup any short hostname, fqdn, or MX record.
I can telnet to any host, using the short hostname or fqdn.
I can mail to any fqdn or MX alias.
===> I _can't_ *mail* to any short hostname except the localhost's
(it says "host unknown" when I do a "smail -bt" test)
Can somebody help me figure out what it is trying to do? Smail seems
to be failing to figure out that it needs to tack on .simons-rock.edu
to the name. As I said above, I can nslookup short hostnames and fqdn
just fine (e.g. plato and plato.simons-rock.edu).
My DNS records are set up in the following format :
; MX Mail routing ("A" records are for broken mailers which require IPs.)
simons-rock.edu.IN MX 0 plato.simons-rock.edu.
simons-rock.edu.IN A198.112.200.2
abel.simons-rock.edu. IN MX 0plato.simons-rock.edu.
; Networking Office 1 - 30
plato.simons-rock.edu. IN A198.112.200.2
www.simons-rock.edu.IN CNAMEplato.simons-rock.edu.
gopher.simons-rock.edu. IN CNAMEplato.simons-rock.edu.
My /etc/resolv.conf:
domain simons-rock.edu
search simons-rock.edu
nameserver 198.112.200.8
My relevant /etc/smail/transports entry:
smtp: driver=tcpsmtp, max_addrs=100, -max_chars, inet;
use_bind, defer_no_connect, -local_mx_okay, defnames
My /etc/smail/routers:
inet_addrs:
driver=gethostbyaddr, transport=smtp;
check_for_local, fail_if_error
inet_hosts:
driver=bind, transport=smtp;
defer_no_connect, -local_mx_okay, defnames,
gateways=uu.net:uucp:+:cunyvm.cuny.edu:bitnet
-
Here's some help from Ian Jackson
-
Hmm. Can you try adding
dns_search
type: boolean
If set allow the resolver to search its domain list
for matches. This experimental and might not have
the effect you expect depending on your resolver
search capabilities.
to your bind router and see what the effect is ?
If you could try it with all of
-defnames, -dns_search
-defnames, +dns_search
+defnames, -dns_search
