RE: bind-users Digest, Vol 1485, Issue 1
nly one handling dns requests) > > Before split-DNS, we had created our own TLD ... but the problem with > that was we couldn't buy SSL certificates for these services, and > there was no interest in having our users to accept self-signed certs > or to add a private CA to everything so the TLD became a > subdomain that was only in the internal view (originally)...though > later added a stub in the external view to publish an MX record so > that users/apps sending mail without setting a correct from address > would still work. (sure I've told people they need to do this lots of > times...but then an important app was upgraded and the setting > lostbut it needed to work anyways.) Not to start a religious war, but is all of this really simpler than basing your maintenance systems around Dynamic Update? Dynamic Update could also be used to do your DR switchover, if you don't already have dedicated load-balancer devices performing that function. - Kevin -- Message: 2 Date: Mon, 01 Apr 2013 13:25:22 +1000 From: Noel Butler To: bind-users@lists.isc.org Subject: Re: Lots of "RSA_verify failed" after upgrade to 9.7.7 Message-ID: <1364786722.6226.2.camel@tardis> Content-Type: text/plain; charset="utf-8" On Mon, 2012-11-05 at 21:21 +1100, Mark Andrews wrote: > > Ignore them. They will be addressed in the next maintenance release. > it was, but now seems to have reared its ugly head again in 9.9.2-p2 Apr 1 12:20:35 fox named[589]: RSA_verify failed Apr 1 12:20:35 fox named[589]: error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:263: Apr 1 12:20:35 fox named[589]: RSA_verify failed Apr 1 12:20:35 fox named[589]: error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:263: -- next part -- An HTML attachment was scrubbed... URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130401/8e3de249/attachment-0001.html> -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130401/8e3de249/attachment-0001.bin> -- Message: 3 Date: Mon, 01 Apr 2013 15:03:47 +1100 From: Mark Andrews To: Noel Butler Cc: bind-us...@isc.org Subject: Re: Lots of "RSA_verify failed" after upgrade to 9.7.7 Message-ID: <20130401040348.15e9531b7...@drugs.dv.isc.org> In message <1364786722.6226.2.camel@tardis>, Noel Butler writes: > > On Mon, 2012-11-05 at 21:21 +1100, Mark Andrews wrote: > > > > > > Ignore them. They will be addressed in the next maintenance release. > > > > > it was, but now seems to have reared its ugly head again in 9.9.2-p2 > > Apr 1 12:20:35 fox named[589]: RSA_verify failed Apr 1 12:20:35 fox > named[589]: error:04077068:rsa routines:RSA_verify:bad > signature:rsa_sign.c:263: > Apr 1 12:20:35 fox named[589]: RSA_verify failed Apr 1 12:20:35 fox > named[589]: error:04077068:rsa routines:RSA_verify:bad > signature:rsa_sign.c:263: BIND 9.7.7 and BIND 9.9.2 were both released at the same time (Oct 9, 2012). BIND 9.9.2-P1 and BIND 9.9.2-P2 are security releases. The betas of the next maintenance release 9.9.3b1 and 9.9.3b2 contain the fix. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Message: 4 Date: Mon, 01 Apr 2013 16:14:46 +1000 From: Noel Butler To: Mark Andrews Cc: bind-us...@isc.org Subject: Re: Lots of "RSA_verify failed" after upgrade to 9.7.7 Message-ID: <1364796886.6226.6.camel@tardis> Content-Type: text/plain; charset="utf-8" On Mon, 2013-04-01 at 15:03 +1100, Mark Andrews wrote: > In message <1364786722.6226.2.camel@tardis>, Noel Butler writes: > > > > On Mon, 2012-11-05 at 21:21 +1100, Mark Andrews wrote: > > > > > > > > > > Ignore them. They will be addressed in the next maintenance release. > > > > > > > > > it was, but now seems to have reared its ugly head again in 9.9.2-p2 > > > > Apr 1 12:20:35 fox named[589]: RSA_verify failed > > Apr 1 12:20:35 fox named[589]: error:04077068:rsa > > routines:RSA_verify:bad signature:rsa_sign.c:263: > > Apr 1 12:20:35 fox named[589]: RSA_verify failed > > Apr 1 12:20:35 fox named[589]: error:04077068:rsa > > routines:RSA_verify:bad signature:rsa_sign.c:263: > > BIND 9.7.7 and BIND 9.9.2 were both released at the same time (Oct > 9, 2012). > > BIND 9.9.2-P1 and BIND 9.9.2-P2 are security releases. > > The betas of
Auto-dnssec maintain and 'continous' resigning
Hello all, I have a few zones signed with DNSSEC and "autodnssec maintain". I have one particular zone that every now and then (I'm working on finding a pattern or trigger) This re-signing process runs for a while, incrementing the serial each time and growing the journal until stopping. I know I need to do more legwork here, but I would appreciate any heads-up on this particular problem. Warm regards, ~Carlos ___ 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: Dynamic Update Policy.....
From: Chris Buxton [cli...@buxtonfamily.us]
Sent: Saturday, March 30, 2013 08:23 PM
To: Gary Greene
Cc: bind-users@lists.isc.org
Subject: Re: Dynamic Update Policy.
> On Mar 28, 2013, at 4:03 PM, Gary Greene wrote:
>
>> I'm trying to get bind to use ddns updates for our environment, however I'm
>> getting errors in the logs on the
>> system that the host is being denied from making the changes.
>>
>> Currently, I'm only allowing certain hosts to update their records, as a
>> test.
>>
>> The stanza for update-policy follows:
>>
>> zone "minervanetworks.com" {
>> type master;
>> notify yes;
>> update-policy {
>> grant ggreene-imac$@MINERVANETWORKS.COM ms-self * A;
>> grant cvallejo-w7-lt$@MINERVANETWORKS.COM ms-self * A;
>> grant cvallejo-test-w7-lt$@MINERVANETWORKS.COM ms-self * A;
>> };
>> file "/etc/named.d/minervanetworks.zone";
>> check-names ignore;
>> };
>>
>> The error I see in the logs:
>> Mar 28 15:57:29 ns1 named[11482]: client 10.5.1.11#52418: view internal:
>> update 'minervanetworks.com/IN'
>> denied
>
> That log message is normal.
>
> If you want to use GSS-TSIG, that's not going to work. I don't have a
> complete step-by-step of what's required, but
> at a minimum:
>
> - Don't use ms-self.
> - Do create a user account in AD with a service principal name that matches
> the hostname of the master name
> server as advertised in the SOA and NS records, prefixed by "DNS/". For
> example,
> "DNS/ns1.minervanetworks@minervanetworks.com". Without this, GSS-TSIG
> will not be attempted.
> - Do not be concerned by the denied update. Every attempt to update will go
> something like this:
>
> 1. SOA query for name to be updated, to recursion server.
> 2. Address lookup for server listed in SOA record, to recursion server.
> 3. Insecure DDNS update message to server listed in SOA record. [denied]
> 4. TKEY query to server listed in SOA record, to establish a single-use
> shared key.
> 5. Signed update message to server listed in SOA record. [approved or denied,
> according to policy]
>
>> The reverse zones work, as they are setup to allow dhcpd to make the changes
>> (and they work correctly),
>> however the forward zone does not.
>
> At a guess, you're not using GSS-TSIG for reverse record updates, correct?
That is correct. I'm just using normal TSIG pre-genned keys for the reverse
zones handled by dhcpd.
> Is there a reason not to have DHCP update the host records as well as the
> reverse?
The overriding reason that we wish to use GSS-TSIG is because we have a number
of devices on the network we _don't_ want in DNS (iPads, iPhones, Android
devices, etc.) that all get their IP info from the same DHCP server. Internally
(and externally) most devices use only the minervanetworks.com domain, with
rare sub-domain exceptions. While it would likely be good to move some stuff to
a sub-domain, doing so would pose significant work (moving hosts to a subdomain
in AD is not trivial.)
I was hoping to get ms-self to work, as it seemed it would require the least
amount of work over all
--
Gary L. Greene, Jr.
Sr. Systems Administrator
IT Operations
Minerva Networks, Inc.
Cell: (650) 704-6633
___
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 'continous' resigning
Reframing the question in more general terms... Which events trigger a zone re-sign and reload when using "auto-dnssec maintain" ? regards, ~Carlos On 4/1/13 12:04 PM, Carlos M. Martinez wrote: > Hello all, > > I have a few zones signed with DNSSEC and "autodnssec maintain". I have > one particular zone that every now and then (I'm working on finding a > pattern or trigger) > > This re-signing process runs for a while, incrementing the serial each > time and growing the journal until stopping. > > I know I need to do more legwork here, but I would appreciate any > heads-up on this particular problem. > > Warm regards, > > ~Carlos > ___ 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: forward zone not working
On 3/19/2013 8:30 PM, Gerry Reno wrote: On 03/19/2013 08:10 PM, b...@bitrate.net wrote: On Mar 18, 2013, at 23.04, Gerry Reno wrote: On 03/18/2013 10:25 PM, b...@bitrate.net wrote: On Mar 18, 2013, at 20.27, Gerry Reno wrote: Using BIND 9.8.2 When you setup Samba 4 AD DC using BIND9_DLZ and your domain has external servers (eg: www,mail) at external providers this means that the ISP and the internal network nameservers will both have SOA record for the domain. it's not really anything particularly related to samba or dlz. it's just two different computers serving the same zone. you're just "hijacking" or overloading that particular label. in addition to declaring the zone in your config, you'll need to delegate that new zone from the parent. it's worth noting that this scales poorly. having to add delegations and zone declarations for every label for which this is desired becomes quickly prohibitive. instead, i'd suggest using a subdomain for samba - e.g. something like ad.example.com. there are a number of other solutions as well which would likely be more sensible than hijacking labels. -ben If it was more than just a few labels I would do it another way. But this will suffice, if I can only get bind to actually get the forward zone working. I don't need any delegation. I'm not looking to slave the zone. as i said, you'll need to delegate that new zone from the parent. i'm not sure what slaves zones would have to do with that. As I said, if I was going to do this for a bunch of labels I would add an external view and just slave it from the ISP which holds the SOA for the external answers. And sure delegation works. You don't even need a forward zone. So what exactly is the use case for this forward zone? If you can achieve what you want through delegation alone, and unless you think that you can squeeze out a performance benefit by forwarding to a "rich cache", then yeah, there is no compelling use case for forwarding and you shouldn't do it. Selective forwarding is most commonly employed when you can't talk directly to the authoritative nameservers for the zone and need to go through an intermediate resolver. I see a number of postings over several y ears where people have not been able to get the forward zone working. Probably because they don't follow the simple advice to delegate the zone. - Kevin ___ 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: Forward First on Master Zone (bypass SOA)
On 3/29/2013 12:09 AM, Doug Barton wrote: On 03/28/2013 12:28 PM, Ben-Eliezer, Tal (ITS) wrote: My organization is evaluating the use of split-view DNS in our environment. Simple ... don't do it. It's almost never the right answer, and as you're learning carries with it more administrative overhead than the problems it's designed to solve. Much better to spend the time carefully considering what your goals are, and finding other ways to reach them. And your alternative is what? Run the external version of the namespace on a completely separate infrastructure from the internal version? My personal preference is to make the upfront investment in developing a split-view config and then pay less in hardware and maintenance costs (in terms of the vendor and my own staff) in the long term, because I have fewer nameservers to procure and manage. Of course, I'm a little biased, since I've *already* developed that config, which rarely requires tinkering, so the hardware and maintenance savings are just gravy. For someone just starting out, the cost/benefit decision might be a little tougher, especially if they're not experienced with BIND configuration, and thus might cause a lot of drama/nail-biting/disruption until they get it right. - Kevin ___ 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
BIND cannot load backup of slaved root zone
Steps to reproduce:
1.Delete or move root.zone out of the bind directory if it exists.
1.Slave the root zone by adding the following to named.conf:
zone "." {
type slave;
file "root.zone";
notify no;
masters{192.0.32.140; 192.0.47.140; };
};
2.Restart BIND
3.restart BIND again
Unexpected results:
BIND cannot load backup of slaved root zone as shown by the following
warnings in the logfile:
general: error: dns_master_load: out of range
general: error: zone ./IN: loading from master file root.zone failed:
out of range
general: info: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700
general: warning: zone ./IN: unable to load from 'root.zone'; renaming
file to 'db-5784' for failure analysis and retransferring.
Expected results:
BIND should be able to reload the backup zone file.
--
Kevin Morgan
PGP Public Key ID 0xB6028066
Key fingerprint = 09FB 59EB D9FE 7C9C 12DF 9530 A877 FAB7 B602 8066
___
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: Forward First on Master Zone (bypass SOA)
-Original Message- From: Kevin Darcy Date: Monday, April 1, 2013 2:46 PM To: "bind-users@lists.isc.org" Subject: Re: Forward First on Master Zone (bypass SOA) >On 3/29/2013 12:09 AM, Doug Barton wrote: >> On 03/28/2013 12:28 PM, Ben-Eliezer, Tal (ITS) wrote: >>> My organization is evaluating the use of split-view DNS in our >>> environment. >> >> Simple ... don't do it. It's almost never the right answer, and as >> you're learning carries with it more administrative overhead than the >> problems it's designed to solve. >> >> Much better to spend the time carefully considering what your goals >> are, and finding other ways to reach them. >And your alternative is what? Run the external version of the namespace >on a completely separate infrastructure from the internal version? Wouldn't you do that to some extent anyway, to separate external infra -- which I'd think is authoritative only -- and internal which is likely a mix of authoritative and recursive? I guess we've overkilled...We're running a split-horizon config on separate infrastructure. There has always been those for and against split horizon. I often flip back and forth since I see logic in many of the arguments on both sides. When I usually hear people speak against split-horizon it has to do with added complexity and minimal benefit (can be harder to debug, confusing to new admins, internal resources should rely on more than DNS for protection and leak out in a lot of ways beside DNS, etc). They generally advocate converging the namespace itself more than dictating what the infrastructure should look like. You could have a cohesive name space served from separate infra or common infra using views and ACLs to decide who can access the cache. I would envision a hidden master feeding both sets of infra so maintenance is still centralized. ___ 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 'continous' resigning
On Apr 1, 2013, at 2:36 PM, Carlos M. Martinez wrote: > Reframing the question in more general terms... Which events trigger a > zone re-sign and reload when using "auto-dnssec maintain" ? Obvious ones: modifications to the dynamic zone Less obvious ones: key events (publication/activation/inactivation/deletion) signature nearing-expiration AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com ___ 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
DLZ $client% parameter segfault
Hello All,
I am trying to use Bind 9.9.2-P2 with the DLZ module, however I continue to run
into segfault issues when trying to use $client$
{SELECT SQL_CACHE zone_name FROM dns_zones … }
{{select zone_ttl AS ttl …. WHERE geo_ip LIKE '$client$'}
I am trying to user $client$ in the A record lookup, not the zone transfer. Is
this possible?
Thanks so much,
Michael
___
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
Does 9.9.2-P2 support rate-limit configuration?
Hi, Does 9.9.2-P2 (the recent release that fixes CVE-2013-2266: A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named) support rate-limit ? If not is there a way to patch the source code to allow for rate-limiting? Thanks ___ 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: Does 9.9.2-P2 support rate-limit configuration?
> From: Red Cricket > Does 9.9.2-P2 (the recent release that fixes > CVE-2013-2266: A Maliciously Crafted Regular Expression Can Cause Memory > Exhaustion in named) > support rate-limit ? not without patching. > If not is there a way to patch the source code to > allow for rate-limiting? Yes, there are 12 more patches for 9.9.2-P2 and 9.8.4-P2 in the usual place. That place can be found by following the link labeled "Patch files for BIND9" on http://www.redbarn.org/dns/ratelimits Two of the new patches are copies with names that includd the version string for the FreeBSD ports. Vernon Schryverv...@rhyolite.com ___ 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
The $client$ parameter appears to work for zone transfers, as per this example
https://github.com/opennetadmin/ona/wiki/bind-dlz
However if I use $client$ on any other queries bind segfaults.
Strace doesn't seem to show anything useful...
Ideas?
Thanks again,
Mike
On Apr 1, 2013, at 2:51 PM, Michael McConnell wrote:
> Hello All,
>
> I am trying to use Bind 9.9.2-P2 with the DLZ module, however I continue to
> run into segfault issues when trying to use $client$
>
> {SELECT SQL_CACHE zone_name FROM dns_zones … }
> {{select zone_ttl AS ttl …. WHERE geo_ip LIKE '$client$'}
>
> I am trying to user $client$ in the A record lookup, not the zone transfer.
> Is this possible?
>
> Thanks so much,
> Michael
>
> ___
> 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
___
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
