RE: Windows 9.16.25 fails to start (1067 Terminated unexpectedly)
I run BIND on Windows as well but I've been unable to upgrade to 9.16.25 - I get an error stating "Error Validating Account. Unable to install service using this account.". So I'm presently running 9.16.21. What are the last few things in the Application Event Log (Source: named) before it terminates? Richard. -Original Message- From: bind-users On Behalf Of Jakob Bohm via bind-users Sent: 11 February 2022 12:19 pm To: bind-users Subject: Windows 9.16.25 fails to start (1067 Terminated unexpectedly) Dear list, When recently trying to upgrade some secondary-only authoritative servers running on Windows machines, I found that Bind 9.16.25 (x86_64) binaries from isc.org failed to completely startup, causing Windows to report that "1067 The process terminated unexpectedly.", with 0 process exit code. Attempting to up the debug level all the way to "-d 100" failed to log a reason, but downgrading to the 9.16.21 binaries resumed operation. Is there a known issue and workaround for this, or is there any additional information to extract? -- 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: Obsoleting keep-response-order option in BIND 9.19/9.20+
Thanks Fred, those are all good advices for the DNS over TCP implementors. Ondřej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 11. 2. 2022, at 18:32, Fred Morris wrote: > > It's not BIND's fault or responsibility, but I hope it is well documented > and remains well documented. > >> On Fri, 11 Feb 2022, Ondřej Surý wrote: >> [...] >> when out-of-order response processing was introduced in BIND 9.11.0, there >> was >> a “defensive” option added called keep-response-order that takes ACL as >> option >> to enable the previous behaviour where the DNS responses were sent in the >> same >> order as the received DNS queries. >> >> For BIND 9.19 (development) and 9.20 (stable) release scheduled in 2 years, >> we >> plan to make BIND 9 rely on DNS clients being compliant with RFC 7766[1]: >> >>> 7. Response Reordering >>> [...] >>> For the avoidance of future doubt, this requirement is clarified. >>> Authoritative servers and recursive resolvers are RECOMMENDED to >>> support the preparing of responses in parallel and sending them out >>> of order, regardless of the transport protocol in use. Stub and >>> recursive resolvers MUST be able to process responses that arrive in >>> a different order than that in which the requests were sent, >>> regardless of the transport protocol in use. >>> >>> In order to achieve performance on par with UDP, recursive resolvers >>> SHOULD process TCP queries in parallel and return individual >>> responses as soon as they are available, possibly out of order. >>> >>> Since pipelined responses can arrive out of order, clients MUST match >>> responses to outstanding queries on the same TCP connection using the >>> Message ID. If the response contains a question section, the client >>> MUST match the QNAME, QCLASS, and QTYPE fields. Failure by clients >>> to properly match responses to outstanding queries can have serious >>> consequences for interoperability. > > Let's face it, DNS is hard to do right. > > Having done several different things involving DNS over TCP these last few > years this behavior has caught my attention, notwithstanding that I hadn't > read 7766 for comprehension. > > Coding a client under these conditions, let me offer a few defensive > strategies: > > * send the prepended length field with the message from the application > layer (hopefully it ends up in the same packet) > > * don't expect the prepended length field to be prepended in the same > packet as the reply > > * for that matter don't expect that a response which would fit in a > UDP packet will arrive in a single read > > * when in doubt, connect + send a request + get a response + close > > * send a single request and wait for a single response (manage any > queueing on your end) even if you plan to send multiple requests > > * if the response doesn't look right hang up and try again > > I strongly counsel against premature optimization. > > I hope those suggestions can also serve to inform server implementers / > operators. > > (I think the RFC has a number of biases towards server implementers / > operators, some plain, some more along the lines of moral hazard.) > > -- > > Fred Morris > -- > 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 -- 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: Obsoleting keep-response-order option in BIND 9.19/9.20+
It's not BIND's fault or responsibility, but I hope it is well documented and remains well documented. On Fri, 11 Feb 2022, Ondřej Surý wrote: [...] when out-of-order response processing was introduced in BIND 9.11.0, there was a “defensive” option added called keep-response-order that takes ACL as option to enable the previous behaviour where the DNS responses were sent in the same order as the received DNS queries. For BIND 9.19 (development) and 9.20 (stable) release scheduled in 2 years, we plan to make BIND 9 rely on DNS clients being compliant with RFC 7766[1]: 7. Response Reordering [...] For the avoidance of future doubt, this requirement is clarified. Authoritative servers and recursive resolvers are RECOMMENDED to support the preparing of responses in parallel and sending them out of order, regardless of the transport protocol in use. Stub and recursive resolvers MUST be able to process responses that arrive in a different order than that in which the requests were sent, regardless of the transport protocol in use. In order to achieve performance on par with UDP, recursive resolvers SHOULD process TCP queries in parallel and return individual responses as soon as they are available, possibly out of order. Since pipelined responses can arrive out of order, clients MUST match responses to outstanding queries on the same TCP connection using the Message ID. If the response contains a question section, the client MUST match the QNAME, QCLASS, and QTYPE fields. Failure by clients to properly match responses to outstanding queries can have serious consequences for interoperability. Let's face it, DNS is hard to do right. Having done several different things involving DNS over TCP these last few years this behavior has caught my attention, notwithstanding that I hadn't read 7766 for comprehension. Coding a client under these conditions, let me offer a few defensive strategies: * send the prepended length field with the message from the application layer (hopefully it ends up in the same packet) * don't expect the prepended length field to be prepended in the same packet as the reply * for that matter don't expect that a response which would fit in a UDP packet will arrive in a single read * when in doubt, connect + send a request + get a response + close * send a single request and wait for a single response (manage any queueing on your end) even if you plan to send multiple requests * if the response doesn't look right hang up and try again I strongly counsel against premature optimization. I hope those suggestions can also serve to inform server implementers / operators. (I think the RFC has a number of biases towards server implementers / operators, some plain, some more along the lines of moral hazard.) -- Fred Morris -- 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: Bind: Standard Ports And Non Standard Ports
On Fri, Feb 11, 2022 at 10:21 AM Tim Daneliuk via bind-users < bind-users@lists.isc.org> wrote: > > After some months of poking around, we are now certain that our so-called > "Business" > service from Comcast is compromising our DNS servers because of their > execrable "Security Edge" garbage. (They are willing to remove this > 'service' > only if we are willing to incur a higher monthly recurring fee.) > > According to "the Internet" (aka, some random reddit thread), there is a way to disable this: https://www.reddit.com/r/networking/comments/fl0ujm/xfinity_secureedge_for_business_transparently/ It did not *look* like this required changing service / a higher fee, but ... W > Our master is in the wild and works fine, but the slave is behind the > compromised > Comcast pipe. The effect of having Security Edge in place is that the > slave cannot get updates from the master and is also unable to resolve > anything outside our own zone. Comcast is apparently hijacking all port > 53 requests and doing unspeakable things with them. > > Is there a way to have these servers work as usual, listening to resolution > request on port 53, but have the slave update AND forward requests to the > master over a non-standard port, so as to work around the Comcast madness? > > TIA, > Tim > > P.S. My guess is that this so-call "security" service is no such thing, or > at > least its not the only thing. They are probably harvesting DNS > lookups > to sell as marketing data, or at least that would be my first guess. > -- > 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 > -- The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- E. W. Dijkstra -- 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: Bind: Standard Ports And Non Standard Ports
I have Comcast Business with 2 name servers behind it and 50 or so domain names hosted on them. No problems at all. Never heard of Security Edge. We could have a discussion on your setup and compare notes but your problems have nothing to do with port 53 filtering in the Comcast network, IMHO. Ted On 2/11/2022 7:20 AM, Tim Daneliuk via bind-users wrote: After some months of poking around, we are now certain that our so-called "Business" service from Comcast is compromising our DNS servers because of their execrable "Security Edge" garbage. (They are willing to remove this 'service' only if we are willing to incur a higher monthly recurring fee.) Our master is in the wild and works fine, but the slave is behind the compromised Comcast pipe. The effect of having Security Edge in place is that the slave cannot get updates from the master and is also unable to resolve anything outside our own zone. Comcast is apparently hijacking all port 53 requests and doing unspeakable things with them. Is there a way to have these servers work as usual, listening to resolution request on port 53, but have the slave update AND forward requests to the master over a non-standard port, so as to work around the Comcast madness? TIA, Tim P.S. My guess is that this so-call "security" service is no such thing, or at least its not the only thing. They are probably harvesting DNS lookups to sell as marketing data, or at least that would be my first guess. -- 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: Is there a community product maintaining Windows support?
I just became a maintainer on the apcupsd project. I don't know if bind for windows is built like apcupsd is, by using mingw32 but unfortunately there's problems with the mingw32 project these days, it's gone through a lot of transitions. Getting a working build environment for apcupsd at least, requires using pretty old versions of mingw. No doubt I'm going to be jumped on for saying so but I know for apcupsd I've got a -lot- of work to do to get it up to speed. There are some people out there who have built their own mingw32/mingw64 binaries that are separate from the ones "officially" distributed which might be an avenue. My guess the ISC developer who was spearheading this port moved on to other things and ISC can't find someone who wants to get involved in this and I can understand why. There is an interesting article on this problem here: https://increment.com/open-source/the-rise-of-few-maintainer-projects/ I would ask you this Jakob - would you trust a windows binary of bind that you compiled? I've got years of history participating on the apcupsd project. When I start submitting changes to it, the users of it have that trust automatically from that history. They won't worry if they download a binary from sourceforge that I built that it's going to gun their system. I'm a public figure in OSS besides that - people may like me or think I'm an asshole - but they know I'm a real person who has a rep. to maintain. I've got a business, federal and state tax ID's, a published phone number, multiple domain names I've owned for years. I can't run and hide. You can probably review the bind mailing list and dig out less than 100 names of people who have been on it, regularly posting, for the last decade. If none of those people step up to create a fork - then the windows port is effectively going to be dead I'm afraid. Nobody is going to trust "some dude" with zero history who sets up on github and forks bind and posts a windows binary for downloading just because he says it's gold. Would you? Trust a production system to that? OSS got it's start by making the CODE available, NOT BINARIES. Users like you were expected to be completely happy with the fact that the code was even there at all and it compiled. You do your own building. Not knowing how to run a compiler is no excuse. The Internet has tons of tutorials on it. You want a bind for windows - build it yourself. That's the can-do attitude that OSS started with. I remember the first time I ever downloaded an real OSS code and built it myself. It was rzsz - zmodem code for windows. Back in the BBS days, really. That's the only way you got that binary. It was a total gas and I was hooked. Don't deny yourself the same pleasure. Ted On 2/11/2022 8:24 AM, Jakob Bohm via bind-users wrote: As ISC has apparently announced that it will no longer maintain the code for running bind on Windows operating systems, and that this is now up to the community, is there a community group that has stepped up to the task? Enjoy Jakob -- 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: Bind: Standard Ports And Non Standard Ports
Yes, look for “port” configuration in the documentation: https://bind9.readthedocs.io/en/v9_16_25/ You can configure the upstream to listen on non-standard port and the downstream to use it. We use this internally in the system tests. As a side note please separate the technical questions and rants. The experience shows that sticking to the technical questions leads to more pleasant experience on the mailing list. Thanks. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 11. 2. 2022, at 16:21, Tim Daneliuk via bind-users > wrote: > > > After some months of poking around, we are now certain that our so-called > "Business" > service from Comcast is compromising our DNS servers because of their > execrable "Security Edge" garbage. (They are willing to remove this 'service' > only if we are willing to incur a higher monthly recurring fee.) > > Our master is in the wild and works fine, but the slave is behind the > compromised > Comcast pipe. The effect of having Security Edge in place is that the > slave cannot get updates from the master and is also unable to resolve > anything outside our own zone. Comcast is apparently hijacking all port > 53 requests and doing unspeakable things with them. > > Is there a way to have these servers work as usual, listening to resolution > request on port 53, but have the slave update AND forward requests to the > master over a non-standard port, so as to work around the Comcast madness? > > TIA, > Tim > > P.S. My guess is that this so-call "security" service is no such thing, or at > least its not the only thing. They are probably harvesting DNS lookups > to sell as marketing data, or at least that would be my first guess. > -- > 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 -- 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: Bind: Standard Ports And Non Standard Ports
On 2022-02-11 16:20, Tim Daneliuk via bind-users wrote: After some months of poking around, we are now certain that our so-called "Business" service from Comcast is compromising our DNS servers because of their execrable "Security Edge" garbage. (They are willing to remove this 'service' only if we are willing to incur a higher monthly recurring fee.) Our master is in the wild and works fine, but the slave is behind the compromised Comcast pipe. The effect of having Security Edge in place is that the slave cannot get updates from the master and is also unable to resolve anything outside our own zone. Comcast is apparently hijacking all port 53 requests and doing unspeakable things with them. Is there a way to have these servers work as usual, listening to resolution request on port 53, but have the slave update AND forward requests to the master over a non-standard port, so as to work around the Comcast madness? TIA, Tim P.S. My guess is that this so-call "security" service is no such thing, or at least its not the only thing. They are probably harvesting DNS lookups to sell as marketing data, or at least that would be my first guess. If bind cannot be configured to avoid a port blocking or filtering 3rd party filter between two of your own servers, the obvioussolution is to use a traditional VPN solution such as DNSSEC or OpenVPN to encrypt all traffic between the two servers. That should pass through any ISP filters that don't block work-from-home VPNs. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- 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
Is there a community product maintaining Windows support?
As ISC has apparently announced that it will no longer maintain the code for running bind on Windows operating systems, and that this is now up to the community, is there a community group that has stepped up to the task? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- 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
Bind: Standard Ports And Non Standard Ports
After some months of poking around, we are now certain that our so-called "Business" service from Comcast is compromising our DNS servers because of their execrable "Security Edge" garbage. (They are willing to remove this 'service' only if we are willing to incur a higher monthly recurring fee.) Our master is in the wild and works fine, but the slave is behind the compromised Comcast pipe. The effect of having Security Edge in place is that the slave cannot get updates from the master and is also unable to resolve anything outside our own zone. Comcast is apparently hijacking all port 53 requests and doing unspeakable things with them. Is there a way to have these servers work as usual, listening to resolution request on port 53, but have the slave update AND forward requests to the master over a non-standard port, so as to work around the Comcast madness? TIA, Tim P.S. My guess is that this so-call "security" service is no such thing, or at least its not the only thing. They are probably harvesting DNS lookups to sell as marketing data, or at least that would be my first guess. -- 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
Windows 9.16.25 fails to start (1067 Terminated unexpectedly)
Dear list,
When recently trying to upgrade some secondary-only authoritative
servers running on Windows machines, I found that Bind 9.16.25 (x86_64)
binaries from isc.org failed to completely startup, causing Windows to
report that "1067 The process terminated unexpectedly.", with 0 process
exit code. Attempting to up the debug level all the way to "-d 100"
failed to log a reason, but downgrading to the 9.16.21 binaries resumed
operation.
Is there a known issue and workaround for this, or is there any
additional information to extract?
The bind binaries are installed in C:\Program Files\ISC BIND 9\bin
The config files are in C:\Program Files\ISC BIND 9\etc
Commenting out all the configured secondary zones did not fix the issues.
The zone primaries are identified by IP address in the zone config entries.
One of the last (but not always the actual last) debug messages logged
before failure was this:
resolver: debug 1: fetch: ./NS
This may or may not point to incomplete disabling of useless root server
access attempts.
Current config file:
options {
directory "C:\Program Files\ISC BIND 9\etc";
automatic-interface-scan no;
listen-on { 172.31.41.230; 127.0.0.1; };
listen-on-v6 { any; };
// Authoritative only
allow-query-cache { none; };
// Do not provide recursive service
recursion no;
// This is the default
allow-query { any; };
// This is not
allow-transfer { none; };
// Other useful settings
minimal-responses yes;
multi-master yes;
notify master-only;
version none;
server-id hostname;
max-zone-ttl 2764800;
// Prevent queries that would case troubles
blackhole { 0.0.0.0/8;
10.0.0.0/8;
172.16.0.0/12;
192.168.0.0/16;
169.254.0.0/16; };
};
logging {
channel bind.log {
file "C:\Windows\logs\bind\bind.log" versions 10 size 20m;
// severity information;
print-category yes;
print-severity yes;
print-time yes;
};
category client { bind.log; };
category cname { bind.log; };
category config { bind.log; };
category database { bind.log; };
category default { bind.log; };
category delegation-only { bind.log; };
category dispatch { bind.log; };
category dnssec { bind.log; };
category dnstap { bind.log; };
category edns-disabled { bind.log; };
category general { bind.log; };
category lame-servers { bind.log; };
category network { bind.log; };
category notify { bind.log; };
category nsid { bind.log; };
category queries { bind.log; };
category query-errors { bind.log; };
category rate-limit { bind.log; };
category resolver { bind.log; };
category rpz { bind.log; };
category security { bind.log; };
category serve-stale { bind.log; };
category spill { bind.log; };
category trust-anchor-telemetry { bind.log; };
category unmatched { bind.log; };
category update { bind.log; };
category update-security { bind.log; };
category xfer-in { bind.log; };
category xfer-out { bind.log; };
category zoneload { bind.log; };
};
include "zones.bind.conf";
include "rndc.key";
controls {
inet 127.0.0.1 port 953 allow { localhost; } keys { "rndc-key"; };
};
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
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
Changing ZSK-lifetime in dnssec-policy is not applied
Hi
Using BIND-9.16.22 and dnssec-policy:
I've migrated an already existing and signing "auto-dnssec"-configured
zone to dnssec-policy (same algorithms). That worked without any issues.
After a while, I changed the ZSK lifetime from 30d to 60d (see below) in
the dnssec-policy:
dnssec-policy "thewaytogo" {
signatures-refresh 5d;
signatures-validity 14d;
signatures-validity-dnskey 14d;
dnskey-ttl 3600s;
publish-safety 1h;
retire-safety 1h;
purge-keys 10d;
keys {
ksk lifetime unlimited algorithm ecdsap256sha256;
zsk lifetime 60d algorithm ecdsap256sha256;
};
zone-propagation-delay 300s;
max-zone-ttl 86400s;
parent-propagation-delay 1h;
parent-ds-ttl 3600;
nsec3param iterations 0 optout no salt-length 0;
};
After reloading/restarting named, I can't see the new lifetime
(scheduled rollover), neither in the rndc-output, nor in the keyfile
itself (ZSK 63304). The new lifetime should be 12/13 Apr and not 13 Mar.
# rndc-output
$ rndc dnssec -status example.com
dnssec-policy: thewaytogo
current time: Fri Feb 11 13:02:10 2022
key: 455 (ECDSAP256SHA256), ZSK
published: yes - since Wed May 20 14:50:09 2020
zone signing: no
Key is retired, will be removed on Mon Jun 29 15:55:09 2020
- goal: hidden
- dnskey: omnipresent
- zone rrsig: unretentive
key: 63304 (ECDSAP256SHA256), ZSK
published: yes - since Fri Feb 11 08:19:18 2022
zone signing: yes - since Fri Feb 11 09:24:18 2022
Next rollover scheduled on Sun Mar 13 07:19:18 2022
- goal: omnipresent
- dnskey: omnipresent
- zone rrsig: rumoured
key: 39500 (ECDSAP256SHA256), KSK
published: yes - since Wed May 20 14:50:09 2020
key signing:yes - since Wed May 20 14:50:09 2020
No rollover scheduled
- goal: omnipresent
- dnskey: omnipresent
- ds: omnipresent
- key rrsig: omnipresent
# key-file
; This is the state of key 63304, for example.com.
Algorithm: 13
Length: 256
Lifetime: 2592000
Predecessor: 455
KSK: no
ZSK: yes
Generated: 20220211071918 (Fri Feb 11 08:19:18 2022)
Published: 20220211071918 (Fri Feb 11 08:19:18 2022)
Active: 20220211082418 (Fri Feb 11 09:24:18 2022)
Retired: 20220313082418 (Sun Mar 13 09:24:18 2022)
Removed: 20220323092918 (Wed Mar 23 10:29:18 2022)
DNSKEYChange: 20220211092418 (Fri Feb 11 10:24:18 2022)
ZRRSIGChange: 20220211092418 (Fri Feb 11 10:24:18 2022)
DNSKEYState: omnipresent
ZRRSIGState: rumoured
GoalState: omnipresent
Any hints for this?
Many thanks.
Best regards,
Tom
--
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
Obsoleting keep-response-order option in BIND 9.19/9.20+
Hi, when out-of-order response processing was introduced in BIND 9.11.0, there was a “defensive” option added called keep-response-order that takes ACL as option to enable the previous behaviour where the DNS responses were sent in the same order as the received DNS queries. For BIND 9.19 (development) and 9.20 (stable) release scheduled in 2 years, we plan to make BIND 9 rely on DNS clients being compliant with RFC 7766[1]: > 7. Response Reordering > >RFC 1035 is ambiguous on the question of whether TCP responses may be >reordered -- the only relevant text is in Section 4.2.1, which >relates to UDP: > > Queries or their responses may be reordered by the network, or by > processing in name servers, so resolvers should not depend on them > being returned in order. > >For the avoidance of future doubt, this requirement is clarified. >Authoritative servers and recursive resolvers are RECOMMENDED to >support the preparing of responses in parallel and sending them out >of order, regardless of the transport protocol in use. Stub and >recursive resolvers MUST be able to process responses that arrive in >a different order than that in which the requests were sent, >regardless of the transport protocol in use. > >In order to achieve performance on par with UDP, recursive resolvers >SHOULD process TCP queries in parallel and return individual >responses as soon as they are available, possibly out of order. > >Since pipelined responses can arrive out of order, clients MUST match >responses to outstanding queries on the same TCP connection using the >Message ID. If the response contains a question section, the client >MUST match the QNAME, QCLASS, and QTYPE fields. Failure by clients >to properly match responses to outstanding queries can have serious >consequences for interoperability. We haven’t found any evidence that the option was ever used in production to un-break a non-compliant DNS client and hence we plan to directly make the option to do nothing instead of graceful removal which would force us to support the option for the next 6 years. The option will be marked obsolete, so named-checkconf will issue a warning, and removed in BIND 9.21+ development release. 1. https://datatracker.ietf.org/doc/html/rfc7766#section-7 -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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: dnssec: ds showing hidden 3+ days after key roll
Hi Larry,
This is documented in the DNSSEC RFCs, but AFAICS it is not mentioned in
our documentation. I created a merge request to add such a note in the
appropriate places:
https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5823
Best regards,
Matthijs
On 10-02-2022 18:23, Larry Rosenman wrote:
On 02/10/2022 10:10 am, Matthijs Mekking wrote:
Hi,
There are several things wrong here. The gist of it is that there is
no valid ZSK and since the zone is not properly signed, BIND does not
want to publish the DS record (even if outside BIND you already
published the DS).
You can tell that BIND does not agree because it did not publish a CDS
record in your zone.
I also noticed two different algorithms. I hadn't noticed it before
but your policy says:
keys {
ksk lifetime unlimited algorithm 8 2048 ;
zsk lifetime 30d algorithm 13;
};
This is a garbage policy because you specify different algorithms for
the ksk and the zsk. This can never result in a validly signed zone.
Change the algorithm of the keys so that they match.
Perhaps we can add a named-checkconf check for this.
Best regards,
Matthijs
[snip]
Thanks! Is that little nuance documented? (The need for KSK and ZSK
to be aligned on type of key)
--
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
