from:"Axel Rau"

identifying DNSKEY by label

2023-07-29 Thread Axel Rau

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
uses still auto-dnssec maintain.

Axel
---
PGP-Key: CDE74120  ☀ mobile: +49 160 7568212
computing @ chaos claudius

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

GUI tool to help replacing zone file editing by ddns

2021-09-09 Thread Axel Rau

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 of small zones to move to ddns. I have completed,
a GUI tool for editing zone files.
From the README of zad:
In times of DNSsec, edited zone files interfere with resigning 
activities of the nameserver. To avoid inconsistency, zones can be maintained 
by dynamic update (RFC 2136). zad provides a GUI for dynamic updates and zone 
visualisation to make address and host name editing easy and even easier than 
file editing.

https://zad.readthedocs.io/en/latest/index.html

Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: How to return REFUSED

2021-05-06 Thread Axel Rau



> 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, len 58)
17:40:21.483470 91.216.35.171.53 > 186.149.116.55.80: [udp sum ok] 1 Refused- 
q: RRSIG? pizzaseo.com. 0/0/0(30) (DF) (ttl 64, id 0, len 58)

Hopefully, they give up in some days, if there is no amplification any more.

I have now 2 views. All zones are in the internal view.
The (only) external zones in external view use in-view to reference them in 
internal view.
axfr seems to work,, notify still to be tested.

If someone wants to play with the staging server please:

dig ANY chaos1.de. @ns3.lrau.net.

Any feedback welcome,
Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: How to return REFUSED

2021-05-06 Thread Axel Rau



> 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 match-clients, specifying allow-query { none; }. 
> Put it as the first view, and both non-recursive queries, and queries from 
> your "recursive-users" ACL, will fall through to subsequent views.
> 
> P.S. ISC's "understanding views" knowledgebase article doesn't mention 
> match-recursive-only, so there is a discrepancy there. Either the feature has 
> been removed, and the ARM documentation hasn't been updated to reflect it, or 
> the knowledgebase article only focuses on the most common view-matching 
> criteria, omitting match-recursive-only, since the use cases for that are 
> very rare.


Thanks, Kevin for your quick response, which let me start converting to views,

Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: How to return REFUSED

2021-05-06 Thread Axel Rau



> 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
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: How to return REFUSED

2021-05-06 Thread Axel Rau



> 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 sure that none recursive-users get a REFUSED if query is 
>> recursive?
> 
> Weird! I think your config should do what you want so I wonder why it
> isn't working. Your server is responding to the problem queries with a
> referral from the root zone, so have you configured your server with a
> local authoritative copy of the root?

Yes.
> 
> There's a broader issue here:
> 
> Usually when you have a server that is providing recursive service to
> anyone, it is best to set the allow-query ACL to cover just your users, so
> everyone else gets REFUSED.
> 
> This means that your recursive server cannot also be used as an
> authoritative server advertised in NS records. Your public authoritative
> servers should be authoritative-only and not offer recursion to anyone.
> 
>> PS: I want to minimize the responses to this amplification attack:
> 
> Ooh, RRSIG queries are fun. They are like a stealth ANY query.
> 
> BIND has several tools for dealing with this kind of junk:
> 
>  * RRL is very effective
> 
>  * minimal-any also minimizes responses to RRSIG queries
> 
>  * minimal-responses can also help to reduce packet sizes
> 
> Your server is responding with a referral from the root, so minimal-any
> won't have any effect on the response. And because it's a referral, the
> glue etc. is not optional, so there's nothing that minimal-responses can
> omit. So in your situation the most useful things to do would be:
> 
>  * tighten up your allow-query ACL
> 
>  * if you can't do that, use RRL (you can add recursive-users to the
>exempt-clients list)
> 
>  * configure separate views for recursive-users and others; do not
>include the root zone in your external view

Currently, I have:

minimal-responses yes;
require-server-cookie yes;

rate-limit {
responses-per-second 5;
exempt-clients { recursive-users; };
};

which do not really help.

This NS has some other clients in the DMZ LAN, so I need Views.
I gave up with views years ago and I have now to learn to use them with all the 
recent stuff, like in-view.
in-view can be helpful to reference the auth zones in the local view, I guess.

Thanks for your your comprehensive explanation,
Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

How to return REFUSED

2021-05-05 Thread Axel Rau

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:
- - -
19:05:18.703238 185.230.55.130.30120 > 91.216.35.71.53: [no udp cksum] 1+ 
RRSIG? pizzaseo.com.(30) (ttl 249, id 33043, len 58)
19:05:18.703568 91.216.35.71.53 > 185.230.55.130.30120: [udp sum ok] 1- q: 
RRSIG? pizzaseo.com. 0/13/14 ns: com. NS j.gtld-servers.net., com. NS 
m.gtld-servers.net., com. NS c.gtld-servers.net., com. NS b.gtld-servers.net., 
com. NS d.gtld-servers.net., com. NS e.gtld-servers.net., com. NS 
l.gtld-servers.net., com. NS f.gtld-servers.net., com. NS h.gtld-servers.net., 
com. NS i.gtld-servers.net., com. NS a.gtld-servers.net., com. NS 
k.gtld-servers.net., com. NS g.gtld-servers.net. ar: m.gtld-servers.net. A 
192.55.83.30, l.gtld-servers.net. A 192.41.162.30, k.gtld-servers.net. A 
192.52.178.30, j.gtld-servers.net. A 192.48.79.30, i.gtld-servers.net. A 
192.43.172.30, h.gtld-servers.net. A 192.54.112.30, g.gtld-servers.net. A 
192.42.93.30, f.gtld-servers.net. A 192.35.51.30, e.gtld-servers.net. A 
192.12.94.30, d.gtld-servers.net. A 192.31.80.30, c.gtld-servers.net. A 
192.26.92.30, b.gtld-servers.net. A 192.33.14.30, a.gtld-servers.net. A 
192.5.6.30, m.gtld-servers.net.  2001:501:b1f9::30(490) (ttl 63, id 11754, 
len 518)
- - -
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

[RESOLVED] Why are no notifies send?

2020-10-22 Thread Axel Rau



> 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 log entry at the notifying host. 
It seems, sending
of notifies is being logged at a lower log level than sending. (I have debug 
6). The host in my
original posting does not accept notifies over IPv6 and I can’t access its 
logs, so I just saw
nothing at the sending side.

Thanks, Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Why are no notifies send?

2020-10-20 Thread Axel Rau



> 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
Only meaningful if notify is active for this zone. The set of machines that 
will receive a DNS NOTIFY message for this zone is made up of all the listed 
name servers (other than the primary master) for the zone plus any IP addresses 
specified with also-notify. A port may be specified with each also-notify 
address to send the notify messages to a port other than the default of 53. A 
TSIG key may also be specified to cause the NOTIFY to be signed by the given 
key. also-notify is not meaningful for stub zones. The default is the empty 
list.

Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Why are no notifies send?

2020-10-20 Thread Axel Rau

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/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. ; };
>};
>  server 2001:470:100::2 {
>keys { ns4-he.net. ; };
>};
> 
> 
> // From slave.dns.he.net pulls zones from us, ns1.he.net receives notify from 
> us
>  acl not-he {  !216.218.133.2;  !2001:470:600::2;  !2001:470:100::2;  any; };
>  acl ns4-he { !not-he; key ns4-he.net.; };
> 
> 
>   also-notify {
>2001:470:100::2 key "ns4-he.net" ;
>144.91.89.26 key "ns5-ping" ;
>   };
> - - -
> I can’t see any notifies to 2001:470:100::2 in the logs.
> 
> What am I doing wrong?
> 
> Axel
> ---
> PGP-Key: CDE74120  ☀  computing @ chaos claudius
> 
> 
> 

---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Why are no notifies send?

2020-10-16 Thread Axel Rau

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. ; };
};
  server 2001:470:100::2 {
keys { ns4-he.net. ; };
};


// From slave.dns.he.net pulls zones from us, ns1.he.net receives notify from us
  acl not-he {  !216.218.133.2;  !2001:470:600::2;  !2001:470:100::2;  any; };
  acl ns4-he { !not-he; key ns4-he.net.; };


also-notify {
2001:470:100::2 key "ns4-he.net" ;
144.91.89.26 key "ns5-ping" ;
};
- - -
I can’t see any notifies to 2001:470:100::2 in the logs.

What am I doing wrong?

Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

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

2020-09-04 Thread Axel Rau



> 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 an errno 35 (see below).


Commenting these out, seems to resolve the issue:

query-source address  91.216.35.21;
notify-source   91.216.35.21 port 53;
transfer-source   91.216.35.21 port 53;

query-source-v6 address2a05:bec0:26:5::71;
notify-source-v6 2a05:bec0:26:5::71 port 53;
transfer-source-v6 2a05:bec0:26:5::71 port 53;

Queries to localhost shows that the response does not come from localhost:

root@ns5:/var/log # dig localhost @localhost
;; reply from unexpected source: 91.216.35.21#53, expected 127.0.0.1#53

;; reply from unexpected source: 91.216.35.21#53, expected 127.0.0.1#53

;; reply from unexpected source: 91.216.35.21#53, expected 127.0.0.1#53


; <<>> DiG 9.16.6 <<>> localhost @localhost
;; global options: +cmd
;; connection timed out; no servers could be reached

No issue with remote queries.

Questions:

What has query-source address to do with a query response?
Why does the issue not happen on another server (same config, same OS&bind 
version) ?

Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

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

2020-09-01 Thread 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 an errno 35 (see below).

clueless,
Axel


root@ns5:/var/log # uname -a
FreeBSD ns5 12.1-RELEASE-p8 FreeBSD 12.1-RELEASE-p8 GENERIC  amd64

root@ns5:/var/log # named -V
BIND 9.16.6 (Stable Release) 
running on FreeBSD amd64 12.1-RELEASE-p8 FreeBSD 12.1-RELEASE-p8 GENERIC
built by make with '--disable-linux-caps' '--localstatedir=/var' 
'--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2' 
'--with-openssl=/usr' '--with-readline=-L/usr/local/lib -ledit' 
'--with-dlz-filesystem=yes' '--enable-dnstap' '--disable-fixed-rrset' 
'--disable-geoip' '--without-maxminddb' '--without-gssapi' 
'--with-libidn2=/usr/local' '--with-json-c' '--disable-largefile' 
'--with-lmdb=/usr/local' '--disable-native-pkcs11' '--without-python' 
'--disable-querytrace' '--enable-tcp-fastopen' '--disable-symtable' 
'--prefix=/usr/local' '--mandir=/usr/local/man' 
'--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd12.1' 
'build_alias=amd64-portbld-freebsd12.1' 'CC=cc' 'CFLAGS=-O2 -pipe 
-DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include 
-fno-strict-aliasing ' 'LDFLAGS= -L/usr/local/lib -ljson-c 
-fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG 
-isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'
compiled by CLANG 4.2.1 Compatible FreeBSD Clang 8.0.1 (tags/RELEASE_801/final 
366581)
compiled with OpenSSL version: OpenSSL 1.1.1d-freebsd  10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.1d-freebsd  10 Sep 2019
compiled with libuv version: 1.38.1
linked to libuv version: 1.38.1
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.3.2
linked to protobuf-c version: 1.3.2
threads support is enabled

23480 isc-socket-0 STRU  struct kevent[] = { { ident=512, filter=EVFILT_READ, 
flags=0, fflags=0, data=0x35, udata=0x0 } }
 23480 isc-socket-0 RET   kevent 0x1
 23480 isc-socket-0 CALL  recvmsg(0x200,0x7fffdbddbb70,0)
 23480 isc-socket-0 GIO   fd 512 read 53 bytes
   0x 552a 0120 0001   0001 0377   |U*. .www|
   0x0010 0568 6569 7365 0264 6500 0001 0001   |.heise.de...|
   0x0020 2910    0c00 0a00 0810 a161  |)..a|
   0x0030 cea7 9c05 fa |.|

 23480 isc-socket-0 STRU  struct sockaddr { AF_INET, 193.105.105.1:56885 }
 23480 isc-socket-0 RET   recvmsg 0x35
 23480 isc-socket-0 CALL  _umtx_op(0x802f38bb8,0x15,0x1,0,0)
 23480 isc-socket-0 RET   _umtx_op 0
 23480 isc-socket-0 CALL  kevent(0x5a,0x7fffdbddbec0,0x1,0,0,0)
 23480 isc-socket-0 STRU  struct kevent[] = { { ident=512, filter=EVFILT_READ, 
flags=0x2, fflags=0, data=0, udata=0x0 } }
 23480 isc-socket-0 STRU  struct kevent[] = {  }
 23480 isc-socket-0 RET   kevent 0
 23480 isc-socket-0 CALL  kevent(0x5a,0,0,0x802fa7200,0x800,0)
 23480 isc-socket-0 STRU  struct kevent[] = {  }
 23480 isc-worker RET   _umtx_op 0
 23480 isc-worker CALL  recvmsg(0x200,0x7fffddfec9c0,0)
 23480 isc-worker RET   recvmsg -1 errno 35
 23480 isc-worker CALL  write(0x59,0x7fffddfecbc0,0x8)
 23480 isc-worker GIO   fd 89 wrote 8 bytes
   0x 0002  fdff   ||

 23480 isc-worker RET   write 0x8
 23480 isc-worker CALL  _umtx_op(0x80178f188,0xf,0,0,0)
 23480 isc-socket-0 STRU  struct kevent[] = { { ident=88, filter=EVFILT_READ, 
flags=0, fflags=0, data=0x8, udata=0x0 } }
 23480 isc-socket-0 RET   kevent 0x1
 23480 isc-socket-0 CALL  read(0x58,0x7fffdbddbe40,0x8)
 23480 isc-socket-0 GIO   fd 88 read 8 bytes
   0x 0002  fdff   ||

 23480 isc-socket-0 RET   read 0x8
 23480 isc-socket-0 CALL  kevent(0x5a,0x7fffdbddbec0,0x1,0,0,0)
 23480 isc-socket-0 STRU  struct kevent[] = { { ident=512, filter=EVFILT_READ, 
flags=0x1, fflags=0, data=0, udata=0x0 } }
 23480 isc-socket-0 STRU  struct kevent[] = {  }
 23480 isc-socket-0 RET   kevent 0
 23480 isc-socket-0 CALL  read(0x58,0x7fffdbddbe40,0x8)
 23480 isc-socket-0 RET   read -1 errno 35
 23480 isc-socket-0 CALL  kevent(0x5a,0,0,0x802fa7200,0x800,0)
 23480 isc-socket-0 STRU  struct kevent[] = {  }
 23480 isc-socket-0 STRU  struct kevent[] = { { ident=512, filter=EVFILT_READ, 
flags=0, fflags=0, data=0x35, udata=0x0 } }
 23480 isc-socket-0 RET   kevent 0x1
 23480 isc-socket-0 CALL  recvmsg(0x200,0x7fffdbddbb70,0)
 23480 isc-socket-0 GIO   fd 512 read 53 bytes
   0x 552a 0120 0001   0001 0377   |U*. .www|
   0x0010 0568 6569 7365 0264 6500 0001 0001   |.heise.de...|
   0x0020 2910    0c00 0a00 0810 a161  |)..a|
   0x0030 cea7 9

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

2020-09-01 Thread Axel Rau



> 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à:


Listen-on {
91.216.35.21;
127.0.0.1;
};
Listen-on-v6 {
2a05:bec0:26:5::71;
::1;
};

Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

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

2020-09-01 Thread Axel Rau

Thanks for answering:

root@ns5:/ # dig NS lrau.net @91.216.35.21

; <<>> DiG 9.16.5 <<>> NS lrau.net @91.216.35.21
;; global options: +cmd
;; connection timed out; no servers could be reached

root@ns5:/ # dig NS lrau.net @localhost

; <<>> DiG 9.16.5 <<>> NS lrau.net @localhost
;; global options: +cmd
;; connection timed out; no servers could be reached

root@ns5:/ # sockstat -p 53
USER COMMANDPID   FD PROTO  LOCAL ADDRESS FOREIGN ADDRESS
root cron   59891 5  dgram  -> /var/run/log
root sendmail   59197 3  dgram  -> /var/run/log
bind named  47812 3  dgram  -> /var/run/log
bind named  47812 137 udp4  91.216.35.21:53   *:*
bind named  47812 138 udp4  91.216.35.21:53   *:*
bind named  47812 139 udp4  91.216.35.21:53   *:*
bind named  47812 140 udp4  91.216.35.21:53   *:*
bind named  47812 141 udp4  91.216.35.21:53   *:*
bind named  47812 142 udp4  91.216.35.21:53   *:*
bind named  47812 143 udp4  91.216.35.21:53   *:*
bind named  47812 144 udp4  91.216.35.21:53   *:*
bind named  47812 145 udp4  91.216.35.21:53   *:*
bind named  47812 146 udp4  91.216.35.21:53   *:*
bind named  47812 147 udp4  91.216.35.21:53   *:*
bind named  47812 148 udp4  91.216.35.21:53   *:*
bind named  47812 149 udp4  91.216.35.21:53   *:*
bind named  47812 150 udp4  91.216.35.21:53   *:*
bind named  47812 151 udp4  91.216.35.21:53   *:*
bind named  47812 152 udp4  91.216.35.21:53   *:*
bind named  47812 154 tcp4  91.216.35.21:53   *:*
bind named  47812 155 udp6  2a05:bec0:26:5::71:53 *:*
bind named  47812 156 udp6  2a05:bec0:26:5::71:53 *:*
bind named  47812 157 udp6  2a05:bec0:26:5::71:53 *:*
bind named  47812 158 udp6  2a05:bec0:26:5::71:53 *:*
bind named  47812 159 udp6  2a05:bec0:26:5::71:53 *:*
bind named  47812 160 udp6  2a05:bec0:26:5::71:53 *:*
bind named  47812 161 udp6  2a05:bec0:26:5::71:53 *:*
bind named  47812 162 udp6  2a05:bec0:26:5::71:53 *:*
bind named  47812 163 udp6  2a05:bec0:26:5::71:53 *:*
bind named  47812 164 udp6  2a05:bec0:26:5::71:53 *:*
bind named  47812 165 udp6  2a05:bec0:26:5::71:53 *:*
bind named  47812 166 udp6  2a05:bec0:26:5::71:53 *:*
bind named  47812 167 udp6  2a05:bec0:26:5::71:53 *:*
bind named  47812 168 udp6  2a05:bec0:26:5::71:53 *:*
bind named  47812 169 udp6  2a05:bec0:26:5::71:53 *:*
bind named  47812 170 udp6  2a05:bec0:26:5::71:53 *:*
bind named  47812 172 tcp6  2a05:bec0:26:5::71:53 *:*
bind named  47812 512 udp4  91.216.35.21:53   *:*
bind named  47812 513 udp6  2a05:bec0:26:5::71:53 *:*
root rsyslogd   45747 0  dgram  /var/run/log
root rsyslogd   45747 1  dgram  -> /var/run/log
root@ns5:/ #


> Am 01.09.2020 um 16:14 schrieb Ondřej Surý :
> 
> Hi Axel,
> 
> the `nc` commands you used for testing neither proves that
> it’s that specific `named` listening on that port nor DNS
> daemon at all.  FWIW it could be a dummy UDP/TCP server
> 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
> 
>> On 1. 9. 2020, at 16:11, Axel Rau  wrote:
>> 
>> 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
>> root@ns5:/ # nc -vu localhost 53
>> Connection to localhost 53 port [udp/domain] succeeded!
>> 
>> From master server:
>> [hermes:local/etc/namedb] root# nc -v ns5.lrau.net 53
>> Connection to ns5.lrau.net 53 port [tcp/domain] succeeded!
>> ^C
>> [hermes:local/etc/namedb] root#  nc -vu ns5.lrau.net 53
>> Connection to ns5.lrau.net 53 port [udp/domain] succeeded!
>> 
>> 
>> Any help greatly appreciated,
>> Axel
>> 
>> PS:
>> 
>> part of named.conf:
>>  allow-notify {
>>  hermes-ns5;
>>  };
>>  allow-transfer {
>>  full-trusted;
>>  ns5-ping;
>>  ns4-he;
>>  management-hosts;
>>  };
>>  allow-query { any; };
>>  allow-query-cache { recursive-users; };
>>  allow-recursion

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

2020-09-01 Thread Axel Rau

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  @127.0.0.1 
> dig ns5.lrau.net  @::1
> 
> Also, have a look in /etc/hosts and make sure that you have something like:
> 127.0.0.1 localhost
> 
> 
> (nc may be connecting over v4 and  may be 
> doing v6, etc...)
> 

; <<>> DiG 9.16.5 <<>> NS lrau.net @127.0.0.1
;; global options: +cmd
;; connection timed out; no servers could be reached

root@ns5:/ # dig NS lrau.net @::1

; <<>> DiG 9.16.5 <<>> NS lrau.net @::1
;; global options: +cmd
;; connection timed out; no servers could be reached

root@ns5:/ # dig NS lrau.net @91.216.35.21

; <<>> DiG 9.16.5 <<>> NS lrau.net @91.216.35.21
;; global options: +cmd
;; connection timed out; no servers could be reached

root@ns5:/ # dig NS lrau.net @localhost

; <<>> DiG 9.16.5 <<>> NS lrau.net @localhost
;; global options: +cmd
;; connection timed out; no servers could be reached

root@ns5:/ # grep localhost /etc/hosts
127.0.0.1   localhost
::1 localhost

---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

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

2020-09-01 Thread Axel Rau

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
root@ns5:/ # nc -vu localhost 53
Connection to localhost 53 port [udp/domain] succeeded!

From master server:
[hermes:local/etc/namedb] root# nc -v ns5.lrau.net 53
Connection to ns5.lrau.net 53 port [tcp/domain] succeeded!
^C
[hermes:local/etc/namedb] root# nc -vu ns5.lrau.net 53
Connection to ns5.lrau.net 53 port [udp/domain] succeeded!


Any help greatly appreciated,
Axel

PS:

part of named.conf:
allow-notify {
hermes-ns5;
};
allow-transfer {
full-trusted;
ns5-ping;
ns4-he;
management-hosts;
};
allow-query { any; };
allow-query-cache { recursive-users; };
allow-recursion { recursive-users; };


root@ns5:/usr/local/etc/namedb/working/slave # named -V
BIND 9.16.5 (Stable Release) 
running on FreeBSD amd64 12.1-RELEASE-p8 FreeBSD 12.1-RELEASE-p8 GENERIC
built by make with '--disable-linux-caps' '--localstatedir=/var' 
'--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2' 
'--with-openssl=/usr' '--with-readline=-L/usr/local/lib -ledit' 
'--with-dlz-filesystem=yes' '--disable-dnstap' '--disable-fixed-rrset' 
'--disable-geoip' '--without-maxminddb' '--without-gssapi' 
'--with-libidn2=/usr/local' '--with-json-c' '--disable-largefile' 
'--with-lmdb=/usr/local' '--disable-native-pkcs11' '--without-python' 
'--disable-querytrace' 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-tcp-fastopen' 
'--with-tuning=default' '--disable-symtable' '--prefix=/usr/local' 
'--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' 
'--build=amd64-portbld-freebsd12.1' 'build_alias=amd64-portbld-freebsd12.1' 
'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem 
/usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -L/usr/local/lib -ljson-c 
-fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG 
-isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'
compiled by CLANG 4.2.1 Compatible FreeBSD Clang 8.0.1 (tags/RELEASE_801/final 
366581)
compiled with OpenSSL version: OpenSSL 1.1.1d-freebsd  10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.1d-freebsd  10 Sep 2019
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.14
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled

default paths:
 named configuration:  /usr/local/etc/namedb/named.conf
 rndc configuration:   /usr/local/etc/namedb/rndc.conf
 DNSSEC root key:  /usr/local/etc/namedb/bind.keys
 nsupdate session key: /var/run/named/session.key
 named PID file:   /var/run/named/pid
 named lock file:  /var/run/named/named.lock

---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

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

2020-03-14 Thread 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:
_acme-challenge.imap.lrau.net. 3600 IN  TXT 
"mAtCUMOhsZiajcz5v0ae37-8VRlXFZEyd9csm6ARJYQ"
_acme-challenge.imap.lrau.net. 3600 IN  TXT 
"tR0VhMRfb4v5WsctEgoD3aWNRJ73n2wqn9hlTPE9pA0"

Here, I see, what me prevented to run my challenge successfully.
LEs boulder server didn’t like more than 1 RR in the RRSET.
Using 'replace‘ instead of 'add‘ in dnspython update.Update solves my problem.

I was misdirected by update: 0 here:

Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOTAUTH, id:  35882
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1

Thanks a lot, Chuck and Timothe for your answers,
Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP
___
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: TXT with dot in NAME for ACME via dynamic update

2020-03-14 Thread Axel Rau



> 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 pretty sure that is not correct, but we can't help unless you
> show your work.  If you need to specify the zone to update, you can
> and should.  BIND's nsupdate(8) and other dynamic DNS clients allow
> you to do this.


With this file
- - -
server localhost
debug
zone lrau.net
ttl 3600
add _acme-challenge.imap.lrau.net.  3600 TXT  
"tR0VhMRfb4v5WsctEgoD3aWNRJ73n2wqn9hlTPE9pA0"
show
send
answer
- - -
I get:
- - -
# nsupdate -k /usr/local/etc/namedb/dns-keys/ddns-key.conf 
~/admin/ns-update-example.txt
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; ZONE SECTION:
;lrau.net.  IN  SOA

;; UPDATE SECTION:
_acme-challenge.imap.lrau.net. 3600 IN  TXT 
"tR0VhMRfb4v5WsctEgoD3aWNRJ73n2wqn9hlTPE9pA0"

Sending update to ::1#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  4
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1
;; ZONE SECTION:
;lrau.net.  IN  SOA

;; UPDATE SECTION:
_acme-challenge.imap.lrau.net. 3600 IN  TXT 
"tR0VhMRfb4v5WsctEgoD3aWNRJ73n2wqn9hlTPE9pA0"

;; TSIG PSEUDOSECTION:
ddns-key.   0   ANY TSIGhmac-sha256. 1584206515 300 32 
. . . 4 NOERROR 0


Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  4
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;lrau.net.  IN  SOA

;; TSIG PSEUDOSECTION:
ddns-key.   0   ANY TSIGhmac-sha256. 1584206515 300 32 
. . . 4 NOERROR 0

Answer:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  4
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;lrau.net.  IN  SOA

;; TSIG PSEUDOSECTION:
ddns-key.   0   ANY TSIGhmac-sha256. 1584206515 300 32 
. . . 4 NOERROR 0

# dig _acme-challenge.imap.lrau.net.  @localhost

; <<>> DiG 9.16.0 <<>> _acme-challenge.imap.lrau.net. @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6153
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 404b9f34e94920a4ef3dd3065e6d14308acdeabfe0744b88 (good)
;; QUESTION SECTION:
;_acme-challenge.imap.lrau.net. IN  A

;; AUTHORITY SECTION:
lrau.net.   3600IN  SOA ns4.lrau.net. 
hostmaster.lrau.net. 2020030850 86400 7200 604800 3600

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Sat Mar 14 17:28:16 UTC 2020
;; MSG SIZE  rcvd: 145

(pki_dev_p37) [root@hermes /usr/local/py_venv/pki_dev_p37/src]#

Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP
___
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

TXT with dot in NAME for ACME via dynamic update

2020-03-14 Thread Axel Rau

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 file.

The problem is:
- bind requires for dynamic update with
dnssec-update-mode maintain
auto-dnssec maintain
  both require dynamic DNS

- letsencrypt requires challenges like the above.

This makes it impossible to create automatic ACME clients with dns-01 challenge.

Does anybody have a workaround?

Thanks, Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP
___
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: Logging of notify sending

2019-05-26 Thread Axel Rau



> 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 key may be specified for each server in the masters statement in
the definition of a slave zone; in this case, all SOA QUERY messages, NOTIFY
messages, and zone transfer requests (AXFR or IXFR) will be signed using the
specified key. Keys may also be specified in the also-notify statement of a
master or slave zone, causing NOTIFY messages to be signed using the specified
key.

Axel
---

PGP-Key:29E99DD6  ☀  computing @ chaos claudius

___
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: Logging of notify sending

2019-05-26 Thread Axel Rau




> 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 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.
>> 
> As Rick Dicaire said previously, "Notifications themselves don't use TSIG". 
> You will never see a TSIG key associated with a notify because notifies 
> aren't signed; the zone transfers triggered by notifies are.
So what for is the optional key in the also-notify statement?

Axel
---
axel@chaos1.de  PGP-Key:29E99DD6   computing @ chaos claudius
___
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: Logging of notify sending

2019-05-25 Thread Axel Rau



> 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, Axel
---
PGP-Key:29E99DD6  ☀  computing @ chaos claudius

___
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: Logging of notify sending

2019-05-25 Thread Axel Rau



> 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 to check, if the TSIG key is being used for the notify.
> 
> 
> Have you looked at syslog?
> 
> You should see similar to:
> 
> May 25 13:04:28 dns1 named[28905]: client @0x7f205c0f2ef0 
> 192.168.15.13#52447/key gw-zones (dhcp.ldev): transfer of 'dhcp.ldev/IN': 
> IXFR started: TSIG gw-zones (serial 2017051319 -> 2017051320)
> May 25 13:04:28 dns2 named[23971]: zone dhcp.ldev/IN: transferred serial 
> 2017051320: TSIG 'gw-zones‘

This is logging of zone transfer, not sending of notify.

Axel
---
PGP-Key:29E99DD6  ☀  computing @ chaos claudius

___
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

Logging of notify sending

2019-05-25 Thread Axel Rau

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

___
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: SOA serial out of sync

2018-06-23 Thread Axel Rau


> 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:
> 
> https://lists.isc.org/pipermail/bind-users/2017-September/099145.html
Thanks for pointing this out.

My problem happened again with bind 9.12.1.
As you can see below, „next key event" is in the past!

Axel

PS:
—-
[hermes:master/signed/lrau.net] root# rndc zonestatus lrau.net
name: lrau.net
type: master
files: master/signed/lrau.net/lrau.net.zone, 
master/signed/lrau.net/caldav.lrau.net.tlsa, 
master/signed/lrau.net/git3.lrau.net.tlsa, 
master/signed/lrau.net/git4.lrau.net.tlsa, 
master/signed/lrau.net/lists3.lrau.net.tlsa, 
master/signed/lrau.net/lists4.lrau.net.tlsa, 
master/signed/lrau.net/mailout3.lrau.net.tlsa, 
master/signed/lrau.net/mailout4.lrau.net.tlsa, 
master/signed/lrau.net/mx3.lrau.net.tlsa, 
master/signed/lrau.net/mx4.lrau.net.tlsa, 
master/signed/lrau.net/timap3.lrau.net.tlsa, 
master/signed/lrau.net/tmx3.lrau.net.tlsa, 
master/signed/lrau.net/acme_challenges.inc
serial: 2018062201
signed serial: 2018062201
nodes: 88
last loaded: Fri, 15 Jun 2018 15:17:08 GMT
secure: yes
inline signing: yes
key maintenance: automatic
next key event: Fri, 22 Jun 2018 21:07:51 GMT
next resign node: _25._tcp.lists4.lrau.net/NSEC
next resign time: Fri, 29 Jun 2018 21:38:07 GMT
dynamic: no
reconfigurable via modzone: no
[hermes:master/signed/lrau.net] root# date
Sat Jun 23 11:08:53 CEST 2018
[hermes:master/signed/lrau.net] root# grep Serial lrau.net.zone
2018062202  ; Serial number
---
PGP-Key:29E99DD6  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP
___
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: SOA serial out of sync

2018-06-19 Thread Axel Rau


> 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, nobody has a clue on this.

To summarise:

Occasionally it happens after rndc reload that the serial in the zone file is 
bigger than that in served SOA.
In this case, named begins serving stale data.
Probability for this to happen increases with size of the journal file.

I’m using auto-dnssec maintain; inline-signing yes; serial-update-method 
increment;
The ARM does not state clearly, which is the base of the increment if the zone 
file changes (file or internal).
In my case, the served serial is based on the zone file and usually bigger than 
that.

Question: Could the problem arise by incrementing the serial without changing 
the zone data?
(Occasionally this could happen with my script)

I have upgraded to bind 9.12.1P2 and look forward. . .

Thanks, Axel
---
PGP-Key:29E99DD6  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP
___
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: SOA serial out of sync

2018-06-14 Thread Axel Rau

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" -- is the serial number in the "including" zone being incremented?Yes.I think at this point you're going to need to provide a lot more detail about your configuration, and what's special about these zones.  It sounds like this is not a straightforward configuration, and it’s hard to figure out from the bits and pieces you've provided what could be going wrong.The only thing, which may be special are include files, which may be empty from time to time (used for acme challenge responses).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.<>
Axel
---PGP-Key:29E99DD6  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP
___
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: SOA serial out of sync

2018-06-14 Thread Axel Rau


> 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 problem from just not picking up a zone update.
> 
> Have you checked the logs for errors during zone loading?  

 zone nussberg.de/IN (signed): reconfiguring zone keys
 zone nussberg.de/IN (signed): next key event: 13-Jun-2018 21:05:10.419
 zone nussberg.de/IN (unsigned): loaded serial 2018061301
 zone nussberg.de/IN (signed): receive_secure_serial: not exact
 zone nussberg.de/IN (signed): reconfiguring zone keys
 zone nussberg.de/IN (signed): next key event: 13-Jun-2018 22:05:10.428

Axel
---
PGP-Key:29E99DD6  ☀  computing @ chaos claudius

___
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: SOA serial out of sync

2018-06-14 Thread Axel Rau


> 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 signed with OpenPGP
___
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: SOA serial out of sync

2018-06-14 Thread Axel Rau


> 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.nussberg.de. 3600 IN TLSA 3 0 1 
DAE0AC343A6694DEAF0BAB42FC8A6B1F82E42799654BD667B458DC91655C6AB4
- - -
After reload no TLSAs are picked up by the server:
- - -
[hermes:local/etc/rc.d] root# dig AXFR nussberg.de. @localhost | grep TLSA
[hermes:local/etc/rc.d] root#
- - -
Zone status:
- - -
[hermes:local/etc/rc.d] root# rndc zonestatus nussberg.de
name: nussberg.de
type: master
files: master/signed/nussberg.de/nussberg.de.zone, 
master/signed/nussberg.de/git.nussberg.de.tlsa, 
master/signed/nussberg.de/acme_challenges.inc
serial: 2018061301
signed serial: 2018060702
nodes: 12
last loaded: Tue, 05 Jun 2018 07:08:59 GMT
secure: yes
inline signing: yes
key maintenance: automatic
next key event: Thu, 14 Jun 2018 10:05:11 GMT
next resign node: email1._domainkey.nussberg.de/TXT
next resign time: Sun, 17 Jun 2018 19:29:37 GMT
dynamic: no
reconfigurable via modzone: no
- - -
What else can I collect to help fixing this?

Thanks, Axel

PS: Why does
dig TLSA _443._tcp.git.nussberg.de. @localhost
not work at all?
---
PGP-Key:29E99DD6  ☀  computing @ chaos claudius

___
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: SOA serial out of sync

2018-06-09 Thread Axel Rau

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: 2018060604
> 
> zone file was edited by script and a rndc reload given.
> [...] 
> Manual fixing requires another cycle with zone file editing:
> 
>  
> You don't say this clearly, but it sounds like you're reporting more than 
> just the serial not updating.  Is that correct?
Yes.
> Are there actual updates to the zone that are not being picked up?
Yes, that’s the point. If the problem happens, the signing machinery is blocked 
until resolved manually.
I don’t know the reason. named-checkzone reported no errors, but in case of 
syntax-errors, named behaves similar.
>   As Tony says, the serial number can differ from the file to what's served 
> by the name server when the name server is doing automatic signing.
> 
> Can you clarify which it is?
I hope, I did (-:

There is nothing special with this zone file:

- - -
[hermes:~] root# rndc zonestatus lrau.net
name: lrau.net
type: master
files: master/signed/lrau.net/lrau.net.zone, 
master/signed/lrau.net/caldav.lrau.net.tlsa, 
master/signed/lrau.net/git3.lrau.net.tlsa, 
master/signed/lrau.net/git4.lrau.net.tlsa, 
master/signed/lrau.net/lists3.lrau.net.tlsa, 
master/signed/lrau.net/lists4.lrau.net.tlsa, 
master/signed/lrau.net/mailout3.lrau.net.tlsa, 
master/signed/lrau.net/mailout4.lrau.net.tlsa, 
master/signed/lrau.net/mx3.lrau.net.tlsa, 
master/signed/lrau.net/mx4.lrau.net.tlsa, 
master/signed/lrau.net/timap3.lrau.net.tlsa, 
master/signed/lrau.net/tmx3.lrau.net.tlsa, 
master/signed/lrau.net/acme_challenges.inc
serial: 2018060805
signed serial: 2018060805
nodes: 88
last loaded: Thu, 07 Jun 2018 10:37:34 GMT
secure: yes
inline signing: yes
key maintenance: automatic
next key event: Sat, 09 Jun 2018 13:08:21 GMT
next resign node: gw2.m6d2.lrau.net/NSEC
next resign time: Fri, 29 Jun 2018 21:38:07 GMT
dynamic: no
reconfigurable via modzone: no

[hermes:local/etc/namedb] root# named-checkzone lrau.net 
/usr/local/etc/namedb/master/signed/lrau.net/lrau.net.zone 
zone lrau.net/IN: loaded serial 2018060805
OK
- - -

Thanks, Axel
---
PGP-Key:29E99DD6  ☀  computing @ chaos claudius

___
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: SOA serial out of sync

2018-06-09 Thread Axel Rau

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 signed and unsigned zones have separate serial
> numbers, so this is normal. If I understand inline-signing correctly, when
> you only modify the unsigned zone's serial number, that is not a big
> enough change to require an update to the signed version of the zone.
I changed a RR and the serial. Immediately after such a change, both
serials are usually equal, which my script checks.
If thea are different, this usually indicates some error with signing.
> 
> You can use `rndc zonestatus` to see the server's view of both serial
> numbers.
I see.
> 
> You can use `rndc signing -serial` to set the serial number of the signed
> zone.
> 
> You might want to set `serial-update-method` if you want something more
> meaningful than an increment for each update (e.g. `date`).


OK.

Thanks for responding,
Axel
---
PGP-Key:29E99DD6  ☀  computing @ chaos claudius

___
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

inline-signing: SOA serial out of sync

2018-06-07 Thread Axel Rau

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 notify to …

Config detail:

key-directory "master/signed/lrau.net/";
auto-dnssec maintain;
inline-signing yes;
dnssec-secure-to-insecure no;

Manual fixing requires another cycle with zone file editing:

——-——-
[hermes:master/signed/lrau.net] root# service named stop
Stopping named.
Waiting for PIDS: 37110.
[hermes:master/signed/lrau.net] root# ls -l *.jbk *.jnl *.signed
-rw-r--r--  1 bind  pki_op 512 Jan 11 13:12 lrau.net.zone.jbk
-rw-r--r--  1 bind  pki_op   16409 Jun  6 21:05 lrau.net.zone.jnl
-rw-r--r--  1 bind  pki_op   50263 Jun  6 21:19 lrau.net.zone.signed
-rw-r--r--  1 bind  pki_op  682052 Jun  6 21:05 lrau.net.zone.signed.jnl
[hermes:master/signed/lrau.net] root# rm *.jbk *.jnl *.signed
[hermes:master/signed/lrau.net] root# service named start
Starting named.
[hermes:master/signed/lrau.net] root# ls -l *.jbk *.jnl *.signed
-rw-r--r--  1 bind  pki_op512 Jun  7 12:37 lrau.net.zone.jbk
-rw-r--r--  1 bind  pki_op   8222 Jun  7 12:37 lrau.net.zone.signed
-rw-r--r--  1 bind  pki_op  57521 Jun  7 12:37 lrau.net.zone.signed.jnl
[hermes:master/signed/lrau.net] root# dig SOA lrau.net @localhost

; <<>> DiG 9.11.3 <<>> SOA lrau.net @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36163
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 9abf10cb4372b10e0eae26085b190b0d3486a4bef440b95c (good)
;; QUESTION SECTION:
;lrau.net.  IN  SOA

;; ANSWER SECTION:
lrau.net.   86400   IN  SOA ns4.lrau.net. 
hostmaster.lrau.net. 2018060632 86400 7200 604800 3600
. . .
[hermes:local/etc/namedb] root# named-checkzone lrau.net 
master/signed/lrau.net/lrau.net.zone
zone lrau.net/IN: loaded serial 2018060606  << still not in 
sync
OK

# edited zone file manually (serial set to 2018060640):

[hermes:master/signed/lrau.net] root# rndc reload
server reload successful
[hermes:local/etc/namedb] root# named-checkzone lrau.net 
master/signed/lrau.net/lrau.net.zone
zone lrau.net/IN: loaded serial 2018060640
OK
[hermes:master/signed/lrau.net] root# dig SOA lrau.net. @localhost
. . .
;; ANSWER SECTION:
lrau.net.   86400   IN  SOA ns4.lrau.net. 
hostmaster.lrau.net. 2018060640 86400 7200 604800 3600
——


What is going wrong here?
What can I do to get this fixed?

Thanks, Axel
---
PGP-Key:29E99DD6  ☀  computing @ chaos claudius

___
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

$include not working with inline-signing

2015-03-29 Thread Axel Rau

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

_25._tcp.tmx4.lrau.net. IN TLSA 3 0 1 
56c2987c6e14bdd40d3f8b2cbe004e85d2ff27a466b7d041b2178e0bd880b33f

I have no origin set, because the arm says: 
„The origin and the current domain name revert to the values they
had prior to the $INCLUDE once the file has been read.“

What am I doing wrong?
Is this a bug?
Any workaound?

Thanks, 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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: key rollover with BIND 9.9

2013-01-26 Thread Axel Rau


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 the last decade of blog posts about tools
> and techniques that are no longer necessary.
> 
> I have a test zone set with "auto-dnssec maintain" and "inline-signing
> yes".  My zone gets signed, RRSIGs get generated, and so on.
> 
> The 9.9 ARM says at 4.9.7 that named will automatically carry out the
> key rollover. Does this include creation of new key files?
> 
> When the KSK rolls over, do I need to update my registrar? Or does
> that happen automatically? (I see hints that the root servers pick up
> the new DS record, but that seems too good to be true.)
> 
> By default, keys have no expiration date. I'm assuming I must set an
> expiration date on the ZSK and KSK for named to automatically create
> the new key?
> 
> As a test, I've set my test zone ZSK with a fairly short time to
> expire.
> 
> dnssec-settime -I +7d -D +14d Kabsolutenetbsd.com.+005+39543
> 
> named hasn't created a new ZSK, however. Should I expect it to? Or is
> there some other document I need to read?
> 
It's your responsibility to create the keys and to renew the DS-RR with your 
registrar.
I have written a python3 script which does all this housekeeping including 
registrar updates for 2 registrars.
You find it here
https://github.com/mc3/DSKM

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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Announcing DSKM DNSsec key management tool ready for beta testing

2012-06-04 Thread Axel Rau

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 or reverse (IP4 or IP6).
Initial implemented registrar is joker.com and ip registry ripe.net.

Local means internal zones with local trust anchor.

Intention is to have DNSsec automated completely.

Design is state-table driven with transitions triggered by DNS query results
or point in time reached, written in Python3.

License is GPLv3, may be downloaded from here
https://sourceforge.net/projects/dskm/files/

Source at GitHub:
https://github.com/rabaxabel/DSKM
Who implements the next registrar?
I will implement manual registrar handover notification per email soon.

I'm still improving my knowledge about DNSsec (Thanks list!) but DSKM
is running with 3 test domains and shortend key life times for 2 months now
with only minor problems.

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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: 9.9.1 continues to sign with inactive KSK

2012-05-25 Thread Axel Rau


Am 25.05.2012 um 14:16 schrieb Tony Finch:

> Axel Rau  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:03, I:2012-05-24T16:55:03, 
>> D:2012-05-25T16:55:03)]
>> ---
>> 46210 is inactive and still used to sign DNSKEYs (from  dig +dnssec DNSKEY 
>> framail.de. at 2012-05-25T13:55) :
>> ---
>> framail.de.  86400   IN  RRSIG   DNSKEY 8 2 86400 20120622185603 
>> 20120523175603 46210 framail.de...
>> framail.de.  86400   IN  RRSIG   DNSKEY 8 2 86400 20120623175502 
>> 20120524165502 1699 framail.de...
>> ---
>> Shouln't named have ceased signing keys with this key?
> 
> The 46210 signature's inception date is 2012-05-23 which is before its
> key's inactive date 2012-05-24.
That's true, but this sig does not live until its expire time at 2012-06-22.
In my case, it disappeared on 2012-05-26 between 15:55 and 16:55.

Questions:
Why did it disappear at that time?
In general terms, at which point of time can I be sure that all sigs are 
removed?

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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

9.9.1 continues to sign with inactive KSK

2012-05-25 Thread Axel Rau

Hi all,

there is a KSK roll over running for framail.de.
Its a inline-signing maintain configuration, upgraded fron 9.9.0.
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:03, I:2012-05-24T16:55:03, 
D:2012-05-25T16:55:03)]
---
46210 is inactive and still used to sign DNSKEYs (from  dig +dnssec DNSKEY 
framail.de. at 2012-05-25T13:55) :
---
framail.de. 86400   IN  RRSIG   DNSKEY 8 2 86400 20120622185603 
20120523175603 46210 framail.de...
framail.de. 86400   IN  RRSIG   DNSKEY 8 2 86400 20120623175502 
20120524165502 1699 framail.de...
---
Shouln't named have ceased signing keys with this key?

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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: KSK stays published 3 days after delete time

2012-05-11 Thread Axel Rau


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 using inline-signing.
>> The repository is the key-directory configured in named.conf.
>> "Deleted" means: My script deleted it.
> 
> Named won't delete the key from the zone unless you explicitly tell
> it to do so.  For all it knows, your key file may have been removed
> by mistake.
> 
> The correct way to remove a key from your zone is to schedule it
> for deletion.  If it already has a successor published, then you can
> schedule the event immediately:
> 
>   $ dnssec-settime -K  -D now Kframail.de.+007+13245
That's what I mean with "key 22924 of framail.de has a delete date of
2012-05-07T14:55:02 set".
> 
>   $ rndc loadkeys framail.de
> The -D option says "the key should be deleted after the specified
> time", which in this case is "now".  "rndc loadkeys" tells named to
> examine the keys in the repository and note any changes to the scheduled
> events.  named will see that the specified KSK is scheduled for deletion,
> it will remove it from the DNSKEY RRset, and it will resign the DNSKEY
> RRset wth the remaining key(s).
I have "auto-dnssec maintain;" set and my understanding is, that named
does not require a rndc loadkeys to remove the key from the DNSKEY RRSET
if the delete time, set with  dnssec-settime, has passed.
Is this wrong?
> 
> After that's happened, you can remove the key file from the repository
> if you wish.
> 
> If you still have a copy of the key file, put it back and follow the
> above steps.  Otherwise, I suggest resigning the zone from scratch
> with the remaining keys.  (Update the SOA serial number in the unsigned
> zonefile to something higher than the current serial number in the
> signed zone; move .signed and .signed.jnl to some other
> location; restart named.  A new signed zone should be generated with
> the correct keyset.)

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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: KSK stays published 3 days after delete time

2012-05-10 Thread Axel Rau


Am 10.05.2012 um 19:55 schrieb Axel Rau:

> 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 using inline-signing.
The repository is the key-directory configured in named.conf.
"Deleted" means: My script deleted it.

> 
> Is this a bug, triggered by my timing?
> Should I wait one more maintenance cycle until deleting?

"maintenance cycle" means dnssec-loadkeys-interval.

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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: KSK stays published 3 days after delete time

2012-05-10 Thread Axel Rau


Am 10.05.2012 um 21:32 schrieb Alexander Gurvitz:

> Did you delete it manually (at 2012-05-07T14:55:02.569706) ?
Yes; i.e. my script.
> If so, maybe it's still in the zone because BIND doesn't know the timing
> metadata anymore ?
I thought that would be in the journal or internal repository of named.

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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

KSK stays published 3 days after delete time

2012-05-10 Thread Axel Rau

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 maintenance cycle until deleting?

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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

2012-03-06 Thread Axel Rau


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 supposed it would notice changes of $INCLUDEd DS or 
NSEC3PARAM RR automagically and act upon.

So my script has to do these 3 steps on changing NSEC3PARAM:
1. create new NSEC3PARAM (replacing $INCLUDED file)
2. increment SOA serial
3. rndc  signing -nsec3param myZone? 

Thanks, 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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

2012-03-06 Thread Axel Rau


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";
>};
> 
> 
>$ rndc signing -nsec3param 1 0 10 BEEF example.nil
>$ rndc signing -list example.nil
>Pending NSEC3 chain 1 0 10 BEEF
>$ dnssec-keygen -3 example.nil
>Generating key pair.++
>..++ 
>Kexample.nil.+007+28952
>$ dnssec-keygen -3fk example.nil
>Generating key pair...+++
>..+++ 
>Kexample.nil.+007+04053
>$ rndc loadkeys example.nil
>$ sbin/rndc signing -list example.nil
>Done signing with key 4053/NSEC3RSASHA1
>Done signing with key 28952/NSEC3RSASHA1
>$ dig @localhost +short nsec3param example.nil
>1 0 10 BEEF
So, I have to do this again, if the NSEC3PARAM changes (e.g. with a different 
salt during ZSK rollover)?
Or does auto-dnssec maintain take care on the changed NSEC3PARAM?

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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: A few conceptual question about dnssec.

2012-02-18 Thread Axel Rau


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 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: State diagram for DNSsec key lifecycle

2012-02-16 Thread Axel Rau


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 submitting the follow-up DS while its KSK not yet 
>> active.
>> Please review carefully and comment. Simplifications are also welcome.
> From state 'KSK2 active KSK1 inactive' to state 'DS1 retired from parent' the 
> diagram shows a delay of MD.
> Keeping the DS after inactivity of its KSK makes no sense to me.
> 
> What do you mean?
Due to lack of input, I did a major rework of the diagram, based on NIST 
800-81r1.

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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: State diagram for DNSsec key lifecycle

2012-02-14 Thread Axel Rau


Am 13.02.2012 um 19:48 schrieb Axel Rau:

> ere 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 submitting the follow-up DS while its KSK not yet 
> active.
> Please review carefully and comment. Simplifications are also welcome.
From state 'KSK2 active KSK1 inactive' to state 'DS1 retired from parent' the 
diagram shows a delay of MD.
Keeping the DS after inactivity of its KSK makes no sense to me.

What do you mean?

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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: State diagram for DNSsec key lifecycle

2012-02-13 Thread Axel Rau


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-02 uses the term 'used for signing' 
> as synonym for 'active' on page 22.
> I will update the diagram.
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 submitting the follow-up DS while its KSK not yet active.
Please review carefully and comment. Simplifications are also welcome.

Axel
PS: If someone cares, here is the cert of our root ca:
https://www.chaos1.de/cacert.pem
---
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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: State diagram for DNSsec key lifecycle

2012-02-11 Thread 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-02 uses the term 'used for signing' 
as synonym for 'active' on page 22.
I will update the diagram.

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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: State diagram for DNSsec key lifecycle

2012-02-11 Thread Axel Rau


Am 10.02.2012 um 00:54 schrieb Spain, Dr. Jeffry A.:

>> Please comment on this state diagram:
>> https://www.chaos1.de/svn-public/repos/network-tools/DNSsec/trunk/dnssec_key_states.pdf
> 
> For greater clarity, I suggest that for the state transitions (captions on 
> the arrows), you refer specifically to the four metadata timestamps that are 
> present in the keys: Publish, Activate, Inactive, and Delete, since these 
> govern what bind does with the keys.
Yes, this was my intention, but I have several implicit assumptions: publish = 
now(), active2 = active1.
I will clarify this. 
> 
> I think it would help also to add some information about how you will set the 
> values for these timestamps when the keys are generated with dnssec-keygen.
I will add this, when the diagram has been fixed.
> 
> You don't address the issue of key revocation, but perhaps that should wait 
> for later.
I consider this for version 2.

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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

State diagram for DNSsec key lifecycle

2012-02-09 Thread Axel Rau

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 script are in red color. mgmt dir is the per zone directory 
where named finds the keys.

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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Extracting key tag from DNSKEY

2012-01-25 Thread Axel Rau


Am 26.01.2012 um 00:12 schrieb Evan Hunt:

> 
>> Can I extract the key tag from a DNSKEY, obtained via dig?
> 
> "dig +multi" will show it.  In BIND 9.9, so will "dig +rrcomments".
Thanks Alan and Evan,
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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Extracting key tag from DNSKEY

2012-01-25 Thread Axel Rau

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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

2012-01-19 Thread Axel Rau


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 an authoritative server
> validate its own answers.)
Can dig tell me, if the sigs are valid, if I provide my trusted key?
Or do I need a 2nd (validating) ns?

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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

9.9.0rc1: example from arm 4.8.3 does not validate

2012-01-18 Thread Axel Rau

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 
8ebpRn+R2YT/WPJPnwww1pEaA0DIUjntlqp6qBaaCpsN3FxeiY2zA02R 
usDYpxqJZk/VLZ7EcOHvHRc2Ifz/tKl/vanSyHQ6R2ClLr+ksRtV8N8f 
k9dqBP/xPXELAfzISwsmlXQ4fz8UzpjeDpDk2oX07v1qQCkfy17FDGJP 
vR5MLl1v+4S/sinXpmHDxVfbhZ1W4K9MeOh+1juZtGTY6c3WyWOKzrzT pMhikbuYoeM=";
};
---
and
---
zone "example.com" IN {
type master;
file "master/signed/example.com/example.com.zone";
update-policy local;
key-directory "master/signed/example.com/";
auto-dnssec maintain;
inline-signing yes;
allow-query {
any;
};
};
---
But I'm getting no ad-flag:
---
root# dig DNSKEY +dnssec example.com.

; <<>> DiG 9.9.0rc1 <<>> DNSKEY +dnssec example.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22049
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;example.com.   IN  DNSKEY

;; ANSWER SECTION:
example.com.86400   IN  DNSKEY  256 3 5 
AwEAAbOJTICgDlvkj+ck/K6nYBhRaLxzlgD0fiFrIzC/d9X3abRTIIXH 
MCrmxJLrdXjlb7s/zUl+9AaRpwF3+QjXXQh+uD5QCVB9iRJ+EWPxE1M6 
5B6UL2XLrtYCUtxb2t+RHT0A5hHEBBqsExcxViydx4oIJ6Rd5dvLin7K 7l6ZU/Bf
example.com.86400   IN  DNSKEY  257 3 5 
AwEAAd5l859ggW8ZpVAQxEmugl+N/klWH+kFpcoQYGd3ngB6381lva2E 
IUXa2iOxJPmvYut96zUqhprlUfuEBvhU21Dd8dv7rr3Q5a+UT5XA9fUe 
8ebpRn+R2YT/WPJPnwww1pEaA0DIUjntlqp6qBaaCpsN3FxeiY2zA02R 
usDYpxqJZk/VLZ7EcOHvHRc2Ifz/tKl/vanSyHQ6R2ClLr+ksRtV8N8f 
k9dqBP/xPXELAfzISwsmlXQ4fz8UzpjeDpDk2oX07v1qQCkfy17FDGJP 
vR5MLl1v+4S/sinXpmHDxVfbhZ1W4K9MeOh+1juZtGTY6c3WyWOKzrzT pMhikbuYoeM=
example.com.86400   IN  RRSIG   DNSKEY 5 2 86400 20120216202248 
20120117192248 9765 example.com. 
FQSI+1SKjNuGtbNobrXIXAfKZGDrq6MWjq3O1FdMocSoLlhybTV9S98y 
ELPXTGg65Wfh6A0O2ebrbIGp5cJd3ncXbdGc9nkAgOh6LRqfuvzfqDnq 
fmUPRn7Ze8XyTHq4fhpBhe6cuNrLWn/Zw4C/8OUMDiQr75IIbsWUZnpJ qGo=
example.com.86400   IN  RRSIG   DNSKEY 5 2 86400 20120216202248 
20120117192248 56641 example.com. 
DM48WcSycwGSmtmD70xCxM6fNGVxZFLtXJK9ZEH/BU0wwAwTz8eeUtHa 
B0Vvh4ioEOgw24bdKl3oyqk/HkG530BWwTVoRp3HzmZkdgUoFY8JEb/A 
CqW9NFb+H1OGTgGtnCgrI3Fc2U9f7MaQpqkt3AzYBGYtFYtDEVDzLYcf 
UL3Eyv3MB4F3e5NqVrSymZhpcDkqfFh7uWUTGfU06ImJ7SZVdz0JHEQ2 
pcyKbS5jRrpH7yoATyyC/PzEnXIBWXSNwiveNWI2eDvC6stZa0BY5H4Z 
YJro2oRUozV67EtRlDryLqc4mgX0aOSr0mQHaUG2GzTc77fbiMoKRoH6 +tq1vw==
---
What am I doing wrong?

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 mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

56 matches

Mail list logo