Re: multiple slave zones pointing to same file?
On 10/2/2010 3:15 PM, online-reg wrote: IME the best way to do this on a Unix'y system is to use hard links. That way if you ever need to change one of them to be its own file it's trivial to do so. Also IME, BIND doesn't react well to having multiple slave zones sharing the same file, but that may have improved in more recent versions, I haven't tried it for a couple of years now. Thanks Doug, but I'm not entirely clear on what you're recommending? It seems like you're saying it's OK, but then you're saying BIND doesn't like it? I'm guessing then that you're not running BIND on a Unix system. In any case, Mark is in a much better position than I to state categorically, "Don't do that" so I am happy to defer to his wisdom. Just use different files for each zone. Yes, it's a bit of duplication on the file system, but that's not the end of the world. Disk is cheap, DNS failure is expensive. hth, Doug -- Breadth of IT experience, and| Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc.key vs. rndc.conf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/2/2010 5:08 PM, online-reg wrote:
| Hi All: One more conf issue on bind 9.7.1-P2
| After running rndc-confgen and reloading BIND I?m getting this error:
| WARNING: key file (/etc/namedb/rndc.key) exists, but using default
| configuration file (/etc/namedb/rndc.conf)
| rndc: connection to remote host closed
| This may indicate that
| * the remote server is using an older version of the command protocol,
| * this host is not authorized to connect,
| * the clocks are not synchronized, or
| * the key is invalid.
| It seems like I have a valid key in both files...what do I need to change?
I'm guessing from the /etc/namedb path above that you're using FreeBSD.
In that case there is no reason to use rndc.conf, as FreeBSD generates
an rndc.key file for you.
1. Stop named ('service named stop' or '/etc/rc.d/named stop')
2. rm /etc/rndc.conf
3. Start named ('service named start' or '/etc/rc.d/named start')
4. rndc status
hth,
Doug
- --
Breadth of IT experience, and| Nothin' ever doesn't change,
depth of knowledge in the DNS. | but nothin' changes much.
Yours for the right price. :) | -- OK Go
http://SupersetSolutions.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (MingW32)
iQEcBAEBCAAGBQJMqAh+AAoJEFzGhvEaGryEV5AH/jsw9Ym7yxubcHUhwaN8X1Ar
ft2zWwczSZec6Tt63RHz1phJ+ynvtmHcDcQ5QptBgZvPHz8LoPMd2FUBKWkHhdNi
B9mhfV1Vgr6aAknULMixVoQSVzdrExQUd+q0WJQKphLRXFtCRHWD34yJq4zk1kDi
RneCmXCRXuLS1qhU+Ffd8teX7+deZZCTFtaErsaJDGSN6mjGg2LF1v0myoKy9iq4
zf9uN2CpLjaQiMgjXDsZc+SN2GEARIhpFz+yiwMAz199YOJxbrBHFpwZte3hIEBw
j/k91RxoRyueijSii3oEVZVAbfmJePijddmpPWBH5tTUAfzmARCK74F5lUuvsBo=
=Vqt0
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc.key vs. rndc.conf
On Sat, 2 Oct 2010, online-reg wrote: > Hi All: One more conf issue on bind 9.7.1-P2 > > After running rndc-confgen and reloading BIND I?m getting this error: > > WARNING: key file (/etc/namedb/rndc.key) exists, but using default > configuration file (/etc/namedb/rndc.conf) > rndc: connection to remote host closed > This may indicate that > * the remote server is using an older version of the command protocol, > * this host is not authorized to connect, > * the clocks are not synchronized, or > * the key is invalid. > > It seems like I have a valid key in both files...what do I need to change? And clocks are close in time? Also this same problem could happen if you have a custom key file, but it is still using the default configuration file instead (so maybe using old, wrong key).___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
9.7.1-P2 managed-keys error
02-Oct-2010 17:33:53.125 general: error: managed-keys-zone ./IN: loading from master file managed-keys.bind failed: file not found I've googled around but am not clear on what's causing this error? Does this file need to be created manually for BIND to be able to write to it? I have a directory "/etc/namedb/working", and permissions are: drwxr-xr-x 2 bind wheel 512 Jul 18 19:23 . drwxr-xr-x 6 root wheel 512 Oct 2 15:52 .. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
rndc.key vs. rndc.conf
Hi All: One more conf issue on bind 9.7.1-P2 After running rndc-confgen and reloading BIND I’m getting this error: WARNING: key file (/etc/namedb/rndc.key) exists, but using default configuration file (/etc/namedb/rndc.conf) rndc: connection to remote host closed This may indicate that * the remote server is using an older version of the command protocol, * this host is not authorized to connect, * the clocks are not synchronized, or * the key is invalid. It seems like I have a valid key in both files...what do I need to change?___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multiple slave zones pointing to same file?
In message <4ca7b926.9070...@wingenbach.org>, John Wingenbach writes: > > Doesn't support it? Correct. It is not supported. Don't take the fact that it doesn't complain as evidence that this is supported practice. The only place where shared file use is supported is in static master zones. > Since when does named not allow you to use the > same file name for more then one zone? I've been doing that for several > years. You should not use the same file name for any zone named writes. This includes slave and stub zones, master files that named updates. Doing so will cause problems. Some of this named will detect on restart and correct by re-transfering the zone. Others it can't and those require manual intervention. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multiple slave zones pointing to same file?
Doesn't support it? Since when does named not allow you to use the same file name for more then one zone? I've been doing that for several years. -- John Wingenbach On 10/2/2010 6:49 PM, Mark Andrews wrote: In message<58f2f2eb90f24743a050575c87c7c...@nyoffice.enigmedia.local>, "online -reg" writes: Hi All: IâEUR^(TM)m building a new Bind 9.7.1-P2 slave server and am taking an opportunity to review my conf files. I have a number of zones on the primary that all point to the same zone configuration file. On my slave server, is there any way to configure named.conf so that multiple zones are all âEURoealiasedâEUR? to the same zone config? No. Named does NOT support this. Mark ___ 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: multiple slave zones pointing to same file?
In message <58f2f2eb90f24743a050575c87c7c...@nyoffice.enigmedia.local>, "online -reg" writes: > Hi All: Iâm building a new Bind 9.7.1-P2 slave server and am taking an > opportunity to review my conf files. > > I have a number of zones on the primary that all point to the same zone > configuration file. On my slave server, is there any way to configure > named.conf so that multiple zones are all âaliasedâ to the same zone > config? No. Named does NOT support this. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multiple slave zones pointing to same file?
On 10/2/2010 11:16 AM, online-reg wrote:
> Hi All: I’m building a new Bind 9.7.1-P2 slave server and am taking an
> opportunity to review my conf files.
>
> I have a number of zones on the primary that all point to the same zone
> configuration file. On my slave server, is there any way to configure
> named.conf so that multiple zones are all “aliased” to the same zone
> config?
>
> Previously, I was using a basic slave config statement for each zone:
>
> zone "domain.com" { type slave; file "domain.com.zone"; masters {
> 192.168.0.1; }; };
>
> but, it seems like a lot of unnecessary files are being created?
>
> I thought about using the same file name for all the slave zones
> statements in named.conf, but wouldn't that force the file to be
> overwritten multiple times for no reason?
How often does the file change? If the answer is "not often" then a little
file system churn is harmless.
Not often.
IME the best way to do this on a Unix'y system is to use hard links. That
way if you ever need to change one of them to be its own file it's trivial
to do so. Also IME, BIND doesn't react well to having multiple slave zones
sharing the same file, but that may have improved in more recent versions,
I haven't tried it for a couple of years now.
Thanks Doug, but I'm not entirely clear on what you're recommending? It
seems like you're saying it's OK, but then you're saying BIND doesn't like
it?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: multiple slave zones pointing to same file?
Simply set the "file" option to the same name on the slave server.
On 10/2/2010 2:59 PM, Doug Barton wrote:
On 10/2/2010 11:16 AM, online-reg wrote:
Hi All: I’m building a new Bind 9.7.1-P2 slave server and am taking an
opportunity to review my conf files.
I have a number of zones on the primary that all point to the same zone
configuration file. On my slave server, is there any way to configure
named.conf so that multiple zones are all “aliased” to the same zone
config?
Previously, I was using a basic slave config statement for each zone:
zone "domain.com" { type slave; file "domain.com.zone"; masters {
192.168.0.1; }; };
but, it seems like a lot of unnecessary files are being created?
I thought about using the same file name for all the slave zones
statements in named.conf, but wouldn't that force the file to be
overwritten multiple times for no reason?
How often does the file change? If the answer is "not often" then a
little file system churn is harmless.
IME the best way to do this on a Unix'y system is to use hard links.
That way if you ever need to change one of them to be its own file
it's trivial to do so. Also IME, BIND doesn't react well to having
multiple slave zones sharing the same file, but that may have improved
in more recent versions, I haven't tried it for a couple of years now.
hth,
Doug
___
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: multiple slave zones pointing to same file?
On 10/2/2010 11:16 AM, online-reg wrote:
Hi All: I’m building a new Bind 9.7.1-P2 slave server and am taking an
opportunity to review my conf files.
I have a number of zones on the primary that all point to the same zone
configuration file. On my slave server, is there any way to configure
named.conf so that multiple zones are all “aliased” to the same zone
config?
Previously, I was using a basic slave config statement for each zone:
zone "domain.com" { type slave; file "domain.com.zone"; masters {
192.168.0.1; }; };
but, it seems like a lot of unnecessary files are being created?
I thought about using the same file name for all the slave zones
statements in named.conf, but wouldn't that force the file to be
overwritten multiple times for no reason?
How often does the file change? If the answer is "not often" then a
little file system churn is harmless.
IME the best way to do this on a Unix'y system is to use hard links.
That way if you ever need to change one of them to be its own file it's
trivial to do so. Also IME, BIND doesn't react well to having multiple
slave zones sharing the same file, but that may have improved in more
recent versions, I haven't tried it for a couple of years now.
hth,
Doug
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
multiple slave zones pointing to same file?
Hi All: I’m building a new Bind 9.7.1-P2 slave server and am taking an
opportunity to review my conf files.
I have a number of zones on the primary that all point to the same zone
configuration file. On my slave server, is there any way to configure
named.conf so that multiple zones are all “aliased” to the same zone config?
Previously, I was using a basic slave config statement for each zone:
zone "domain.com" { type slave; file "domain.com.zone"; masters {
192.168.0.1; }; };
but, it seems like a lot of unnecessary files are being created?
I thought about using the same file name for all the slave zones statements
in named.conf, but wouldn't that force the file to be overwritten multiple
times for no reason?
TIA
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Force Bind caching resolver to always obey DNSSSEC
On 10/02/2010 10:01 AM, lst_ho...@kwsoft.de wrote: So the problem are not resolvers unaware of DNSSEC but resolvers with inappropriate defaults or configured wrong by accident. Additionally this problem is not easy detectable as it can occur far downstream. So i would say it is a valid concern for network operators to make it possibe to force obeying DNSSEC at the border. The problem is that if, as some people expect, DNSSEC resolution eventually gets pushed down into "thick" client resolvers, then these resolvers need a way to tell the upstream cache "just cache, don't check". This, as well as debugging, is what +cd is for (see 3.2.2. of RFC 4033). Any "ignore +cd" config would have to be I think quite complex to avoid breaking this paradigm - probably an ACL. I understand why you want this, but enabling such a feature (if it existed, which it doesn't) could have adverse effects too. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Bind won't start: /etc/named.conf
What does the logs say?
Is the server chrooted or not?
And I think you want to use "type slave;" for that zone, if this is a secondary
server.
-Original Message-
From: Dotan Cohen [mailto:dotanco...@gmail.com]
Sent: Wednesday, September 29, 2010 12:53 AM
To: Imri Zvik
Cc: bind-users@lists.isc.org
Subject: Re: Bind won't start: /etc/named.conf
On Tue, Sep 28, 2010 at 23:49, Imri Zvik wrote:
> What are you trying to achieve? An empty named.conf file means named will
> use defaults for everything, and will probably just work out-of-the-box (as
> a simple resolver) so you should give more information about the goal and
> problem (including log entries, troubleshooting data etc.).
>
The goal is to for the server to be the second name server for a FQDN.
This is the relevant zone file:
[r...@venus ~]# cat /var/named/example.de.hosts
$ORIGIN example.de.
$TTL 86400
example.de. IN SOA example.de. foo.example.de. (
2010092801; Serial - increment me
10800
3600
604800
38400 )
IN NSns2.example.de.
ns2IN A x.x.x.168
This is the non-working named.conf that I pieced together from other
working file on other servers:
[r...@venus ~# cat /etc/named.conf
options {
directory "/etc";
pid-file "/var/run/named/named.pid";
listen-on {
any;
};
};
zone "." {
type hint;
file "/etc/db.cache";
};
zone "example.de" {
type master;
file "/var/named/example.de.hosts";
};
--
Dotan Cohen
http://gibberish.co.il
http://what-is-what.com
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Auto signing & ARM
On 10/01/2010 09:59 PM, Tony Finch wrote:
I haven't seen any answers to Timothe's questions below, though I
have been keeping an eye out for them. The documentation in this area
is a bit thin...
A few comments based on what I've observed.
Consider this configuration snippet:
View "internal" in { key-directory "/..." ... } zone
"xx.example.net" in { auto-dnssec maintain; type master; file ...
allow-transfer ... update policy { grant ... } }
I run (This is a test, /dev/urandom isn't used in real life)
dnssec-keygen -q -a NSEC3RSASHA1 -b 1024 -P now -A +3mo -r
/dev/urandom -K /... xx.example.net.
I get a Kxx.example.net+... file with all the right permissions.
Now, according to the ARM:
"4.9.5 DNSKEY rollovers via UPDATE It is possible to perform key
rollovers via dynamic update. You need to add the K* files ...
But: if I DON'T add the keys by dynamic update, but instead issue
an rndc sign xx.example.net in internal
The new key shows up in the zone. As expected, nothing is signed.
So, it seems that it is NOT necessary to insert the DNSKEY RRs via
dynamic update. Either dynamic update or rndc wakes up named and
causes a scan of the keys directory.
Note the "it is possible to".
In bind 9.6, you could only perform a key rollover by inserting the
DNSKEY via dynamic update. The process was a bit awkward for ZSK rollover:
1. Generate the new key
2. Insert the public DNSKEY via DDNS; do NOT add the private key to
the key-directory
3. Wait the required time for the old DNSKEY to be flushed from caches
4. In quick succession:
* add the new private key to key-directory
* remove the old private key from key-directory
5. Wait until bind has incrementally resigned the zone, plus cache
expiry time
6. Use DDNS to remove the old key
Note, no "rndc reload" is required; bind checks for the private key for
each DNSKEY it has on each signing batch.
Bind 9.7 essentially adds two things:
1. Key lifetime data to the private key files
2. An "rndc sign" command, for doing the initial signing
1) Before I decide whether to rely on it, is this a bug or a
feature? Dynamic update is a bit less work - but avoids having the
control channel open beyond the local host. So there are
trade-offs.
Personally, I think the key lifetime stuff in bind 9.7 is far superior
to using DDNS of DNSKEY.
In the same area of the ARM, the 5011 section seems to be a good
way to let the slave servers learn about key changes. The section
talks about dnssec-signzone -S as the way to trigger distribution.
2) I would expect that a key to a "dnssec-auto maintain" zone via
the dynamic update/rndc sign route would also satisfy the 5011
requirements. Is that correct?
I don't follow I'm afraid.
Slave servers don't need/have the keys; they can't sign the zone, and
don't verify it either because they're authoritative.
3) If dnssec-revoke or dnssec-settime are invoked, I assume that
rndc sign would trigger publication. If one would rather do
everything with dynamic update, what's the simplest transaction
that will trigger Re-scanning the changed key? Do I have to read
the key file& insert the key?
Well, the dynamic update to add/remove a DNSKEY will happen instantly.
Bind will not sign with it until it a) does a scheduled incremental
resign and b) sees the private key in the key-directory.
Note that bind will NOT stop you removing the final DNSKEY from the
zone, or stop you removing the ZSK leaving only the KSK.
In bind 9.7 at least, bind seems to be smart enough to defer removal of
the DNSKEY until any corresponding signatures have been removed, IIRC.
What this means is:
* if you accidentially remove the ZSK, there will be a CPU spike as
the KSK is used to resign the zone, and then the ZSK will be removed.
You stand a reasonable chance of this causing you problems of course -
cached RRSIG records without the corresponding DNSKEY cached will fail
to validate until their TTL expires
* if you accidentally remove the KSK, obviously it will all blow up.
That leaves the DS records for internally delegated zones. As
best I can tell, I still need to find the parent zone and insert
them via dynamic update. But: in the case where the parent zone is
served by the same view in the same server, named has everything it
needs to autogenerate DS record(s) when a DNSKEY is published and
install it in the parent. Well, maybe which hash type(s) are
desired, but that would be easy to put in a .conf file...
4) Shouldn't named handle this?
Perhaps, perhaps not. It does not thought.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Force Bind caching resolver to always obey DNSSSEC
Zitat von Barry Margolin : In article , lst_ho...@kwsoft.de wrote: Zitat von Alan Clegg : > On 10/1/2010 4:50 PM, lst_ho...@kwsoft.de wrote: > >> Sorry for being unclear. We want the SERVFAIL as it should be for >> invalid DNSSEC data *in all cases* eg. even if a client ask with the >> cdflag (checking disable) set. > > CD means "don't check", so you can't by definition. > > AlanC > That i was afraid of. It's a pitty that there is no way to save the downstream clients from stupid resolvers/downstream caches. Since CD is not set by default, a "stupid resolver" that doesn't know about DNSSEC won't set it. Someone has to go out of their way to request this behavior. I have detected this because we have a internal Bind 9.4 act as caching resolver forwarding to our border Bind 9.7 which is also a caching resolver and has DNSSEC enabled. If the internal Bind 9.4 is not explicitely configured to use DNSSEC (dnssec-enable yes; dnssec validation yes;) it will set CD and therefore by default makes the DNSSEC on the border useless. So the problem are not resolvers unaware of DNSSEC but resolvers with inappropriate defaults or configured wrong by accident. Additionally this problem is not easy detectable as it can occur far downstream. So i would say it is a valid concern for network operators to make it possibe to force obeying DNSSEC at the border. Regards Andreas ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
