identifying DNSKEY by label

Hi all, I have several ZSKs in one zone, but only one is being used for signing. The others seem to be relicts from earlier rollovers. I would like to delete the unused DNSKEY RRs via nsupdate, but how can I identify a DNSKEY by label ? The zone has not yet been converted to dnssec-policy but

GUI tool to help replacing zone file editing by ddns

Hi all, once, I received the advice (from Tony?) to move to ddns. At that time I had trouble with zones no longer being updated from reloaded zone files. (Reloading zone files with inline-signing and autodnssec-maintain could interfere with key-signing activities of the server.) To help admins

Re: How to return REFUSED

> Am 06.05.2021 um 18:41 schrieb Axel Rau : > > This NS has some other clients in the DMZ LAN, so I need Views. With 2 views ddos trace looks much better: 17:40:21.483188 186.149.116.55.80 > 91.216.35.171.53: [no udp cksum] 1+ RRSIG? pizzaseo.com.(30) (ttl 242, id 21165, l

Re: How to return REFUSED

> Am 05.05.2021 um 22:06 schrieb Kevin Darcy via bind-users > mailto:bind-users@lists.isc.org>>: > > I just checked the ARM, and it denotes that "match-recursive-only" (boolean) > still exists for views. So, you might be able to set up a special view with > that, as well as a negated

Re: How to return REFUSED

> Am 06.05.2021 um 12:05 schrieb Matus UHLAR - fantomas : > > > Which named version do you run? 9.16.15 > do you use views? No, but after reading Tonys response, I’m now starting to convert my config to views. Axel --- PGP-Key: CDE74120 ☀ computing @ chaos claudius signature.asc

Re: How to return REFUSED

> Am 06.05.2021 um 16:45 schrieb Tony Finch : > > Axel Rau wrote: > >> I have, >> >> allow-query { any; }; >> allow-query-cache { recursive-users; }; >> allow-recursion { recursive-users; }; >> >> How can I make

How to return REFUSED

I have, allow-query { any; }; allow-query-cache { recursive-users; }; allow-recursion { recursive-users; }; How can I make sure that none recursive-users get a REFUSED if query is recursive? Axel PS: I want to minimize the responses to this amplification attack: - - -

[RESOLVED] Why are no notifies send?

> Am 22.10.2020 um 23:31 schrieb Tony Finch : > > > Notifies from my primary to my on-site servers go over IPv6 with a TSIG > key. They are all dual-stack. After reading this, I did a test with another secondary and the notify worked over IPv6! I saw it in the logs of the secondary, but no

Re: Why are no notifies send?

> Am 20.10.2020 um 16:02 schrieb Sami Ait Ali Oulahcen : > > I don't see the part where the acls are used. Yes, acls have nothing to do with the notify, instead they are used in an allow-transfer statement. > Is "also-notify" meant to be "allow-notify" ? No: From bind 9.16 ARM: also-notify

Re: Why are no notifies send?

Using the IPv4 address of the dual stack notify receiver, works. Has anybody a working IPv6 notify address in use? Axel > Am 16.10.2020 um 10:59 schrieb Axel Rau : > > Signierter PGP-Teil > Hi all, > > related parts from my named.conf: > - - - > include "/usr/l

Why are no notifies send?

Hi all, related parts from my named.conf: - - - include "/usr/local/etc/namedb/dns-keys/Kns4-he.net.conf"; // slave.dns.he.net pulls zones from us, ns1.he.net receives notify from us server 216.218.133.2 { keys { ns4-he.net. ; }; }; server 2001:470:600::2 { keys { ns4-he.net. ;

[RESOLVED] Re: No response from localhost with "allow-query { any; };"

> Am 01.09.2020 um 22:28 schrieb Axel Rau : > > tcp queries are being answered, but udp queries receive no response. > This is independent of client location (local, remote). > > A ktrace shows 8 bytes are written on fd 89, the 8 bytes read on fd 88. > The next read gets a

Re: No response from localhost with "allow-query { any; };"

tcp queries are being answered, but udp queries receive no response. This is independent of client location (local, remote). A ktrace shows 8 bytes are written on fd 89, the 8 bytes read on fd 88. The next read gets an errno 35 (see below). clueless, Axel root@ns5:/var/log # uname -a FreeBSD

Re: No response from localhost with "allow-query { any; };"

> Am 01.09.2020 um 16:57 schrieb Petr Menšík : > > Please include any listen-on { ... } and listen-on-v6 { ... } clauses. > > It seems any of 127.0.0.1; ::1; nor localhost; is listed in them. > Because it is not listening on localhost socket, it would not answer any > queries. > Voilà:

Re: No response from localhost with "allow-query { any; };"

and you would not know. > > First you need to use a tool from your operating system > to check what is listening on those ports, and then use > `dig` (or other DNS debugging tool) to send actual DNS > queries. > > Ondrej > -- > Ondřej Surý (He/Him) > ond...@isc.org >

Re: No response from localhost with "allow-query { any; };"

Thanks for your answer! > Am 01.09.2020 um 16:18 schrieb Warren Kumari : > > The output you included doesn't really show very much, other than that nc > connect to port 53. > > I'd suggest: > dig ns5.lrau.net @localhost > dig ns5.lrau.net

No response from localhost with "allow-query { any; };"

Hi! this is a new server, which answers external queries, sends notifies and pushes axfrs. It does not answer any query from localhost nor shows any notifies from master in the logs. From local: root@ns5:/ # nc -v localhost 53 Connection to localhost 53 port [tcp/domain] succeeded! ^C

[RESOLVED] Re: TXT with dot in NAME for ACME via dynamic update (Axel Rau)

> Am 14.03.2020 um 19:21 schrieb Timothe Litt : > > dig _acme-challenge.imap.lrau.net. > > is missing a record type. The default is A. > > > dig _acme-challenge.imap.lrau.net. txt > > will likely give you better results > Natural. (-; It seems to work: ;; ANSWER SECTION:

Re: TXT with dot in NAME for ACME via dynamic update

> Am 14.03.2020 um 18:14 schrieb Chuck Aurora : > >> it seems, the dynamic update protocol does not allow things like >> _acme-challenge.some-host.some.domain TXT >> "tR0VhMRfb4v5WsctEgoD3aWNRJ73n2wqn9hlTPE9pA0" >> because there is no zone >> some-host.some.domain > > I am

TXT with dot in NAME for ACME via dynamic update

Hi all, it seems, the dynamic update protocol does not allow things like _acme-challenge.some-host.some.domain TXT "tR0VhMRfb4v5WsctEgoD3aWNRJ73n2wqn9hlTPE9pA0" because there is no zone some-host.some.domain However named accepts such constructs, if loaded from text zone

Re: Logging of notify sending

> Am 26.05.2019 um 18:38 schrieb Rick Dicaire : > A quick google search of "bind also-notify key" returns: > > https://kb.isc.org/docs/aa-00851 > https://kb.isc.org/docs/aa-00296 > > Looks like keys provide a means to differentiate views. ARM for bind 9.14.1 says on page 24: For example, a

Re: Logging of notify sending

> Am 26.05.2019 um 00:24 schrieb Greg Rivers : > > On Saturday, May 25, 2019 4:07:45 PM CDT Axel Rau wrote: >>> Am 25.05.2019 um 22:30 schrieb Anand Buddhdev : >>> 25-May-2019 10:00:02.589 notify: zone 2.in-addr.arpa/IN: sending notifies >>> (serial 1558778

Re: Logging of notify sending

> Am 25.05.2019 um 22:30 schrieb Anand Buddhdev : > > 25-May-2019 10:00:02.589 notify: zone 2.in -addr.arpa/IN: > sending > notifies (serial 1558778402) Yes, but even with debug 8, I get only this summary. No chance to get an log entry per server and the TSIG key in use. Thanks,

Re: Logging of notify sending

> Am 25.05.2019 um 21:02 schrieb Rick Dicaire : > > > > On Sat, May 25, 2019 at 12:27 PM Axel Rau <mailto:axel@chaos1.de>> wrote: > Hi all, > > category notify seems to cover reception of notifies. > How can I log sending of notifies? > I want

Logging of notify sending

Hi all, category notify seems to cover reception of notifies. How can I log sending of notifies? I want to check, if the TSIG key is being used for the notify. tcpdump seems not to show any keys. Thanks, Axel --- PGP-Key:29E99DD6 ☀ computing @ chaos claudius

Re: inline-signing: SOA serial out of sync

> Am 21.06.2018 um 08:18 schrieb Stefan Förster via bind-users > : > > > I used to see something similar (although views were involved), where BIND > was not picking up changes to a zone when only included files were changed: > >

Re: inline-signing: SOA serial out of sync

> Am 14.06.2018 um 18:30 schrieb Axel Rau : > > I include the zone file with the 2 included files, a AXFR dump of it and the > options and zone statement (which is not in a view) of the server config in a > zip archiv. I saw no comments on the provided data, so I assume, no

Re: inline-signing: SOA serial out of sync

Am 14.06.2018 um 17:14 schrieb Matthew Pounsett <m...@conundrum.com>:On 14 June 2018 at 10:16, Axel Rau <axel@chaos1.de> wrote:Am 14.06.2018 um 16:12 schrieb Alan Clegg <a...@clegg.com>:Additionally, I read this as "the records changed are in an includedfile&q

Re: inline-signing: SOA serial out of sync

> Am 14.06.2018 um 15:44 schrieb Matthew Pounsett : > > This now sounds very different from the original report. Are you saying that > the zone started with two TLSA records, you changed it to have only one, > reloaded the zone, but then none were present? Yes. > > That's a very different

Re: inline-signing: SOA serial out of sync

> Am 14.06.2018 um 16:12 schrieb Alan Clegg : > > Additionally, I read this as "the records changed are in an included > file" -- is the serial number in the "including" zone being incremented? Yes. Axel --- PGP-Key:29E99DD6 ☀ computing @ chaos claudius signature.asc Description: Message

Re: inline-signing: SOA serial out of sync

> Am 07.06.2018 um 13:36 schrieb Axel Rau : > > > occasionally named 9.11.3 fails to increment SOA serial like here: > > file: 2018060605 dns: 2018060604 It just happened again. An included zone file has been changed from 2 TLSA RRs to one: - - - _443._tcp.git

Re: inline-signing: SOA serial out of sync

Hi Matthew, sorry for my late answer. > Am 07.06.2018 um 15:31 schrieb Matthew Pounsett : > > > > On 7 June 2018 at 07:36, Axel Rau wrote: > Hi all, > > occasionally named 9.11.3 fails to increment SOA serial like here: > > file: 2018060605 dns: 201806

Re: inline-signing: SOA serial out of sync

Hi Tony, sorry for the late replay. > Am 07.06.2018 um 14:20 schrieb Tony Finch : > > Axel Rau wrote: >> >> occasionally named 9.11.3 fails to increment SOA serial like here: >> >> file: 2018060605 dns: 2018060604 > > With inline signing the

inline-signing: SOA serial out of sync

Hi all, occasionally named 9.11.3 fails to increment SOA serial like here: file: 2018060605 dns: 2018060604 zone file was edited by script and a rndc reload given. This usually works perfect, but here: Only entry in log file: notify: debug 3: zone lrau.net/IN (signed): sending

$include not working with inline-signing

Hi, I have auto-dnssec maintain; inline-signing yes; and tried a $INCLUDE tmx4.lrau.net.tlsa in my manually maintained zone file. It seems that everything after the $include is missing in the zone. The $included file contains one or 2 TLSA RRs with absolute origin like

Re: key rollover with BIND 9.9

Am 26.01.2013 um 00:39 schrieb Michael W. Lucas: Hi, I'm trying to automate key rollover with BIND 9.9.2 (will soon upgrade to new rev). I have a couple of elementary questions that seem to be answered briefly in the documentation, but I suspect that my grasp of key rollover is clouded by

Announcing DSKM DNSsec key management tool ready for beta testing

This is a DNSsec key management add-on to ISC bind 9.9.x for zones with auto-dnssec maintain; inline-signing yes; It creates and deletes keys, submits DS or DNSKEY RRs to parent, validates chain of trust and does alarming per email if something goes wrong. Zones may be local, public

Re: 9.9.1 continues to sign with inactive KSK

Am 25.05.2012 um 14:16 schrieb Tony Finch: Axel Rau axel@chaos1.de wrote: The tags of the KSKs with their dates are (set with dnssec-settime): --- [framail.de/KSK/1699/8(A:2012-05-23T17:55:02, I:2012-05-27T17:55:02, D:2012-05-28T17:55:02)] [framail.de/KSK/46210/8(A:2012-05-20T16:55

Re: KSK stays published 3 days after delete time

Am 10.05.2012 um 23:52 schrieb Evan Hunt: key 22924 of framail.de has a delete date of 2012-05-07T14:55:02 set. It has been deleted from the repository at 2012-05-07T14:55:02.569706, but is still included by named 9.9.0 in the zone framail.de (as of 2012-05-10T19:51:32). To clarify: I'm

KSK stays published 3 days after delete time

All, key 22924 of framail.de has a delete date of 2012-05-07T14:55:02 set. It has been deleted from the repository at 2012-05-07T14:55:02.569706, but is still included by named 9.9.0 in the zone framail.de (as of 2012-05-10T19:51:32). Is this a bug, triggered by my timing? Should I wait one more

Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)

Am 06.03.2012 um 08:55 schrieb Evan Hunt: You should be able to use 'rndc signing -nsec3param' before the zone is signed. It's working for me: zone example.nil { type master; inline-signing yes; auto-dnssec maintain; file example1.db;

Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)

Am 06.03.2012 um 17:28 schrieb Evan Hunt: However, whenever you do wish to change them, Yes. you can do so with 'rndc signing -nsec3param', and the chain will be updated automatically. I see. As named is looking periodically for appearing/disappearing or changed keys in the key directory, I

Re: A few conceptual question about dnssec.

Am 18.02.2012 um 17:35 schrieb dE .: The DS record is a signature right? No its the hash of a DNSKEY (KSK) in the child zone. The DS is signed with a RRSIG. Axel --- PGP-Key:29E99DD6 ☀ +49 151 2300 9283 ☀ computing @ chaos claudius ___ Please

Re: State diagram for DNSsec key lifecycle

Am 14.02.2012 um 16:33 schrieb Axel Rau: Am 13.02.2012 um 19:48 schrieb Axel Rau: Here is the next revision with comments from Mark and Jeff incorporated (same URL): https://www.chaos1.de/svn-public/repos/network-tools/DNSsec/trunk/dnssec_key_states.pdf I'm still unsure about

Re: State diagram for DNSsec key lifecycle

Am 11.02.2012 um 11:33 schrieb Axel Rau: Am 10.02.2012 um 01:57 schrieb Mark Andrews: You don't submitt the initial DS until the KSK is active and any old state about the DNSKEY as clear caches. I recommend activate + publish at the same time. I see. draft-ietf-dnsop-dnssec-key-timing

Re: State diagram for DNSsec key lifecycle

Am 10.02.2012 um 01:57 schrieb Mark Andrews: You don't submitt the initial DS until the KSK is active and any old state about the DNSKEY as clear caches. I recommend activate + publish at the same time. I see. draft-ietf-dnsop-dnssec-key-timing-02 uses the term 'used for signing' as synonym

State diagram for DNSsec key lifecycle

While writing a script for key maintenance of 'auto-dnssec maintained' zones, I try to understand the required actions and states of the keys. Please comment on this state diagram: https://www.chaos1.de/svn-public/repos/network-tools/DNSsec/trunk/dnssec_key_states.pdf Actions of the

Extracting key tag from DNSKEY

Can I extract the key tag from a DNSKEY, obtained via dig? Axel --- PGP-Key:29E99DD6 ☀ +49 151 2300 9283 ☀ computing @ chaos claudius ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users

Re: 9.9.0rc1: example from arm 4.8.3 does not validate

Am 18.01.2012 um 23:54 schrieb Evan Hunt: I tried the example from page 23 with a local zone, a trusted key and inline-signing, like: [...] But I'm getting no ad-flag: That's normal; authoritative servers don't set the AD bit, validating resolvers do. (There's not much point in having

9.9.0rc1: example from arm 4.8.3 does not validate

Hi all, I tried the example from page 23 with a local zone, a trusted key and inline-signing, like: --- trusted-keys { example.com. 257 3 5 AwEAAd5l859ggW8ZpVAQxEmugl+N/klWH+kFpcoQYGd3ngB6381lva2E IUXa2iOxJPmvYut96zUqhprlUfuEBvhU21Dd8dv7rr3Q5a+UT5XA9fUe