Re: about cache nonexist record

2009-07-21 Thread Hauke Lampe 
Tech W. wrote:

> Can I ask how to call nsupdate in Perl language?
> I know some Perl but not good at it.

The documentation for Net::DNS::Update should get you started. Here's
one example:


use Net::DNS;

my $zone = "ixhash.bl.openchaos.org";
my $master = "nsig3.hauke-lampe.de.";

my $key_name = "update-bl.";
my $key = "XXX";

my $update = Net::DNS::Update->new($zone);
my $res = Net::DNS::Resolver->new(
nameservers => [$master],
persistent_udp  => 1,
persistent_tcp  => 1,
recurse => 0,
);

# send update, reset $update object
sub send {
$res->tsig($key_name, $key) if ($key_name);
my $reply = $res->send($update);
if ($reply) {
if ($reply->header->rcode eq 'NOERROR') {
print "Update succeeded\n" if $debug > 0;
} else {
print 'Update failed: ', $reply->header->rcode, "\n";
}
} else {
print 'Update failed: ', $res->errorstring, "\n";
}
$update = Net::DNS::Update->new($zone);
}



$update->push(pre => nxrrset("$hash.$zone A"));
$update->push(update => rr_add("$hash.$zone 42 A 127.0.0.1"));
$update->push(update => rr_add("$hash.$zone 42 TXT \"timestamp $^T\""));
&send;



Hauke.




signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

dnssec-keyfromlabel out of memory

2009-07-21 Thread Greg.Rabil 
Hello,
Trying to run 'dnssec-keyfromlabel' from 9.6.1 distro on RHEL5.

Configured with:
./configure --with-openssl=/usr/local/ssl --with-pkcs11 --enable-threads 
--enable-ipv6 --enable-static

Using PKCS11 engine from OpenSolaris patch for OpenSSL 0.9.8k.

Here's my test:

/opt/dnssec/bind-9.6.1/bin/dnssec/dnssec-keyfromlabel -a RSASHA1 -l foobar 
foobar
dnssec-keyfromlabel: failed to generate key foobar/RSASHA1: out of memory

I have 1GB of memory on this box.  Is this error legitimate?  If so, how much 
memory is expected to be needed for this?  If not, any ideas what the problem 
may be?

Thanks,
Greg


A. Gregory Rabil | Lead Software Architect | BT Diamond IP |
Tel: +1 (610) 423-4770 | Fax: +1 (610) 423-4774 | 
greg.ra...@bt.com |  http://bt.diamondip.com

This electronic message contains information from BT INS, Inc, which may be 
privileged
or confidential.  The information is intended for use only by the individual(s) 
or entity named above.  If you
are not the intended recipient, be aware that any disclosure, copying, 
distribution or use of the contents of
this information is strictly prohibited.  If you have received this electronic 
message in error, please notify
me by telephone or email (to the number or email address above) immediately.

Activity and use of the BT INS, Inc  e-mail system is monitored to secure its 
effective
operation and for other lawful business purposes. Communications using this 
system will also be monitored
and may be recorded to secure effective operation and for other lawful business 
purposes.

BT INS Inc, 1600 Memorex Drive, Suite 200, Santa Clara California 95050-2842 
,United States

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Problems with EDNS0

2009-07-21 Thread Breno Silveira Soares 

Mark Andrews escreveu:

You think there isn't a firewall.  There is something in the path
that is blocking responses.  When you find it can you please inform
the manufacture that there produce is broken and you would like it
fixed.  FORMERR is part of the base DNS specification and shouldn't
be filtered.
  

What I don't understand is: the FORMERR response is a normal UDP packet, ok?
What could filter this packet?

Queries to Akamai servers doesn't work with EDNS. To resolve this 
problem I configure bind with directive "server  { edns no; };", but 
isn't a good solution.

From my server, some queries with EDNS works and some doesn't.



The Akamai do respond to EDNS queries.
Here is what you should be seeing.  It looks like something is
filtering out the FORMERR responses.  Almost all of the above log
messages are for zones where FORMERR is returned.  Responses from
EDNS aware servers are getting back.

B.T.W. you should use 512 not as the buffer size 500.

drugs:dnssec 13:10 {1669} % dig @n0g.akamai.net a961.g.akamai.net +bufsize=512

; <<>> DiG 9.3.6-P1 <<>> @n0g.akamai.net a961.g.akamai.net +bufsize=512
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 52294
;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; Query time: 11 msec
;; SERVER: 60.254.186.21#53(60.254.186.21)
;; WHEN: Tue Jul 21 13:10:50 2009
;; MSG SIZE  rcvd: 12

drugs:dnssec 13:10 {1670} % 


Mark
My server gets responses with EDNS from some NS in Internet, with UDP 
packet > 512 bytes,

e.g: "dig @a.dns.br br dnskey +dnssec +bufsize=2500"
So it's not firewall problem, Am I correct ?

From my server, dig to Akamai with EDNS (+bufsize=512) doesn't get 
FORMERR message, dig return "connection timed out; no servers could be 
reached".

What could be the reason ?

Thanks for your reply.

--
Ats,
Breno S. Soares
Analista de Redes
SERPRO/SUPRE/REBHE
Tel: (31) 3311-6825



"Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa 
pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a 
seu destinatário e pode conter informações confidenciais, protegidas por sigilo 
profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. 
Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, 
esclarecendo o equívoco."

"This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a 
government company established under Brazilian law (5.615/70) -- is directed exclusively 
to its addressee and may contain confidential data, protected under professional secrecy 
rules. Its unauthorized use is illegal and may subject the transgressor to the law's 
penalties. If you're not the addressee, please send it back, elucidating the 
failure."
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-keyfromlabel out of memory

2009-07-21 Thread Mark Andrews 

In message <1e4636828b4ad841900a31378a9fe3cd02ca149...@usemp11.ins.com>, Greg.R
a...@ins.com writes:
> Hello,
> Trying to run 'dnssec-keyfromlabel' from 9.6.1 distro on RHEL5.
> 
> Configured with:
> ./configure --with-openssl=3D/usr/local/ssl --with-pkcs11 --enable-threads =
> --enable-ipv6 --enable-static
> 
> Using PKCS11 engine from OpenSolaris patch for OpenSSL 0.9.8k.
> 
> Here's my test:
> 
> /opt/dnssec/bind-9.6.1/bin/dnssec/dnssec-keyfromlabel -a RSASHA1 -l foobar =
> foobar
> dnssec-keyfromlabel: failed to generate key foobar/RSASHA1: out of memory

dnssec-keyfromlabel -a RSASHA1 -l pkcs11:foobar foobar

> I have 1GB of memory on this box.  Is this error legitimate?  If so, how mu=
> ch memory is expected to be needed for this?  If not, any ideas what the pr=
> oblem may be?
> 
> Thanks,
> Greg
> 
> 
> A. Gregory Rabil | Lead Software Architect | BT Diamond IP |
> Tel: +1 (610) 423-4770 | Fax: +1 (610) 423-4774 | greg.ra...@bt.com greg.ra...@bt.com> |  http://bt.diamondip.com
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-keyfromlabel out of memory

2009-07-21 Thread Mark Andrews 

Mark Andrews writes:
> 
> In message <1e4636828b4ad841900a31378a9fe3cd02ca149...@usemp11.ins.com>, Greg
> .R
> a...@ins.com writes:
> > Hello,
> > Trying to run 'dnssec-keyfromlabel' from 9.6.1 distro on RHEL5.
> > 
> > Configured with:
> > ./configure --with-openssl=3D/usr/local/ssl --with-pkcs11 --enable-threads 
> =
> > --enable-ipv6 --enable-static
> > 
> > Using PKCS11 engine from OpenSolaris patch for OpenSSL 0.9.8k.
> > 
> > Here's my test:
> > 
> > /opt/dnssec/bind-9.6.1/bin/dnssec/dnssec-keyfromlabel -a RSASHA1 -l foobar 
> =
> > foobar
> > dnssec-keyfromlabel: failed to generate key foobar/RSASHA1: out of memory
> 
> dnssec-keyfromlabel -a RSASHA1 -l pkcs11:foobar foobar

This assumes you have already created a RSA key called "foobar" in the HSM.

> > I have 1GB of memory on this box.  Is this error legitimate?  If so, how mu
> =
> > ch memory is expected to be needed for this?  If not, any ideas what the pr
> =
> > oblem may be?
> > 
> > Thanks,
> > Greg
> > 
> > 
> > A. Gregory Rabil | Lead Software Architect | BT Diamond IP |
> > Tel: +1 (610) 423-4770 | Fax: +1 (610) 423-4774 | greg.ra...@bt.com =
> > greg.ra...@bt.com> |  http://bt.diamondip.com
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Problems with EDNS0

2009-07-21 Thread Mark Andrews 

In message <4a661d77.9050...@serpro.gov.br>, Breno Silveira Soares writes:
> This is a multi-part message in MIME format.
> Mark Andrews escreveu:
> > You think there isn't a firewall.  There is something in the path
> > that is blocking responses.  When you find it can you please inform
> > the manufacture that there produce is broken and you would like it
> > fixed.  FORMERR is part of the base DNS specification and shouldn't
> > be filtered.
> >   
> What I don't understand is: the FORMERR response is a normal UDP packet, ok?
> What could filter this packet?
> 
> >> Queries to Akamai servers doesn't work with EDNS. To resolve this 
> >> problem I configure bind with directive "server  { edns no; };", but 
> >> isn't a good solution.
> >> From my server, some queries with EDNS works and some doesn't.
> >> 
> >
> > The Akamai do respond to EDNS queries.
> > Here is what you should be seeing.  It looks like something is
> > filtering out the FORMERR responses.  Almost all of the above log
> > messages are for zones where FORMERR is returned.  Responses from
> > EDNS aware servers are getting back.
> >
> > B.T.W. you should use 512 not as the buffer size 500.
> >
> > drugs:dnssec 13:10 {1669} % dig @n0g.akamai.net a961.g.akamai.net +bufsize=
> 512
> >
> > ; <<>> DiG 9.3.6-P1 <<>> @n0g.akamai.net a961.g.akamai.net +bufsize=512
> > ; (1 server found)
> > ;; global options:  printcmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 52294
> > ;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> >
> > ;; Query time: 11 msec
> > ;; SERVER: 60.254.186.21#53(60.254.186.21)
> > ;; WHEN: Tue Jul 21 13:10:50 2009
> > ;; MSG SIZE  rcvd: 12
> >
> > drugs:dnssec 13:10 {1670} % 
> >
> > Mark
> My server gets responses with EDNS from some NS in Internet, with UDP 
> packet > 512 bytes,
> e.g: "dig @a.dns.br br dnskey +dnssec +bufsize=2500"
> So it's not firewall problem, Am I correct ?

No.  A firewall can filter on all sorts of things.

I've seen firewall block queries on CD being set but allow
through EDNS responses that are fragmented with CD being
clear.

i.e.
"dig +bufsize=4096 example.net" succeeded.
"dig +cd example.net" failed.

You just have an unusual firewall issue.  FORMERR responses
are being blocked.
 
> From my server, dig to Akamai with EDNS (+bufsize=512) doesn't get 
> FORMERR message, dig return "connection timed out; no servers could be 
> reached".
> What could be the reason ?

You have a device in the path that is filtering out the
FORMERR responses.  Such devices are usually labeled
"firewall" but could be something else like a NAT with a
bad DNS ALG.
 
Mark

> Thanks for your reply.
> 
> -- 
> Ats,
> Breno S. Soares
> Analista de Redes
> SERPRO/SUPRE/REBHE
> Tel: (31) 3311-6825
> 
> 
> 
> "Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa 
> pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada 
> exclusiv
> amente a seu destinatário e pode conter informações confidenciais, protegidas 
> po
> r sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o 
> infrato
> r às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, 
> reen
> viá-la ao emitente, esclarecendo o equívoco."
> 
> "This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a gov
> ernment company established under Brazilian law (5.615/70) -- is directed exc
> lusively to its addressee and may contain confidential data, protected under 
> professional secrecy rules. Its unauthorized use is illegal and may subject t
> he transgressor to the law's penalties. If you're not the addressee, please s
> end it back, elucidating the failure."
> 
> --000705070102040209010704
> Content-Type: text/html;
>   charset="ISO-8859-1"
> Content-Transfer-Encoding: 7bit
> 
> 
> 
> 
>   
> 
> 
> Mark Andrews escreveu:
>   type="cite">
>   
> You think there isn't a firewall.  There is something in the path
> that is blocking responses.  When you find it can you please inform
> the manufacture that there produce is broken and you would like it
> fixed.  FORMERR is part of the base DNS specification and shouldn't
> be filtered.
>   
> 
> What I don't understand is: the FORMERR response is a normal UDP
> packet, ok?
> What could filter this packet?
> 
> 
>   type="cite">
>   
>   
> Queries to Akamai servers doesn't work with EDNS. To resolve
>  this 
> problem I configure bind with directive "server  { edns no; };", bu
> t 
> isn't a good solution.
> >From my server, some queries with EDNS works and some doesn't.
> 
>   
>   
> The Akamai do respond to EDNS queries.
> 
> 
>   type="cite">
>   
> Here is what you should be seeing.  It looks like something is
> filtering out the FORMERR responses.  Almost all of the above log
> messages are for zones where FORMERR is returne