Insecurity proof failed resolving newsletter.postbank.de - but why?
Hi List, I'm seeing a dnssec validation error that I can't pin down, for the domain: newsletter.postbank.de. Neither of http://dnsviz.net/ and http://dnssec-debugger.verisignlabs.com/ report finding a problem, but two (ubuntu packaged) versions of bind report a failure validating the delegation as intentionally insecure. I've tried versions: BIND 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1.1 (Extended Support Version) id:d8a6fe8b built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-geoip=/usr' '--with-atf=no' '--enable-ipv6' '--enable-filter-' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2' using OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013 using libxml2 version: 2.9.1 and BIND 9.8.1-P1 built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-geoip=/usr' '--enable-ipv6' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' using OpenSSL version: OpenSSL 1.0.1 14 Mar 2012 using libxml2 version: 2.7.8 Running with -g 2 (on v9.9.3), I see: == 20-Jan-2014 11:58:43.779 createfetch: newsletter.postbank.de SOA 20-Jan-2014 11:58:43.780 createfetch: . NS 20-Jan-2014 11:58:43.817 decrement_reference: delete from rbt: 0x7ff58b51f010 . 20-Jan-2014 11:58:43.817 decrement_reference: delete from rbt: 0x7ff58b520010 a.root-servers.net 20-Jan-2014 11:58:43.817 decrement_reference: delete from rbt: 0x7ff58b520010 b.root-servers.net 20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 0x7ff58b520010 c.root-servers.net 20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 0x7ff58b520010 d.root-servers.net 20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 0x7ff58b520010 e.root-servers.net 20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 0x7ff58b520010 f.root-servers.net 20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 0x7ff58b520010 g.root-servers.net 20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 0x7ff58b520010 h.root-servers.net 20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 0x7ff58b520010 i.root-servers.net 20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 0x7ff58b520010 j.root-servers.net 20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 0x7ff58b520010 k.root-servers.net 20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 0x7ff58b520010 l.root-servers.net 20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 0x7ff58b520010 m.root-servers.net 20-Jan-2014 11:58:43.819 createfetch: . DNSKEY 20-Jan-2014 11:58:43.881 createfetch: ns1.ecircle.de A 20-Jan-2014 11:58:43.882 createfetch: ns1.ecircle.de 20-Jan-2014 11:58:43.882 createfetch: ns2.ecircle.de A 20-Jan-2014 11:58:43.882 createfetch: ns2.ecircle.de 20-Jan-2014 11:58:43.905 createfetch: ns3.ecircle.com A 20-Jan-2014 11:58:43.905 createfetch: ns3.ecircle.com 20-Jan-2014 11:58:43.938 decrement_reference: delete from rbt: 0x7ff58b52c010 ns3.ecircle.com 20-Jan-2014 11:58:43.939 decrement_reference: delete from rbt: 0x7ff58b52c010 ns3.ecircle.com 20-Jan-2014 11:58:43.943 decrement_reference: delete from rbt: 0x7ff58b52c010 ns3.ecircle.com 20-Jan-2014 11:58:43.974 decrement_reference: delete from rbt: 0x7ff58b52c010 ns3.ecircle.com 20-Jan-2014 11:58:43.974 createfetch: de DS 20-Jan-2014 11:58:44.120 createfetch: postbank.de DS 20-Jan-2014 11:58:44.244 createfetch: de DNSKEY 20-Jan-2014 11:58:44.270 createfetch: newsletter.postbank.de DS 20-Jan-2014 11:58:44.307 createfetch: postbank.de DNSKEY 20-Jan-2014 11:58:44.341 error (insecurity proof failed) resolving 'newsletter.postbank.de/SOA/IN': 2a01:4f8:140:3482::3#53 20-Jan-2014 11:58:44.373 validating @0x7ff57c017bf0: newsletter.postbank.de SOA: got insecure response; parent indicates it should be secure 20-Jan-2014 11:58:44.373 error (insecurity proof failed) resolving 'newsletter.postbank.de/SOA/IN': 195.140.184.21#53 20-Jan-2014 11:58:44.409 validating @0x7ff57c007f00: newsletter.postbank.de SOA: got insecure response; parent indicates it should be secure 20-Jan-2014 11:58:44.409 error (insecurity proof failed) resolving 'newsletter.postbank.de/SOA/IN': 46.4.73.157#53 20-Jan-2014 11:58:44.410 client ::1#55009 (newsletter.postbank.de): query failed (SERVFAIL) for newsletter.postbank.de/IN/SOA at query.c:7406 20-Jan-2014 11:58:44.410 fetch completed at resolver.c:3044 for newsletter.postbank.de/SOA in 0.629817: failure/insecurity proof failed
Re: Insecurity proof failed resolving newsletter.postbank.de - but why?
On Jan 20 2014, Graham Clinch wrote: I'm seeing a dnssec validation error that I can't pin down, for the domain: newsletter.postbank.de. Neither of http://dnsviz.net/ and http://dnssec-debugger.verisignlabs.com/ report finding a problem, but two (ubuntu packaged) versions of bind report a failure validating the delegation as intentionally insecure. I've tried versions: BIND 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1.1 [...] and BIND 9.8.1-P1 built with '--prefix=/usr' '--mandir=/usr/share/man' [...] I can reproduce the effect with BIND 9.9.4, 9.9.4-P2, 9.9,5b1. I think the problem is as follows. The nameservers for postbank.de generate a referral for newsletter.postbank.de which includes a minimally enclosing NSEC3 like this: o27g5ei98muhh7iemoihmbn83qndjsv1.postbank.de. 3600 IN NSEC3 1 0 1 \ 8BB5BA1AF57572EE O27G5EI98MUHH7IEMOIHMBN83QNDJSV2 The salt is generated dynamically (different each time) and doesn't match postbank.de's NSEC3PARAM, but that shouldn't matter. What *does* matter is that the NSEC3 proves that there are no NS records as well (as no DS ones) for newsletter.postbank.de (despite the fact that the NS records are included in the referral). Note the absence of opt-out in the NSEC3. -- Chris Thompson Email: c...@cam.ac.uk ___ 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: Insecurity proof failed resolving newsletter.postbank.de - but why?
Graham Clinch g.cli...@lancaster.ac.uk wrote: I'm seeing a dnssec validation error that I can't pin down, for the domain: newsletter.postbank.de. Looks like a bug in BIND to me. It works out that there is no DS in the parent then gets muddled. I note that postbank.de is in the middle of a double-signature ZSK rollover. Dunno if that is relevant, but it is a bit unusual. 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: newsletter.postbank.de DS: in authvalidated 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: newsletter.postbank.de DS: resuming nsecvalidate 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: newsletter.postbank.de DS: looking for relevant NSEC3 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: newsletter.postbank.de DS: looking for relevant NSEC3 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: newsletter.postbank.de DS: NSEC3 proves name exists (owner) data=0 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: newsletter.postbank.de DS: nonexistence proof(s) found 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80b044860(newsletter.postbank.de/DS): received validation completion event 20-Jan-2014 12:18:51.415 dnssec: debug 3: validator @0x8071e8300: dns_validator_destroy 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80b044860(newsletter.postbank.de/DS): nonexistence validation OK ... right ... 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80b044860(newsletter.postbank.de/DS): clone_results 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80b044860(newsletter.postbank.de/DS): done 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80b044860(newsletter.postbank.de/DS): stopeverything 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80b044860(newsletter.postbank.de/DS): cancelqueries 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80b044860(newsletter.postbank.de/DS): sendevents 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80ac04000(postbank.de/DNSKEY): doshutdown 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80ac04000(postbank.de/DNSKEY): stopeverything 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80ac04000(postbank.de/DNSKEY): cancelqueries 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80ac04000(postbank.de/DNSKEY): unlink 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80ac04000(postbank.de/DNSKEY): destroy 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x80bb74500: newsletter.postbank.de A: in dsfetched2: ncache nxrrset 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x80bb74500: newsletter.postbank.de A: resuming proveunsecure 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x80bb74500: newsletter.postbank.de A: insecurity proof failed ... what? ... 20-Jan-2014 12:18:51.416 resolver: debug 3: fetch 0x801859ff0 (fctx 0x80b044860(newsletter.postbank.de/DS)): destroyfetch 20-Jan-2014 12:18:51.416 resolver: debug 3: fctx 0x80b044860(newsletter.postbank.de/DS): shutdown 20-Jan-2014 12:18:51.416 resolver: debug 3: fctx 0x80b044430(newsletter.postbank.de/A): received validation completion event 20-Jan-2014 12:18:51.416 dnssec: debug 3: validator @0x80bb74500: dns_validator_destroy 20-Jan-2014 12:18:51.416 resolver: debug 3: fctx 0x80b044430(newsletter.postbank.de/A): validation failed 20-Jan-2014 12:18:51.416 resolver: debug 3: fctx 0x80b044430(newsletter.postbank.de/A): add_bad 20-Jan-2014 12:18:51.416 lame-servers: info: error (insecurity proof failed) resolving 'newsletter.postbank.de/A/IN': 195.140.184.21#53 Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: RPZ Whitelist
Hello,
We can't get working whitelist with rpz.
On a Ubuntu 12.04.4 LTS Server we have bind9 9.8.1-P1 and some rpz with
'policy CNAME xxx.xxx.xx' working fine. Now we have a whitelist with 'policy
No-Op' but the whitelist will be ignored.
Configs:
Response-policy {
zone whitelist.rpz policy NO-OP;
.
};
.
zone whitelist.rpz {
type master;
file /etc/bind/whitelist.rpz;
};
We have tested the same Config with passthru policy (instead of No-Op) on
bind9 9.9.4, because we read that 9.8.1 could have issues with the No-Op
policy.
The new version of bind and the new policy don't work either.
Is this still an issue or has anybody been able to run a
whitelist-configuration?
All the best an thanks for your answers.
___
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: Insecurity proof failed resolving newsletter.postbank.de - but why?
Hi List ( Chris Tony), What *does* matter is that the NSEC3 proves that there are no NS records as well (as no DS ones) for newsletter.postbank.de (despite the fact that the NS records are included in the referral). Note the absence of opt-out in the NSEC3. Thanks for the replies - and noticing the missing 'NS'! From my rather brain-busting afternoon reading, I believe this situation is covered by section 4.4 of RFC 6840, which requires a validator to ensure the NS type bit is set for an insecure delegation's NSEC(3) (or that it's covered by opt-out, but as Chris pointed out, that doesn't seem to be the case here). I've left feedback for the dnsviz maintainer in the hopes that this case can be picked up in future. Graham -- Graham Clinch Systems Programmer, Lancaster University ___ 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
classless ptr setup
I have a full /24, which I would like to separate into two /25's, and assign each half to two of my customers. The snag is that *I* maintain the DNS for each of these customers. Is it possible to create the classless setup within my system so that it starts with the /24 but can assign the two classless /25's ? If so, I am stumped on the setup. Any help would be appreciated. ___ 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: classless ptr setup
Hi-- On Jan 20, 2014, at 10:43 AM, Jim Pazarena b...@paz.bz wrote: I have a full /24, which I would like to separate into two /25's, and assign each half to two of my customers. The snag is that *I* maintain the DNS for each of these customers. Is it possible to create the classless setup within my system so that it starts with the /24 but can assign the two classless /25's ? Start by reading: http://www.ietf.org/rfc/rfc2317.txt Regards, -- -Chuck ___ 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: classless ptr setup
In your zone file for the class c (x.y.z), you'd create a delegation like
this in the zone file:
; For 0-127
0/25 NS some.server.
0/25 NS some.other.server.
1 CNAME 1.0/25.z.y.x.in-addr.arpa.
2 CNAME 2.0/25.z.y.x.in-addr.arpa.
...
; For 128 on...
128/25 NS some.server.
128/25 NS some.other.server.
129 CNAME 129.128/25.z.x.y.in-addr.arpa.
130 CNAME 130.128/25.z.x.y.in-addr.arpa.
...
...then the servers you delegated to have this:
named.conf:
zone 0/25.z.y.x.in-addr.arpa {
...
...
}
...and in the zone file:
1 PTR some.host.
...
as normal.
HTH,
-John
From: Jim Pazarena b...@paz.bz
To: bind-users@lists.isc.org
Date: 01/20/2014 01:43 PM
Subject:classless ptr setup
Sent by:bind-users-bounces+johnh=primebuchholz@lists.isc.org
I have a full /24, which I would like to separate into two /25's, and
assign each half to two of my customers. The snag is that *I* maintain
the DNS for each of these customers.
Is it possible to create the classless setup within my system so that it
starts with the /24 but can assign the two classless /25's ?
If so, I am stumped on the setup. Any help would be appreciated.
___
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 consider the environment before printing this e-mail.
This e-mail is intended only for the named person or entity to which it
is addressed and contains valuable business information that is
privileged, confidential and/or otherwise protected from disclosure.
Dissemination, distribution or copying of this e-mail or the information
herein by anyone other than the intended recipient, or an employee, or
agent responsible for delivering the message to the intended recipient,
is strictly prohibited. All contents are the copyright property of the
sender. If you are not the intended recipient, you are nevertheless
bound to respect the sender's worldwide legal rights. We require that
unintended recipients delete the e-mail and destroy all electronic
copies in their system, retaining no copies in any media. If you have
received this e-mail in error, please immediately notify us by calling
our Help Desk at (603) 433-1143, or e-mail to i...@primebuchholz.com.
We appreciate your cooperation.
___
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: Non-responsive name servers when started during boot on OS X Mavericks 10.9
On Jan 17, 2014, at 6:45 PM, Larry Stone lston...@stonejongleux.com wrote: Background: I have been using my Macintosh as a server… […] Problem: This morning, by happenstance, both were rebooted a few minutes apart and suddenly, nobody could access anything. Finally figured out that named on both was not responding (queries timed out). Killed named (which was immediately restarted by Apple’s launchd) and all was well. Rebooted the secondary to see if it was repeatable and same thing. Nothing of interest in the log - both the initial startup at boot time and restart log identically (and it does log the RFC 1918 empty zones warning so it gets that far). I’m guessing there’s some resource not available at boot time that’s causing named to hang but that really just a will guess. I remember fixing this problem way back when Apple first switched to launchd (10.4 or so). Basically, Apple patches (or used to patch) named to make it register with the system to be told when a network interface is added. Their patch allowed named to start up before the network is up, and then essentially get a SIGHUP or something like it every time a network interface comes up or goes down. The problem is that launchd starts named before the network is up. The solution is to have it wait a few seconds before starting. The way we did it back then was to have launchd start a script instead of starting named directly. The script would simply sleep 3 seconds (or something like that) before starting named. It would then stay open. I’d bet that the package from Men Mice includes this script or an equivalent workaround. When I wrote the original script I wrote about above, I worked at Men Mice. Regards, Chris Buxton ___ 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: additional section policy
On Jan 19, 2014, at 7:30 PM, houguanghua houguang...@hotmail.com wrote: Would you please tell me which RFC depicts the policy of 'additional section'? and how bind server deals with 'additional section'? Sometimes the number of 'additional section' is more than numbe of 'authority section'. I don't know how local bind server will do when receiving these additional sections. Local Bind server may: -- pick one name server randomly -- or use sophisticated policies that score name servers and pick more often the ones that replied faster Which is right? The additional section is filled in by the responding name server with whatever records it feels would help the querier in the near future. This could be, for example, the addresses of name servers listed in NS records. It appears you’re asking about specifically this case. This behavior is described in RFC 1034 or 1035, I believe. As for responding to this data by following up on a referral and asking a listed name server, the BIND name server uses the RTT (round trip time) algorithm. Basically, it tries to guess which remote server would respond fastest and queries that server. Regards, Chris Buxton ___ 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: classless ptr setup
Let us know how that goes - never tried it, but it seems like it would
work - it's just going to trigger a lookup to itself for the other zone
I'd say.
-John
From: Jim Pazarena b...@paz.bz
To: bind-users@lists.isc.org
Date: 01/20/2014 02:21 PM
Subject:Re: classless ptr setup
Sent by:bind-users-bounces+johnh=primebuchholz@lists.isc.org
Thank you for this. I am familiar with the setup; I suppose that my
question was unclear.
Can the SAME named.conf handle BOTH the /24 cname assignments AND
the /25 in-addr.arpa records.
Which sounds like a dumb question, but I thought named may not like it.
But I'll set it up and see if named complains (if at all).
Thanks again.
On 2014-01-20 11:00 AM, jo...@primebuchholz.com wrote:
In your zone file for the class c (x.y.z), you'd create a delegation
like
this in the zone file:
; For 0-127
0/25 NS some.server.
0/25 NS some.other.server.
1 CNAME 1.0/25.z.y.x.in-addr.arpa.
2 CNAME 2.0/25.z.y.x.in-addr.arpa.
...
; For 128 on...
128/25 NS some.server.
128/25 NS some.other.server.
129 CNAME 129.128/25.z.x.y.in-addr.arpa.
130 CNAME 130.128/25.z.x.y.in-addr.arpa.
...
...then the servers you delegated to have this:
named.conf:
zone 0/25.z.y.x.in-addr.arpa {
...
...
}
...and in the zone file:
1 PTR some.host.
...
as normal.
HTH,
-John
From: Jim Pazarena b...@paz.bz
To: bind-users@lists.isc.org
Date: 01/20/2014 01:43 PM
Subject:classless ptr setup
Sent by:bind-users-bounces+johnh=primebuchholz@lists.isc.org
I have a full /24, which I would like to separate into two /25's, and
assign each half to two of my customers. The snag is that *I* maintain
the DNS for each of these customers.
Is it possible to create the classless setup within my system so that it
starts with the /24 but can assign the two classless /25's ?
If so, I am stumped on the setup. Any help would be appreciated.
___
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 consider the environment before printing this e-mail.
This e-mail is intended only for the named person or entity to
which it
is addressed and contains valuable business information that is
privileged, confidential and/or otherwise protected from
disclosure.
Dissemination, distribution or copying of this e-mail or the
information
herein by anyone other than the intended recipient, or an
employee, or
agent responsible for delivering the message to the intended
recipient,
is strictly prohibited. All contents are the copyright
property of the
sender. If you are not the intended recipient, you are
nevertheless
bound to respect the sender's worldwide legal rights. We
require that
unintended recipients delete the e-mail and destroy all
electronic
copies in their system, retaining no copies in any media. If
you have
received this e-mail in error, please immediately notify us by
calling
our Help Desk at (603) 433-1143, or e-mail to
i...@primebuchholz.com.
We appreciate your cooperation.
___
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 consider the environment before printing this e-mail.
This e-mail is intended only for the named person or entity to which it
is addressed and contains valuable business information that is
privileged, confidential and/or otherwise protected from disclosure.
Dissemination, distribution or copying of this e-mail or the information
herein by anyone other than the intended recipient, or an employee, or
agent responsible for delivering the message to the intended recipient,
is strictly prohibited. All contents are the copyright property of the
sender. If you are not the intended recipient, you are nevertheless
bound to respect the sender's worldwide legal rights. We require that
unintended recipients delete the e-mail and destroy all electronic
copies in their system, retaining no copies in any media. If you have
received this e-mail in error, please immediately notify us by calling
our Help Desk at (603) 433-1143, or e-mail to i...@primebuchholz.com.
We appreciate your cooperation.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
Re: classless ptr setup
In article mailman.2099.1390245691.20661.bind-us...@lists.isc.org, Jim Pazarena b...@paz.bz wrote: Thank you for this. I am familiar with the setup; I suppose that my question was unclear. Can the SAME named.conf handle BOTH the /24 cname assignments AND the /25 in-addr.arpa records. Which sounds like a dumb question, but I thought named may not like it. But I'll set it up and see if named complains (if at all). Of course it should work. It's just a subdomain delegation and a CNAME. There's no reason a subzone can't be hosted on the same server as the parent zone. There's nothing special about reverse zones as far as BIND is concerned. -- Barry Margolin Arlington, MA ___ 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: classless ptr setup
On 01/20/2014 11:21 AM, Jim Pazarena wrote: Thank you for this. I am familiar with the setup; I suppose that my question was unclear. Can the SAME named.conf handle BOTH the /24 cname assignments AND the /25 in-addr.arpa records. Which sounds like a dumb question, but I thought named may not like it. But I'll set it up and see if named complains (if at all). There's no reason named cannot do it, but the question is why would you want to? It would make sense to split the zone into /25s if you were going to delegate them to your customers, but if you're going to host it all on the same server you get a lot of extra complexity for no real benefit. You may get some useful information at https://dougbarton.us/DNS/2317.html in any case. Doug ___ 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: Non-responsive name servers when started during boot on OS X Mavericks 10.9
On Jan 20, 2014, at 1:22 PM, Chris Buxton cli...@buxtonfamily.us wrote: Problem: This morning, by happenstance, both were rebooted a few minutes apart and suddenly, nobody could access anything. Finally figured out that named on both was not responding (queries timed out). Killed named (which was immediately restarted by Apple’s launchd) and all was well. Rebooted the secondary to see if it was repeatable and same thing. Nothing of interest in the log - both the initial startup at boot time and restart log identically (and it does log the RFC 1918 empty zones warning so it gets that far). I’m guessing there’s some resource not available at boot time that’s causing named to hang but that really just a will guess. I remember fixing this problem way back when Apple first switched to launchd (10.4 or so). Basically, Apple patches (or used to patch) named to make it register with the system to be told when a network interface is added. Their patch allowed named to start up before the network is up, and then essentially get a SIGHUP or something like it every time a network interface comes up or goes down. The problem is that launchd starts named before the network is up. The solution is to have it wait a few seconds before starting. The way we did it back then was to have launchd start a script instead of starting named directly. The script would simply sleep 3 seconds (or something like that) before starting named. It would then stay open. Thanks Chris. As I mentioned in a follow-up, I did reach that conclusion after finding it was responsive on 127.0.0.1 but not on the machine’s external address. And I have worked around it in exactly the way you mention except I have the sleep at 30 seconds (I tried 15 and it was too short - but that machine is slow; OTOH, I tested on my new MBP with an SSD system disk and it boots so fast that named seems to come up OK. For my needs, the script delay as a work-around is “good enough”. I’d bet that the package from Men Mice includes this script or an equivalent workaround. When I wrote the original script I wrote about above, I worked at Men Mice. The problem I have with it is there’s no documentation I can find. If they have patched it, I’d like to know about. One reason I’ve moved away from Apple provided versions (besides them suddenly removing it) and am now going with all “built from source” for my server software is Apple’s tendency to make undocumented changes to open source software. It’s been a problem in the support environments of some other software I use (not that this issue is unique to Apple). I used a package inspector to look at the Men Mice package and there’s no launchd plist in there so it’s not clear to me how they get it started. But inspecting packages is new to me so there may be other things I’m not seeing. In any event, as I said, I have a “good enough” solution for my needs so anything further on this will be mostly of intellectual interest. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature ___ 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: Insecurity proof failed resolving newsletter.postbank.de - but why?
In message alpine.lsu.2.00.1401201234190.13...@hermes-2.csi.cam.ac.uk, Tony Finch writes: Graham Clinch g.cli...@lancaster.ac.uk wrote: I'm seeing a dnssec validation error that I can't pin down, for the domain: newsletter.postbank.de. Looks like a bug in BIND to me. It works out that there is no DS in the parent then gets muddled. I note that postbank.de is in the middle of a double-signature ZSK rollover. Dunno if that is relevant, but it is a bit unusual. It looks like a missing NS bit in the NSEC3 record which causes the isdelegation check to fail. DNSSEC proves delegations exist, or don't exist, as the case may be unless the delegation is in a optout range. ; DiG 9.10.0a1 newsletter.postbank.de +dnssec ds ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 28762 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;newsletter.postbank.de.IN DS ;; AUTHORITY SECTION: postbank.de.8981IN SOA ns1.postbank.de. webmaster.postbank.de. 2010022883 86400 7200 604800 86400 postbank.de.8981IN RRSIG SOA 7 2 86400 20140125074615 20140118074615 55913 postbank.de. MAyl9jCfxylOItqAJc/Pyb55D/KI8reTVkxLYJ2oecBzhNoKTiaYw7o9 ceU7CSXRjIwWLe6DL2SKbHKrwe8G3lYHgoYOwmV62k+TgpM9Cvr8gyV/ LdheakhaDuWYmnehF5+Q1gDWQpNwoqpBLsZxQYC9B9Lg+Q2EYJflVRKf /8o= postbank.de.8981IN RRSIG SOA 7 2 86400 20140126152235 20140119152235 32699 postbank.de. KWYHjij78NobHPVWt4SpPQUWCR/uxTjQ9ZlAplju25xazg4aPcN5g5Qw wQDPXNLVSMRhb6YZdfffN877a7CBlWPlRC5s488wwqT94kUHyOdIT+Oi UqNACz6i5Tmv9bf6ViS97sjF3JoAg2Uc3nDHFojVojzC6C6MG8tqmy49 0Pg= 393dv6p4d1fhr0kisru6alkuv0vq5th0.postbank.de. 8981 IN RRSIG NSEC3 7 3 86400 20140128024505 20140121024505 55913 postbank.de. fsi6k+JrX3ohDihsO0XG9Upl7UOs7ceMLAv3UBqgf/u7KCJiA/rp6kMO o9nqk0dJVPhcIKnB01aV+2/+MKsX0Df346CCVF11y2+mztL2Cem5K0dj vEnziZCYam34IhbKE+LuWTfPQFq4sUaMYDyXAsZi8anoMgwYtQTUdpRg Ego= 393dv6p4d1fhr0kisru6alkuv0vq5th0.postbank.de. 8981 IN RRSIG NSEC3 7 3 86400 20140128024505 20140121024505 32699 postbank.de. cCDLXMaENZIu31d1Qb4CStZAKxwtRScfyBAGoJ5LQ4mlAjNnnlhqyxNv ig+dnMWa24qL9TLoeBMr25cpcXrHi/+SkSJkQvpuzMf5lVFWekVPPOx1 ZcCPui+etUdrIRcB49a1ksT71STTQUI0noXKH6gZ/k5AisRoN/I/Z+TB ku4= 393dv6p4d1fhr0kisru6alkuv0vq5th0.postbank.de. 8981 IN NSEC3 1 0 1 D252CA1843C35103 393DV6P4D1FHR0KISRU6ALKUV0VQ5TH1 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Jan 21 14:20:11 EST 2014 ;; MSG SIZE rcvd: 864 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: newsletter.postbank.de DS: in authvalidated 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: newsletter.postbank.de DS: resuming nsecvalidate 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: newsletter.postbank.de DS: looking for relevant NSEC3 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: newsletter.postbank.de DS: looking for relevant NSEC3 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: newsletter.postbank.de DS: NSEC3 proves name exists (owner) data=0 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x8071e8300: newsletter.postbank.de DS: nonexistence proof(s) found 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80b044860(newsletter.postbank.de/DS): received validation completion event 20-Jan-2014 12:18:51.415 dnssec: debug 3: validator @0x8071e8300: dns_validator_destroy 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80b044860(newsletter.postbank.de/DS): nonexistence validation OK ... right ... 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80b044860(newsletter.postbank.de/DS): clone_results 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80b044860(newsletter.postbank.de/DS): done 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80b044860(newsletter.postbank.de/DS): stopeverything 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80b044860(newsletter.postbank.de/DS): cancelqueries 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80b044860(newsletter.postbank.de/DS): sendevents 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80ac04000(postbank.de/DNSKEY): doshutdown 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80ac04000(postbank.de/DNSKEY): stopeverything 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80ac04000(postbank.de/DNSKEY): cancelqueries 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80ac04000(postbank.de/DNSKEY): unlink 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx 0x80ac04000(postbank.de/DNSKEY): destroy 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x80bb74500: newsletter.postbank.de A: in dsfetched2: ncache nxrrset 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x80bb74500: newsletter.postbank.de A: resuming proveunsecure 20-Jan-2014 12:18:51.415 dnssec:
Re: Insecurity proof failed resolving newsletter.postbank.de - but why?
On Mon, Jan 20, 2014 at 12:46 PM, Graham Clinch g.cli...@lancaster.ac.ukwrote: Thanks for the replies - and noticing the missing 'NS'! From my rather brain-busting afternoon reading, I believe this situation is covered by section 4.4 of RFC 6840, which requires a validator to ensure the NS type bit is set for an insecure delegation's NSEC(3) (or that it's covered by opt-out, but as Chris pointed out, that doesn't seem to be the case here). I've left feedback for the dnsviz maintainer in the hopes that this case can be picked up in future. Should be fixed now. Not sure why I hadn't implemented that check before, but I have now. Casey ___ 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
