Re: About root zones
On 02.01.12 17:03, Barry Margolin wrote: >In that case, you probably shouldn't enable the option. I'm not even >suggesting that the option be on by default. > >Actually, does libresolv really use those other facilities? In article , Matus UHLAR - fantomas wrote: highly depends on configuration of host.conf or nsswitch.conf, but afaik hosts are preferred by default on most of systems. >gethostbyname() does, but BIND probably shouldn't use that, because it >loses data like TTLs. and that is one of reasons why BIND does not (and apparently even should not) use system libresolv and gethost* functions. On 03.01.12 09:37, Barry Margolin wrote: Are we talking about the same libresolv? I'm talking about functions like res_query(), which are very DNS-specific. They return the raw DNS reply data, including details like TTL. gethostbyname() is the function that uses nsswitch.conf. Yes, I've mistaken those two. However, it comes to another reason why BIND should not use system resolver: If someone messes it up (e.g. puts bad entry to /etc/hosts), it could mess up DNS. Replicating configuration errors to DNS may also break things. In fact, it may cause similar problems than Peter Andreev is trying to avoid. And it may cause them independantly on the nameserver used. -- 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. M$ Win's are shit, do not use it ! ___ 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: View-specific logging
* JINMEI Tatuya / 神明達哉: > At Mon, 02 Jan 2012 09:42:29 +, > Florian Weimer wrote: > >> I would like to switch on query logging for specific views only. Is >> this possible using BIND 9.7 (or any other BIND version, for that >> matter)? > > As far as I know it's not possible with any version of BIND 9 (and not > only for query logging but also for logging in general). Adding "querylog yes/no" to the view configuration doesn't look too hard because the query logging code already has got a pointer to the dns_view structure. A general per-view logging configuration is certainly more difficult to implement. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ 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
DNSSEC Next key event
Hi,
I have a question about DNSSEC and "Next key event".
I have created 4 keys (ZSK) in advance. Every key has an active period
of 3 month and are published 3 days before
activation time and inactivated 3 days after.
I have set the following options in named.conf
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
key-directory "/var/named/dyn/keys";
.
.
zone "domain.com" {
type master;
file "dyn/zone.domain.com";
update-policy local;
auto-dnssec maintain;
};
In earlier version of BIND (9.8.0-P4) I would see the following
messages in /var/log/messages when I reloaded BIND.
Dec 28 14:04:38 mumin named[18046]: zone domain.com/IN: next key event:
25-Feb-2012 13:30:00.000
The date and time for the next key event, in this case, would be the
publication time for the next key.
Now, in BIND version 9.8.1-P1, the following is reported in the
logfile.
--
Jan 5 07:39:33 mumin named[2320]: zone domain.com/IN: next key event:
05-Jan-2012 08:39:33.840
Jan 5 08:39:33 mumin named[2320]: zone domain.com/IN: next key event:
05-Jan-2012 09:39:33.842
Jan 5 09:39:33 mumin named[2320]: zone domain.com/IN: next key event:
05-Jan-2012 10:39:33.845
--
Next key event is every next hour and NOT when the "real" key change
occur.
Is this correct?
Per-Olof Axelsson
IT-Department
University of Borås, Sweden
___
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: DNSSEC and IXFR
Is it possible to update DNSSEC-signed domain, re-sign and generate small differencies to be transferred by IXFR? Does it apply with dynamic updates, and with manually configur4ed zones (via ixfr-from-differencies turned on)? On 25.11.11 17:18, Evan Hunt wrote: It works fine with dynamic updates, and as of 9.9.0 it will also work with manually configured zones that have inline-signing turned on. And for example, when a simple RR addition/deletion is issued, is a while zone re-signed or does just newly added record with proper NSEC records issued, so the change can be transferred as a very simple IXFR removing old NSEC and adding new record with tro NSEC's ? Or, is there something I don't understand correctlt about DNSSEC? -- 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. "To Boot or not to Boot, that's the question." [WD1270 Caviar] ___ 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
.IN Domain is DNSSEC enabled or not
Dear All, I am new to DNSSEC. I purchase a new domain especially for testing dnssec. When i ask my domain seller to put my DS key in .IN Domain, they say that .IN Domain is still not ready for this But as per my knowledge .IN is DNSSEC ready. I do the "dig @8.8.8.8 in. NS +dnssec" query, and it is showing the RRSIG record in the query answer. It this is sufficient to prove that .IN Domain is DNSSEC enabled or i have to check something else. Please don't print this e-mail until & unless you really need, it will save Trees on Planet Earth. Thanks n Regards, GAURAV KANSAL 9910118448 VoIP - 6259 Operation And Routing Unit NIC , NEW DELHI ___ 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
