Re: managed-keys.bind's directory problem
On Dec 14, 2009, at 6:28 PM, Doug Barton wrote:
> Chris Buxton wrote:
>
>> The options { directory ""; }; statement specifies named's working
>> directory (its 'cwd'), not the location of the configuration
>> directory.
>
> I continue to assert that both the code and long custom say that it
> specifies both, and further continue to assert that this is a mistake.
> However it's clear at this point that there is no consensus that this
> behavior should be changed, so I'll make the changes on my end.
Long custom on FreeBSD might say that, but the example I gave of putting config
files in /etc and zone files in /var/named is actually quite well established.
That has generally been the default setup that I've seen on Linux, Solaris, and
Mac OS X, going back to the mid-90's.
Things have gotten more complicated recently as chroot jails become more
common, and as security becomes more of a concern. Debian Linux (and Ubuntu by
inheritance), for example, specifically suggests putting nothing but slave/stub
zone files into the working directory, /var/cache/bind. Master zone data (and
any other data that must be writable by named) is intended to go into
/var/lib/bind, while config data (including default zone data) goes into
/etc/bind. The documentation makes specific mention of using full paths as
needed.
I can't speak to what the code says. I'm not fluent at reading source code.
Chris Buxton
Professional Services
Men & Mice
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: managed-keys.bind's directory problem
fujiw...@wide.ad.jp wrote: > I'm using BIND 9.7.0b3 an DLV (dns-lookaside auto;). FYI I recently committed the port for 9.7.0rc1. Hopefully this will make it easier for you to continue testing. Please try the port and let me know if you have any problems with it. > The named tried to write "managed-keys.bind" file into the named's > working directory. I just committed the update I described in my previous message. If you're not running -current and you'd like to experiment with it you can grab the files from http://svn.freebsd.org/viewvc/base?view=revision&revision=200563. Put the BIND.chroot.dist file in /etc/mtree and the new named.conf file in /etc/namedb/. What I suggest to users (and do myself) is that they use the default named.conf file and include customizations via the "include" directive. That way you can easily pick up changes when the default is updated. If you choose not to do that, no problem, the 2 key changes are 'directory "/etc/namedb/working";' and the need to fully qualify all file and path names in named.conf. Once your files are updated you can do '/etc/rc.d/named restart' and the new working directory will be created for you with proper permissions (assuming you don't have any of the chroot options disabled in rc.conf). I tested this configuration several different ways, including the use of 'dnssec-lookaside auto;' and it worked fine. The managed-keys.bind file was created and used as expected in /etc/namedb/working. If you have any questions or problems please let me know. I will MFC this change before the 7.3-RELEASE, but I will likely give it some time to settle in -current before I do. Thanks for bringing this issue to our attention. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Handling of RSASHA256 and RSASHA512 in BIND 9.6.0 and BIND 9.6.0-P1
While this reminder is timely and helpful, more welcome would be the
news that BIND 9.6.2 is going to have actual support for
RSASHA{256|512}. My cursory reading of the 9.6.2b1 code does not seem
to indicate that it does, although I would be happy to be proven wrong.
I personally don't think it's reasonable to expect everyone who wants
to validate with BIND to upgrade to 9.7.x for a variety of reasons
that I'd be happy to elucidate if they are not obvious.
Doug
--
Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/
Mark Andrews wrote:
> With upcoming deployment of RSASHA256 to sign the root zone, ISC
> would like to remind BIND 9.6.0 and BIND 9.6.0-P1 users that use
> DLV, but have not yet upgraded, that they will need to upgrade to
> a more recent version of BIND 9.6.x as BIND 9.6.0 and BIND 9.6.0-P1
> will not correctly handle RSASHA256 and RSASHA512 signed zones in
> DLV.
>
> 2579. [bug] DNSSEC lookaside validation failed to handle unknown
> algorithms. [RT #19479]
>
> This defect was addressed in BIND 9.6.1.
>
> ISC has arranged for two test zones to be made available which are
> signed using the new algorithms which are listed in dlv.isc.org.
>
> You can test whether you can successfully resolve these zones using the
> following queries.
>
> dig rsasha256.island.dlvtest.dns-oarc.net soa
> dig rsasha512.island.dlvtest.dns-oarc.net soa
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Handling of RSASHA256 and RSASHA512 in BIND 9.6.0 and BIND 9.6.0-P1
With upcoming deployment of RSASHA256 to sign the root zone, ISC would like to remind BIND 9.6.0 and BIND 9.6.0-P1 users that use DLV, but have not yet upgraded, that they will need to upgrade to a more recent version of BIND 9.6.x as BIND 9.6.0 and BIND 9.6.0-P1 will not correctly handle RSASHA256 and RSASHA512 signed zones in DLV. 2579. [bug] DNSSEC lookaside validation failed to handle unknown algorithms. [RT #19479] This defect was addressed in BIND 9.6.1. ISC has arranged for two test zones to be made available which are signed using the new algorithms which are listed in dlv.isc.org. You can test whether you can successfully resolve these zones using the following queries. dig rsasha256.island.dlvtest.dns-oarc.net soa dig rsasha512.island.dlvtest.dns-oarc.net soa -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: m...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: managed-keys.bind's directory problem
Chris Buxton wrote:
> On Dec 13, 2009, at 5:40 PM, Doug Barton wrote:
>> On Fri, 11 Dec 2009, Mark Andrews wrote: To repeat my primary
>> objection, if the named user can write to the configuration
>> directory it can change the contents of named.conf. That's a
>> security problem.\
>
> So don't put named.conf inside the working directory. Put it in
> /etc, or something like that.
The actual solution I'm currently testing (and will likely commit to
-current soon) is to place the working directory "under" the
configuration directory. In FreeBSD currently the configuration is in
/etc/namedb, which is also what's listed as "directory" in named.conf.
I've added a directory /etc/namedb/working that is writable by the
bind user and is now listed as "directory" instead. By default the
named process chroots into /var/named, so /etc/namedb is actually a
symlink to /var/named/etc/namedb.
> /etc/ named.conf rndc.conf /var/named/ (working directory)
Two problems with this idea. The first is that the default
configuration has to work whether or not the user chooses the chroot
option (which is on by default). I obviously could create
/var/named/var/named, but that's just silly.
The other (and in my mind more serious) problem is that in named.conf
all unqualified paths are considered relative to the working
directory. To me that indicates that there is still a pretty strong
connection between "the configuration directory" and "the working
directory" and certainly leads to users making bad decisions about
what to put where. It also means that if I want to make a clean
separation between the two I either have to fully qualify every path
name in named.conf (not exactly rocket science of course, just
inconvenient and goes against 15 years of experience) or I have to use
funky solutions like 'file "../foo/barfile"' which is (arguably) ugly,
and definitely liable to lead to confusion.
> You are not bound to put anything into the working directory. Just
> make sure it's writable by named. However, this is a convenient
> place to put zone files, as long as you don't mind giving named
> permission to rewrite/overwrite them.
Well obviously if you're slaving zones or using dynamic updates you
have to have at least one directory somewhere that named can write to.
IMO it's also nice to have a path for master zones that the named user
cannot write to, but maybe I'm just paranoid.
> The options { directory ""; }; statement specifies named's working
> directory (its 'cwd'), not the location of the configuration
> directory.
I continue to assert that both the code and long custom say that it
specifies both, and further continue to assert that this is a mistake.
However it's clear at this point that there is no consensus that this
behavior should be changed, so I'll make the changes on my end.
Doug
--
Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: managed-keys.bind's directory problem
On Dec 13, 2009, at 5:40 PM, Doug Barton wrote:
> On Fri, 11 Dec 2009, Mark Andrews wrote:
> To repeat my primary objection, if the named user can write to the
> configuration directory it can change the contents of named.conf. That's a
> security problem.\
So don't put named.conf inside the working directory. Put it in /etc, or
something like that.
/etc/
named.conf
rndc.conf
/var/named/
(working directory)
You are not bound to put anything into the working directory. Just make sure
it's writable by named. However, this is a convenient place to put zone files,
as long as you don't mind giving named permission to rewrite/overwrite them.
Of course, the paths above can be prefixed with a chroot directory path.
>> On some OS's this is the only way to get a core file for debugging as there
>> is no way to specify anything other than the current working directory.
>
> Once again, I assert that this is a design flaw in named. Processes should
> not be dumping random stuff into the same directory where their configuration
> files go. It may have been acceptable back in the BIND 4 days, but it's time
> to move on.
Yes, it's time for you to move on. Don't put anything that should not be
writable in or under the working directory. Start using absolute paths instead
of just filenames.
The options { directory ""; }; statement specifies named's working directory
(its 'cwd'), not the location of the configuration directory.
Chris Buxton
Professional Services
Men & Mice
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Best practices or known issues with split-dns
Hi Gord, There are a couple of references available from ISC: https://www.isc.org/software/bind/documentation/arm95#id2549568 and https://www.isc.org/faq, the question about views using TSIG. Regards, Sue Taylor, Gord wrote: > I should also clarify, before someone states it, that I don't WANT to > use split-dns, and my goal is to always migrate away from it. But there > are instances (acquisitions, routing constraints, etc.) where we are > stuck with split-dns, at least for a short period of time. > > Thanks, > Gord T (GCIH, CISSP, GEEK) > > -Original Message- > From: bind-users-boun...@lists.isc.org > [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Taylor, Gord > Sent: 2009, December, 11 10:56 AM > To: bind-users@lists.isc.org > Subject: Best practices or known issues with split-dns > > > I'm trying to put together a list of best practices for use in my org > around the use of split-dns (implementation, operational, technical, > etc.) . Obviously, I'd rather not start from scratch, and since I'd only > be basing the doc on my experience, there may be things I miss as well. > Does anyone have, or know of, a similar doc? Even if I get a bunch of > pointers to several sites with individual items, I don't mind pulling > disparate sources together into a single doc. > > If I find enough content I could make it generic enough to post publicly > as well for community consumption - maybe through bind9.net (I'd be open > to suggestions on where to post). > > Thanks, > Gord T (GCIH, CISSP, GEEK) > > > ___ > > This e-mail may be privileged and/or confidential, and the sender does not > waive > any related rights and obligations. Any distribution, use or copying of this > e-mail or the information > it contains by other than an intended recipient is unauthorized. > If you received this e-mail in error, please advise me (by return e-mail or > otherwise) immediately. > > Ce courriel peut contenir des renseignements protégés et confidentiels. > Lexpéditeur ne renonce pas aux droits et obligations qui sy rapportent. > Toute diffusion, utilisation ou copie de ce courriel ou des renseignements > quil contient > par une personne autre que le destinataire désigné est interdite. > Si vous recevez ce courriel par erreur, veuillez men aviser immédiatement, > par retour de courriel ou par un autre moyen. > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Susan Graves Internet Systems Consortium Get trained by the experts! https://www.isc.org/services/training ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Hi
supriya samanta wrote: > Hello All, > > As per ISC security bulletin *CVE-2009-4022* There is a problem with > BIND 9 Cache Update From Additional Section > > *Problem Description:* A Nameserver with DNSSEC validation enabled may > incorrectly add records to its cache from the additional section of > responses received during resolution of a recursive client query.This > behavior only occurs when processing client queries with checking disabled > (CD).It may occur both when requesting,and not when requesting,DNSSEC > records(DO).If the nameserver is authoritative-only this will not occur. > > We have some business requirement where we need to reproduce the problem. > > Could anyone advice a test case which I may use or direct me to some > website which could be useful for this purpose. > You should contact ISC directly about this rather than the mailing list. Danny -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bonjour! I wish to compile 9.7.0b3
jv wrote: > Thank you! Evan, > > I have not VisualStudio which is commercial. Do you think I can use an > other compiler or do you think VisualStudio light is enough (Version > 2008 seems available). > > Best It should work fine. Danny -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Windows : compilation options
Danny Mayer a écrit : > Romain De Rasse wrote: > >> Hi, >> >> I succeeded in compile ISC Bind for Windows. I'm now trying to enable >> "fixed rrset" (--enable-fixed-rrset for the configure file). But I >> did'nt find how to change options for a Windows compilation. >> >> Can anyone help me ? >> > > #define DNS_RDATASET_FIXED 1 > > in config.h > > Danny > > OK thanks, I succeeded in compiling with fixed rrset enabled. Strange thing though, the "Beyond Compare" soft doesn't find any difference between this two directories : Build\Release after compiling with fixed rrset enabled and Build\Release after compiling without. In the Bind sources directory tree, only ".obj" files are different, and these files are not located in Build\Release. I don't really understand how, but it works. It's the most important. Regards, Romain ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bonjour! I wish to compile 9.7.0b3
jv wrote: > This is my first mail on this list. I hope I am at the right place. I > have loaded BIND 9.7.0b3 under Windows. Now I would like to compile it. > Could someone help me with what is exactly to be done (and if I should > install a special compiler). > Thank you for your help! > > -- > Joel Verdon Just follow the instructions in the win32-build.txt file. You need to build OpenSSL and libxml2 first. That file contains instructions on those as well. Almost any MSVC compiler will work. Danny -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: non-ascii zone
ok, I understand ...
domain name must bee processed by idn / libidn
idn --idna-to-ascii españa.eu
result
xn--espaa-rta.eu
PHP equivalent function is idn_to_ascii.
Right zone definition
zone "xn--espaa-rta.eu" IN {
type master;
file "zone/master/españa.eu";
}
For whois (4.7.24) I can use UTF8 domain names,
but for dig (9.4.2-P1) is required non-ascii string = idn converted.
And the same for other network tools.
Thanks for pointing.
Regards Maring
> > Hi guys,
> > how to define zone for domain with non-ascii characters by right way?
> >
> > Something like
> > zone "españa.eu" IN {
> > " IN { > > type master;
> > file "zone/master/españa.eu";
> > }
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: How to find out DNS Server version ?
On 13 Nov 2009, at 14:20, Tibo wrote:
>
> We have 4 little datacenters over the world.
> I would like to check if all DNS servers are up to date but only people
> responsible of a datacenter can access their servers for security reasons.
> I know some tools on the net can do that but it's not easy for me and
> I'd like to automatise all of that.
How about just using an ACL for rndc on each nameserver which allows
only your local network to run "rndc status" against each nameserver?
>From the output of that, the first line will give you the version number.
The DNS server admins will also have to give you an rndc key which you
will use on your local system to connect to the server. This is referenced
below as "my-rndc-key.rndc".
For example, you could have the following in each nameserver's named.conf:
=
/*
* ACL for controlling slave servers
*/
acl "allowed-rndc" {
127.0.0.1; /* loopback */
192.168.1.0/24; /* localnet */
x.x.x.x/24; /* any network */
};
/*
* Control socket
*/
controls {
inet * /* this can be as restrictive as desired */
allow { allowed-rndc; }
keys { my-rndc-key.rndc; };
};
=
Then, from your "x.x.x.x/24" network, you can run the following:
# rndc -s ip-of-dns-server-here status
This will give you the following output:
=
version: 9.6.1-P2
number of zones: 5
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running
=
You can then get the version number from the first line. Hope this helps.
Thanks,
Khusro
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: non-ascii zone
hi,
you can write your zone to browser, so you can see how does it write
www.españa.eu -> www.xn--espaa-rta.eu
On 12/14/2009 10:45 AM, Martin Fuxa wrote:
Hi guys,
how to define zone for domain with non-ascii characters by right way?
Something like
zone "españa.eu" IN {
type master;
file "zone/master/españa.eu";
}
Regards Martin
___
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
non-ascii zone
Hi guys,
how to define zone for domain with non-ascii characters by right way?
Something like
zone "españa.eu" IN {
type master;
file "zone/master/españa.eu";
}
Regards Martin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
