Re: dnssec updated zone data is not live ??

[Kevin Darcy]

Gregory Machin wrote:

Hi
Please can you advise. I's been ages since I have configured dnssec .
I used nsupdate (with dnssec) to update a zone file with all the host
current ip's so that they are reachable via a host name even when the
ip has changed (a dyndns.org type of thing).  Everything seems to work
fine named accepts the update and writes it to the .jnl file but when
it try and ping the updated host name  I get "ping: unknown host
greg.za.protetor.net", and this is one the server running named. yet I
the logs show

Dec 10 14:47:52 server named[17862]: client 97.xxx.xxx.127#50043: view
external: updating zone 'device.example.net/IN': deleting rrset at
'greg.device.example.net' A
Dec 10 14:47:52 server named[17862]: client 97.xxx.xxx.127#50043: view
external: updating zone 'device.example.net/IN': adding an RR at
'greg.device.example.net' A

Which is correct from what I remember the last time I did this.

my zone configuration:
/etc/named.conf
zone "device.example.net" {
type master;
file "/var/named/device.example.net.db";
allow-transfer { any; };
allow-update { key device.example.net; };
};


zone file:

$ORIGIN .
$TTL 3600   ; 1 hour
device.example.net IN SOA  ns1.example.net. ns2.example.net. (
2009120805 ; serial
900; refresh (15 minutes)
600; retry (10 minutes)
86400  ; expire (1 day)
3600   ; minimum (1 hour)
)
NS  ns1.example.net.
NS  ns2.example.net.
A   205.234.215.112
MX  0 server.example.net.
$ORIGIN device.example.net.
$TTL 60 ; 1 minute
gregA   97.xxx.xxx.127



Running:
BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5


  
First of all, are you talking about DNSSEC, or just plain Dynamic Update 
(presumably crypto-authenticated if this is going to be a 
publically-updateable zone)? I don't see any DNSSEC records in the zone 
file you posted.


Secondly, if you do an AXFR of the zone after the Dynamic Update, does 
it reflect the change?


Thirdly, on the machine which is originating the ping, how is it set up 
to resolve names? Does it only use DNS? Does it only use *itself* for 
resolving DNS? Is there some intermediate caching going on (e.g. nscd or 
equivalent)? If so, have you waited long enough for the entries to 
expire from that intermediate cache?


- Kevin

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

BIND 9.6.2b1 is now available.

[Mark Andrews]

BIND 9.6.2b1 is now available.

BIND 9.6.2b1 is a maintenance release for BIND 9.6.

BIND 9.6.2b1 can be downloaded from

ftp://ftp.isc.org/isc/bind9/9.6.2b1/bind-9.6.2b1.tar.gz

The PGP signature of the distribution is at

ftp://ftp.isc.org/isc/bind9/9.6.2b1/bind-9.6.2b1.tar.gz.asc
ftp://ftp.isc.org/isc/bind9/9.6.2b1/bind-9.6.2b1.tar.gz.sha256.asc
ftp://ftp.isc.org/isc/bind9/9.6.2b1/bind-9.6.2b1.tar.gz.sha512.asc

The signature was generated with the ISC public key, which is
available at .

A binary kit for Windows XP and Window 2003 is at

ftp://ftp.isc.org/isc/bind9/9.6.2b1/BIND9.6.2b1.zip
ftp://ftp.isc.org/isc/bind9/9.6.2b1/BIND9.6.2b1.debug.zip

The PGP signature of the binary kit for Windows XP and Window 2003 is at

ftp://ftp.isc.org/isc/bind9/9.6.2b1/BIND9.6.2b1.zip.asc
ftp://ftp.isc.org/isc/bind9/9.6.2b1/BIND9.6.2b1.zip.sha256.asc
ftp://ftp.isc.org/isc/bind9/9.6.2b1/BIND9.6.2b1.zip.sha512.asc
ftp://ftp.isc.org/isc/bind9/9.6.2b1/BIND9.6.2b1.debug.zip.asc
ftp://ftp.isc.org/isc/bind9/9.6.2b1/BIND9.6.2b1.debug.zip.sha256.asc
ftp://ftp.isc.org/isc/bind9/9.6.2b1/BIND9.6.2b1.debug.zip.sha512.asc

Changes since 9.6.0.

--- 9.6.2b1 released ---

2797.   [bug]   Don't decrement the dispatch manager's maxbuffers.
[RT #20613]

2790.   [bug]   Handle DS queries to stub zones. [RT #20440]

2789.   [bug]   Fixed an INSIST in dispatch.c [RT #20576]

2786.   [bug]   Additional could be promoted to answer. [RT #20663]

2784.   [bug]   TC was not always being set when required glue was
dropped. [RT #20655]

2783.   [func]  Return minimal responses to EDNS/UDP queries with a UDP
buffer size of 512 or less.  [RT #20654]

2782.   [port]  win32: use getaddrinfo() for hostname lookups.
[RT #20650]

2777.   [contrib]   DLZ MYSQL auto reconnect support discovery was wrong.

2772.   [security]  When validating, track whether pending data was from
the additional section or not and only return it if
validates as secure. [RT #20438]

2765.   [bug]   Skip masters for which the TSIG key cannot be found.
[RT #20595]

2760.   [cleanup]   Corrected named-compilezone usage summary. [RT #20533]

2759.   [doc]   Add information about .jbk/.jnw files to
the ARM. [RT #20303]

2758.   [bug]   win32: Added a workaround for a windows 2008 bug
that could cause the UDP client handler to shut
down. [RT #19176]

2757.   [bug]   dig: assertion failure could occur in connect
timeout. [RT #20599]

2755.   [doc]   Clarify documentation of keyset- files in
dnssec-signzone man page. [RT #19810]

2754.   [bug]   Secure-to-insecure transitions failed when zone
was signed with NSEC3. [RT #20587]

2750.   [bug]   dig: assertion failure could occur when a server
didn't have an address. [RT #20579]

2749.   [bug]   ixfr-from-differences generated a non-minimal ixfr
for NSEC3 signed zones. [RT #20452]

2747.   [bug]   Journal roll forwards failed to set the re-signing
time of RRSIGs correctly. [RT #20541]

2743.   [bug]   RRSIG could be incorrectly set in the NSEC3 record
for a insecure delegation.

2729.   [func]  When constructing a CNAME from a DNAME use the DNAME
TTL. [RT #20451]

2723.   [bug]   isc_base32_totext(), isc_base32hex_totext(), and
isc_base64_totext(), didn't always mark regions of
memory as fully consumed after conversion.  [RT #20445]

2722.   [bug]   Ensure that the memory associated with the name of
a node in a rbt tree is not altered during the life
of the node. [RT #20431]

2721.   [port]  Have dst__entropy_status() prime the random number
generator. [RT #20369]

2718.   [bug]   The space calculations in opensslrsa_todns() were
incorrect. [RT #20394]

2716.   [bug]   nslookup debug mode didn't return the ttl. [RT #20414]

2715.   [bug]   Require OpenSSL support to be explicitly disabled.
[RT #20288]

2714.   [port]  aix/powerpc: 'asm("ics");' needs non standard assembler
flags.

2713.   [bug]   powerpc: atomic operations missing asm("ics") /
__isync() calls.

2706.   [bug]   Loading a zone with a very larg

dnssec updated zone data is not live ??

[Gregory Machin]

Hi
Please can you advise. I's been ages since I have configured dnssec .
I used nsupdate (with dnssec) to update a zone file with all the host
current ip's so that they are reachable via a host name even when the
ip has changed (a dyndns.org type of thing).  Everything seems to work
fine named accepts the update and writes it to the .jnl file but when
it try and ping the updated host name  I get "ping: unknown host
greg.za.protetor.net", and this is one the server running named. yet I
the logs show

Dec 10 14:47:52 server named[17862]: client 97.xxx.xxx.127#50043: view
external: updating zone 'device.example.net/IN': deleting rrset at
'greg.device.example.net' A
Dec 10 14:47:52 server named[17862]: client 97.xxx.xxx.127#50043: view
external: updating zone 'device.example.net/IN': adding an RR at
'greg.device.example.net' A

Which is correct from what I remember the last time I did this.

my zone configuration:
/etc/named.conf
zone "device.example.net" {
type master;
file "/var/named/device.example.net.db";
allow-transfer { any; };
allow-update { key device.example.net; };
};


zone file:

$ORIGIN .
$TTL 3600   ; 1 hour
device.example.net IN SOA  ns1.example.net. ns2.example.net. (
2009120805 ; serial
900; refresh (15 minutes)
600; retry (10 minutes)
86400  ; expire (1 day)
3600   ; minimum (1 hour)
)
NS  ns1.example.net.
NS  ns2.example.net.
A   205.234.215.112
MX  0 server.example.net.
$ORIGIN device.example.net.
$TTL 60 ; 1 minute
gregA   97.xxx.xxx.127



Running:
BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5


any suggestions would be welcome. I have run out of ideas and googles.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: managed-keys.bind's directory problem

[fujiwara]

> From: Mark Andrews 
> In message <20091210.162242.460114267490885968.fujiw...@pyon.org>, 
> fujiw...@wid
> e.ad.jp writes:
>> I'm using BIND 9.7.0b3 an DLV (dns-lookaside auto;).
>> 
>> The named tried to write "managed-keys.bind" file into the named's
>> working directory.
>> 
>> The current BIND 9 requires the working directory is writable by named
>> (From ARM). But I think the working directory should not be writable
>> by named and some OSs' default configuration set the working directory
>> not writable.
> 
> Then those OS's are misconfiguring named.  This has been a requirement
> since the BIND 4 days.  It's just named has not complained and there
> has been loss of functionality as a result.  On some OS's this is the
> only way to get a core file for debugging as there is no way to specify
> anything other than the current working directory.
> 
> Note there is no requirement for named's config files to be below the
> working directory.
> 
> ../master-files/ or /master-files/ or /var/named/master-files could
> all be used instead of ./master-files
>  
> The working directory does not have to be /var/named.

Thank you. I understand where I misunderstood.

Now, I changed the work directory as "/etc/namedb/var" and prepended "../"
to all relative path on my FreeBSD Box.
(and added "var uname=bind" into /etc/mtree/BIND.chroot.dist.)
It works well.

>> I'm very happy if I can change the managed-keys.bind path.
> 
> We will look into that.

Regards,

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

Re: Bonjour! I wish to compile 9.7.0b3

[Evan Hunt]

> Thank you! Evan,
> 
> I have not VisualStudio which is commercial. Do you think I can use an other
> compiler or do you think VisualStudio light is enough (Version 2008 seems
> available).

I'm sorry, I don't know.  Try it and see.  If it works, let me know, and
we'll add the information to the win32-build.txt file.  Good luck.

--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Hi

[supriya samanta]

 Hello All,

As per ISC security bulletin *CVE-2009-4022* There is a problem with BIND 9
Cache Update From Additional Section

*Problem Description:* A Nameserver with DNSSEC validation enabled may
incorrectly add records to its cache from the additional section of
responses received during resolution of a recursive client query.This
behavior only occurs when processing client queries with checking disabled
(CD).It may occur both when requesting,and not when requesting,DNSSEC
records(DO).If the nameserver is authoritative-only this will not occur.

We have some business requirement where we need to reproduce the problem.

Could anyone advice a test case which I may use or direct me to some website
which could be useful for this purpose.

Any help will be appreciated.

Many Thanks,
Supriya Samanta
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: managed-keys.bind's directory problem

[Mark Andrews]

In message <20091210.162242.460114267490885968.fujiw...@pyon.org>, fujiw...@wid
e.ad.jp writes:
> I'm using BIND 9.7.0b3 an DLV (dns-lookaside auto;).
> 
> The named tried to write "managed-keys.bind" file into the named's
> working directory.
> 
> The current BIND 9 requires the working directory is writable by named
> (From ARM). But I think the working directory should not be writable
> by named and some OSs' default configuration set the working directory
> not writable.

Then those OS's are misconfiguring named.  This has been a requirement
since the BIND 4 days.  It's just named has not complained and there
has been loss of functionality as a result.  On some OS's this is the
only way to get a core file for debugging as there is no way to specify
anything other than the current working directory.

Note there is no requirement for named's config files to be below the
working directory.

../master-files/ or /master-files/ or /var/named/master-files could
all be used instead of ./master-files
 
The working directory does not have to be /var/named.

> It is usable to avoid named's unknown BUG which may break the working
> directory.
> 
> For example, FreeBSD changes the working directory's
> owner/group/permission configured by /etc/mtree/BIND.chroot.dist and
> it sets the working directory not writable by named.
> 
> I changed /etc/mtree/BIND.chroot.dist in my FreeBSD box, but I don't
> like this solution.
>
> I'm very happy if I can change the managed-keys.bind path.

We will look into that.

> -
> -
> >From BIND 9.7.0b3 ARM:
> 
>   In the current implementation, the managed keys database is stored
>   as a master-format zone file called managed-keys.bind. When the key
>   database is changed, the zone is updated. As with any other dynamic
>   zone, changes will be written into a journal file,
>   managed-keys.bind.jnl. They are committed to the master file as soon
>   as possible afterward; in the case of the managed key database, this
>   will usually occur within 30 seconds. So, whenever named is using
>   automatic key maintenace, those two files can be expected to exist
>   in the working directory. (For this reason among others, the working
>   directory should be always be writable by named.)
> 
>   If the dnssec-lookaside option is set to auto, named will
>   automatically initialize a managed key for the zone dlv.isc.org. The
>   key that is used to initialize the key maintenance process is built
>   into named, and can be overridden from bindkeys-file.
> 
> ---
> 
> --
> Kazunori Fujiwara, JPRS
> 
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
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 Bogus NXDOMAIN survives authenticating RR

[Niobos]

Thank you very much for your help; I'll forward the conversation to the 
bug-tracking list.

Since these are my first DNSSEC experiments, I just wanted to make sure that it 
wasn't a problem with my understanding of the concept.

Niobos

On 10 Dec 2009, at 00:59, Hauke Lampe wrote:
> The signatures on your SOA and NSEC3 records in the NXDOMAIN response
> are all valid. It's their meaning, the proof of nonexistence for the
> removed record, that cannot be established:
> 
>> validating @0xb4e01470: removed.dnssec.dest-unreach.be A: attempting 
>> negative response validation
>>  validating @0xb4e01ee0: dnssec.dest-unreach.be SOA: verify rdataset 
>> (keyid=33827): success
>>  validating @0xb8e98b60: 
>> 67152CME7SOELFT0OOTFB03FQ968LOM1.dnssec.dest-unreach.be NSEC3: verify 
>> rdataset (keyid=33827): success
>>  validating @0xb8e98b60: 
>> OKIU30OTQ4ETK8K4VP0L3MM20HUNI5R2.dnssec.dest-unreach.be NSEC3: verify 
>> rdataset (keyid=33827): success
>> validating @0xb4e01470: removed.dnssec.dest-unreach.be A: NSEC3 proves name 
>> exists (owner) data=1
>> validating @0xb4e01470: removed.dnssec.dest-unreach.be A: nonexistence 
>> proof(s) not found
> 
> BIND seems to cache the validation state of the signatures, not the
> failed nonexistence proof. At least it doesn't re-validate cached answers:
> 
>> client 127.0.0.1#47401: UDP request
>> client 127.0.0.1#47401: using view '_default'
>> client 127.0.0.1#47401: request is not signed
>> client 127.0.0.1#47401: recursion available
>> client 127.0.0.1#47401: query
>> client 127.0.0.1#47401: query (cache) 'removed.dnssec.dest-unreach.be/A/IN' 
>> approved
>> client 127.0.0.1#47401: send
>> client 127.0.0.1#47401: sendto
>> client 127.0.0.1#47401: senddone
>> client 127.0.0.1#47401: next
>> client 127.0.0.1#47401: endrequest
> 
> So, while the first query returns SERVFAIL as expected, subsequent
> responses from the cache even have the AD flag set. This is the one
> thing that *really* puzzled me (otherwise I probably wouldn't have begun
> looking at long debug logs ;)
> 
>> ha...@pope:~$ dig +dnssec removed.dnssec.dest-unreach.be 
> [...]
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46781
>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
> 
> The response doesn't validate:
> 
>> ha...@pope:~$ dig +sigchase +trusted-key=./dnskey-dnssec.dest-unreach.be 
>> +dnssec removed.dnssec.dest-unreach.be 
> [...]
>> ;; Impossible to verify the Non-existence, the NSEC RRset can't be 
>> validated: FAILED
> 
> I think this is a bug in BIND's resolver part. You should forward a bug
> report to bind9-b...@isc.org.
> 
> Unbound returns SERVFAIL to all queries for
> removed.dnssec.dest-unreach.be and keeps logging the failed NSEC3 test:
> 
>> unbound: [968:0] debug: Validating a nxdomain response
>> unbound: [968:0] debug: nsec3: keysize 1024 bits, max iterations 150
>> unbound: [968:0] info: start nsec3 nameerror proof, zone 
>> 
>> unbound: [968:0] info: ce candidate > CLASS0>
>> unbound: [968:0] debug: nsec3 proveClosestEncloser: proved that qname 
>> existed, bad
>> unbound: [968:0] debug: nsec3 nameerror proof: failed to prove a closest 
>> encloser
>> unbound: [968:0] debug: NameError response failed nsec, nsec3 proof was 
>> sec_status_bogus
>> unbound: [968:0] info: validate(nxdomain): sec_status_bogus
> 

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