Re: bind autosign - DS distribution

2010-12-09 Thread Kevin Oberman
> From: Chris Buxton > Date: Thu, 9 Dec 2010 21:16:41 -0800 > Sender: bind-users-bounces+oberman=es@lists.isc.org > > > On Dec 9, 2010, at 2:26 PM, Matus UHLAR - fantomas wrote: > > > Is it possible(planned) for bind to sign slave zone? > > And, are incremental updates possible with dnssec?

Re: bind autosign - DS distribution

2010-12-09 Thread Chris Buxton
On Dec 9, 2010, at 2:26 PM, Matus UHLAR - fantomas wrote: > Is it possible(planned) for bind to sign slave zone? > And, are incremental updates possible with dnssec? > > I'm thinking about hidden master bind loading (un)signed zones and providing > axfr/ixfr to our public servers Secure64 makes

Re: bind autosign - DS distribution

2010-12-09 Thread fakessh @
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 10.12.2010 00:24, Matus UHLAR - fantomas a écrit : > On 09.12.10 23:45, fakessh @ wrote: >> webmin implement the mecanism of resign zones > > good to know, but our system fille DNS data using some automatic processes > from more sources and I don'

Re: DiG 9.3.6-P1 segfaults on CentOS

2010-12-09 Thread Brian Keefer
On Dec 9, 2010, at 4:20 PM, Mark Andrews wrote: > > In message , Brian Keefer > write > s: >> Downloading the tarball for bind-9.7.2-P1 from ftp.isc.org and building it fr >> om source fixed the segfault issue. >> >> I'm still seeing a (possibly related) issue where if I do dig +trace txt > bl

Re: DiG 9.3.6-P1 segfaults on CentOS

2010-12-09 Thread Mark Andrews
In message , Brian Keefer write s: > Downloading the tarball for bind-9.7.2-P1 from ftp.isc.org and building it fr > om source fixed the segfault issue. > > I'm still seeing a (possibly related) issue where if I do dig +trace txt bl record> it takes 6-10 seconds (measured by time(1)) to complete

Re: DiG 9.3.6-P1 segfaults on CentOS

2010-12-09 Thread Brian Keefer
On Dec 9, 2010, at 1:16 PM, Brian Keefer wrote: > This issue was initially reported to me by a customer running CentOS 5.5 > x86_64. I was able to duplicate it on CentOS 5.5 i386 with dig version: > DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 > > When doing a dig +trace to a DNSBL for a TXT record

Re: m master file managed-keys.bind failed

2010-12-09 Thread Doug Barton
On 12/08/2010 11:51, Martin McCormick wrote: I wrote: Who is supposed to own /var/named? I received a response from a kind soul from this list who reminded me of a directive new to bind9.7.1 that lets you determine where the managed-keys.bind file lives. I set up managed-keys-director

Re: bind autosign - DS distribution

2010-12-09 Thread Matus UHLAR - fantomas
On 09.12.10 23:45, fakessh @ wrote: > webmin implement the mecanism of resign zones good to know, but our system fille DNS data using some automatic processes from more sources and I don't think they should use webmin for that ;) -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantoma

Re: bind autosign - DS distribution

2010-12-09 Thread Matus UHLAR - fantomas
> In message <20101209222644.ga2...@fantomas.sk>, Matus UHLAR - fantomas writes: > > Is it possible(planned) for bind to sign slave zone? On 10.12.10 09:41, Mark Andrews wrote: > The master signs the zone. The slaves just serve it. The master still loads the zone somehow, from a file probably (e

Re: bind autosign - DS distribution

2010-12-09 Thread fakessh @
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 09.12.2010 23:26, Matus UHLAR - fantomas a écrit : >> In message <20101209220716.ga2...@fantomas.sk>, Matus UHLAR - fantomas >> writes: >>> pardon my ignorance if this has been discussed (haven't notice), but >>> if BIND is configured to automatica

Re: bind autosign - DS distribution

2010-12-09 Thread Mark Andrews
In message <20101209222644.ga2...@fantomas.sk>, Matus UHLAR - fantomas writes: > > In message <20101209220716.ga2...@fantomas.sk>, Matus UHLAR - fantomas writ > es: > > > pardon my ignorance if this has been discussed (haven't notice), but > > > if BIND is configured to automatically sign dynamic

Re: bind autosign - DS distribution

2010-12-09 Thread Matus UHLAR - fantomas
> In message <20101209220716.ga2...@fantomas.sk>, Matus UHLAR - fantomas writes: > > pardon my ignorance if this has been discussed (haven't notice), but > > if BIND is configured to automatically sign dynamic zones, does it > > distribute DS records to parent zones somehow? and if not, what are wa

Re: bind autosign - DS distribution

2010-12-09 Thread Mark Andrews
In message <20101209220716.ga2...@fantomas.sk>, Matus UHLAR - fantomas writes: > Hello, > > pardon my ignorance if this has been discussed (haven't notice), but > if BIND is configured to automatically sign dynamic zones, does it > distribute DS records to parent zones somehow? and if not, what a

bind autosign - DS distribution

2010-12-09 Thread Matus UHLAR - fantomas
Hello, pardon my ignorance if this has been discussed (haven't notice), but if BIND is configured to automatically sign dynamic zones, does it distribute DS records to parent zones somehow? and if not, what are ways to do that? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.s

DiG 9.3.6-P1 segfaults on CentOS

2010-12-09 Thread Brian Keefer
This issue was initially reported to me by a customer running CentOS 5.5 x86_64. I was able to duplicate it on CentOS 5.5 i386 with dig version: DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 When doing a dig +trace to a DNSBL for a TXT record they're getting a segfault after making the final query (pr

Re: DIG Source IP

2010-12-09 Thread Gary Wallis
Gary Wallis wrote: John Williams wrote: If I have a Linux host with multiple IP's, is there a way to utilize the DIG command such that the query appears like it's coming from different IP addresses? So If I have 10 virtual IP's, is there a way to control the source IP of the query? I've re

Re: DIG Source IP

2010-12-09 Thread Warren Kumari
On Dec 9, 2010, at 9:51 AM, John Williams wrote: > If I have a Linux host with multiple IP's, is there a way to utilize the DIG > command such that the query appears like it's coming from different IP > addresses? > > So If I have 10 virtual IP's, is there a way to control the source IP of the

Re: DIG Source IP

2010-12-09 Thread Gary Wallis
John Williams wrote: If I have a Linux host with multiple IP's, is there a way to utilize the DIG command such that the query appears like it's coming from different IP addresses? So If I have 10 virtual IP's, is there a way to control the source IP of the query? I've referenced the DIG man

Re: DIG Source IP

2010-12-09 Thread Matus UHLAR - fantomas
On 09.12.10 06:51, John Williams wrote: > If I have a Linux host with multiple IP's, is there a way to utilize the DIG > command such that the query appears like it's coming from different IP > addresses? > > So If I have 10 virtual IP's, is there a way to control the source IP of the > query?

Re: DIG Source IP

2010-12-09 Thread Sim
Hi Have you tried [-b address] ? --- Sim 2010/12/9 John Williams : > If I have a Linux host with multiple IP's, is there a way to utilize the DIG > command such that the query appears like it's coming from different IP > addresses? > > So If I have 10 virtual IP's, is there a way to control the

RE: DIG Source IP

2010-12-09 Thread Todd Snyder
dig -b {srcip} -Original Message- From: bind-users-bounces+tsnyder=rim@lists.isc.org [mailto:bind-users-bounces+tsnyder=rim@lists.isc.org] On Behalf Of John Williams Sent: Thursday, December 09, 2010 9:51 AM To: bind-users@lists.isc.org Subject: DIG Source IP If I have a Linux h

DIG Source IP

2010-12-09 Thread John Williams
If I have a Linux host with multiple IP's, is there a way to utilize the DIG command such that the query appears like it's coming from different IP addresses? So If I have 10 virtual IP's, is there a way to control the source IP of the query? I've referenced the DIG man page and it doesn't app

Re: maximum number of FD events (64) received

2010-12-09 Thread Dmitry Rybin
28.09.2010 10:46, JINMEI Tatuya / 神明達哉 пишет: > These logs are not (directly) related to file descriptors. They mean > epoll returned more socket events than the implementation normally > expects (which is 64). This is not necessarily an error because the > remaining events will be returned with