bind 9.6-esv-r1 segfault
Yesterday Bind has crashed with the following error: # grep segfault messages Sep 23 20:21:10 ns kernel: [5079807.029465] named[19531]: segfault at dededf1e ip 0813d4d7 sp b618f320 error 5 in named[8048000+1c9000] Is it possible to determine the cause of this failure? # uname -a Linux ns 2.6.32.13-0.4-pae #1 SMP 2010-06-15 12:47:25 +0200 i686 i686 i386 GNU/Linux bind configuration options: $ ./configure --enable-largefile --enable-ipv6 --enable-epoll --enable-threads -- wbr, Sergey V. Lobanov ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: repository for zone files
On Fri, 24 Sep 2010, Jason Mitchell wrote: [...@clueby4.net ~]$ cat /etc/redhat-release CentOS release 5.5 (Final) [...@clueby4.net ~]$ yum info bind-chroot Name : bind-chroot That's only there as legacy though, to not break updating old systems that depend on it. The recommended method to secure your nameserver when starting from a fresh install, is to use SElinux, not chroot. Paul ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: repository for zone files
On Thu, 23 Sep 2010, Paul Wouters wrote: > Note that RHEL/CentOS/Fedora rely on SElinux instead of chroot(). The problem > with chroot() is needing copies of system files, which make it hard to package > for updates, etc. But the same applies, for SElinux policies to work properly, > stick with the OS. > > Also, /etc should not containt megabytes of zones files imho, that's much better > placed in /var. > > Paul That's not strictly true. [...@clueby4.net ~]$ cat /etc/redhat-release CentOS release 5.5 (Final) [...@clueby4.net ~]$ yum info bind-chroot Loaded plugins: fastestmirror Excluding Packages in global exclude list Finished Available Packages Name : bind-chroot Arch : x86_64 Epoch : 30 Version: 9.3.6 Release: 4.P1.el5_4.2 Size : 44 k Repo : base Summary: A chroot runtime environment for the ISC BIND DNS server, named(8) URL: http://www.isc.org/products/BIND/ License: BSD-like Description: This package contains a tree of files which can be used as a : chroot(2) jail for the named(8) program from the BIND package. : Based off code from Jan "Yenya" Kasprzak Regards, Jason ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: repository for zone files
On Thu, 23 Sep 2010, Michael Sinatra wrote: On 09/23/10 12:53, Stewart Dean wrote: On AIX, I'm used to /etc/dns. CentOS seems to place in /var/named. Is there any blessed, bestofallpossibleworlds place for the zone files. I'm moving our DNS from from AIX to CentOS/Fedora. I'm inclined to create the /etc/dns dir but maybe it'd be better to put it in /var/named.Comments, brickbats? I have always found it to be a good idea to do what the OS wants. Many OSes now are set up to run bind in a chroot jail (a good thing), but this requires Note that RHEL/CentOS/Fedora rely on SElinux instead of chroot(). The problem with chroot() is needing copies of system files, which make it hard to package for updates, etc. But the same applies, for SElinux policies to work properly, stick with the OS. Also, /etc should not containt megabytes of zones files imho, that's much better placed in /var. Paul ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: repository for zone files
On 09/23/10 13:14, Greg Whynott wrote: they (the distro maintainers) could not agree to put anything in the same place if the worlds sanity depended on it. /var/named /srv/bind /etc/bind /var/lib/named /usr/local/named it's all over the place. myself i just create links from /var/named (which is where I think it was found on most commercial UNIX's I've used, IRIX admin here..) to wherever they decided to stick it. That being said, if you build it from source (which I'd be inclined to do if not using a linux wiht a support contract), you can pass the path to configure and place it anywhere you wish with zero functionally loss. its a bunch of "my way makes sense, i'll pee in this corner, its mine now). its UNIX fragmentation all over again. 8) Over the years, I have learned the utility of sticking to your OS's package-management system. It ensures that files being placed in the major system directories are tracked and can be updated/uninstalled easily when necessary. You can always create a /usr/wild-wild-west directory for non-package stuff, but that doesn't scale well. Compiling from source is fine, as long as you create your own RPM/dpkg/pkg/port/whatever so that you keep track of what's there. When using your own packages, it's still good to do what the OS prefers so that you can maintain compatibility with the OS's packages (and its default configuration for things like SELinux). I agree, though, with your sentiment. From an administration perspective, it no longer makes sense to have "Linux vs. BSD vs. Other Unix" arguments--it's now "RHEL/CentOS/Fedora vs. Debian/Ubuntu vs. SuSE vs. Mandriva vs. Gentoo vs. FreeBSD vs. OpenBSD vs. NetBSD vs. Dragonfly vs. (Open)Solaris vs. AIX vs. etc etc etc." It's further complicated by the fact that some distros do a better job of keeping BIND up-to-date than others. Some do a fine job of applying security patches...to BIND 9.3.x. That's fine if you plan to sleep through DNSSEC. It doesn't help much if you need newer features for your system that's running as a dedicated DNS server--and you probably do. FreeBSD is good in this regard, thanks to the efforts of Doug Barton who keeps the various BIND trains up to date in ports. In other words, so distros/OSes are better for BIND than others, but the idea of having to choose different distros/OSes for different services doesn't scale terribly well. michael ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: All zone blocks for "public" view should be listed here in "internal"too!
> > why do you use views then? I guess there's no need for it... On 23.09.10 23:13, Bèrto ëd Sèra wrote: > Because I usually tend to modify a proposed configuration as little as > possible, as long as it doesn't cause trouble. But it looks like this one is > quite far from what a web-server needs. in order to preserve simplicity I tend to remove proposed configurations and use my own for bind, apache and some other software packages. Those "proposed configurations" are usually for the very "general" cases that don't exist anywhere. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. One OS to rule them all, One OS to find them, One OS to bring them all and into darkness bind them ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: All zone blocks for "public" view should be listed here in "internal"too!
> > Hi! > > why do you use views then? I guess there's no need for it... > Because I usually tend to modify a proposed configuration as little as possible, as long as it doesn't cause trouble. But it looks like this one is quite far from what a web-server needs. Bèrto ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: repository for zone files
they (the distro maintainers) could not agree to put anything in the same place if the worlds sanity depended on it. /var/named /srv/bind /etc/bind /var/lib/named /usr/local/named it's all over the place. myself i just create links from /var/named (which is where I think it was found on most commercial UNIX's I've used, IRIX admin here..) to wherever they decided to stick it. That being said, if you build it from source (which I'd be inclined to do if not using a linux wiht a support contract), you can pass the path to configure and place it anywhere you wish with zero functionally loss. its a bunch of "my way makes sense, i'll pee in this corner, its mine now). its UNIX fragmentation all over again. 8) -g On Sep 23, 2010, at 4:01 PM, Michael Sinatra wrote: > On 09/23/10 12:53, Stewart Dean wrote: >> On AIX, I'm used to /etc/dns. CentOS seems to place in /var/named. Is >> there any blessed, bestofallpossibleworlds place for the zone files. I'm >> moving our DNS from from AIX to CentOS/Fedora. I'm inclined to create >> the /etc/dns dir but maybe it'd be better to put it in >> /var/named.Comments, brickbats? > > I have always found it to be a good idea to do what the OS wants. Many > OSes now are set up to run bind in a chroot jail (a good thing), but > this requires a specific directory structure. If your OS has already > set that up (and if the startup scripts work with that structure), then > it's best to keep them that way. Probably the ideal thing to do is use > the OS defaults and then symlink your previous directory structure to > the OS defaults as necessary to maintain compatibility with your > in-house scripts and processes. > > michael > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: repository for zone files
On Thu, 23 Sep 2010 15:53:26 -0400, Stewart Dean wrote: > On AIX, I'm used to /etc/dns. CentOS seems to place in /var/named. Is > there > any blessed, bestofallpossibleworlds place for the zone files. I'm moving > our > DNS from from AIX to CentOS/Fedora. I'm inclined to create the /etc/dns > dir but > maybe it'd be better to put it in /var/named.Comments, brickbats? I've worked with both. Prefer /var/named, but this is MY preference. I'd suggest using whatever is the standard default for the operating system you are running. This allows new sysadmins to come in and be productive quicker (but only a little quicker). And then you have the possiblity of using a "chroot" environment, which can mess everything up even further. Then again, I am saying to use the normal default OS directory to assist new sysadmins. I'd be a little scared of any sysadmin that came in and couldn't deal with whatever was on the machine. The real key is to use the directory that is specified in the named.conf file, when in the "chroot" location that "named" runs with. Guessing causes mistakes, and "assume" means ... Bill Larson ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: All zone blocks for "public" view should be listed here in "internal"too!
On 23.09.10 20:32, Bèrto ëd Sèra wrote: > Thanks for the answer :) Well, this is web-server, there is no such thing as > an internal user or network, let alone 127.0.0.1 (which is definitely in > "internal" only). why do you use views then? I guess there's no need for it... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I don't have lysdexia. The Dog wouldn't allow that. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: repository for zone files
/etc = named.conf, rndc.conf and other config files /var/named = zone files. Are you running just bind or bind-chroot. If the latter then named.conf goes in /var/named/chroot/etc rather than /etc and the zone files go into /var/named/chroot/var/named instead of /var/named. You can configure things any way you like but if you're using the RHEL updates then you need to put them where RHEL's RPMs put them. Also if you're using SELinux RHEL sets the contexts based on where it expects things to be. If you really want to see things from /etc/dns you could just make an /etc/dns directory then create symbolic links to the named.conf and the zone files in /etc/dns. -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Stewart Dean Sent: Thursday, September 23, 2010 3:53 PM To: bind-users@lists.isc.org Subject: repository for zone files On AIX, I'm used to /etc/dns. CentOS seems to place in /var/named. Is there any blessed, bestofallpossibleworlds place for the zone files. I'm moving our DNS from from AIX to CentOS/Fedora. I'm inclined to create the /etc/dns dir but maybe it'd be better to put it in /var/named.Comments, brickbats? -- "One must think like a hero to behave like a merely decent human being." - May Sarton Stewart Dean, Unix System Admin, Bard College, New York 12504 sd...@bard.edu voice: 845-758-7475, fax: 845-758-7035 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: repository for zone files
On 09/23/10 12:53, Stewart Dean wrote: On AIX, I'm used to /etc/dns. CentOS seems to place in /var/named. Is there any blessed, bestofallpossibleworlds place for the zone files. I'm moving our DNS from from AIX to CentOS/Fedora. I'm inclined to create the /etc/dns dir but maybe it'd be better to put it in /var/named.Comments, brickbats? I have always found it to be a good idea to do what the OS wants. Many OSes now are set up to run bind in a chroot jail (a good thing), but this requires a specific directory structure. If your OS has already set that up (and if the startup scripts work with that structure), then it's best to keep them that way. Probably the ideal thing to do is use the OS defaults and then symlink your previous directory structure to the OS defaults as necessary to maintain compatibility with your in-house scripts and processes. michael ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
repository for zone files
On AIX, I'm used to /etc/dns. CentOS seems to place in /var/named. Is there any blessed, bestofallpossibleworlds place for the zone files. I'm moving our DNS from from AIX to CentOS/Fedora. I'm inclined to create the /etc/dns dir but maybe it'd be better to put it in /var/named.Comments, brickbats? -- "One must think like a hero to behave like a merely decent human being." - May Sarton Stewart Dean, Unix System Admin, Bard College, New York 12504 sd...@bard.edu voice: 845-758-7475, fax: 845-758-7035 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: All zone blocks for "public" view should be listed here in "internal"too!
Hi!
Thanks for the answer :) Well, this is web-server, there is no such thing as
an internal user or network, let alone 127.0.0.1 (which is definitely in
"internal" only). Since the shipped configuration files is accepting queries
from:
acl "trusted" {
127.0.0.0/8;
::1/128;
};
I'd say is made for a single machine only, which is definitely not my case.
My internal currently is:
match-clients { trusted; };
recursion yes;
additional-from-auth yes;
additional-from-cache yes;
zone "." in {
type hint;
file "/var/bind/root.cache";
};
zone "localhost" IN {
type master;
file "/var/bind/pri/localhost.zone";
allow-update { none; };
notify no;
allow-query { any; };
allow-transfer { none; };
};
zone "127.in-addr.arpa" IN {
type master;
file "/var/bind/pri/127.zone";
allow-update { none; };
notify no;
allow-query { any; };
allow-transfer { none; };
};
I cannot think of much using it, apart from database listeners on 127.0.0.1
so allowing matches for "trusted" should be okay. There is nothing that
should call one domain from another. Interlinks in web pages are actually
client-side calls from the public network, so nothing comes from "within".
My Public is
view "public" in {
/*
* Our external (untrusted) view. We permit any client to access
* portions of this view. We do not perform recursion or cache
* access for hosts using this view.
*/
match-clients { any; };
recursion no;
additional-from-auth no;
additional-from-cache no;
zone "." in {
type hint;
file "/var/bind/root.cache";
};
zone "example.org" {
type master;
file "/var/bind/pri/example.org.external";
allow-query { any; };
allow-transfer { xfer; };
};
etc etc
xfer goes to the secondary nameserver, so everything should be safe.
Thanks
Bèrto
On 23 September 2010 20:21, Lightner, Jeff wrote:
> In views order is important. If you have internal before others (e.g.
> external) then that is the default view.
>
>
>
> What I **think** it is telling you is that if you have an internal view
> that you restrict to certain networks that you need to insure you have all
> the public zones in the external view and the internal view if you intend to
> have your internal users see them. That is what we do here.
>
>
> --
>
> *From:* bind-users-bounces+jlightner=water@lists.isc.org [mailto:
> bind-users-bounces+jlightner =water.com@
> lists.isc.org] *On Behalf Of *Bèrto ëd Sèra
> *Sent:* Thursday, September 23, 2010 1:14 PM
> *To:* bind-users@lists.isc.org
> *Subject:* All zone blocks for "public" view should be listed here in
> "internal"too!
>
>
>
> Hi!
>
>
>
> I hope this is the right alley for my question. I run a public DNS for
> several domains on a gentoo server. After upgrading to 9.7.1_p2 I read in
> the shipped configuration that "All zone blocks for "public" view should be
> listed here in "internal" too!".
>
>
>
> Now, what does it mean? Do I simply copy and paste the public zone entries
> in the internal zone? And what's the point in doing it, is everyone needs it
> anyway?
>
>
>
> I hope you'll pardon my obvious lack of basic knowledge on the subject.
>
> Bèrto
>
> Proud partner. Susan G. Komen for the Cure.
>
> *Please consider our environment before printing this e-mail or
> attachments.*
> --
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
> information and is for the sole use of the intended recipient(s). If you are
> not the intended recipient, any disclosure, copying, distribution, or use of
> the contents of this information is prohibited and may be unlawful. If you
> have received this electronic transmission in error, please reply
> immediately to the sender that you have received the message in error, and
> delete it. Thank you.
> --
>
--
==
Constitution du 24 juin 1793 - Article 35. - Quand le gouvernement viole les
droits du peuple, l'insurrection est, pour le peuple et pour chaque portion
du peuple, le plus sacré des droits et le plus indispensable des devoirs.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: All zone blocks for "public" view should be listed here in "internal"too!
In views order is important. If you have internal before others (e.g. external) then that is the default view. What I *think* it is telling you is that if you have an internal view that you restrict to certain networks that you need to insure you have all the public zones in the external view and the internal view if you intend to have your internal users see them. That is what we do here. From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Bèrto ëd Sèra Sent: Thursday, September 23, 2010 1:14 PM To: bind-users@lists.isc.org Subject: All zone blocks for "public" view should be listed here in "internal"too! Hi! I hope this is the right alley for my question. I run a public DNS for several domains on a gentoo server. After upgrading to 9.7.1_p2 I read in the shipped configuration that "All zone blocks for "public" view should be listed here in "internal" too!". Now, what does it mean? Do I simply copy and paste the public zone entries in the internal zone? And what's the point in doing it, is everyone needs it anyway? I hope you'll pardon my obvious lack of basic knowledge on the subject. Bèrto Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
All zone blocks for "public" view should be listed here in "internal" too!
Hi! I hope this is the right alley for my question. I run a public DNS for several domains on a gentoo server. After upgrading to 9.7.1_p2 I read in the shipped configuration that "All zone blocks for "public" view should be listed here in "internal" too!". Now, what does it mean? Do I simply copy and paste the public zone entries in the internal zone? And what's the point in doing it, is everyone needs it anyway? I hope you'll pardon my obvious lack of basic knowledge on the subject. Bèrto ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Max-Cache-TTL
Two reasons. First, we assume authoritive control for two to three domains each quarter. Limiting the caching TTL would make changes easier to make when we don't have the cooperation of the hosting provider(s). Second, we use BIND to blackhole records/domains. Limiting the TTL would make the changes propagate faster. For internal clients, we have eight servers to handle outbound DNS requests and they are treated as the DNS servers of last resort. However, there are something between seven to eight hundred DNS servers through the enterprise that we have no control over. I am looking for way to ensure when we make changes that they are quickly propagated, especially when we're making blackhole changes. Brian -Original Message- From: bind-users-bounces+brian.atkins2=va@lists.isc.org [mailto:bind-users-bounces+brian.atkins2=va@lists.isc.org] On Behalf Of Dave Sparro Sent: Thursday, September 23, 2010 10:37 AM To: bind-users@lists.isc.org Subject: Re: Max-Cache-TTL On 9/23/2010 10:19 AM, Atkins, Brian (GD/VA-NSOC) wrote: > I'm looking for methods to reduce the period of time we cache external > records (e.g., www.google.com). I think the option I need to implement > is max-cache-ttl. > > Is this the correct method for limiting caching? Are there reasons that > I should or should not do it? > The answer to the first question probably depends on the answer to "Why do you want to limit the time period that external records are cached on your server?" -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Max-Cache-TTL
On 9/23/2010 10:19 AM, Atkins, Brian (GD/VA-NSOC) wrote: I'm looking for methods to reduce the period of time we cache external records (e.g., www.google.com). I think the option I need to implement is max-cache-ttl. Is this the correct method for limiting caching? Are there reasons that I should or should not do it? The answer to the first question probably depends on the answer to "Why do you want to limit the time period that external records are cached on your server?" -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Max-Cache-TTL
I'm looking for methods to reduce the period of time we cache external records (e.g., www.google.com). I think the option I need to implement is max-cache-ttl. Is this the correct method for limiting caching? Are there reasons that I should or should not do it? Thanks, Brian ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
