Re: error when removing expired key files
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
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
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
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 ?
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
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
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 ?
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 ?
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 ?
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
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