Re: Primary zone not fully maintained by BIND
On 27-05-2022 15:59, Matthijs Mekking wrote: Yes, I would recommend key separation (that is use a different key-directory per view). I tried that, gracefully, by setting 'dnssec-policy' to insecure for the internal view. That gave me some issues. Probably, because I had already moved the key for the external view to a separate directory. Anyway, I couldn't withdraw the original key from the internal view and reverted to the original setup: same key directory and same policy for both internal and external view of zone penguinpee.nl. I am going to investigate your configuration more next week, to see if there is a hidden bug. Thank you for looking into it. If there's anything I can do to assist, please let me know. Right now, I have a bunch of RRSIG RRs that are about to expire some time on 1 June. One thing that caught my eye when I was poking around, is the output of 'rndc zonestatus. For the internal view I get a date in the future for 'next resign time'. For the external view, the date is in the past. Not sure if that's a tell tale sign. -- Sandro -- 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: Primary zone not fully maintained by BIND
On 23-05-2022 15:48, Tony Finch wrote: The place I would look first is the log messages from `named`: is it complaining about anything? Plenty of: zone penguinpee.nl/IN/external: reconfiguring zone keys zone penguinpee.nl/IN/external: next key event: 22-May-2022 01:00:01.961 When the log files rolled over at 00:00 on 22 May, named.log just reported: 22-May-2022 00:00:07.093 general: info: reloading configuration succeeded 22-May-2022 00:00:07.272 general: info: reloading zones succeeded 22-May-2022 00:00:07.402 general: notice: all zones loaded 22-May-2022 00:00:07.402 general: notice: running One of the things I have to take care with (because I have got it wrong several times!) is filesystem permissions: can `named` read the .private keys? can it read and write to the zone files? can it read and write to the directories containing the keys and the zone files? Yeah, that's all fine. All keys for internal and external, forward and reverse zones are stored in the same directory with rw access for named. On the internal zone, the records look just fine: RRSIG CNAME 13 3 259200 ( 20220605095654 20220522085940 56132 penguinpee.nl. Geyl5Rz6Kqwfp5JUf09A1NB3fRU6EhdszCihduKlJat7 W8780MyS2awJjI+xDi9zG9fkO8yQx48hGeDDFxc3dA== ) The reverse zone in the external view was up to date and named was able to re-sign the affected zone after the restart. So, permissions are good, I'd say. I'll do some more digging through the log files. I meanwhile increased the severity to 'debug 3' for dnssec_debug. -- Sandro -- 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
Primary zone not fully maintained by BIND
Hello,
I was notified this morning by my registrar, that validation of my zone
records failed. Upon inspection, it turned out that only the SOA record
was still up to date. A and MX al returned RRSIG expired.
I checked my logs and did not see any warning signs. I also tried to get
the zone re-signed manually using 'rndc sign'. That either didn't work
or I wasn't patient enough. I ended up removing all DNSSEC related
entries from the zone file, increasing the serial and restarted named.
Upstream servers already stopped answering queries, so I was in a bit of
a hurry getting this fixed.
Since I want to avoid this happening again, I would like to understand
what went wrong. My setup is as follows for the zone in question:
options {
dnssec-validation yes;
dnssec-policy default;
};
view "internal" {
match-clients { local; };
recursion no;
allow-update{ key ddns-key.penguinpee.nl; };
zone "penguinpee.nl" {
typeprimary;
file"dynamic/penguinpee.nl.internal.zone";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "penguinpee.nl" {
typeprimary;
file"master/penguinpee.nl.zone";
allow-query { any; };
allow-transfer { transip; };
notify no;
};
};
Using delv, the internal view of the zone fully validated, for SOA, A,
etc. However in the external view delv told me 'RRSIG has expired'
for all records but SOA.
Looking at the zone file, I indeed saw expired entries like:
RRSIG MX 13 2 300 (
20220501085742 20220421164308 56132 penguinpee.nl.
FcrfTtdZDxO1dmarFgvbb+jAM5dT8EOrqGdOywKjQqjL
dcSHfaFuR8qP5PyyrCW6UOqMxWRjelPqBQBaBIY2aA== )
I thought that with 'dnssec-policy default' BIND would take care of it.
Upon updating the zone, increase the serial number and tell named with
'rndc reload zone'. What am I missing?
-- Sandro
--
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: Primary zone not fully maintained by BIND
On 23-05-2022 16:12, Sandro wrote: I'll do some more digging through the log files. I meanwhile increased the severity to 'debug 3' for dnssec_debug. Nothing really pops out. I have scrolled through all the logs since rotation on Sunday at midnight. Since increasing verbosity on category dnssec, I see messages regarding transitioning DS from RUMOURED to OMNIPRESENT failing. But that happens for pretty much all zones. I added logging for the unmatched category. Is there any other category that I should tweak to get more output regarding this issue? I have most categories on info. -- Sandro -- 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: Primary zone not fully maintained by BIND
On 26-05-2022 10:34, Matthijs Mekking wrote: What version are you using? We had a bug with dnssec-policy and views (#2463), but that has been fixed. I'm using BIND 9.16.28-RH on Fedora Server. I'll take a look at the bug report in a minute. Since 9.16.18 you should not be able to set the same key-directory for the same zone in different views. That's odd. I have the key-directory option set globally in options and it is being used by all zones internal and external. Key for penguinpee.nl is shared between both views it appears. I was just about to sent an update, when your mail arrived... ;) -- Sandro -- 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: Primary zone not fully maintained by BIND
On 23-05-2022 16:12, Sandro wrote: I'll do some more digging through the log files. I meanwhile increased the severity to 'debug 3' for dnssec_debug. I'm having some issues again. Not as severe as last time, since the RRSIG records are all still within their validity period. However, bind tells me it cannot rekey my zone. So, I suspect this will turn into a problem by the time the RRSIG records run out: 26-May-2022 10:06:14.458 debug 3: zone penguinpee.nl/IN/external: zone_rekey failure: unexpected error (retry in 600 seconds) This message then repeats every 10 minutes. The last successful rekey happened on 25 May at 09:38:25 after zone reload. Shortly after, at 09:38:54, the first error occurred and it hasn't been rectified since. I may have issued a 'rndc sign' for the zone shortly after the reload. Could that have "confused" BIND as JP put it? I'll attach the full log for better readability (long lines). How do I get BIND to tell me more about the unexpected error? -- Sandro PS: This may turn out to be spilled milk. But I had this typed up already before I saw the mail from Matthijs.26-May-2022 10:06:14.399 info: zone penguinpee.nl/IN/external: reconfiguring zone keys 26-May-2022 10:06:14.438 debug 1: keymgr: keyring: penguinpee.nl/ECDSAP256SHA256/56132 (policy penguinpee) 26-May-2022 10:06:14.438 debug 1: keymgr: dnskeys: penguinpee.nl/ECDSAP256SHA256/56132 (policy penguinpee) 26-May-2022 10:06:14.438 debug 1: keymgr: DNSKEY penguinpee.nl/ECDSAP256SHA256/56132 (CSK) matches policy penguinpee 26-May-2022 10:06:14.438 debug 1: keymgr: DNSKEY penguinpee.nl/ECDSAP256SHA256/56132 (CSK) is active in policy penguinpee 26-May-2022 10:06:14.438 debug 1: keymgr: new successor needed for DNSKEY penguinpee.nl/ECDSAP256SHA256/56132 (CSK) (policy penguinpee) in 2641414922 seconds 26-May-2022 10:06:14.438 debug 1: keymgr: examine CSK penguinpee.nl/ECDSAP256SHA256/56132 type DNSKEY in state OMNIPRESENT 26-May-2022 10:06:14.438 debug 1: keymgr: CSK penguinpee.nl/ECDSAP256SHA256/56132 type DNSKEY in stable state OMNIPRESENT 26-May-2022 10:06:14.438 debug 1: keymgr: examine CSK penguinpee.nl/ECDSAP256SHA256/56132 type ZRRSIG in state OMNIPRESENT 26-May-2022 10:06:14.438 debug 1: keymgr: CSK penguinpee.nl/ECDSAP256SHA256/56132 type ZRRSIG in stable state OMNIPRESENT 26-May-2022 10:06:14.439 debug 1: keymgr: examine CSK penguinpee.nl/ECDSAP256SHA256/56132 type KRRSIG in state OMNIPRESENT 26-May-2022 10:06:14.439 debug 1: keymgr: CSK penguinpee.nl/ECDSAP256SHA256/56132 type KRRSIG in stable state OMNIPRESENT 26-May-2022 10:06:14.439 debug 1: keymgr: examine CSK penguinpee.nl/ECDSAP256SHA256/56132 type DS in state OMNIPRESENT 26-May-2022 10:06:14.439 debug 1: keymgr: CSK penguinpee.nl/ECDSAP256SHA256/56132 type DS in stable state OMNIPRESENT 26-May-2022 10:06:14.458 debug 3: zone penguinpee.nl/IN/external: zone_rekey failure: unexpected error (retry in 600 seconds) -- 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: Primary zone not fully maintained by BIND
On 26-05-2022 11:05, Sandro wrote: I'll take a look at the bug report in a minute. Well, there are similarities between #2463 and my setup, but also differences. In my case, all zones are signed, internal and external. I have one dnssec-policy defined in the options section, which is a verbatim copy of dnssec-policy.default with only one adjustment: zone-propagation-delay is set to 1h instead of 300s. The internal view of penguinpee.nl is a dynamic primary zone. It receives zone updates from Kea DHCP Server. The external zone is a static primary zone, updated manually as needed. Since they share the same key now, I could reconfigure the internal view and have BIND create a new key in a separate directory for that view. I could also define a separate policy for the internal view to see if that makes a difference. Probably one change at a time to nail this thing down. Thank you, Matthijs, for pointing out the bug. Do you have any suggestion for what to try first, key separation or policy separation? -- Sandro -- 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: Splitting long strings in RRs using parentheses
On 26-05-2022 15:27, Jan-Piet Mens via bind-users wrote: A semicolon begins a comment in a zone file [1], so yes. -JP [1] https://jpmens.net/2015/10/28/the-semicolon-in-zone-master-files-some-history/ Thank you, JP. Nice blog post. Very enlightening. On 26-05-2022 15:29, Bjørn Mork wrote: https://datatracker.ietf.org/doc/html/rfc1035#section-5.1 So yes, that's expected behaviour. You need to quote that ; unless you want BIND to interpret it as the start of a comment Thank you as well, Bjørn. I might skim through the RFC, but JP's post is much lighter reading. ;) Quite a contrast to the required semicolons in the BIND configuration files. Many a time, when I first started using BIND, it would throw errors at me because of a missing semicolon inside curly braces or right after the closing one. -- Sandro -- 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: Primary zone not fully maintained by BIND
On 26-05-2022 12:00, Sandro wrote: Thank you, Matthijs, for pointing out the bug. Do you have any suggestion for what to try first, key separation or policy separation? Well, I went for key separation. Let's see if it sticks. Last time I restarted BIND everything seemed fine in the beginning as well. Of course, the question remains if there's still a bug hiding here somewhere. I'd be happy providing more information and performing tests to gather information. What's been throwing me of balance over and over is the fact the zone file on disk can be outdated for quite some time, while the answers provided querying BIND with dig are already updated. But that's probably me getting acquainted with BIND being in charge of the zone. -- Sandro -- 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
Splitting long strings in RRs using parentheses
Hello, While adding a DKIM key to my zone I was looking for information about using parentheses for working around the string length limitation. I looked at the way BIND puts them in my zone file for RRSIG entries and and applied that to the TXT record: 20220317-a4qe._domainkeyTXT ( v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAA OCAQ8AMIIBCgKCAQEAmEsWuQCj+OenaSQ3dM6WItExor ... QXLXEHkQIDAQAB ) However, that was transformed by BIND into: 20220317-a4qe._domainkey.penguinpee.nl. 3600 IN TXT "v=DKIM1" "OCAQ8AMIIBCgKCAQEAmEsWuQCj+OenaSQ3dM6WItExor" ... "QXLXEHkQIDAQAB" The bit from the first semicolon to the end of the line was missing. Is that expected behavior? I couldn't find any documentation regarding the usage of parentheses. I know I can also use multiple strings, just like in the answer from BIND. I worked around the issue defining it as follows: 20220317-a4qe._domainkeyTXT "v=DKIM1; k=rsa; " ( p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQ That returns the full key and all parameters. So, this question is more out of curiosity. -- Sandro -- 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
severity dynamic not behaving as expected
Hello (again),
I was reviewing my logging configuration, implementing new categories
and generally reorganizing stuff.
From what I remember and from what I read in the documentation, using
"severity dynamic" on a channel should result in logging being disabled
for that channel as long as debugging is turned of. Yet, I'm seeing info
messages in my debug.log file.
This is the relevant configuration:
channel default_debug {
file"/var/log/named/debug.log";
print-category yes;
print-severity yes;
print-time yes;
severitydynamic;
};
category general { default_logfile; default_syslog; default_debug; };
There are more categories logging to that channel, but as an example
from category general I'm seeing info messages in debug.log:
general: info: received control channel command 'stats'
general: info: dumpstats complete
(timestamps left out for brevity)
I verified with 'rndc status' that debug level is 0.
Has the behavior changed or am I completely misunderstanding something
here (again)?
-- Sandro
--
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: Probably stupid simple question...
On 01-06-2022 20:07, Bruce Johnson via bind-users wrote: I am migrating our BIND system to a new server/BIND version, and have a question about dynamically updated zone files (we have one dynamic zone). I am just copying all the configuration and zone files to the new server, do I need to run rndc freeze before shutting down bind and moving them or will just stopping the bind service properly deal with updating the zone file? Also do I need to copy over the .jnl file when I do this or will a new one get generated as needed? Not a stupid question, but an easy answer (man 8 rndc): This command stops the server, making sure any recent changes made through dynamic update or IXFR are first saved to the master files of the updated zones. So as long as you stop named with 'rndc stop', the zone file will be up to date. That also makes the journal file obsolete. So, you don't need to move that over. But it doesn't hurt if you do. Before starting named on the new system, assuming your main configuration file is 'etc/named.conf', use: named-checkconf -z /etc/named.conf This will check your configuration and all your zones and tell you if anything is wrong. -- Sandro -- 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: Primary zone not fully maintained by BIND
On 24-05-2022 20:57, Jan-Piet Mens via bind-users wrote: Slightly off-topic, but I believe ISC reccomend using a custom policy instead of `default' in case the default changes in future. Yes, sort of. The documentation hints at the fact that the default policy is subject to change. I meanwhile grabbed the dnssec-policy.default file from GitLab and using that as a locally defined policy. That surprises me a bit; I've always maintained BIND will not validate a DNSSEC-signed zone it is authoritative for. Unless you mean RRSIGs were still valid. My terminology might not have been accurate. It is/were the RRSIGS that were outdated for all but the SOA record. I used the command provided in the documentation: delv @10.0.0.242 -a Kpenguinpee.nl.+013+56132.key \ +root=penguinpee.nl penguinpee.nl. SOA +multiline The key file here is the DNSKEY converted into a trust-anchor as per BIND ARM [1]. Checking any other record with delv returned 'RRSIG has expired'. BIND should be signing the zone(s) with dnssec-policy, yes, and the dynamically-updateable zone will be signed on update and SOA serial increased automatically. I wonder whether it's getting confused (can software get confused? I suppose so) with the two identically-named zones. If this were my installation and I had to use views, I'd try specifying distinct policies for the zones to see if that makes a difference. That thought, regarding the same zone in different views, had occurred to me. However, having to specify different policies for different views would be at best a workaround. I'd rather find out what it is that confuses BIND and file a bug for it. Looking at it from a users perspective, on a large setup with multiple zones/views (not mine) one would hardly want to setup a separate policy for every zone/view. For now, everything is looking fine again. But if it fails again, I will take another close look and hopefully something will turn up, that points me in the right direction. Should it be the views, is there a specific logging category I should increase verbosity on? [1] https://bind9.readthedocs.io/en/latest/dnssec-guide.html?highlight=delv#verification -- Sandro -- 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
Using non-standard domain names in DNS
Hello, I recently ran into "bad [owner] name" errors trying to setup a '_acme-challenge' subdomain. Yes, this is for Let's Encrypt domain validation. I wanted to use the dns-rfc2136 plugin [1], which, as the name suggests, does dynamic zone updates for the authentication challenge. Since my registrar does not support NOTIFY and Let's Encrypt queries all name servers for the domain, I would need to set the propagation time in accordance with the TTL, which my registrar uses for doing AXFRs, in order to make this work on the main domain (penguinpee.nl). On the Let's Encrypt forum it was suggested to use a dedicated zone with only a single name server, the one dns-rfc2136 is able to update dynamically. It seems [2] that would only work with '_acme-challenge' as a delegated zone, which named refuses unless I set 'check-names master ignore;'. But it seems common practice, at least in the Let's Encrypt community, to set it up this way and they are planning on making it the default behavior for DNS plugins [3]. tl;dr I was wondering what the opinion is of other DNS administrators regarding the use of none-standard domain names in DNS. After all, there's probably a reason for the default behavior of 'check-names' in BIND. -- Sandro [1] https://certbot-dns-rfc2136.readthedocs.io/en/stable/ [2] https://community.letsencrypt.org/t/domain-authentication-fails-with-dns-rfc2136-plugin/180103/8 [3] https://github.com/certbot/certbot/issues/7701 -- 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: Using non-standard domain names in DNS
On 26-06-2022 23:19, Mark Andrews wrote: The names of name servers need to follow the rules for hostnames. i.e. the labels are made up of letters, digits and hyphens (LDH). That means the name servers can’t live in the zone. There should be no A or records in the zone. Similarly there can’t be MX records as they also are restricted to LDH. Thank you for clarifying. That helped me understand where I went wrong. Let’s Encrypt isn’t asking for exceptions to the rules. Your assumptions in your question are wrong. Check-names just stops people breaking the rules accidentally. If you saw instructions to set ‘check-names no;’ please go back and correct the instructions to say to use a valid hostnames for the name servers. I didn't mean to imply that Let's Encrypt is asking for exceptions. And check-names did indeed prevent me from doing something stupid. I found my mistake after re-reading the output I got from named-checkconf and corrected it. It works now without check-names being modified. The Let's Encrypt dns-01 challenge also succeeded. -- Sandro -- 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: Unable to start Bind on a fresh RHEL 8.6 system with enforcing SELinux
On 10-06-2022 15:27, Reindl Harald wrote:
Am 10.06.22 um 15:22 schrieb Sandro:
On 10-06-2022 12:53, Reindl Harald wrote:
if it would be useful my "ExecReload=/usr/bin/kill -HUP $MAINPID"
won't work for nearly 10 years without "PIDFile" (no i won't use and
configure rndc - keep it simple)
That's a personal choice, but probably not the answer to the OPs
question. The shipped unit file for named on Fedora (and by extension
RHEL) makes use of PID files. I presume to cater for cases where rndc is
not being used.
you missed my point - this "ExecReload" proves that the PIDFile is useless
> The shipped unit file for named on
> Fedora (and by extension RHEL) makes
> use of PID files
but why in the world for a service with only a single process?
I'm not saying you are wrong. But since 'pid-file' option has a default
setting if not defined otherwise in options {}, named will try to write it.
Maybe the default should be 'none'. Or setting it to 'none' should be
advised for systemd managed systems. Until then, with SELinux in
enforcing mode, the file security context must be correct.
OP's question, as I read it, was why named chokes on not being able to
write the PID file.
-- Sandro
--
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: Unable to start Bind on a fresh RHEL 8.6 system with enforcing SELinux
On 10-06-2022 17:21, Reindl Harald wrote: My apologies if I offended you. seriously - about what magic are you talking? do you even know what a pidfile is? it's a simple textfile where the process writes it's PID and PIDFile forces systemd to read that file and use the content as "Main PID" Yes, I am aware of what a pidfile is. So, above would underline my analysis that systemd was not able to read the pidfile. Possible causes: 1. Configuration issue: named did not write the pidfile to the file indicated in the unit file by PIDFile 2. SELinux issue: named was not able to write the pidfile, because SELinux denied access. the whole point of my responses was the upstream should reconsider to use the option becasue it's proven to be useless no matter what some outdated manpage says I cannot comment on the man page being up to date. But I already agreed with your point of view, that PIDFile in case of named has become obsolete. So, I think we are on the same page here. -- Sandro -- 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: Unable to start Bind on a fresh RHEL 8.6 system with enforcing SELinux
On 10-06-2022 16:02, Reindl Harald wrote: come on! the OP clearly stated the only problem is the "PIDFile" line in the systemd-unit and so what named writes or not is completly irrelevant "PIDFile" for systemd has nothing to do with "pid-file" of named :facepalm: Indeed. I was led down the garden path. The PIDFile setting in the unit file can be totally different from the pid-file option in bind. Although, they should probably point to the same file. Yet, the man page for systemd.service (5) states: Usage of this option [PIDFile] is recommended for services where Type= is set to forking. So, it was probably just a simple misconfiguration and systemd applying some of its "magic" to a non-existent file... Anyway, in my case the PIDFile option is set, be it useful or not, and SELinux is running in enforcing mode all without any issues. -- Sandro -- 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: Unable to start Bind on a fresh RHEL 8.6 system with enforcing SELinux
On 10-06-2022 10:52, Søren Andersen wrote: I've installed a fresh BIND on a RHEL 8.6 system with enforcing SElinux, and when I try to start BIND with the provided systemd unit file it just waits and timeout, and also logs these errors in /var/log/message Jun 10 10:09:25 systemd[1]: isc-bind-named.service: Can't convert PID files /var/opt/isc/scls/isc-bind/run/named/named.pid O_PATH file descriptor to proper file descriptor: Permission denied Jun 10 10:09:25 systemd[1]: isc-bind-named.service: Can't convert PID files /var/opt/isc/scls/isc-bind/run/named/named.pid O_PATH file descriptor to proper file descriptor: Permission denied What is the SELinux context of the directory, where the PID files are stored? In your case: ls -Z /var/opt/isc/scls/isc-bind/run/named It needs to be named_var_run_t for SELinux allowing named access to that directory. You may need to set this yourself using 'chcon', since your installation is not using the default path, that an installation from the package manger would. On 10-06-2022 12:53, Reindl Harald wrote: if it would be useful my "ExecReload=/usr/bin/kill -HUP $MAINPID" won't work for nearly 10 years without "PIDFile" (no i won't use and configure rndc - keep it simple) That's a personal choice, but probably not the answer to the OPs question. The shipped unit file for named on Fedora (and by extension RHEL) makes use of PID files. I presume to cater for cases where rndc is not being used. -- Sandro -- 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: FORMERR responses after upgrading resolver from 9.16 to 9.18.8
On 21-10-2022 16:53, Ondřej Surý wrote: there are two layers- Google certainly doesn’t do anything wrong, but they would do a world a favor if there was a stronger push towards compliance with DNS protocol. That's the conundrum with big tech. If it serves them well, they will force others to follow their/the standards. Doing favors for the better good does not seem to be in their dictionary. Look at DNSSEC. Somebody needs to make the first step, so we did it. It’s documented in the troubleshooting section, it can be disabled, and if anybody feels there could be more or better documentation, we do accept external Merge Requests, and we do appreciate improvements to the documentation as well as to the code. The documentation is equally important as correct code, and we are not operator ourselves, so we might miss few things. Kudos for biting the bullet. I hope it will trickle down and get the mopping done. I'm certainly in favor of reporting over working around the issue. But I don't have customers breathing down my neck. -- Sandro -- 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: FORMERR responses after upgrading resolver from 9.16 to 9.18.8
On 23-10-2022 01:18, Crist Clark wrote: On Sat, Oct 22, 2022 at 3:20 PM Sandro wrote: [snip] Doing favors for the better good does not seem to be in their dictionary. Look at DNSSEC. Do you mean signing their domains or their public resolver services? I was referring to signing their own zones. https://developers.google.com/speed/public-dns/faq Does Google Public DNS support the DNSSEC protocol? Google Public DNS is a validating, security-aware resolver. All responses from DNSSEC signed zones are validated unless clients explicitly set the CD flag in DNS requests to disable the validation. https://developers.cloudflare.com/1.1.1.1/faq/#how-does--work-with-dnssec How does 1.1.1.1 work with DNSSEC? 1.1.1.1 is a DNSSEC validating resolver. 1.1.1.1 sends the DO (DNSSEC OK) bit on every query to convey to the authoritative server that it wishes to receive signed answers if available. 1.1.1.1 supports the signature algorithms specified in Supported DNSKEY signature algorithms <https://developers.cloudflare.com/1.1.1.1/encryption/dnskey/>. -- 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: Sparklight and DNSSEC
On 23-09-2022 18:54, Philip Prindeville wrote: Anyway, I suggested that they standup a second pair of DNS servers, this time with DNSSEC enabled, and let their customers decide if streaming is more important than security. Waiting to hear back... How many ISP's squelch DNSSEC like that? I hope it's not a common practice! Mine doesn't. I agree with you that there are better solutions to the problem(s) described than turning of DNSSEC completely. Nevertheless, I run my own recursive DNS server using OpenNIC's root server, thus bypassing my ISP completely. -- Sandro -- 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: Seeing lots of DNS issues on OpenWRT
On 23-09-2022 21:59, Ed Daniel wrote: As per your previous email 17:54 where you share Sparklight response, Quad9 uses strict DNS checking iirc, you should add another couple of cloud DNS resolvers like 1.1.1.1 and 8.8.8.8 that fall back to resolve when DNSSEC is broken at destination. As I hinted in response to the mail you sent earlier, you could set this up to do your own recursive queries from the root servers going up the chain of trust. Domains that have DNSSEC disabled will just work. Only broken DNSSEC enabled domains will not be answered. I use Unbound for that purpose, but it can be done using BIND as well. -- Sandro -- 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: Sparklight and DNSSEC
On 24-09-2022 11:20, Bjørn Mork wrote: Philip Prindeville writes: How many ISP's squelch DNSSEC like that? I hope it's not a common practice! More common than you'd like to think. See Geoff's excellent world map at https://stats.labs.apnic.net/dnssec Thank you for sharing this. Is there any documentation on how this data is gathered? I looked up my own ISP, which does full validation. However, in the NL data set it shows as doing neither full nor partial. Out of 41 samples (it's a very small and relatively new ISP), the score for both is zero. Also, going from world map down to the country (NL), using the intermediate steps provided, the figures for NL change: World (XA): 61.35% Europe (XE): 56.99% Western Europe (QO): 56.99% -- Sandro -- 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: new dnssec zone OK, error "zone_rekey:dns_zone_getdnsseckeys failed: not found" only in local bind logs ?
On 14-10-2022 15:26, PGNet Dev wrote:
zone "example.com" IN {
type master; file "/namedb/master/example.com.zone";
dnssec-policy "pgnd";
key-directory "/keys/dnssec/example.com";
update-policy { grant pgnd-external-rndc-key zonesub txt; };
};
what's the source of the "zone_rekey:dns_zone_getdnsseckeys"?
specifically, what's not being found?
have i missed/miconfig'd config, omitted a file/dir that current config
expects, or is this a bug?
Did you check that BIND has access to key-directory?
In the example.com domain above you are using an absolute path. BIND
needs to be able to read and write in '/keys/dnssec/example.com'.
Normally this is a relative path. Relative to 'directory' option.
Think ownership, permission and things like SELinux, AppArmore depending
on your OS.
-- Sandro
--
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
Domain no longer fully secure after move
Hi, I'm trying to understand what exactly is wrong with DNSSEC for my domain, penguinpee.nl, before contacting involved parties. I recently (last weekend) moved the domain to a new registrar. The keys are now managed by the registrar directly. At least I don't see an option providing my own or additional keys in their web interface. Moreover, I'm no longer running my own DNS server. :( Previously, I could set my own BIND server as a primary server for my domain and have the registrar use AXFR to update the secondaries. The DNSViz analysis for the current situation: https://dnsviz.net/d/penguinpee.nl/Y5oJSw/dnssec/ And from before the move: https://dnsviz.net/d/penguinpee.nl/Yq3P8w/dnssec/ Verisign has one single complaint: No DS records found for penguinpee.nl in the nl zone. IIUC, the details for the DS record have to be provided by my new registrar, so SIDN can add them. -- Sandro -- 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: Domain no longer fully secure after move
On 16-12-2022 10:26, Ondřej Surý wrote: some registrars or registries strip the DS record when you move between registrars. I don't know if this is the case with .nl, but I just know that it might happen. It sure was stripped. Before I provided the details for the DS entry myself, since I also signed the zone myself. I would have expected the new registrar to take care of the DS record, since they are now the party signing the zone. -- Sandro -- 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: Domain no longer fully secure after move
On 14-12-2022 19:13, Sandro wrote: I recently (last weekend) moved the domain to a new registrar. The keys are now managed by the registrar directly. At least I don't see an option providing my own or additional keys in their web interface. Moreover, I'm no longer running my own DNS server. Previously, I could set my own BIND server as a primary server for my domain and have the registrar use AXFR to update the secondaries. The DNSViz analysis for the current situation: https://dnsviz.net/d/penguinpee.nl/Y5oJSw/dnssec/ And from before the move: https://dnsviz.net/d/penguinpee.nl/Yq3P8w/dnssec/ Verisign has one single complaint: No DS records found for penguinpee.nl in the nl zone. Answering my own mail, by way of slapping my palm on my forehead. The missing DS record in the .nl domain is all that's wrong. That breaks the chain of validation, therefore showing all penguinpee.nl entries as insecure. I got confused earlier, since the RRs in penguinpee.nl are actually signed. But it's the validation that breaks due to the missing DS record. End of year fatigue... -- Sandro -- 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: dyndb ldap being raped by redhat
On 08-04-2024 15:30, Marc wrote: I am quite a bit annoyed with how redhat has completely failed to put proper engineers on this dyndb-ldap. https://issues.redhat.com/ or https://bugzilla.redhat.com/ is where you need to complain. Does anyone know of a fork of dyndb before Redhat started messing it up for their freeipa shit? I just need a version that was working like on el6/el7(?) which is working on el9. You can download the SRPM (e.g. [1] or using yumdownloader from yum-utils) and rebuild it for EL9, e.g. in Copr[2] or locally. Though, EL6 is already EOL en EL7 will be in a few months. So the version shipped is probably rather ancient and your mileage may vary. [1] https://downloads.redhat.com/redhat/linux/enterprise/7Server/en/os/SRPMS/ [2] https://copr.fedorainfracloud.org/ -- Sandro -- 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
