Re: managed-keys vs trust-anchors
On Mon, Jan 02, 2023 at 07:33:46AM -0500, Bob McDonald wrote: > I've upgraded to bind 9.16.36. > > I went to the ISC site and picked up the bind.keys file. > > However, it is intended for use in bind 9.11 and contains the managed-keys > clause. This throws an error in the syslog messages during startup. It > appears to still function correctly. > > In the ARM for bind 9.16 it states that managed-keys clause is deprecated. > Replacing the managed-keys clause with the trust-anchors clause seems to > fix the issue. In the file itself it states the following: > > # This file is NOT expected to be user-configured. > > Perhaps I've missed something. If not, the documentation needs to be a bit > more clear on this. Would it be helpful to have a version of the bind.keys > file for bind 9.16 and above? Thanks for bringing this to our attention. It's no longer necessary to get the bind.keys file from the ISC website. We've updated the site to remove the downloadable version, and just put some explanatory text there instead. The bind.keys file was originally put there for reasons that aren't really applicable anymore; you can safely rely on the one that's compiled in to named now. Some background on this can be found in the discussion at https://www.mail-archive.com/bind-users@lists.isc.org/msg31664.html. (And, if for some odd reason you really do need to download a new copy of bind.keys instead of updating BIND, you can pull it from the source tree: https://gitlab.isc.org/isc-projects/bind9/-/blob/main/bind.keys.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: managed-keys vs trust-anchors
On Wed, Jan 04, 2023 at 03:25:10PM -0500, Bob McDonald wrote: > Thanks Evan and Ondrej. I'll let the folks at FreeBSD know also. Their > bind packages still include that file. The file itself is harmless. But we used to say it was best practice to check for updates at the ISC website before turning on DNSSEC validation, and we no longer consider that to be worthwhile advice. Just keep your packages up to date and you'll be fine. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion yes/no?
On Tue, Jan 24, 2023 at 04:48:34PM -, David Carvalho via bind-users wrote: > Hello. > > I hope someone could help to understand the following. > > I have "my.domain.pt" and a master and slave server for the "my" part. I > have been using "recursion yes" in both named.conf, as I want them to be > both authoritative and cache for my clients. > > Last week I migrated my slave DNS server to version 9.16 and only today, > after having issues with the primary server migration, I realized that for > most queries, my slave DNS does not answer the "ADDITIONAL SECTION" unless I > specify "+norec" with the dig command. You didn't mention what version you were upgrading from, but I guess 9.11, because the default setting of "minimal-responses" was changed in 9.12. It used to default to "no", but it now defaults to "no-auth-recursive". From the ARM: minimal-responses takes one of four values: - no: the server is as complete as possible when generating responses. - yes: the server only adds records to the authority and additional sections when such records are required by the DNS protocol (for example, when returning delegations or negative responses). This provides the best server performance but may result in more client queries. - no-auth: the server omits records from the authority section except when they are required, but it may still add records to the additional section. - no-auth-recursive: the same as no-auth when recursion is requested in the query (RD=1), or the same as no if recursion is not requested. no-auth and no-auth-recursive are useful when answering stub clients, which usually ignore the authority section. no-auth-recursive is meant for use in mixed-mode servers that handle both authoritative and recursive queries. So when recursion is requested in the query, the server omits the NS records from the authority section, and if there's no NS records then there won't need to be corresponding A or records in the additional section. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion yes/no?
On Wed, Jan 25, 2023 at 10:23:16AM -, David Carvalho wrote: > Will there be any inconvenient setting minimal-responses to no? Having > that default behaviour when using "dig" can be useful. No, it's quite harmless. Minimal-repsonses saves a bit of time when processing a query, but unless your server gets an overwhelming amount of traffic you won't notice it. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rpz testing -> shut down hung fetch while resolving
On Thu, Jan 26, 2023 at 07:03:37PM +0100, Havard Eidnes via bind-users wrote: > Hi, > > I recently made an upgrade of BIND to version 9.18.11 on our > resolver cluster, following the recent announcement. Shortly > thereafter I received reports that the validation that lookups of > "known entries" in our quite small RPZ feed (it's around 1MB > on-disk) no longer succeeds as expected, but instead take a long > time, finally gives SRVFAIL to the client, and associated with > this we get this log message: > > Jan 26 18:41:27 xxx-res named[6179]: shut down hung fetch while resolving > 'known-rpz-entry.no/A' This usually means there's a circular dependency somewhere in the resolution or validation process. For example, we can't resolve a name without looking up the address of a name server, but that lookup can't succeed until the original name is resolved. The two lookups will wait on each other for ten seconds, and then the whole query times out and issues that log message. The log message is new in 9.18, but the 10-second delay and SERVFAIL response would probably have happened in earlier releases as well. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Converting between zone file formats
On Mon, Jan 30, 2023 at 11:11:03AM +0100, Havard Eidnes via bind-users wrote: > You didn't answer, though, whether the 9.16 named-checkzone will > be able to read & correctly interpret the binary zone files 9.18 > stores in the file system, or whether there is some other and > more preferable way to accomplish what I want, either with 9.18 > itself or otherwise. It should, the raw file format hasn't changed. (There used to be a format called "map" that was incompatible between versions, but you're not using that, and it's been removed from BIND now anyway.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RPZ zone response delay time ?
On Fri, Apr 07, 2023 at 05:27:38PM +0100, Jason Vas Dias wrote: > I will put something like this as a patch into MY named, I just > wondered if there'd be any interest in adding such a > 'DelayRPZResponse' NamedConf option for the standard BIND9 release. You can put in a feature request at https://gitlab.isc.org/isc-projects/bind9, and if you submit a patch we'll look at it, but I don't think this is the right way to do this. Why are you remapping to a blackholed address, instead of returning NXDOMAIN? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-validation?
On Wed, Apr 12, 2023 at 05:41:33PM +0100, David Carvalho via bind-users wrote: > After reverting my primary dns configuration, and asking my provider to > remove the DNSKEY, I had to include dnssec-validation no; otherwise it would > keep answering with SERVFAIL > > I noticed the server was constantly trying to reach top domain dns servers. > > Is this dnssec-validation mandatory? Any help appreciated. dnssec-validation can be set three ways: - "no" (validation is never performed) - "yes" (validation *may* be performed, but only if you have also configured a trust anchor in named.conf) - "auto" (validation will be performed using the standard root zone trust anchor, which is built in to BIND and doesn't need to be configured by hand). The default is "auto". When it's set to that, your server will query the root name servers in order to confirm that the automatically-configured trust anchor is correct. You said it was "trying to" reach the root, which suggests it wasn't succeeding? If so, that would explain why everything that wasn't locally authoritative would return SERVFAIL. Note that this is related to *recursive* queries, that is, queries for zones that are not served by your secondary server. It should have nothing to do with whether your own domain is signed, or whether there's a DS record for it in the parent zone. My guess is, you had the authoritative configuration working fine (otherwise presumably dnssec-analyzer would've complained), but recursive isn't working. Unfortunately, since you haven't provided any configuration info or even the name of the domain you were trying to set up, I can't make any more educated guesses than that. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-validation?
On Thu, Apr 13, 2023 at 11:38:15AM +0100, David Carvalho wrote: > Problem number 1: Dnssec seems to be running on "di.ubi.pt", but > dnssec-validation still needs to be set to no; Will this cause troubles? > Dns2 is set to auto and runs fine. >From here, di.ubt.pt appears to be properly signed and everything's working from here. Turning off validation won't have any affect on that. Your only problem is with local recursive service. > Problem number 2: How can I avoid the key regeneration (using version > 9.16.23) every named restart? I'm not certain what you mean by key regeneration. Taking a stab in the dark: Check that the working directory for named is writable. If named can't write files, then it can't save trust anchor status across restarts and it has to reinitialize each time. If that doesn't turn out to be the problem, then can show me the relevant lines from your log file so I can see what you're referring to by "key regeneration"? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Question regarding delv and custom local trust anchor
On Thu, Jun 08, 2023 at 09:54:15AM -0400, Josh Kuo wrote:
> *$ delv -a right.key www.example.com <http://www.example.com>. A*;; broken
> trust chain resolving 'www.example.com/A/IN': 127.0.0.53#53
> ;; resolution failed: broken trust chain
The address 127.0.0.53 was the clue I needed to figure this out: I suspect
you're on linux, and it's using systemd-resolved as the local resolver.
When I tried delv on a system configured that way, it got a NOTIMP response
to its first query:
$ delv +cd +mtrace @127.0.0.53 www.isc.org
;; fetch: www.isc.org/A
;; sending packet to 127.0.0.53#53
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7870
;; flags: rd cd; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 8e31ae172137a02f
;; QUESTION SECTION:
;www.isc.org. IN A
;; received packet from 127.0.0.53#53
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 7870
;; flags: qr rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
; OPT=5: 05 07 08 0a 0d 0e 0f ("...")
; OPT=6: 01 02 04 ("...")
; OPT=7: 01 (".")
;; QUESTION SECTION:
;www.isc.org. IN A
;; NOTIMP unexpected RCODE resolving 'www.isc.org/A/IN': 127.0.0.53#53
;; resolution failed: SERVFAIL
So, I'm guessing systemd-resolved is choking on the EDNS COOKIE option.
This needs to be reported as a bug to the systemd maintainers. And, maybe
delv should have a +nocookie option.
In the meantime, the workaround is the one you found: point delv to a
resolver that implements EDNS correctly. It will validate the data it
receives, but it has to receive some.
The newest version of delv, in the BIND 9.19 development release, has
a 'delv +ns' option to do its own resolution internally, without needing
an external server to look up the data; that would also work.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Question regarding delv and custom local trust anchor
On Thu, Jun 08, 2023 at 07:57:12PM +, Evan Hunt wrote: > So, I'm guessing systemd-resolved is choking on the EDNS COOKIE option. > This needs to be reported as a bug to the systemd maintainers. And, maybe > delv should have a +nocookie option. Hmm, on further inspection, I was wrong about this - the COOKIE isn't the problem. It seems to be sending back NOTIMP if you specify the CD and DO bits (i.e., +cd and +dnssec) in the same query. I had added the +cd flag to the query because I was seeing SERVFAIL on a query for the .org DS record. I guessed that this was caused by an upstream validation problem, and I may have been right about that, but we can't bypass it with +cd because of this NOTIMP bug. So... I'm not sure what the specific problem is now, but the general problem does appear to be systemd-resolved. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Deprecation notice for BIND 9.20+: "dialup", "heartbeat-interval"
Hello, In line with ISC's deprecation policy, I am notifying the mailing list of our intent to deprecate the "dialup" and "heartbeat-interval" options in named. These options concentrate zone maintenance operations, such as zone transfers between primary and secondary servers, into clusters for the benefit of servers that only have intermittent connectivity to the internet. This is no longer a common enough scenario to justify the added code complexity. They will be deprecated as of BIND 9.20 and removed in BIND 9.22. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: in-view RPZ definitions
On Fri, Nov 10, 2023 at 05:24:59PM -0500, Lannar Dean via bind-users wrote: > This is a continuation of a very old thread from this mailing list found > here: > https://groups.google.com/g/comp.protocols.dns.bind/c/nAHtXSDcDl4?pli=1 > > It appears that what I'm attempting to do did not work at the time of this > thread 8 years ago, but I'm wondering if anything has changed by now. Many things have, but not this particular thing yet. To explain the problem, each view has an "RPZ summary database" which is an index of all the rules in the response-policy zones configured for that view. It makes it possible to determine quickly which policy zone or zones have matching rules for a query; that way we don't have to waste time trying the query against *all* of the policy zones. The summary database is populated by the policy zone when it's loaded. In your example, zone cf1 was in view1, so it sent its summary information to view1. It doesn't know that it's also in view2. I've been thinking for a while about the best way to address this, and there might be some news coming in the not-too-distant future, but I don't have a good solution for you right now, sorry. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Deprecation notice for BIND 9: "resolver-nonbackoff-tries", "resolver-retry-interval"
Hello, In line with ISC's deprecation policy, I am notifying the mailing list of our intent to deprecate the "resolver-nonbackoff-tries" and "resolver-retry-interval" options in named. These options fine-tune query retry behavior in the resolver for testing purposes. They are not thought to be useful in a production environment, and we know of no operators using them. (Please let us know if this is incorrect!) Our plan is to mark these options as deprecated in BIND 9.16 and 9.18, and to remove them as of BIND 9.20. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Deprecation notice for BIND 9: "resolver-nonbackoff-tries", "resolver-retry-interval"
On Wed, Dec 06, 2023 at 04:05:03PM -0800, Fred Morris wrote: > They don't seem well documented. Indeed they are not! > I say go ahead, if nothing else consider it a "scream test". But can you > take a moment and tell us which stakeholder group(s) you think you're > optimizing for, why, and how? In this case, merely optimizing for the number of things we on the BIND development team need to test and maintain. I really don't think anyone's using these knobs, so they might as well not be there. They were added during the development process for serve-stale, which came to us originally as a third-party contributed patch. I suspect they were used by the contributors for testing, but nobody on our team ever did, or gathered any of the data that would be needed to properly document them. So they really should have been stripped out of the patch before it was merged. You do raise a good point - there may be reasons for different sites to want to teak these settings. Iif so, though, they we should probably add the tuning to named judiciously, after a proper research and data-gathering process, instead just accidentally leaving it there. :) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Deprecated DSCP support
On Thu, Feb 29, 2024 at 10:34:42AM +0100, Borja Marcos wrote: > But bear in mind that this is only guaranteed to work inside your > network/ASN. It’s not unusual to scrub DSCP at the network border. Same problem would also apply to DSCP values set internally by named, of course. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND statistics
On Mon, Aug 26, 2024 at 06:05:19PM +0200, Havard Eidnes via bind-users wrote: > Thanks. I found it, and it's more than a little embarassing. > > This is what you get when not building with --with-libxml2: an > "un-rendered" xsl file as a result, in essence just the content > of bin/named/xsl.c. And this happened because I wasn't paying > attention to what options were turned on by default for the > package I was putting together. "Surely stats is on by default!" > Not so. (Well, I didn't even think it was optional.) Lesson > learned. It *is* on by default, if it can find libxml2. Does yours live in a nonstandard location? Perhaps, if libxml2 and libjson-c are both unavailable, we should disable statistics-channels in the configuration - at least that way the problem would've been easier to figure out. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: lists.isc.org rDNS failed, DNSSEC?
On Fri, Feb 24, 2012 at 04:48:14AM +, vinny_abe...@dell.com wrote: > I kind of had the same thought... If ISC had a DNS outage due to expired > signatures of a zone, what chance do I have in successfully deploying and > maintaining DNSSEC for my zones? Somewhat ironically, the part of ISC responsible for maintaining those particular reverse zones isn't using the latest ISC software to do it. DNSSEC has gotten *much* easier over the past few years. (I have half a dozen signed domains and I haven't had to think about them since I set the server up last April--it just works.) But ISC was one of the first adopters of DNSSEC, and at that time 'dnssec-signzone' was the only tool available. We're still using some of the scripts that were written at that time, because the world is full of broken things to fix, taking priority over things that mostly work. However, I believe the Ops department is planning to switch over to BIND 9.9 fairly soon, in order to take advantage of the new inline-signing feature (which in fact was largely developed at their behest). https://kb.isc.org/article/AA-00626/109/Inline-Signing-in-ISC-BIND-9.9.0-Examples.html -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: lists.isc.org rDNS failed, DNSSEC?
> I suppose there are different classes of failures; unfortunately on > the resolver, there is only one result, SERVFAIL, to cover all. It > would be better if there was a way to distinguish the "oops, admin > bungled DNSSEC" errors from the ones which are more likely to be > indicative of spoofing. I'd like to see an EDNS(0) option that returns a detailed explanation of how a SERVFAIL happened. (I intend to write that IETF draft when engineering work gets out of my way enough that I have time to do it.) But it won't help until clients learn how to request that option and do something useful with the result. > The hardest part of that might be to decide which is which. IME the > one that bites us most often is that of the expired RRSIG. If we > could log that but go ahead and accept the data, most of the pain > would stop. BIND has this: "dnssec-accept-expired yes;" Note that it opens you to replay attacks, but misconfigured zones are more common than replay attacks, for now anyway. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: RFC 6303 and bind 9.9.0
> Just for clarification, do I understand correctly that if none of the > empty zones described in RFC 6303 are set up explicitly in the bind 9.9.0 > configuration file, then bind 9.9.0 will process them as such anyway > using built-in generic zone processing rules? Yes. To expand a bit on Mark's answer, all of the namespaces covered by RFC 6303 have built-in empty zones in BIND 9.9, and these zones are activated by default in any view that supports recursion. No configuration should be necessary. If you want to set up reverse DNS for a private network in a nonroutable address space, you can go ahead and do so; zones that you configure override the built-in zones. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: BIND 9.9.0 is now available
On Fri, Mar 02, 2012 at 11:13:06AM +0100, Matus UHLAR - fantomas wrote: > > NXDOMAIN redirection is now possible. This enables a resolver > > to respond to a client with locally-configured information > > when a query would otherwise have gotten an answer of "no > > such domain". This allows a recursive nameserver to provide > > alternate suggestions for misspelled domain names. Note that > > names that are in DNSSEC-signed domains are exempted from > > this when validation is in use. [RT #23146] > > just by signing? so I can spare all our domains from being misused by > such shit just by signing them? Not entirely, but it'll help, yes. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
> According to the docs it should be possible to set NSEC3PARAM on the
> unsigned version when using inline-signer mode. The signing BIND 9.9
> should then decide to use NSEC3, which salt, opt-out, etc. based on this.
> I have tried this and could not get it to work. The only way to use NSEC3
> with the inline signer atm is to run 'rndc -nsec3param' once the zone has
> been configured. Any hints?
You should be able to use 'rndc signing -nsec3param' before the zone
is signed. It's working for me:
zone "example.nil" {
type master;
inline-signing yes;
auto-dnssec maintain;
file "example1.db";
};
$ rndc signing -nsec3param 1 0 10 BEEF example.nil
$ rndc signing -list example.nil
Pending NSEC3 chain 1 0 10 BEEF
$ dnssec-keygen -3 example.nil
Generating key pair.++
..++
Kexample.nil.+007+28952
$ dnssec-keygen -3fk example.nil
Generating key pair...+++
..+++
Kexample.nil.+007+04053
$ rndc loadkeys example.nil
$ sbin/rndc signing -list example.nil
Done signing with key 4053/NSEC3RSASHA1
Done signing with key 28952/NSEC3RSASHA1
$ dig @localhost +short nsec3param example.nil
1 0 10 BEEF
--
Evan Hunt -- each@isc.orggg
Internet Systema Consortium, Inc.
___
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: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
> So, I have to do this again, if the NSEC3PARAM changes (e.g. with a > different salt during ZSK rollover)? Or does auto-dnssec maintain take > care on the changed NSEC3PARAM? I'm not sure I understand the question; there's no requirement that you change the NSEC3 parameters during a key roll. However, whenever you do wish to change them, you can do so with 'rndc signing -nsec3param', and the chain will be updated automatically. (Also, if you want to switch to NSEC instead of NSEC3, you can use 'rndc signing -nsec3param none'.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
On Tue, Mar 06, 2012 at 05:52:05PM +0100, Axel Rau wrote: > As named is looking periodically for appearing/disappearing or changed > keys in the key directory, I supposed it would notice changes of > $INCLUDEd DS or NSEC3PARAM RR automagically and act upon. > > So my script has to do these 3 steps on changing NSEC3PARAM: > 1. create new NSEC3PARAM (replacing $INCLUDED file) > 2. increment SOA serial > 3. rndc signing -nsec3param myZone? No $INCLUDE file is necessary for this. If you were using auto-dnssec with a dynamic DNS zone in BIND 9.7 or higher, you could use 'nsupdate' to insert a new NSEC3PARAM record. This causes several things to happen: - a new NSEC3 chain is generated for the zone - the new NSEC3PARAM record is inserted - the old NSEC3PARAM record (if any) is removed - the old NSEC or NSEC3 chain is removed - the SOA serial number is incremented Now in BIND 9.9, if you're using auto-dnssec with either a dynamic DNS or an inline-signing zone, then you can do this same thing by running 'rndc signing -nsec3param' instead of 'nsupdate'. Your script that creates a new include file and bumps the SOA serial number is no longer needed for NSEC3PARAM updates. As for DS records, those are updated like any other data in the zone (i.e., use 'nsupdate' for dynamic DNS, or update your zone file and run 'rndc reload' for inline-signing zones). -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
On Wed, Mar 07, 2012 at 10:33:24AM +1100, Wolfgang Nagele wrote: > Nothing says so in the specs: http://tools.ietf.org/html/rfc5155#section-4 It does, actually: "The presence of an NSEC3PARAM RR at a zone apex indicates that the specified parameters may be used by authoritative servers to choose an appropriate set of NSEC3 RRs for negative responses." In other words, by putting NSEC3PARAM in place, you're telling your slaves that they can rely on the existence of a full and complete NSEC3 chain matching those parameters. If the zone isn't signed yet, or the NSEC3 chain isn't fully generated yet, then that could cause breakage. The way we work around this is by using a special private-type record (TYPE65534, by default) into the zone, which contains your intended NSEC3 parameters. After named has finished generating the chain, it removes the private record. (You could insert this record into the unsigned zone if you wanted to, and it would work, but using rndc is a lot easier.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
On Wed, Mar 07, 2012 at 09:30:06AM +0100, Marc Lampo wrote: > Switch from NSEC to NSEC3 !!! > This is a statement with potentially huge consequences, IMHO. I said "NSEC3 to NSEC", actually. As you noted, switching from NSEC to NSEC3 requires planning: if your domain uses a DNSKEY algorithm less than 7, you'll need to roll to a new algorithm first. However, any algorithm that supports NSEC3 also supports NSEC, so if you decide you don't want NSEC3 and want to revert, you can do so quite easily. I always recommend using 'dnssec-keygen -3' when generating keys, in order to keep one's options open, even though I *don't* recommend NSEC3 for most people. (It places additional computational burdens on both the recursive and authoritative servers, for benefits that are relatively limited if you're not a TLD operator.) I expect we'll switch to using -3 as the default in some future release. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
> It is not possible to configure NSEC3 as a default in named.conf (on a > per zone basis), is it? I would welcome such a feature. I considered it, but bogged down on issues like what to do if you have nsec3 parameters set a certain way in named.conf, then change them in the running zone, then restart your server--it will detect the mismatch, but does it restore the original nsec3 chain, or yield to the zone contents? Ultimately decided it was better to keep the nsec3 configuration in only one place, the zone itself. > I also find it a bit strange that BIND decides to go for NSEC, even when > the KSK and ZSK are configured with algorithm: 7 (NSEC3RSASHA1). I think the thing that's confusing there is the name "NSEC3RSASHA1". There's no difference between algorithm 7 and algorithm 5 (RSASHA1). The use of a new algorithm number for a previously-existing algorithm is sort of a signaling mechanism: it tells older resolvers (e.g., BIND 9.5 and earlier) that you're using a newer version of the DNSSEC specification than they're equipped to deal with . But it doesn't mean NSEC3 is required, or even expected. The use of "NSEC3" in the human-readable algorithm name is rather misleading (it certainly confused me at first). Later algorithms such as RSASHA256 also support NSEC3, but they don't say so in their names, which I think leads to less confusion around this point. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
> - use algo 7 with NSEC allows you to move to NSEC3 without much hassle > (but older resolvers won't validate your replies meanwhile) > > - use algo 5 with NSEC and you have to do a algorithm rollover first > when you want to move to NSEC3 (but meanwhile, older resolvers will > validate your replies). Yes, exactly. > Are there still any 'older' resolvers around? Maybe not... Fewer and fewer, and they mostly aren't using DNSSEC. (They can't validate the root zone, after all.) But after some discussion last year, we still felt it was too soon to update the default algorithm in dnssec-keygen. Maybe in 9.10. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Feature request for dig
On Tue, Mar 06, 2012 at 07:37:31PM -0800, Mark K. Pettit wrote: > Please add something to "dig" that replicates the behavior of BIND as > closely as possible with regards to the many queries it issues as part of > a DNSSEC-validing resolution. There's "dig +sigchase", but a) you have to enable it at compile time with "configure --enable-sigchase" and b) in its current state it's terrible and you really shouldn't use it. We do want to improve dig in this area, but haven't had time yet. For now, the best tool I'm aware of for this is "drill", which is part of Unbound (https://unbound.net). -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: "rndc reconfig" vs. "rndc reload"
> I was considering doing "rndc reconfig", followed by a "rndc reload > " for each of the new zones. > > Would this work? 'reconfig' reloads the configuration without reloading all of the zones, but if it sees that you've added or removed any zones in the config file, it will load or unload those. So, when you say "new zones" above, if you meant actually *new*, then it's not necessary to do a subsequent reload. But if you meant existing zones that have been updated, then I believe your approach would work. BIND 9.9.0 has improved reconfig time somewhat, you might try it if you have a chance. Used to be, reconfig would pause the system, then parse the config file and apply the necessary changes, then resume. In 9.9.0, it parses the config file *first*, and *then* pauses the system to apply the changes. If you have a really big config file due to a large number of zones, that can save a noticeable amount of downtime. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: BIND 9.8.2 is now available
> Looks like the release notes for 9.8.1 are in the 9.8.2 tarball. Yep, we've stopped including the release notes inside the BIND tarballs, but I missed removing them from one branch--oops. We noticed it over the weekend, and a new tarball should be up by tomorrow. (I'm just waiting for the person with the signing key to get me a new set of signatures.) Sorry about that, and thanks for the heads up. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: BIND 9.8.2 is now available
> In order to save me poring through lots of archives and posts for the answer > to a simple question: Are there any differences between 9.7x and 9.8x that > require a change in named.conf configuration? The bottom line is that if I > want to upgrade from 9.7 to 9.8, are there any "Gotchas" that I need to know > about? > > What I have in mind is something like the change in default recursive query > functionality that occurred between 9.3 and 9.4, not new features. If there > are, just let me know the area to research and I'll get the details myself. There were new configuration options added, but as far as I can recall, none of them were removed or changed in particularly dramatic ways. The 9.8.0 release notes covered all the feature changes between 9.7 and 9.8; you might want to review them: http://ftp.isc.org/isc/bind9/9.8.0/RELEASE-NOTES-BIND-9.8.html -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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
ISC BIND 9.8.2 followup announcement
A cosmetic flaw was found in BIND 9.8.2 after publication: the release notes for BIND 9.8.1 were inadvertedly left in the tarball. As this caused confusion among some users, ISC is re-publishing BIND 9.8.2 with the spurious files removed. Absolutely no other changes have been made to the release. As a result of this change, maintainers of distibutions which pull directly from ISC may need to update checksums for the BIND 9.8.2 tarball. No other users are likely to be affected. New tarball: SHA256 (bind-9.8.2.tar.gz) = 7f30faf98c59353d26eef40ce9049de91aa5bb003321edbba14eeed974beda71 SHA1 (bind-9.8.2.tar.gz) = e2c1230e65cb609624c21260e5508f6ec1bf0a8e MD5 (bind-9.8.2.tar.gz) = 4c47675e093f33b1fa70536afaf0cce6 Old tarball: SHA256 (bind-9.8.2.tar.gz) = 2ce26bf9fa36540920f9d1a526c48ce50474a3f3a0ac27c1138152869e1d2c7e SHA1 (bind-9.8.2.tar.gz) = 09f0b18bde0438186d6639f08c17db3b98e81c17 MD5 (bind-9.8.2.tar.gz) = 9d92bed18795a35ebe629f715cf41353 -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: ISC BIND 9.8.2 followup announcement
> fyi, DLZ external has been broken post 9.8.1p1. fails to compile with > an undefined reference to main. both for 9.8.2 and 9.9.0 Thanks for the heads-up. Please open a bug ticket at bind9-b...@isc.org, and include information about the OS you're building on. I expect this is going to turn out to be a quirk of your OS: it's supposed to be building a dynamically loadable shared object, but seems to be trying to build an executable binary instead. We'll need to fix it with a change to 'configure'. (For what it's worth, i.e. very little, it does work on all the platforms we routinely test.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Secondary Zone 'Raw' File format
> A new option was added in 9.9 to cache slave zones in 'raw' format rather
> than text format.
That's actually always been an option ("masterfile-format raw;") and is
recommended for servers with a lot of slave zones because it reduces
startup time considerably--it takes about half as long to load a zone
if you don't need to parse text.
What changed in 9.9 is that it's now the default behavior, and you have
to specify "masterfile-format text;" if you want to save a slave zone in
text format.
> Is there any specific documentation on what the format of this 'raw' format
> actually is?
It's just DNS wire format, not much different from what you'd see if
you ran a sniffer during a zone transfer. You can convert it to text
format to see what's in the file with:
named-checkzone -D -f raw
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: Secondary Zone 'Raw' File format
> The other things that changed in BIND 9.9 is that there is a new version > of the "raw" format (as in "-F raw=1" versus "-F raw=0" in named-checkzone, > q.v. its man page). You're right, I forgot that bit. > What was the motivation for that change? It's for inline signing. Raw format 1 has an extended header that includes the serial number of the zone from which it was generated. This lets us resynchronoize the unsigned and signed versions of an inline-signing zone, in the event that, for example, you update the original zone file and restart named. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Secondary Zone 'Raw' File format
> I understand as you say that its the wire format, but for info is it > proprietary or is it related to the message standards defined in RFC > 1035<http://www.zytrax.com/books/dns/apd/rfc1035.txt>. > or is it something else It's not exactly RFC 1035 wire format; it's just similar. There's no formal specification for raw format zone files. No part of BIND is proprietary: it's BSD-licensed, any vendor who wants to copy our file formats is free to do so. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Inline Signing does not update SOA?
> Ralph: There was a lot of discussion about this issue on the bind forum > around the first of the year. My recollection is that with inline-signing > enabled, stopping named, editing the zone file, and restarting named > isn't a supported method of updating zone data. That was unsupported in the first alpha release of the feature, but it should work now as long as the SOA serial is updated. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: [PATCH[ dig +do option
On Tue, May 08, 2012 at 11:03:54PM -0400, Paul Wouters wrote: > Please consider applying this patch, many simple souls like me will > appreciate it a lot :) Those who use +do as a shorthand for +domain won't. It'd be okay for the value == NULL case, though. (BTW, suggestions are best sent to bind-sugg...@isc.org.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: KSK stays published 3 days after delete time
> > key 22924 of framail.de has a delete date of 2012-05-07T14:55:02 set. > > It has been deleted from the repository at 2012-05-07T14:55:02.569706, > > but is still included by named 9.9.0 in the zone framail.de > > (as of 2012-05-10T19:51:32). > > To clarify: I'm using inline-signing. > The repository is the key-directory configured in named.conf. > "Deleted" means: My script deleted it. Named won't delete the key from the zone unless you explicitly tell it to do so. For all it knows, your key file may have been removed by mistake. The correct way to remove a key from your zone is to schedule it for deletion. If it already has a successor published, then you can schedule the event immediately: $ dnssec-settime -K -D now Kframail.de.+007+13245 $ rndc loadkeys framail.de The -D option says "the key should be deleted after the specified time", which in this case is "now". "rndc loadkeys" tells named to examine the keys in the repository and note any changes to the scheduled events. named will see that the specified KSK is scheduled for deletion, it will remove it from the DNSKEY RRset, and it will resign the DNSKEY RRset wth the remaining key(s). After that's happened, you can remove the key file from the repository if you wish. If you still have a copy of the key file, put it back and follow the above steps. Otherwise, I suggest resigning the zone from scratch with the remaining keys. (Update the SOA serial number in the unsigned zonefile to something higher than the current serial number in the signed zone; move .signed and .signed.jnl to some other location; restart named. A new signed zone should be generated with the correct keyset.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: KSK stays published 3 days after delete time
> That's what I mean with "key 22924 of framail.de has a delete date of > 2012-05-07T14:55:02 set". Okay. But you also said it was deleted from the repository at or before that time, and clarified that this meant your script had deleted it. It needs to remain in the repository until *after* all scheduled events have taken place. > I have "auto-dnssec maintain;" set and my understanding is, that named > does not require a rndc loadkeys to remove the key from the DNSKEY RRSET > if the delete time, set with dnssec-settime, has passed. > Is this wrong? No, that's correct. "rndc loadkeys" is only necessary when you want to change timing on a key and have named notice the change immediately. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Bind9.9.1 Dependences
> How can I find out which Unix files/libraries bind requires before I do > the compile? "configure" will complain if you're missing anything critical. BIND 9 has relatively few dependencies other than a C compiler and POSIX-compliant system libraries. You need openssl if you want to use crypto; libxml2 if you want XML-based statistics; perl if you want to run the tests, and some of the tests specifically want Net::DNS. I can't think of anything else, offhand. (I'm assuming you mean BIND 9. BIND 10 has a longer list.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Dig fails to validate signature chains of TLD zones
On Wed, May 30, 2012 at 06:35:56PM +0400, Nikolay Shaplov wrote: > I am trying to validate DNSSEC signature of top level zone using dig. "dig +sigchase" is known to have serious flaws (that's why it's not compiled in to BIND 9 by default). Our long-term plan has been to rewrite it completely. So far other work has always had higher priority, so it hasn't happened yet, but it will. In the meantime (much as it pains me to admit to having been outclassed :)), the best command-line tool I'm aware of for validating signatures is "drill", which ships as part of Unbound (http://nlnetlabs.nl). -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Default Options
>Is there a command for bind that will list all Options default names and >settings in named.conf? >Might be helpful in understanding why bind is acting a certin way. Not really... if you download and build source, there's a tool that will print all the supported options (bin/tests/cfg_test --named --grammar) but it doesn't print the default settings. But, if you've downloaded the source anyway, the defaults for nearly every option are set in bin/named/config.c -- scroll down to where it says "default configuration" and read from there. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Corrupted zone files on 9.9.1 slave, temp files with text contents...
> What have I done wrong or not done correctly following the installation? This is discussed in the release notes for BIND 9.9. The default masterfile format for slave zones is now "raw" instead of "text". When you upgrade your server, it will try to load the zones using raw format. Since they were in text format, it will fail; it will then retransfer the zones from their master servers, and dump them again in raw format. The old text files get renamed to db-X, and can be safely removed. If you still want the local backups of your slave zones to be in text format, you can specify that in named.conf by setting "masterfile-format text;" in each of the zones. But, raw zones load from disk twice as fast as text, so personally, I'd just leave it the way it is. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Verify raw data within slaves on 9.9.x
> However - I guess its a little less efficient than the new default 'raw' > mode, especially for large zones. More than a little. Raw zonefiles load in about half the time it takes to parse the equivalent text. The delay only becomes really noticeable when you have big zones, or a lot of small ones, but it's always there. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: bind dies with assertion failure
I can't answer for RedHat, but this bug fix was included in BIND 9.8.2. 3284. [bug] Address race conditions with the handling of rbtnode.deadlink. [RT #27738] On Mon, Jul 02, 2012 at 05:40:51PM -0500, Oscar Ricardo Silva wrote: > I may have missed something but has this been patched in a 9.8.x version > of BIND? According to the 9.9.0 release notes this has been addressed > but just wondering about the availability for other vulnerable versions. > Also, is there a known trigger? > > The reason I'm running is that we're currently running the stock version > of BIND available with RHEL6. It's their policy to backport patches and > if there's a patch available then they may apply it faster rather than > deploying a new version. > > >It is a known issue, and is indeed a bug. We're working on it already, so > >stay tuned. > > > >--Michael > > > >On Feb 14, 2012, at 12:44 PM, Alex wrote: > > > >>>Hi, > >>> > >>>I have a fedora16 x86_64 box and named keeps dying with an assertion > >>failure: > >>> > >>>14-Feb-2012 13:24:41.137 general: critical: rbtdb.c:1619: > >>>INSIST(!((void *)((node)->deadlink.prev) != (void *)(-1))) failed > >>>14-Feb-2012 13:24:41.137 general: critical: exiting (due to assertion > >>failure) > >>> > >>>This is bind-9.8.2-0.2.rc1.fc16.x86_64. Is this a known issue? Is this > >>>indeed a bug or perhaps something otherwise wrong with the server? > >>> > >>>How can I troubleshoot this further? > >>> > >>>Thanks, > >>>Alex -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: bind dies with assertion failure
On Mon, Jul 02, 2012 at 07:16:40PM -0500, Oscar Ricardo Silva wrote: > I *THINK* I found the reason for why we're exposed to this bug ... It > would appear that Redhat based their BIND package on 9.8.2rc1. Guess > where the patch for this bug was applied? 9.8.2rc2. Sigh. It wouldn't be the first time someone has produced a binary package using a release candidate (or even alpha or beta) version of the code instead of waiting for a final release, and doubtless it won't be the last either, but I think I can speak for the entire BIND 9 development team when I say: "that really isn't a good idea; please don't do that anymore." If you're in a position to download and build source, the latest release of 9.8.x is at https://www.isc.org/software/bind/983-p1 and new releases are announced on this mailing list when they occur. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: named-checkconf view in error message?
On Tue, Jul 03, 2012 at 10:54:19PM +, Jack Tavares wrote: > If I run named-checkconf -z to check zones in my config, it will > report on success or failure of each zone, but will not specify which view. > > If a zone name exists in more than one view, it will not indicate in which > view > the failing zone is in. > > This seems like this would be good information to have. > Can I make a request to add that info to the output if possible. The best place for this kind of suggestion is bind-sugg...@isc.org, but don't worry about it, I'll forward this along for you. It's a good idea. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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 - NSEC3 - name.c:1715: INSIST(nlabels == name->labels) failed
On Fri, Jul 06, 2012 at 12:18:10PM -0300, Noel Rocha wrote: > I have this error in my bind9(9.7.0 - last version for ubuntu 10.04 LTS): That's a very old version, and I'm fairly sure this bug has been fixed. If you're in a position where you can ditch the packaged version and build BIND from scratch, you can get newer versions from our website at https://www.isc.org. (If you can't do that, then I would have to suggest taking it up with Ubuntu -- if it's long-term-support release and hasn't reached end of life, then it ought to be tracking the 9.7.x releases; we're up to 9.7.6-P1.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Listen-On and Ipv6
> If no listen-on statement is included, will requests be processed > and logged? If no listen-on-v6 statement is specified, named will not listen on IPv6 interfaces. If it receives a type- query over IPv4, though, it will answer it. (I don't recommend using it, but in the interest of completeness, I will mention that there's a compile-time option that can be turned on that makes it possible to alter this behavior: configure --enable-filter-aaaa). -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: check-names via command line
> >Well, I have to take that back. As far as I can see the -k option of > >named-checkzone has no effect at all, despite the man page, at least > >with BIND 9.8.3-P1. > > > Thank you. Maybe this will be fixed? > > It would be great to have named-checkzone be an authoritative tool as > far as zone: Syntax, rules and other error checking goes. It works for me. What errors are you trying to check for that named-checkzone -k isn't finding? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Journal File Question
> The problem here is that a large portion of the zone file was > "accidentally" deleted. If you have a backup of the zone file from not too long ago (maybe a copy on a slave server?), then that plus the journal file could be enough to get all the data back. The journal will usually contain records of many updates, typically back to your last "rndc freeze". As long as you have a zone file that has a serial number recorded in the journal file, it'll be able to start from there and bring the file up to date. But if you have no backups, or if the backup is from before the journal file was last purged, then there's not much you can do. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Multi-master DNS with Bind
> Hi, > > Looking to find information as to whether I can set up bind for > multi-master DNS. I want to be able to update DNS records via any or more > than one nameserver in the domain and have the records updated and > propagated regardless if the "master" is available. Is this supported or > are there ways to make this work with bind? Not at this time. We've discussed the subject at some length and it may appear in a future release, but it's not on the near-term roadmap. BIND 9 does support update forwarding (i.e., slaves receiving updates and passing them on to the master), but that doesn't sound like what you're looking for. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Multi-master DNS with Bind
> > Not at this time. We've discussed the subject at some length and it > > may appear in a future release, but it's not on the near-term roadmap. > > Couldn't this be done with DLZ? DLZ is a mechanism by which it could be done, but as far as I'm aware no one has done it. You'd need a database that did active data replication on the backend, and a DLZ driver for that database which supported dynamic updates. (The DLZ API introduced in BIND 9.8 has support for those, but most existing DLZ drivers are still using the older API.) I wouldn't want to do it that way, though; DLZ's too slow. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Listen-on per view?
> Is it?possible?to tell each view to listen on certain interfaces? I know > Listen-on is in general options so i was wondering if views have > something similar. No, but you should be able to get the same result with "match-destinations". -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: rndc signing -nsec3param
On Sun, Aug 12, 2012 at 01:17:11AM +0800, GS Bryan wrote:
> looks like this: 'rndc signing -nsec3param 1 0 10 example.com'
> means:-
> - SHA-1 is used for hashing.
> - opt-out is turned off.
> - iteration is done 10 times.
> - the is the salt.
> Am I right? So what kind of command I should enter if I were to use
> SHA-256 for hashing, opt-out is turned on, iteration is done 15 times,
> and salt is FF?
> Does it looks like this: 'rndc signing -nsec3param 2 1 15 FF example.com'?
SHA-256 is not (yet?) a defined hash algorithm for NSEC3, so the "hash"
argument can only currently be set to 1. (It would be nice if you could
just omit it completely, since it's invariant, but we may add other hashes
to NSEC3 in the future and had to allow for that.)
The "flags" field may someday contain more values than just opt-out, too,
but right now that's the only defined flag, and it's the low-order bit
in the field, which is to say 1. So you set opt-out by setting flags to
1, and you unset it by setting flags to 0.
There's a known bug with the "salt" field -- it's supposed to allow you
to omit the salt by using a hyphen ('-') instead of a salt, but that
doesn't work in "rndc signing -nsec3param". This will be be fixed
in 9.9.2.
The order and format of arguments given here precisely matches those in the
NSEC3PARAM RR type. For example right now .ORG has NSEC3PARAM set to:
org. 900 IN NSEC3PARAM 1 0 1 D399EAAB
To duplicate that you'd use "rndc signing -nsec3param 1 0 1 D399EAAB ".
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: playing with 9.9.2b1 and ECDSA
> Is automatic signing with ECDSA supposed to work yet? If you linked with an openssl that supports it (which you must have, or dnssec-signzone wouldn't have worked) then yes, automatic signing should work too. (If you don't mind, can you send this to bind9-b...@isc.org? Or I could forward it for you, your preference.) And, thank you -- I really appreciate beta testers. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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-signzone ignoring "-x" option?
> Does anyone use dnssec-signzone with -x? If so, can you check/tell me > your DNSKEY RRset? And if it works, could you reveal the full > commandline argument used, the bind version, and whether any pkcs#11 > provider was compiled in? I just tested it with "dnssec-signzone -Sx example.com" and "dnssec-signzone -x example.com", on 9.9.2 and 9.7.4, and it worked as expected in all cases. Were you signing your zone from scratch, or re-signing a zone that was already signed? If there was a pre-existing ZSK signature, the signing process might have left it in place. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: openldap, dlz and dynamic dns updates from isc-dhcpd
> My main question is about dynamic updates from the DHCP server. I > would like to know if bind 9.9 can update > an openldap DLZ with dynamic updates from a DHCP server. Given an openldap DLZ driver that can accept dynamic updates, yes. I'm not aware of such a DLZ driver existing yet, but there's no technical reason why it couldn't be written. > I've read about Andrew Tridgell's work on getting BIND to update DLZs > (http://jpmens.net/2011/01/21/bind-gets-a-new-updateable-dlz-driver-dlopen/). > > Can encryption be used to dynamically update BIND's DLZs, just as it > can if zone files are used? I'm not sure what you mean by "using encryption". -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: openldap, dlz and dynamic dns updates from isc-dhcpd
> Here's a possibly wrong assumption: there are BIND deployments that
> use openldap (or an RDBMS, or something else) rather than zone files
> to hold DNS mappings (name to ip address & vice versa), and these
> alternative backends are updated when the DHCP server hands out or
> revokes a lease.
> Is this so? If so, how is the DNS information updated?
There are two sorts of DLZ driver out there -- the older ones that don't
support dynamic update and have to be statically linked into the "named"
binary to work, and then newer ones like Andrew Tridgell's, which are
run-time loadable and can (if desired) be written to accept updates via
dynaamic DNS.
There *is* an LDAP DLZ driver, but it's an old-style driver so it
can't accept DDNS updates. You could probably write some kind of DHCP hook
that updated the LDAP data directly, *not* using dynamic DNS, but I don't
think that's what you were asking about. To use LDAP *and* accept DDNS
updates, you'd need a new-style DLZ driver that supported LDAP, which is
certainly possible, but I don't know whether anyone's done it yet. (I'm
guessing not, though; I think I would've heard.)
> > I'm not sure what you mean by "using encryption".
>
> :-) I'm not sure either. In DHCP config, within a zone { ... }
> block, there are key directives. It seems that BIND & DHCP
> can use a key to be sure of each other and the validity of DNS updates
> coming from the DHCP server. Am I on the right track? When I wrote
> 'encryption' this is what I was referring to.
Okay, you're talking about authentication using TSIG keys -- I thought
so, but wasn't quite sure. :)
There shouldn't be any conflict between that and DLZ.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: ACL per listening IP address ?
> I'm not very familiar with the concept of views but I wonder if the
> "match-client" statement might be the way to go.
It sounds like the one you're interested in is "match-destinations"
actually.
options {
listen-on port 53 { 128.83.185.40; 128.83.185.41; ; };
...
};
view monitor {
match-destinations { ; };
recursion no;
allow-query { localhost; };
zone "testzone" {
type master;
file "test.db";
};
};
view others {
match-destinations { any; };
recursion yes;
allow-recursion { ... };
...
};
Any queries sent to would then be routed into the "monitor"
view, and any queries sent to the public-facing addresses would go to
the "others" view.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: Improved SSL Error Logging [RT #29932]
> BIND 9.7.7, 9.8.4 and 9.9.2 have "improved" OpenSSL error logging.
> Unfortunately, our logs are now filling up with "RSA_verify failed"
> messages.
Yeah, oops, we made that one too noisy. You're not the first one
who's noticed. :/
> How does one go about tracking down the source of these failures and
> correcting them? (We are running OpenSSL 1.0.1c.)
In BIND9, in lib/dns/opensslrsa_link.c, change this:
return (dst__openssl_toresult2("RSA_verify",
DST_R_VERIFYFAILURE));
to this:
return (dst__openssl_toresult(DST_R_VERIFYFAILURE));
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: Lots of "RSA_verify failed" after upgrade to 9.7.7
> But not for 9.7, since 9.7 is EOL since november 2012. Correct? Yes, that's correct. If you're stuck on 9.7 for the time being, you can silence the RSA_verify warnings with the change I mentioned in http://www.mail-archive.com/bind-users@lists.isc.org/msg14747.html (It's not the fix we used for the maintenance release, but it'll serve.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Change in statistics format
On Thu, Nov 15, 2012 at 11:44:12AM -0500, John Miller wrote: > Hello everyone, > > When did BIND 9 switch over from the older The new stats counters were added in 9.5.0. They're in all currently- supported releases; the old format is fully deprecated now. Incidentally, that release also introduced an http statistics channel and XML stats reporting, which might be of interest to your monitoring software. (Note, though, in 9.9.3 we're going to introduce a newer better XML schema for statistics as a compile-time option, and it'll be standard in 9.10, so if they wanted to write code to parse our XML, they might want to know there'll be a few different schema versions in the field soon.) > Is this a tunable parameter? No. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Change in statistics format
> Looks like I'll have to update it for 9.10 tho, hope they updated the > schema number. Yes, we did. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Linux issue with make test failures, 9.9.2-P1
Jeff Earickson wrote: > The "make test" stuff is failing miserably for me on Linux (Redhat > 6.3, x64) with 9.9.2-P1: I'm pretty sure you haven't set up the local addresses the test servers need to run on. From the top of the bind9 tree, run the command: $ sudo sh bin/tests/system/ifconfig.sh up ...then run "make test" and you'll probably get better results. The ifconfig.sh command sets up loopback addresses 10.53.0.1 through 10.53.0.7. The system tests run servers on those addresses and make them talk to each other. Without addresses configured, about 90% of the tests will fail. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Linux issue with make test failures, 9.9.2-P1
> Yup, I knew all of that and that is what I have always done. This morning > I got things to work by skipping the -j option of gmake to do parallel > compiles, and the tests then worked. Neat! > Once I didn't do the parallel compile (-j2), the tests worked. But I did > not see any failures from a parallel compile either. Weird. We actually specify in the README that parallel compiles aren't supported, but it's been my experience that they usually do work, and when they've failed for me it's always been with an outright build failure rather than an apparently successful build that didn't work. You got lucky, I guess. Glad it's sorted out. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: auto-dnssec maintain: KSK being used as a ZSK as well?
> By setting dnssec-dnskey-kskonly, you are telling it to use the KSK as > a(mother) ZSK. You're thinking of "update-check-ksk". "dnssec-dnskey-kskonly" tells named not to use the ZSK when it signs the DNSKEY RRset, but it should still use the ZSK (and not the KSK) for all the other data in the zone. My guess is the ZSK is inaccessible (private key inactive, missing, or has permissions set so that named can't read it). If named has an active KSK it can work with, but no ZSK is available, then it'll use the KSK for all data rather than let the zone go insecure. Running "dnssec-settime -p all " on the ZSK will show you what the key timers are set to. If the key's Activation date is in the future or the Inactive date is in the past, that's the problem. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: set directory for "auto" key files
On Wed, Jan 09, 2013 at 03:59:51PM +, Tony Finch wrote:
> Chris Thompson wrote:
> > One slight niggling disadvantage is that you can't tell
> > named-checkzone / named-compilezone with the -j option where
> > to find the journal is it isn't in the default location.
>
> I submited a patch to add a -J option which addresses this problem.
> (RT #30958)
It will be included in BIND 9.10. (Thanks.)
Meantime, you can kluge around it by writing a script to symlink the
zone file and journal file into the expected relationship with one another,
then remove the symlinks after the checkzone/compilezone is finished.
Something like:
origin=$1 zonefile=$2 journal=$3 shift 3
ln -s $zonefile /tmp/db.$$
ln -s $journal /tmp/db.$$.jnl
named-checkzone "$@" -j $origin /tmp/db.$$
ret=$?
rm -f /tmp/db.$$ /tmp/db.$$.jnl
exit $ret
...or words to that effect.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: SOA "minimum" vs "negative ttl"
On Thu, Jan 24, 2013 at 01:05:33AM +, Jack Tavares wrote: > When a DNS update comes into to add or modify a record and bind > eventually re-writes the master file it will rearrange the SOA and add > comments (which is fine) but it labels > [...] > Is there a reason for this or is it just a hold over? Some of both, I think. RFC 2308 changed the semantics of the field, but not its name; it's still called "SOA minimum" even though it represents something else, and it's referenced that way in subsequent RFCs such as 4034. Also, IMHO, there's a pretty good chance that if we changed the comment from "minimum" to "ncache ttl", it'll turn out someone had a script that depended on the existing format. I don't mind breaking people's scripts if there's a compelling reason, but I'm not sure the benefit here is all that significant, so inertia wins this round. :) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: BIND 9.9.3b1 is now available
> >I have software that reads the stats channel. > > Me too. Took awhile to get right, I'd hate to see it break. :-( The plan is, it *will* break in 9.10, but not in 9.9 (unless you turn the new stats on with the configure option). I'd love it if you'd try it, actually, find out how hard it is to modify your tools to use the new schema, and send feedback. It may not be too painful; the new schema is simpler and flatter and should be easier to parse. And the XSL with Google Charts support is a major improvement over what went before. > >Please, if you have a new schema, put it on another URI so that software > >that wants the old schema gets it, and software that wants the new > >explicitly requests it. E.g. '/statistics/v3' > > Some sort of "API-like" deprecation would at least be cool... The schema includes a version number -- 2.2 for the old stats, 3.0 for the new ones. We increase the second digit when making changes that are backward compatible (i.e. adding new fields, not changing or removing existing ones), and the first digit when making changes that break compatibility. I'd been assuming the version field would be enough, but we can change the URI if needed. > But am I reading right? If I don't build with --enable-newstats, all my > monitoring and trending scripts will continue to chug happily along with > the old view? That's correct. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: rndc addzone|delzone: some questions
> 1. Is named 'deaf' during an `rndc addzone'? I don't think so, but I'm >finding it hard to determine definitely. I'm primarily concerned with >named being able to handle any NOTIFYs it gets. The addzone task (like several other rndc commands) will temporarily acquire exclusive control of the named process so nothing else can happen at the same time. I confess I don't know whether notifies that arrive during this window would be dropped or queued... but my guess is dropped. > 2. When I `rndc addzone ... type "slave"; ...' named immediately picks >that up, transfers the zone and creates the specified file. However, >`rndc delzone', while it drops the zone from named, does not remove >the zone file from the file system. Is that a bug or was that >implemented intentionally? > >It seems a bit illogical to me that the zone file isn't removed from >the file system, but perhaps I'm interpreting 'delzone' too strongly? :) Delzone just means delete the zone from named, not delete the zone file from the filesystem. (And I reckon we can do a good deal more harm by deleting files you wanted to keep than by leaving files for you to delete yourself...) > 3. If I direct `rndc addzone|delzone' to the same named instance from >multiple processes (from the same source IP address), is there any >danger of the .nzf file being corrupted? No. (Or, if so, it would be a serious flaw, and I haven't seen any bug reports about that.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: TKEY and zone transfer
On Tue, Jan 29, 2013 at 04:22:07PM +0800, Kent Tong wrote:
> I read that Bind9 supports using TKEY for zone transfers. However, I don't
> understand how the TKEY negotiation is triggered.
Huh. That is much harder than it ought to be (a fact I hadn't realized
until now, as I'd never had occasion to look closely at this feature until
you asked your question). I've just put in a bug report suggesting we
improve it in a future release.
For now, this is the best I can do for you... though quite honestly, I
think this approach is probably more trouble than it's worth; if it were
me, I'd just use conventional TSIG until there've been some improvements.
But if you really want to use TKEY, here you go, this formula worked for
me:
There's a program in the BIND 9 test suite that you can adapt
to your purposes if you're comfortable with C programming --
bind9/bin/tests/system/tkey/keycreate.c (also keydelete.c for removing
keys after they've been created). You'll need to modify the code to use
port 53 instead of port 5300, and to use different key material (see
below).
First, you need to create a DH (diffie-hellman) key for your server:
$ dnssec-keygen -T KEY -a DH -b 768 -n HOST server
Kserver.+002+32204
Note the key ID (in this example 32204). Put the resulting .key
and .private files into named's working directory, and configure
named.conf to reference that key:
options {
...
tkey-domain "server";
tkey-dhkey "server" 32204;
};
Also, generate a TSIG key to use for the initial TKEY negotiation.
The simplest way to generate TSIG keys is with ddns-confgen:
$ ddns-confgen -q -a hmac-md5 -k tkeyinit
key "tkeyinit" {
algorithm hmac-md5;
secret "RzLQq6b1oBN1QveexTf76g==";
};
Add that key information to your named.conf.
You'll need to copy the name and secret into keycreate.c and keydelete.c:
these written to be test programs; the key material is hard-coded into them.
At this point, you can create a diffie-hellman key for the client, and use
it with keycreate to negotiate a TSIG key with the server:
$ dnssec-keygen -T KEY -a DH -b 768 -n HOST client
Kclient.+002+11382
$ keycreate Kclient.+002+11382 negotiated-key
Knegotiated-key.server.+157+19753
$ cat Knegotiated-key.server.+157+19753.key
negotiated-key.server. IN KEY 512 3 157 MlNODIuzTrNMgSLRCFB1Iw==
The key generated by keycreate can then be used on the client side
to sign transfer requests:
key negotiated-key.server {
algorithm hmac-md5;
secret "MlNODIuzTrNMgSLRCFB1Iw==";
};
zone example.com {
type slave;
masters { 1.2.3.4 key negotiated-key.server };
...
};
...and that should work as long as the server side was configured to allow
transfers using the *initial* TSIG key that was used to create the
negotiated key -- not the negotiated key itself:
zone example.com {
type master;
allow-transfer { key tkeyinit; };
...
};
The transfer request to the server will be signed with the key
negotiated-key.server, not with tkeyinit. The server will still
allow it, though, because tkeyinit is the parent key of
negotiated-key.server. (Note, however, that transfers will also
be allowed for any request signed with tkeyinit, or with any other
key that was negotiated using tkeyinit. I don't know whether there's
a way to make the server accept only one specific negotiated key.)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: TKEY and zone transfer
On Wed, Jan 30, 2013 at 11:14:04AM +0800, Kent Tong wrote:
> Thanks for the kind and excellent replies! So, currently there is no way
> for the client to negotiate the key on-demand automatically?
I don't see a way, no.
There's a partially-implemented feature where negotiated keys can be dumped
to a file when named shuts down and restored when the it's restarted, so
in principle you could negotiate a key with a server once, and then it
would keep the key as long as necessary. But currently this only works
with GSSAPI keys, I believe.
> > zone example.com {
> > type slave;
> > masters { 1.2.3.4 key negotiated-key.server };
> > ...
> > };
>
> BTW, what is the difference between specifying the key in the "masters"
> setting and specifying the key in a server statement?
If you put it in the masters list then you could use different keys for
different purposes when talking to the same server. If it's in a server
statement, then that server always gets the same key.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: TKEY and zone transfer
> > Also, generate a TSIG key to use for the initial TKEY negotiation. > > I thought the point of TKEY was to upgrade from slow public key > authentication to fast secret key authentication, i.e. that you would > start off by authenticating the client with SIG(0). TKEY should work with SIG(0), but I don't have any code to show you that generates SIG(0)-signed TKEY requests -- keycreate.c in the test suite uses TSIG, so I adapted the recipe to that. (Unless some other DNS implementation provides a tool for this purpose? If you know of one, please let me know.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Selective resolution in a corporate environment
> IMHO (and I am really nobody) THIS IS WRONG! BAD BAD BAD! Your giving compa= > nies the ability to selective lie about DNS without the end user knowing it= Unless DNSSEC is in use, in which case the end user can figure it out, so RPZ doesn't bother lying. (I've wished before that there were some EDNS(0) options that could indicate "this answer has been changed due to local resolver policy" in a response, or "seriously: do not lie to me" in a request, but it's hard to see how there'd be any enforcement or verification mechanism for these, whereas DNSSEC already has all the crypto needed to get the job done.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: private trust anchor
On Sun, Feb 10, 2013 at 05:57:42PM -0500, Michael W. Lucas wrote: > Is there a way to set up a private trust anchor for internal-only > zones with BIND 9.9? > > I have some local and RFC1918 zones that I'd like to secure. It seems > I should be able to configure a private trust anchor and use that key > to sign these zones. > > I've found, related docs, like draft-jabley-dnssec-trust-anchor-06, > which has great gobs of theory, but nothing on how to actually do this > with BIND. > > Has anyone done this? Or is this just daft? In my experience the two aren't mutually exclusive, but yes, it does work. Create keys for your local zones, sign them, and put the KSKs into the resolver's named.conf in a "trusted-keys" statement. Then configure the zones as "type forward", with "forwarders" pointing to the authoritative server(s) for your zones. The resolver will then forward queries for those names to the authoritative servers, and validate the responses. (If those weren't enough bread crumbs to show you the way, I can expand on this.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: dns_journal_write_transaction on managed-keys-zone
> After introducing views in my BIND 9.9.2-rpz+rl.028.23-P1 configuration the
> log starts to report managed keys errors periodically. Deleting the files
> does not solve the issue.
>
> view "internal" {
> match-clients { internal_hosts; };
> recursion yes;
> include "/etc/bind/named.conf.default-zones";
> };
>
> view "external" {
> match-clients { any; };
> recursion no;
> rate-limit {
> responses-per-second 5;
> window 5;
> };
> include "/etc/bind/named.conf.local";
> };
I haven't seen this problem before. Can you share the rest of
your configuration with me? You can open a ticket by mailing
bind9-b...@isc.org.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: private trust anchor
> Type forward? Really? I didn't expect that to come from someone at ISC. D'oh, embarrassed now. > Use 'type stub' instead, with a masters statement rather than a > forwarders statement. Chris is correct, both options work, stub is better. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: IPv6 prefixes in ACLs
> Should I put a single entry for my /48 allocation or 16 /64 entries for > the nets I am currently using? Both ways work. > Does it make any difference for performance? Possibly, but I doubt you could measure it. (Unless you're using a really ancent version of BIND, in which case the shorter list is better.) > ::1/128 ; 2001:0db8:100::4/128; > > Is what you do for specific addresses? You don't need the /128. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: newstats XSL broken?
> I've applied that, and it does indeed look better, but not good enough :) > See screen shot [1]. No worries, though: I'll wait until you release > (and I'm more looking forward to your implementing the JSON suggestion I > sent over... ;-) That just means there's no data to graph yet. Send your server a few queries and try it again. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Master Zones and bind99
On Tue, Mar 12, 2013 at 03:10:20PM -0500, Martin McCormick wrote: > Since this is a slave, it appears to have fixed itself > by downloading all its zones again. What should we expect from a > master DNS? Should be fine. Slave zones use a new masterfile format by default. Some error messages the first time you load the server after upgrading to 9.9 are expected; thereafter they should go away. (This is in the release notes.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: DLZ $client% parameter segfault
> Thanks certainly blows up the possibility of doing native GeoDNS at the
> moment? Any chance I am overlooking a method which I could effectively
> get the clients address into a MySQL query with the current 9.9.2
> release?
It's not quite the same as %client%, but I suggest you take a look at
contrib/dlz/example/dlz_example.c, note the use of the clientinfo
structure in dlz_lookup(), and see if it's any use to you. You'd have
to hack the corresponding routine in the mysql DLZ driver.
Incidentally, native GeoIP support has been added as a feature in the
9.10 release -- you'll be able to use it to specify ACLs, e.g.,
"match-clients { geoip country US; };". I expect it to be published
in Q4 of this year.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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-signzone: warning: NSEC3 generation requested with no DNSKEY; ignoring
> dnssec-signzone -d /path/to/dsset -K /path/to/keys -3 00 -f > zone.signed -e +3024000 -j 1800 -o zone.edu -r /dev/urandom -S -T 12h > /path/to/input > > dnssec-signzone: warning: NSEC3 generation requested with no DNSKEY; > ignoring > Fetching ZSK 59544/RSASHA256 from key repository. > Fetching ZSK 29076/RSASHA256 from key repository. > Fetching KSK 0/RSASHA256 from key repository. > Fetching KSK 38074/RSASHA256 from key repository. > Verifying the zone using the following algorithms: RSASHA256. > Zone fully signed: > Algorithm: RSASHA256: KSKs: 1 active, 1 stand-by, 0 revoked > ZSKs: 1 active, 1 stand-by, 0 revoked > > Despite the warning that appears to be saying it's ignoring NSEC3 > generation, the signed output includes NSEC3 data: [...] > What exactly is this warning supposed to mean? The warning is spurious and has been fixed in 9.9.3. It was incorrectly checking to see whether there were any DNSKEY records in the zone *before* loading them from the key files. It should have been doing so afterward, obviously. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Views Question
> If the 'type' info in a zone statement determines master or slave, can
> you have 2 views in the same named.conf file, one with type master zones
> and the other with type slave zones?
There are a couple of ways to read this question, and the answer depends
on which way you intended it.
A query reaches a view, or not, depending on whether it matched an access
control list. Typically, clients from your internal subnet will reach the
internal view, and everyone else goes to the external view.
If you have an authoritative-only server, and it's master for one set of
zones and slave for a separate, disjoint set of zones, then you do *not*
want to divide them up into different views. Some clients would only
be able to see the masters and some would only be able to see the slaves;
it wouldn't make sense.
However, if what you're asking is "can I have two views that serve the
*same* zones, with one view slaving to the other", then the answer is yes.
I do this myself at home: my internal view provides recursive service for
my family, and also contains slaved copies of my external-facing zones.
You can use a TSIG key in the masters option (and, from BIND 9.9 onward, in
the also-notify option) to enable the two views to talk to one another so
that the slave can be updated when the master is. The configuration looks
something like this:
key external-key { [...] };
view internal {
match-clients { !key external-key; localhost; localnets; };
zone example.com {
type slave;
masters { localhost key external-key; };
};
};
view external {
match-clients { any; };
zone example.com {
type master;
also-notify { localhost; };
};
};
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: resolver, search command....
> dig myhost By default dig only uses fully qualified domain names. "dig +search" does what you want. > It would search for that host in path1 or path2 listed above.? It does > not, a +trace shows the resolver querying the root servers for myhost.? > So it appears the search command does not work in environment. > > [root@server1 # dig myhost +trace ...but "dig +trace" behaves completely differently, searching for the name from the root zone down and never touching the local resolver at all, so this would have queried the root server even if you'd used a FQDN. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Rate-Limit Question
On Fri, Jun 14, 2013 at 03:36:19PM +0100, Phil Mayers wrote: > It's not built into bind (yet). Correct. For the record, it'll be in 9.10.0 by default and 9.9.4 as a compile-time option (--enable-rrl). (Our usual policy is not to add substantial new features in maintenance releases like 9.9.4; making it a compile-time option that defaults to off is our way of tiptoeing around the rule.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Rate-Limit Question
> Or, I believe, you can pay for a BIND^w DNS-Co subscription and download > a version with the magic built in? This is also true. DNSco subscribers get first bite at the apple with this and several other features that will be in 9.10. (Primarily GeoIP support, DSCP, and some enhancements to DLZ.) > Or you can wait until some time in the future when it gets integrated > into the base BIND. About which see my previous message. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Rate-Limit Question
On Fri, Jun 14, 2013 at 01:10:47PM -0300, Carlos M. Martinez wrote: > thanks for the heads up. Do you have a estimated time of release for > 9.9.4 and 9.9.10 ? Every time I make predictions about dates, events conspire to make me wrong, but I'm *hoping* to have 9.9.4 out in early August. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: named in BIND 9.9.3-P1 needs libpkcs11.so ?
> This build of OpenSSL 1.0.1e was fully tested and passed all tests so I am > thinking > that an option to the build of bind is the issue here. Probably > "--with-pkcs11" . > > If I don't have that option am I totally shafted for DNSSEC ? You don't need --with-pkcs11 unless you're planning to use a cryptographic accelerator or hardware service module, and you'd have had to build a special version of OpenSSL for that. Remove it from the configure options and you should be fine. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: BIND + LDAP Backend
On Tue, Jul 02, 2013 at 05:22:15PM -1000, Stephan Fabel wrote: > All, > > sorry if this is a repeating theme here... we are interested in utilizing > LDAP as a backend to BIND. Google gives conflicting information on whether > this is possible/recommended/etc. and I couldn't find anything in the > release notes, which doesn't bode well I suppose... > > But anyhow: can someone point me in the right direction? Also, are there > binary packages that contain the LDAP backend, or is the best way building > it yourself? > > Thanks for your help, > > Stephan Yes it's possible. Use "configure --with-dlz-ldap". There's a sample configuration at http://bind-dlz.sourceforge.net/ldap_driver.html. There will also be an improved, dynamically-loadable LDAP DLZ module included in BIND 9.10. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: auto-dnssec maintain and no key: no error message?
> When I run a BIND with "auto-dnssec maintain" and "inline-signing > yes", if I create no key, there is no error message and, worse, the > log file says the zone is signed: Thanks for pointing this out. It's not really an error, but the log should certainly be clearer about what's going on. An inline-signing zone is represented internally as *two* zone objects, one to hold the original unsigned data, and the other the signed. These zones are differentiated in the log file by the labels "(unsigned)" and "(signed)", regardless of whether signing in fact taken place yet. A zone that is to be signed, but can't find a key to sign with, simply waits quietly until a key is provided. Presumably you're planning to create the keys and run "rndc loadkeys" later. We ought to be logging this condition, but it's not an error. If you report this to bind9-b...@isc.org we'll address it. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: ZSK rollover weirdness
> The current ZSK is 44538 > > ; This is a zone-signing key, keyid 44538, for ksu.edu. [...] > ; Revoke: 2013120209 (Mon Dec 2 03:00:00 2013) The revoke bit has no defined meaning for a ZSK. It's used for updating trust anchors via RFC 5011. The code allows you to set it (just as it allows you to use a ZSK as a KSK), but I don't recommend it. Unless there are resolvers that have managed-key trust anchors configured for ksu.edu, you shouldn't bother with the revoke bit for your KSK either. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: ZSK rollover weirdness
> So, can I just remove the Revoke line (is there an option in > dnssec-settime to do this?) "dnssec-settime -R none" can do that. But I gather the key has already had its REVOKE flag set in the zone, so if you want to get things back to the status quo, you probably want to purge and restore the key. Something like this ought to work: dnssec-settime -R none -I now -D now rndc loadkeys ksu.edu sleep 1 dnssec-settime -I -D rndc loadkeys ksu.edu -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: support for single keys?
On Wed, Sep 11, 2013 at 04:40:29PM +0200, Gilles Massen wrote: > Do you know if Bind with auto-dnssec maintain + inline-signing is > supposed to work with a single key (i.e. not a KSK + ZSK)? Yes, it's supposed to work, but I don't think we've tested it much. If you find problems, please report to bind9-b...@isc.org. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: maintain mode with KSK offline?
On Fri, Sep 13, 2013 at 12:38:07PM -0300, Diego Mart??nez wrote: > if I use bind with zone options: > auto-dnssec: maintain > inline-signing: yes > > the KSK (public and private parts) must be on-line, right? > Even if not required to sign the DNSKEY records? The short answer is yes. When you're doing inline signing, the server maintains two copies of the zone internally: the original zone as you configured it (we call it the "raw" zone), and then a second copy that it builds which actually answers queries. When named first loads the raw zone, it's copied over into the signed zone *with any existing DNSSEC records stripped out*. DNSKEYs get brought in from the key directory, the whole thing is signed, NSEC records generated, and finally we're ready to answer queries. Signing the raw zone with an offline KSK before you loaded it would just cause the signed DNSKEY rrset to be stripped before the inline- signing zone got to work. I can think of some ways to kluge around this, but they'd be cumbersome and prone to error. My real recommendation is, if you need an offline KSK, don't use inline signing. (You can still use auto-dnssec.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: New Versions of BIND are available (9.9.4, 9.8.6, and 9.6-ESV-R10)
On Fri, Sep 20, 2013 at 09:20:29AM +1000, Noel Butler wrote: > I have been using this since 9.9.4bx, and although documentation is/was > lacking at the time, so there might be a whitelisting somewhere , but in > its absence, I highly advise against using RRL if your mail servers use > those DNS servers A mail server should be talking to a caching resolver, not an authoritative DNS server; RRL is for authoritaive servers. So the situation shouldn't ordinarily arise. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: 9.9.4 Bug Fixes - RT #34583
> What exactly does "beneath" mean in the following line from the 9.9.4 > bug fixes? > > "Fix forwarding for forward only "zones" beneath automatic empty zones. > [RT #34583]" Named automatically sets up "empty" reverse zones for nonroutable address spaces, to prevent your network sending PTR queries out for things like 10.1.2.3, which can only be configured locally. These zones were interacting badly forward-only zones. For example, if you set up a forward zone for 100.10.in-addr.arpa, which is beneath the empty zone 10.in-addr.arpa, PTR queries for 10.100.*.* should be forwarded while all other queries for 10.* should be answered from the empty zone. That wasn't working; now it is. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: One zone in 2 views
On Thu, Sep 26, 2013 at 06:37:30PM +1200, Michael Ludvig wrote:
> Hi
>
> I've got two nameservers (ns1 master, ns2 slave) each with 2 views
> (internal, external) and a number of zones.
>
> At the moment I'm serving all zones to internal view but would like to
> have some zones served to external clients as well.
>
> I've got two questions:
>
> 1) If I have different example.com in internal and external view on ns1
> (master) can I mirror them both to ns2's internal and external views?
> Right now I can only do the internal and have no idea how to mirror the
> external to ns2. Is it possible at all?
Yes. You set up a TSIG key for the purpose, and configure ns1 like this:
view internal {
match-clients { !key ext-key; localhost; localnets; };
...
};
view external {
match-clients { any; };
};
So then messages from your local network would go to the internal
view *unless* they were signed with ext-key, which would cause the
match to fail and the message would go to the external view instead.
On ns2, you'll set up the zone (for the external view) like this:
zone example.com {
type slave;
masters { 1.2.3.4 key ext-key; };
...
};
... which means that transfer requests from ns1 will be signed with
ext-key, and will reach the external view on ns1. In the internal view,
you leave out the "key ext-key" part, and zone transfer requests will go to
the internal view.
> 2) I've got pub.example.com that should be the same in internal and
> external view. We automatically update this zone with nsupdate.
> The slave (ns2) can see the master's internal view and mirrors the zone,
> so I guess I can mirror it in the internal view and somehow make the
> same zone-file available in ns2's external view. How do I do that?
> Should it have a "type master" (but it's not a master) or slave (it's
> not being axfr'ed in the external view though).
You can actually use the same trick as above to have zones transfer from
one view to another within the same server. Put a master in external
and a slave in internal, and have the slave use "key ext-key" in its
masters statement.
BIND 9.10 is going to include the ability to reference the same
zone from more than one view, sparing the need to keep two copies in
memory and deal with intra-server zone transfers.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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
