Re: Shared libraries loaded after chroot
On Mon, May 16, 2016 at 12:23:30PM +0100, Tony Finch wrote: > Marc Haber <mh+bind-us...@zugschlus.de> wrote: > > in Debian, the bind9 packages have recently started to trouble me in > > chrooted environments since some cryptographic libraries are loaded > > after bind has chrooted itself, which results - in the case of a > > minimal chroot - in a fatal run-time error: > > Debian has a patch which initializes OpenSSL before chrooting, which is > supposed to fix this problem - > http://anonscm.debian.org/cgit/users/lamont/bind9.git/commit/?h=stable/v9.10.3=60cf6b37caf48bd3270aa2b7b8af5ebc47396dce > https://sources.debian.net/src/bind9/1:9.10.3.dfsg.P4-10/debian/patches/28_prechroot_init.diff/ Thanks for the pointer. I have added this to the Debian bug that led to this patch and have put Ben on cc. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Shared libraries loaded after chroot
On Mon, May 16, 2016 at 08:09:05AM -0400, Matthew Pounsett wrote: > On 16 May 2016 at 04:38, Marc Haber <mh+bind-us...@zugschlus.de> wrote: > > I have filed Debian Bug #820974 (http://bugs.debian.org/820974) > > accordingly. The Debian bind people suggest that I copy the respective > > libraries to the chroot so that bind can find them. > > > > Yeah, this has been the fix on a lot of systems since GOST was included in > OpenSSL. It's something to do with the GOST algorithm being implemented > differently from everything else... as a plugin instead of a module, if > memory serves (it probably doesn't).IMHO it's a bug in OpenSSL, not > BIND. > > Another option is to compile BIND with GOST support disabled... but that is > awkward for a lot of people using binary package distribution from the OS > vendor. I think I'll go for a locally built package. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Shared libraries loaded after chroot
On Mon, May 16, 2016 at 08:51:41PM -0400, Paul Kosinski wrote: > I have avoided the problem chroot causes in a fairly general fashion by > using "mount --bind". For example: > > /bin/mount --bind /lib /chroot/dns/lib > > will make the entire /lib directory available to the chrooted BIND, > assuming the path /chroot/dns is created beforehand to serve as the > chroot base for running BIND. This is a wrong and dangerous "fix" since it exposes the parent system's /lib to the chroot. Preventing this exposure is the reason for chroot in the first place. > I have heard that chroot does not provide unbreakable isolation, and, > of course, many extra files are made available to the chrooted process > compared to copying the minimum number of individual files. This is much worse than copying the minimum number of individual files since it allows the chrooted root account to _directly_ _change_ the files of the parent system. You can run unchrooted without much more danger. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Shared libraries loaded after chroot
Hi, in Debian, the bind9 packages have recently started to trouble me in chrooted environments since some cryptographic libraries are loaded after bind has chrooted itself, which results - in the case of a minimal chroot - in a fatal run-time error: May 14 21:57:17 fan named[28066]: starting BIND 9.10.3-P4-Debian -f -u bind -t /var/local /chroot/bind May 14 21:57:17 fan named[28066]: built with '--prefix=/usr' '--mandir=/usr/share/man' '--libdir=/usr/ lib/x86_64-linux-gnu' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--with-python=python3' '-- localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable- static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-geoip=/usr' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-' '--enable-native-pkcs11' '--with-pkcs11=/usr/li b/x86_64-linux-gnu/softhsm/libsofthsm2.so' 'CFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat -Wer ror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE' 'LDFLAGS=- fPIE -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 -DDIG_SIGCHASE' May 14 21:57:17 fan named[28066]: May 14 21:57:17 fan named[28066]: BIND 9 is maintained by Internet Systems Consortium, May 14 21:57:17 fan named[28066]: Inc. (ISC), a non-profit 501(c)(3) public-benefit May 14 21:57:17 fan named[28066]: corporation. Support and training for BIND 9 are May 14 21:57:17 fan named[28066]: available at https://www.isc.org/support May 14 21:57:17 fan named[28066]: May 14 21:57:17 fan named[28066]: adjusted limit on open files from 4096 to 1048576 May 14 21:57:17 fan named[28066]: found 6 CPUs, using 6 worker threads May 14 21:57:17 fan named[28066]: using 3 UDP listeners per interface May 14 21:57:17 fan named[28066]: using up to 4096 sockets May 14 21:57:17 fan named[28066]: ENGINE_by_id failed (crypto failure) May 14 21:57:17 fan named[28066]: error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:233: May 14 21:57:17 fan named[28066]: error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:467: May 14 21:57:17 fan named[28066]: error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:390:id=gost May 14 21:57:17 fan named[28066]: initializing DST: crypto failure May 14 21:57:17 fan named[28066]: exiting (due to fatal error) I have filed Debian Bug #820974 (http://bugs.debian.org/820974) accordingly. The Debian bind people suggest that I copy the respective libraries to the chroot so that bind can find them. This, however, would take possibly security relevant libraries from the automated update mechanisms of the distributions, and would therefore greatly reduce ease of upgrades. It is also not mentioned in Chapter 6 of the ARM. What is the official upstream remedy to this situation? Frankly, I think this is a bug in bind 9.10, it should load all necessary libraries before chrooting itself. I am aware that this would probably need parsing of the configuration before chrooting. What is the recommended way to run bind 9.10 in a chroot? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to Fix Reverse DNS?
On Tue, Sep 22, 2015 at 04:54:45PM -0500, Ron Wingfield wrote:
> I have recently converted from a "legacy" DSL service to AT's
> U-verse . . .has been a painful experience. Heretofore, the following
> from /var/named/named.conf
>
> zone "233.202.162.in-addr.arpa" {
> type master;
> file "./zonefiles/db.233.202.162.rev";
> };
>
>
> . . .and the contents of the zone configuration file as follows:
>
> $TTL 3h
>
> @ IN SOA archaxis.net. root.archaxis.net. (
> 2015080601; Serial
> 3h ; Refresh
> 1h ; Retry
> 1w ; Expire
> 1h ); Negative cashing TTL
>
> IN NS ns1.archaxis.net.
> IN NS ns2.archaxis.net.
>
> 1 IN PTR archaxis.net.
> 1 IN PTR ns1.archaxis.net.
> 1 IN PTR ns2.archaxis.net.
Your provider has used a RFC2317 scheme to delegate the reverse DNS to
you:
81.233.202.162.in-addr.arpa. 7200 INCNAME 81.80/29.233.202.162.in-addr.arpa.
80/29.233.202.162.in-addr.arpa. 7200 IN NS ns2.archaxis.net.
80/29.233.202.162.in-addr.arpa. 7200 IN NS ns1.archaxis.net.
so you need
zone "80/29.233.202.162.in-addr.arpa." {
...
}
Btw, this diagnosis would not have been possible if you had obfuscated
the IP address. Thanks for being open, showing your real data,
allowing swift and easy help.
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
Hi,
On Mon, Mar 14, 2011 at 09:16:13PM -0400, Kevin Darcy wrote:
Stub zones: only available as a single level beyond one's authoritative
core, i.e. the stub server must be able to talk directly to one or more
authoritative servers for the zone.
Forward zones: can be daisy-chained an arbitrary number of levels from
the authoritative core (but this is not recommended due to
manageability, performance and reliability concerns).
Stub zones: will use whatever is in the NS records of the zone (or
descendants of the zone, if not otherwise defined) to resolve queries
which are below a zone cut.
Forward zones: will always use the configured forwarders, which must
support recursion, even for names which are known to be deeper in the
delegation hierarchy and whose delegated/authoritative nameservers might
respond more quickly than the forwarders, if asked.
Thanks for the clarification, I appreciate that.
As a general rule, use type forward zones only if you have some
connectivity issue you need to work around, e.g. trying to resolve
Internet names from behind a restrictive firewall.
So, a type forward zone is the right thing to do for the reverse DNS
zones of RFC1918 networks that are reachable via a VPN link. However,
my setup using a type forward zone doesn't work, and bind does not
even try querying the forwarders listed in the type forward zone
statement when I try to obtain a PTR record for an IP on these nets.
Use slave zones if you want a full copy of the zone available at all
times (unless it expires of course), thus maximizing fault-tolerance
and client-to-resolver performance, but subject to the replication
overhead, storage space and willingness of the zone owner to allow
zone transfers. And use stub zones if you want a more lightweight
alternative to slaving, at the expense of some fault-tolerance and
client-to-resolver performance.
In my case, my slave could only intermittendly reach the master
servers for the zones, so I'd need to reload these zones quite
frequently to catch a time when the VPN tunnel is built. Does a stub
zone use the same mechanism, or will it immediately query for the
stub's NS records when a query comes in and the NS records are no
longer cached?
To answer your specific question, the non-intuitive[1] forwarders { };
is needed to inhibit forwarding which has presumably been defined at a
higher level (semantically) in your config, either at the
1.10.in-addr.arpa level, or somewhere above that, explicitly, or
so-called global forwarding defined in the options clause.
Global forwarders. So they would take precedence over the locally
available delegations for the stub zone?
Greetings
Marc
--
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
On Mon, Mar 14, 2011 at 01:36:10PM +0100, Jan-Piet Mens wrote:
A stub zone tells BIND to load SOA and NS records from its masters {}.
(forwarders {} is, I belive, both useless and incorrect here.) From that
point onwards, your BIND will use the data in the stub to recursively
find answers to queries for that zone.
The forwarder on the other hand, instructs BIND to forward all queries
for the zone to the addresses in the forwarders {} list; the target
server must be prepared and willing to perform recursive lookups on your
behalf.
In this case, the servers mentioned in the configuration I posted are
both authoritative for the zones that they're query for _and_ willing
to recurse for my bind if it asked them a recursive query. Which it
doesn't in the forward setup, it just immediately returns NXDOMAIN.
Greetings
Marc
--
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Stub zone vs forward zone
Hi,
I am running a local instance of bind on my notebook to spare myself
some rather annoying reconfiguration orgies that are bound to happen
when changing networks.
On my biggest customer's network, I am trying to be able to access
their reverse DNS, which is (don't ask) not loaded on the servers that
my notebook is assigned via DHCP as forwarders.
I have thus configured these zones locally, experimenting with
differnt configuration types:
zone 2.1.10.in-addr.arpa {
type stub;
masters { 10.1.2.11; 10.1.2.45; };
file stub/2.1.10.in-addr.arpa;
forwarders { };
};
zone 101.1.10.in-addr.arpa {
type forward;
forwarders { 10.1.101.6; };
forward only;
};
The stub zone works; the forward zone doesn't. When I ask my local
bind for 6.101.1.10.in-addr.arpa (PTR), I get an immediate NXDOMAIN
without bind even trying to talk to the actual name server.
I can ping 10.1.101.6 just fine.
I must admit that I haven't yet full understood the difference between
a stub zone and a forward zone, any why i need the forwarders { } on
the stub zone.
Any hints will be appreciated.
Greetings
Marc
--
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
