bind-users Digest, Vol 1485, Issue 1

Ben-Eliezer, Tal (ITS) Tal.Ben-Eliezer at its.ny.gov
Mon Apr 1 12:31:59 UTC 2013


Hi Kevin-

Thank you for the further elaboration on how you use the include statements in your environment.

Oddly enough this may be a way for me to accomplish what I'd like to do.

Thanks again for the help! I'll report back with any further issues I may experience. Have a great day all!

Tal

-----Original Message-----
From: bind-users-bounces+tal.ben-eliezer=its.ny.gov at lists.isc.org [mailto:bind-users-bounces+tal.ben-eliezer=its.ny.gov at lists.isc.org] On Behalf Of bind-users-request at lists.isc.org
Sent: Monday, April 1, 2013 8:00 AM
To: bind-users at lists.isc.org
Subject: bind-users Digest, Vol 1485, Issue 1

Send bind-users mailing list submissions to
	bind-users at lists.isc.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.isc.org/mailman/listinfo/bind-users
or, via email, send a message with subject or body 'help' to
	bind-users-request at lists.isc.org

You can reach the person managing the list at
	bind-users-owner at lists.isc.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of bind-users digest..."


Today's Topics:

   1. Re: Forward First on Master Zone (bypass SOA) (Kevin Darcy)
   2. Re: Lots of "RSA_verify failed" after upgrade to 9.7.7
      (Noel Butler)
   3. Re: Lots of "RSA_verify failed" after upgrade to 9.7.7
      (Mark Andrews)
   4. Re: Lots of "RSA_verify failed" after upgrade to 9.7.7
      (Noel Butler)


----------------------------------------------------------------------

Message: 1
Date: Sun, 31 Mar 2013 18:01:36 -0400
From: Kevin Darcy <kcd at chrysler.com>
To: bind-users at lists.isc.org
Subject: Re: Forward First on Master Zone (bypass SOA)
Message-ID: <5158B240.70603 at chrysler.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

On 3/29/2013 6:12 PM, Lawrence K. Chen, P.Eng. wrote:
> ----- Original Message -----
>> On Mar 28, 2013, at 12:28 PM, Ben-Eliezer, Tal (ITS) wrote:
>>
>>> I?ve spent hours researching a way to accomplish this without any 
>>> luck. Is there any way to accomplish what I?m trying to do?
>> No, not unless you want to monkey around with static zones and 
>> $INCLUDE directives -- something like this:
>>
>> Internal zone file:
>>
>> $INCLUDE internal.zone.apex
>> $INCLUDE example.com.common-records
>> $TTL 86400
>> some.internal.host	A	192.0.2.1
>> [...]
>>
>> External zone file:
>>
>> $INCLUDE external.zone.apex
>> $INCLUDE example.com.common-records
>> $TTL 86400
>> some.external.host	A	192.0.2.254
>> [...]
>>
>> where the *.zone.apex files look something like this:
>>
>> $TTL 86400
>> @	SOA	[... 7 data fields ...]
>> 	NS	ns1.example.com.
>> 	NS	ns2.example.com.
>> 	MX	10 mx1.example.com.
>>
>> This way, you mostly maintain 3 files of DNS records for the zone -- 
>> external, internal, and common. Note that this is not compatible with 
>> dynamic zones.
>>
>> If you need to support dynamic zones (and who doesn't, these days?), 
>> you're out of luck.
>>
>> Chris Buxton
>> BlueCat Networks
> I/we maintain a 'single' zone file (with help of subversion/cfengine) which is then processed into 4 different zone files through a Makefile on my master nameserver.
>
> Basically, the as-is zone file is the external view state.
>
> All the internal (campus) view lines/$includes are prefixed with:
>
> ;CAMPUS;
>
> where sed removes those comments to generate the 'campus' view zone file.
>
> There there are lines that will have different comments after the line.
>
> one is ;GUEST_NETWORK and another is ;DISASTER_RECOVERY
>
> sed script will replace the IP part of ;GUEST_NETWORK with the IP of a 
> static page informing the user that the resource is available from the 
> guest network. (this is for services where we couldn't have the 
> service owner to do this within their application.)  And, 
> ;DISASTER_RECOVERY replaces the IP with the IP of the server at our DR 
> site.  With the intent that the result is sent by alternate means to 
> our off-campus secondaries, where they can switch to using this 
> file....etc.  Due to DNSSEC, we have to generate a DR version of our 
> zone file (instead of have secondary edit the transfer file and 
> present that.)
>
> These are also based off the external view (since internal services aren't exposed to the guest network, and DR is an alternate external).
>
> All the different zone files are signed using dnssec-signzone with the 
> '-N unixtime' option....to avoid serial number issues. (especially now 
> that I'm not the only 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 
> lost....but 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 <noel.butler at ausics.net>
To: bind-users at lists.isc.org
Subject: Re: Lots of "RSA_verify failed" after upgrade to 9.7.7
Message-ID: <1364786722.6226.2.camel at 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 <marka at isc.org>
To: Noel Butler <noel.butler at ausics.net>
Cc: bind-users at isc.org
Subject: Re: Lots of "RSA_verify failed" after upgrade to 9.7.7
Message-ID: <20130401040348.15E9531B7229 at drugs.dv.isc.org>


In message <1364786722.6226.2.camel at 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: marka at isc.org


------------------------------

Message: 4
Date: Mon, 01 Apr 2013 16:14:46 +1000
From: Noel Butler <noel.butler at ausics.net>
To: Mark Andrews <marka at isc.org>
Cc: bind-users at isc.org
Subject: Re: Lots of "RSA_verify failed" after upgrade to 9.7.7
Message-ID: <1364796886.6226.6.camel at 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 at 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.
> 


Using 9.9.3b3 on one nameserver now, yes all seems good
 Have always used the latest version, applied a patch you gave me
earlier, could of sworn it was fixed, unless I applied two patches and
didnt think about second one. If b3 remains stable after a few days I'll
throw it on main production.

Cheers


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130401/bc814652/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/bc814652/attachment-0001.bin>

------------------------------

_______________________________________________
bind-users mailing list
bind-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

End of bind-users Digest, Vol 1485, Issue 1
*******************************************





More information about the bind-users mailing list