Re: error when removing expired key files

2017-05-09 Thread Nis Wechselberg
Am 09.05.2017 um 06:52 schrieb Gordon Messmer:
>> You might also want to take a look at the dnssec-keymgr utility:
>> https://ftp.isc.org/isc/bind9/9.11.1/doc/arm/man.dnssec-keymgr.html
> 
> That looks great.  Red Hat is shipping bind 9.9, so I hadn't seen it. 
> I'd imagine it doesn't actually depend on any 9.11 features, and can run
> on bind 9.9?

I can't tell for 9.9 exactly but I am currently running a self-compiled
dnssec-keymgr in combination with bind 9.10 from ubuntu repos and it
works without problems.
If I remember correctly the changelog mentioned improvements to the used
tools, but I believe it were no game-breaking changes.



signature.asc
Description: OpenPGP digital 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

bind unexpectedly quit, how to debug

2017-05-09 Thread Paul Seward
Hi all,

We've got some recursive-only servers running bind 9.8.1 on CentOS 6.9
(using 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.1 from the CentOS repos)

They've unexpectedly quit a couple of times in the last month, leaving
errors like this in the logs:

09-May-2017 09:12:56.747 dnssec: info: validating @0x7f37dbf852e0:
ntp1.glb.nist.gov A: no valid signature found
09-May-2017 09:12:56.831 dnssec: info: validating @0x7f37d7dd3100:
www.puma.com.cdn.cloudflare.net A: no valid signature found
09-May-2017 09:12:58.172 dnssec: info: validating @0x7f37dbf852e0:
cdnjs.cloudflare.com : no valid signature found
09-May-2017 09:12:59.470 dnssec: info: validating @0x7f37dbf832c0: cdnjs.com
A: no valid signature found
09-May-2017 09:13:02.401 general: critical: validator.c:1861:
INSIST(rdataset->type == ((dns_rdatatype_t)dns_rdatatype_dnskey)) failed,
back trace
09-May-2017 09:13:02.401 general: critical: #0 0x7f3831b5007f in ??
09-May-2017 09:13:02.401 general: critical: #1 0x7f38304afa9a in ??
09-May-2017 09:13:02.401 general: critical: #2 0x7f383145eb4c in ??
09-May-2017 09:13:02.401 general: critical: #3 0x7f3831466620 in ??
09-May-2017 09:13:02.401 general: critical: #4 0x7f38304ce858 in ??
09-May-2017 09:13:02.401 general: critical: #5 0x7f382fe83aa1 in ??
09-May-2017 09:13:02.401 general: critical: #6 0x7f382f3e3bcd in ??
09-May-2017 09:13:02.401 general: critical: exiting (due to assertion
failure)

The DNSSec validation errors which precede the validator.c assertion don't
appear to trigger the bug when tested against an identical resolver.

What's the best way for me to get more information about what's causing
bind to quit?

-Paul
-- 
--
Paul Seward,Senior Systems Administrator,University of Bristol
paul.sew...@bristol.ac.uk  +44 (0)117 39 41148GPG Key ID: E24DA8A2
GPG Fingerprint:7210 4E4A B5FC 7D9C 39F8  5C3C 6759 3937 E24D A8A2
___
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: inline-signing a zone that exists in two views

2017-05-09 Thread Tony Finch
Gordon Messmer  wrote:
> On 05/08/2017 03:26 AM, Tony Finch wrote:

> > You can't have zones in different views (which sre by implication
> > different zones, or different versions of the same zone) pointing to the
> > same files on disk, because updates to one version will corrupt the other
> > version.
>
> Even if one of them is treated as read-only?

That won't work either because a static master zone won't read the journal
so it will be perpetually out of sync with the other version.

> > Make the second zone a clone of the first using the in-view option
> > instead.
>
> That looks like the right thing to do, but appears to be available only on
> bind 9.10+, and I'm supporting Red Hat servers with 9.9. Are there any
> solutions here, or do I need to roll my own packages until Red Hat catches up?

The classic solution is to make one view a slave of the other. Configure
the slave zone with `masters { localhost key my-tsig; };` and configure
the master view with `match-clients { key my-tsig; };`.

Another alternative (if one view is recursive) is to use a static-stub
zone.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
Sole: East 5 or 6. Moderate, occasionally rough in south. Fair. Good.
___
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: bind unexpectedly quit, how to debug

2017-05-09 Thread Paul Seward
Hi Jim,

I thought I might get that sort of response, I'm not so much asking for a
fix as asking how I can find more information.

We're in the process of migrating from this version of bind to something
more recent - and may well use this incident as a lever to speed up some of
the political hurdles involved in doing so - but until then I need to show
management that I've done my due diligence into investigating the root
cause.

So if anyone has any suggestions for how I can get more information about
what's triggering the crash I would still welcome them.

-Paul

On 9 May 2017 at 11:04, Jim Reid  wrote:

>
> > On 9 May 2017, at 10:47, Paul Seward  wrote:
> >
> > We've got some recursive-only servers running bind 9.8.1 on CentOS 6.9
> (using 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.1 from the CentOS repos)
> >
> > They've unexpectedly quit a couple of times in the last month, leaving
> errors like this in the logs:
>
> Come back when you see the same problem with a current version of BIND (ie
> 9.10 or 9.11). Version 9.8 has been dead for a while and many of its bugs
> have been fixed in newer releases.
>
>


-- 
--
Paul Seward,Senior Systems Administrator,University of Bristol
paul.sew...@bristol.ac.uk  +44 (0)117 39 41148GPG Key ID: E24DA8A2
GPG Fingerprint:7210 4E4A B5FC 7D9C 39F8  5C3C 6759 3937 E24D A8A2
___
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

CNAME with RPZ pointing to RPZ A record ?

2017-05-09 Thread devzero
Hello, 

we have lots of internal extra zones on our dns for development overrides.

I came across RPZ in bind, which looks interesting to us because we could drop 
tons of extra zones and put everything in a rpz-development-override zone file.

I tried RPZ and i can successfully put in an A record or CNAME pointing to 
"any" IP or FQHN.

We use lot`s of CNAME aliasses for server virtual host name aliasses, i.e.

myserver IN A   1.2.3.4
myserver-vhost1  IN CNAME   myserver.
myserver-vhost2  IN CNAME   myserver.
myserver-vhost3  IN CNAME   myserver.

How can we do that with RPZ ?

Apparentyl I can use A records and CNAME in RPZ zone file, but as soon as i 
create a CNAME which points to an A-record within the RPZ Zone file, it doesn`t 
resolve :

rpz-zonefile:

www.this-is-a-test.de   CNAME   www.google.de.
www.this-is-another-test.de   A 1.2.3.4
www.this-doesnt-work.de CNAME www.this-is-another-test.de.


# nslookup www.this-is-a-test.de
Server: 127.0.0.1
Address:127.0.0.1#53

Non-authoritative answer:
www.this-is-a-test.de   canonical name = www.google.de.
Name:   www.google.de
Address: 172.217.18.3

# nslookup www.this-is-another-test.de
Server: 127.0.0.1
Address:127.0.0.1#53

Non-authoritative answer:
Name:   www.this-is-another-test.de
Address: 1.2.3.4

# nslookup www.this-doesnt-work.de
Server: 127.0.0.1
Address:127.0.0.1#53

** server can't find www.this-doesnt-work.de: NXDOMAIN


May  9 12:16:44 nameserverhost named[2902]: client 127.0.0.1#51602 
(www.dies-ist-ein-test.de): rpz QNAME Local-Data rewrite www.this-is-a-test.de 
via www.this-is-a-test.de.rpz-development-overrides
May  9 12:16:52 nameserverhost named[2902]: client 127.0.0.1#53888 
(www.dies-ist-noch-ein-test.de): rpz QNAME Local-Data rewrite 
www.this-is-another-test.de via 
www.this-is-another-test.de.rpz-development-overrides
May  9 12:16:59 nameserverhost named[2902]: client 127.0.0.1#37241 
(www.wieso-funktioniert-das-nicht.de): rpz QNAME Local-Data rewrite 
www.this-doesnt-work.de via www.this-doesnt-work.de.rpz-development-overrides


regards
roland 

___
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: bind unexpectedly quit, how to debug

2017-05-09 Thread Tony Finch
Paul Seward  wrote:
>
> I thought I might get that sort of response, I'm not so much asking for a
> fix as asking how I can find more information.

It'll be one of the 42 CVEs in the table at the top of this page:
https://kb.isc.org/article/AA-00913/74/BIND-9-Security-Vulnerability-Matrix.html

I think all of them probably apply to the version you are running.

However you are running a version with Red Hat's mystery meat patches,
so the vulnerabilities in what you are running won't match the nominal
ISC version number.

If you are running a service based on Red Hat's code, you should really
be paying for support from Red Hat. If that isn't an option, use Carl
Byington's RPMs instead.

> but until then I need to show management that I've done my due diligence
> into investigating the root cause.

Well the root cause is that your management aren't supporting your
routine security patch process!

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
North Shannon, Rockall, Malin, South Hebrides: Variable, mainly easterly at
first, 3 or 4. Slight or moderate. Fair. Good.
___
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: bind unexpectedly quit, how to debug

2017-05-09 Thread G.W. Haywood

Hi there,

On Tue, 9 May 2017, Paul Seward wrote:


... I'm not so much asking for a fix as asking how I can find more
information. ...


grep '\(released\|security\)' bind-9.10.5/CHANGES | head -n 90

--

73,
Ged.
___
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: CNAME with RPZ pointing to RPZ A record ?

2017-05-09 Thread Tony Finch
devz...@web.de  wrote:
>
> We use lot`s of CNAME aliasses for server virtual host name aliasses, i.e.
>
> myserver IN A   1.2.3.4
> myserver-vhost1IN CNAME   myserver.
> myserver-vhost2IN CNAME   myserver.
> myserver-vhost3IN CNAME   myserver.
>
> How can we do that with RPZ ?

You could set up canonical names for your dev servers outside the
namespace that needs to be overridden, so that you can point the RPZ
CNAMEs outside the RPZ domain.

Or you could replace the RPZ CNAME records with address records.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
Biscay: Easterly or northeasterly 5 or 6, occasionally 7 at first, becoming
variable 4 later in south. Moderate or rough, becoming slight or moderate
later. Thundery showers later. Good, occasionally poor later.
___
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


Aw: Re: CNAME with RPZ pointing to RPZ A record ?

2017-05-09 Thread devzero
that would subvert the idea of rpz overriding, as i would need to create zone 
files for zones i want to manage in rpz zone.

i´m curious why it doesn`t work with rpz zone like normal zones.

is that considered to be a bug, a missing feature or possibly intentional ?

roland

> Gesendet: Dienstag, 09. Mai 2017 um 12:39 Uhr
> Von: "Tony Finch" 
> An: devz...@web.de
> Cc: bind-users@lists.isc.org
> Betreff: Re: CNAME with RPZ pointing to RPZ A record ?
>
> devz...@web.de wrote: > > We use lot`s of CNAME aliasses for server virtual 
> host name aliasses, i.e. > > myserver IN A 1.2.3.4 > myserver-vhost1 IN CNAME 
> myserver. > myserver-vhost2 IN CNAMEmyserver. > myserver-vhost3 IN 
> CNAMEmyserver. > > How can we do that with RPZ ? You could set up 
> canonical names for your dev servers outside the namespace that needs to be 
> overridden, so that you can point the RPZ CNAMEs outside the RPZ domain. Or 
> you could replace the RPZ CNAME records with address records. Tony. -- 
> f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Biscay: Easterly or 
> northeasterly 5 or 6, occasionally 7 at first, becoming variable 4 later in 
> south. Moderate or rough, becoming slight or moderate later. Thundery showers 
> later. Good, occasionally poor later.
___
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: Aw: Re: CNAME with RPZ pointing to RPZ A record ?

2017-05-09 Thread Tony Finch
devz...@web.de  wrote:
>
> i´m curious why it doesn`t work with rpz zone like normal zones.

The RPZ machinery (mostly) works between getting an answer and returning
it to a client, which is why it is called "response policy". At the moment
it is a one-shot thing, but you are asking for RPZ to apply to RPZ results.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
Dogger: West or northwest 4 or 5, becoming variable 3 at times. Moderate,
occasionally slight later. Fair. Good.___
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: inline-signing a zone that exists in two views

2017-05-09 Thread Gordon Messmer

On 05/09/2017 03:15 AM, Tony Finch wrote:

The classic solution is to make one view a slave of the other. Configure
the slave zone with `masters { localhost key my-tsig; };` and configure
the master view with `match-clients { key my-tsig; };`.



OK, I think I've got this nailed down.  I had to move the "public" view 
so that it was listed first in named.conf.  That view previously had no 
match-client setting, but now is set to "match-clients   { key tsig-key; 
!localhost; 0.0.0.0/0; };" so that it allows access with the key but 
does not match localhost otherwise (which would result in refusing 
recursion) but does include the rest of the IPv4 space.  The zone in the 
"local" view is now a slave with "masters { 127.0.0.1 key tsig-key; };"


Seems to work.  Localhost can look up records in the zone as well as 
external records.  External hosts can get records from the zone, but 
can't make recursive requests.


I'm happy that it's working, but it seems like it was fairly difficult 
to get right.  Am I doing an unusual thing?  Is it considered 
best-practice (or just normal) for authoritative servers to just not use 
the local server for resolution?


Thanks for your help!

___
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