I recently moved our hidden DNS master service to a new host, DNS38. The original master service is still running but is not being polled at the present time.

The old master, and all the authoritative slaves, are running bind-9.11. The new master host is running bind-9.16.

DNSSEC is enabled for the domain I am dealing with. We use dnssec-validation auto; and auto-dnssec maintain; inline-signing yes; for the zone.

My question relates to loading changes made to the master zone file not being visible to the slave servers.

Using rndc I see this:

rndc zonestatus harte-lyne.ca
name: harte-lyne.ca
type: primary
files: /usr/local/etc/namedb/signtest/harte-lyne.ca.hosts
serial: 2022012604
signed serial: 2022012199
nodes: 1320
last loaded: Tue, 25 Jan 2022 17:38:23 GMT
secure: yes
inline signing: yes
key maintenance: automatic
next key event: Thu, 27 Jan 2022 17:00:50 GMT
next resign node: _22._tcp.inet05.hamilton.harte-lyne.ca/NSEC
next resign time: Thu, 27 Jan 2022 19:51:36 GMT
dynamic: no
reconfigurable via modzone: no

The thing that interests me here is that while the serial of the zone file is 2022012604 the serial of the signed zone file is 2022012199, which is less than the first serial. I believe the signed zones maintain a separate serial sequence but I have been unable to find documentation to confirm or refute this.

In any case, I have made changes to the zone file on the master and reloaded them using rndc reload harte-lyne.ca. This change was duly queued and the serial number of the updated zone file shows in the zonestatus report. However, the changes to the zone do not appear when queried.

# find a changed RR
grep dns01.internal /usr/local/etc/namedb/signtest/harte-lyne.ca.hosts
dns01.internal.harte-lyne.ca.           CNAME dns33.internal.harte-lyne.ca.

# check the validity of the zone file
named-checkzone -i local harte-lyne.ca /usr/local/etc/namedb/signtest/harte-lyne.ca.hosts #  zone configuration test ignore samba errors
zone harte-lyne.ca/IN: loaded serial 2022012701
OK

# reload the zone
rndc reload harte-lyne.ca.
zone reload queued

# check the serial number 
rndc zonestatus harte-lyne.ca.
name: harte-lyne.ca.
type: primary
files: /usr/local/etc/namedb/signed/harte-lyne.ca.hosts
serial: 2022012701
signed serial: 2022012199
nodes: 1311
last loaded: Tue, 25 Jan 2022 17:38:23 GMT
secure: yes
inline signing: yes
key maintenance: automatic
next key event: Thu, 27 Jan 2022 17:00:50 GMT
next resign node: _22._tcp.inet05.hamilton.harte-lyne.ca/NSEC
next resign time: Thu, 27 Jan 2022 19:51:36 GMT
dynamic: no
reconfigurable via modzone: no

Here I have reloaded the zone with a new serial number (2022012701) containing a valid CNAME RR for dns01.internal.harte-lyne.ca. However, if I then dig/drill the master service I do not get a response:

drill @dns38.harte-lyne.ca dns01.internal.harte-lyne.ca
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 54421
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 
;; QUESTION SECTION:
;; dns01.internal.harte-lyne.ca.    IN  A

;; ANSWER SECTION:

;; AUTHORITY SECTION:
harte-lyne.ca.  7200    IN  SOA harte-lyne.ca. nameservice.harte-lyne.ca. 2022012199 10800 3600 1209600 7200

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 216.185.71.38
;; WHEN: Thu Jan 27 11:51:57 2022
;; MSG SIZE  rcvd: 107

The SOA record returned has the serial number 2022012199, which matches the one provided by zonestatus after the reload of the domain. But there is no answer to the query.

I have noted no other anomalies relating to this change. The slaves are transferring from the master without error. But the master does not seem to want to acknowledge that a change has actually occurred.

It seems to me that this has something to do with signing the new RR. It has been more than five years since I set this up and I have no notes covering this particular situation. Moreover,I cannot recall encountering this before. What step am I missing?

• OS FreeBSD-12.1
• CUPS-2.3.3

My goal is to get CUPS to listen for TCP/IP connections on 9100, or any arbitrary ip address and tcp port for that matter, passing the incoming RAW spool file to the cups-pdf filter. After which a cron job or listener process transfers the resulting files to a WebDAV resource for access.

I would like to accomplish the pdf conversion task entirely within CUPS. I have looked at netcat and socat and these may be where I end up. But if it is at all possible to accomplish this with CUPS then I would like to know exactly how one configures a CUPS service to listen on a specific IP address and port; and to route what arrives on that TCP socket to a specific printer.

Is this possible? If so, how is it done?

I have this command:

find /var/cache/pkg  -newermt 2020-01-30 | grep 'kdeaccessibility-4.14.3_1'

Which returns nothing. I change it to this:

find /var/cache/pkg  -newermt 2020-01-30 -exec ls -D '%F' -l -t -r {} \; | grep 'kdeaccessibility-4.14.3_1'

and this is returned:

-rw-r--r--  1 root  wheel        556 2017-07-14 kdeaccessibility-4.14.3_1-6dc124e39c.txz
lrwxr-xr-x  1 root  wheel         40 2017-07-21 kdeaccessibility-4.14.3_1.txz -> kdeaccessibility-4.14.3_1-6dc124e39c.txz

So, the -newermt option seems to be disabled by the -exec option. But I do not understand why.

However, if I add the -type f option then the find works as expected.

find /var/cache/pkg  -type f -newermt 2020-01-30 -exec ls -D '%F' -l -t -r {} \; | grep 'kdeaccessibility-4.14.3_1'

Nothing is returned. I infer from this that presence of a symbolic link is causing the behaviour but I do not understand why.

I need to replace the HDD on a single disk system used as a pbx (CentOS-6 based FreePBX). The existing partition structure is:

ls -l /dev/sd*
brw-rw---- 1 root disk 8, 0 Apr 17  2018 /dev/sda
brw-rw---- 1 root disk 8, 1 Apr 17  2018 /dev/sda1
brw-rw---- 1 root disk 8, 2 May 25 14:12 /dev/sda2

parted /dev/sda print
Model: ATA ST3500418AS (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End    Size   Type     File system  Flags
 1      1049kB  525MB  524MB  primary  ext4         boot
 2      525MB   500GB  500GB  primary               lvm

parted /dev/sda1 print
Model: Unknown (unknown)
Disk /dev/sda1: 524MB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End    Size   File system  Flags
 1      0.00B  524MB  524MB  ext4

parted /dev/sda2 print
Error: /dev/sda2: unrecognised disk label 

I need to transfer the entire system to a new HDD. Ideally I would like to transfer the entire thing (boot-loader, OS, and filesystems) over the network to a larger disk temporarily installed on a separate host, that is not necessarily running CentOS, and then swap the drives. Is this possible?

I am guessing that with lvm in the mix this is a non-starter. But in case it is not then this scenario is the ideal.

Is this possible and how is it best accomplished?

Further information:

df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/vg_voinet01-lv_root
                      64376668   5057112  56042756   9% /
tmpfs                  1952596         0   1952596   0% /dev/shm
/dev/sda1               487652     55768    406284  13% /boot
/dev/mapper/vg_voinet01-lv_home
                       3159816    246372   2749604   9% /home
/dev/mapper/vg_voinet01-LogVol04
                     322407500 134244852 171778648  44% /var
/dev/mapper/vg_voinet01-lv_log
                       9545056    390052   8663484   5% /var/log
/dev/mapper/vg_voinet01-lv_spool
                      65924860  32354984  30214852  52% /var/spool

vgs;lvs
  VG          #PV #LV #SN Attr   VSize   VFree
  vg_voinet01   1   6   0 wz--n- 465.27g 9.91g
  LV       VG          Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  LogVol04 vg_voinet01 -wi-ao---- 312.50g                                                    
  lv_home  vg_voinet01 -wi-ao----   3.12g                                                    
  lv_log   vg_voinet01 -wi-ao----   9.38g                                                    
  lv_root  vg_voinet01 -wi-ao----  62.50g                                                    
  lv_spool vg_voinet01 -wi-ao----  64.00g                                                    
  lv_swap  vg_voinet01 -wi-ao----   3.86g 

This is a fresh install of Debian-10.4. The sources.list file follows:

# deb cdrom:[Debian GNU/Linux 10.4.0 Buster - Official amd64 DVD Binary-1 20200 0509-10:26]/ buster contrib main

deb http://security.debian.org/debian-security buster/updates main contrib
deb-src http://security.debian.org/debian-security buster/updates main contrib

# buster-updates, previously known as 'volatile'
# A network mirror was not selected during install.  The following entries
# are provided as examples, but you should amend them as appropriate
# for your mirror of choice.
#
deb http://deb.debian.org/debian/ buster-updates main contrib
deb-src http://deb.debian.org/debian/ buster-updates main contrib

When I try to install sshd (openssh-serverr) I get this:

[root@smb4-a ~]# apt install -f openssh-server
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 openssh-server : Depends: openssh-client (= 1:7.9p1-10+deb10u1) but 1:7.9p1-10+deb10u2 is to be installed
                  Depends: openssh-sftp-server but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

I am not even going to try to imagine what sort of distribution does not supply a secure remote access as part of the base install. Whatever the reasoning that appears to be the case with Debian and I need such. The problem appears to be this:

 openssh-server : Depends: openssh-client (= 1:7.9p1-10+deb10u1) but 1:7.9p1-10+deb10u2 is to be installed

How is a broken dependency forced to install?

Further info:

[root@smb4-a ~]# apt-get update
Get:1 http://deb.debian.org/debian buster-updates InRelease [49.3 kB]
Hit:2 http://security.debian.org/debian-security buster/updates InRelease
Get:3 http://deb.debian.org/debian buster-updates/main Sources [3,088 B]
Get:4 http://deb.debian.org/debian buster-updates/main amd64 Packages [7,380 B]
Get:5 http://deb.debian.org/debian buster-updates/main Translation-en [5,166 B]
Fetched 64.9 kB in 0s (358 kB/s)           
Reading package lists... Done
[root@smb4-a ~]# apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Further information:

# apt policy openssh-*
openssh-sftp-server:
  Installed: (none)
  Candidate: 1:7.9p1-10+deb10u1
  Version table:
     1:7.9p1-10+deb10u1 500
        500 http://security.debian.org/debian-security buster/updates/main amd64 Packages
openssh-tests:
  Installed: (none)
  Candidate: 1:7.9p1-10+deb10u1
  Version table:
     1:7.9p1-10+deb10u1 500
        500 http://security.debian.org/debian-security buster/updates/main amd64 Packages
openssh-server:
  Installed: (none)
  Candidate: 1:7.9p1-10+deb10u1
  Version table:
     1:7.9p1-10+deb10u1 500
        500 http://security.debian.org/debian-security buster/updates/main amd64 Packages
openssh-client:
  Installed: 1:7.9p1-10+deb10u2
  Candidate: 1:7.9p1-10+deb10u2
  Version table:
 *** 1:7.9p1-10+deb10u2 100
        100 /var/lib/dpkg/status
     1:7.9p1-10+deb10u1 500
        500 http://security.debian.org/debian-security buster/updates/main amd64 Packages

A server restart produced this output on the console:

ZFS: i/o error - all block copies unavailable
ZFS: failed to read pool zroot directory object
qptzfsboot: failed to mount default pool zroot

FreeBSD/x86 boot
ZFS: i/o error - all block copies unavailable
ZFS: can't fild dataset 0
Default: zroot/<0x0>
boot:

I booted the host from the usb livecd and mounted the /etc directory under /tmp to enable ssh access:

ifconf -a # get available i/f names
ifconf em0 inet 192.168.216.46
route add default 192.168.216.1
hostname vhost06.internal
mkdir /tmp/etc
mount_unionfs /tmp/etc /etc
echo 'PermitRootLogin yes' >> /etc/sshd_config
passwd
Changing local password for root
New Password:
Retype New Password:
service sshd onestart

There are no zfs pools available to import:

root@vhost06:~ # zpool status
no pools available
root@vhost06:~ # zpool list
no pools available
root@vhost06:~ # zfs list
no datasets available

gpart shows this geometry:

gpart show

=>         40  15628053088  ada0  GPT  (7.3T)
           40         1024     1  freebsd-boot  (512K)
         1064          984        - free -  (492K)
         2048     16777216     2  freebsd-swap  (8.0G)
     16779264  15611273216     3  freebsd-zfs  (7.3T)
  15628052480          648        - free -  (324K)

=>         40  15628053088  ada1  GPT  (7.3T)
           40         1024     1  freebsd-boot  (512K)
         1064          984        - free -  (492K)
         2048     16777216     2  freebsd-swap  (8.0G)
     16779264  15611273216     3  freebsd-zfs  (7.3T)
  15628052480          648        - free -  (324K)

=>         40  15628053088  ada2  GPT  (7.3T)
           40         1024     1  freebsd-boot  (512K)
         1064          984        - free -  (492K)
         2048     16777216     2  freebsd-swap  (8.0G)
     16779264  15611273216     3  freebsd-zfs  (7.3T)
  15628052480          648        - free -  (324K)

=>         40  15628053088  ada3  GPT  (7.3T)
           40         1024     1  freebsd-boot  (512K)
         1064          984        - free -  (492K)
         2048     16777216     2  freebsd-swap  (8.0G)
     16779264  15611273216     3  freebsd-zfs  (7.3T)
  15628052480          648        - free -  (324K)

=>         40  15628053088  diskid/DISK-VAGWJ6VL  GPT  (7.3T)
           40         1024                     1  freebsd-boot  (512K)
         1064          984                        - free -  (492K)
         2048     16777216                     2  freebsd-swap  (8.0G)
     16779264  15611273216                     3  freebsd-zfs  (7.3T)
  15628052480          648                        - free -  (324K)

=>         40  15628053088  diskid/DISK-VAGWV89L  GPT  (7.3T)
           40         1024                     1  freebsd-boot  (512K)
         1064          984                        - free -  (492K)
         2048     16777216                     2  freebsd-swap  (8.0G)
     16779264  15611273216                     3  freebsd-zfs  (7.3T)
  15628052480          648                        - free -  (324K)

=>         40  15628053088  diskid/DISK-VAHZAD2L  GPT  (7.3T)
           40         1024                     1  freebsd-boot  (512K)
         1064          984                        - free -  (492K)
         2048     16777216                     2  freebsd-swap  (8.0G)
     16779264  15611273216                     3  freebsd-zfs  (7.3T)
  15628052480          648                        - free -  (324K)

=>         40  15628053088  diskid/DISK-VAH3PXYL  GPT  (7.3T)
           40         1024                     1  freebsd-boot  (512K)
         1064          984                        - free -  (492K)
         2048     16777216                     2  freebsd-swap  (8.0G)
     16779264  15611273216                     3  freebsd-zfs  (7.3T)
  15628052480          648                        - free -  (324K)

=>       1  30240767  da0  MBR  (14G)
         1      1600    1  efi  (800K)
      1601   2012560    2  freebsd  [active]  (983M)
   2014161  28226607       - free -  (13G)

=>      0  2012560  da0s2  BSD  (983M)
        0       16         - free -  (8.0K)
       16  2012544      1  freebsd-ufs  (983M)

=>       1  30240767  diskid/DISK-00241D8CE51BB011B9A694C1  MBR  (14G)
         1      1600                                     1  efi  (800K)
      1601   2012560                                     2  freebsd  [active]  (983M)
   2014161  28226607                                        - free -  (13G)

=>      0  2012560  diskid/DISK-00241D8CE51BB011B9A694C1s2  BSD  (983M)
        0       16                                          - free -  (8.0K)
       16  2012544                                       1  freebsd-ufs  (983M)

How do I recover from here?

<------ end of original question

I have made some progress and managed to import and mount one root dataset - iocage. This is a boot on zfs system but I cannot find the dataset that contains the root filesystem so I cannot get at /var/log to see if anything is there:

mkdir /tmp/zroot                       # /tmp is a writable file system
zpool -f zroot                         # force the zpool import
zfs set mountpoint=/tmp/zroot  zroot   # mount the imported pool in a writable fs
zfs mount -a                           # find and mount all the datasets
ll /tmp/zroot
total 12
drwxr-xr-x  9 root  wheel  11 Feb 27 13:09 iocage/

Fortunately, all of the absolutely critical stuff is in /zroot/iocage as the host simply acts as a platform for the jail. However the absence of the root dataset is bothersome to me.

A zpool status showed zroot with no errors.

I next transferred the iocage dataset to another system using zfs send.

zfs snapshot -r zroot/iocage@vh6iocsend1
zfs send -R zroot/iocage@vh6iocsend1 | ssh 192.168.216.45 zfs receive zroot/iocagev6

This took a while but it has completed successfully.

Now I need to get the problem host started. This host was restarted yesterday at noon without a problem. I do not recall running freebsd-update fetch, but even if I had there was nothing for fetch to deliver as the system was already at 12.1p2

I still need help getting the host to boot.

<----------

Additional notes:

I was able to mount the entire zpool using the altroot option of zpool import:

1. Boot into the live cd shell.
2. Import the zfs pool(s) but do not allow import to auto mount any datasets: zpool import -o altroot=/tmp/altroot -N -a.
3. Mount the root / dataset first: zfs mount zroot/ROOT/default.
4. Now mount the remaining datasets: zfs mount -a.

The entire zroot pool's file system is now accessible at /tmp/altroot.

I have used this with zfs send to move the contents of /var to another host. Actually, I sent the entire pool.

However, the original system still will not boot.

Source iocage thick jail running on FreeBSD-12.0p12 Destination FreeBSD-12.1p1

Both hosts are using zfs.

What is the recommended method to transfer an existing iocage thick jail from the source to the destination? Is it as simple as:

rsync -aqz -e "ssh -o LogLevel=error"  /zroot/iocage/jails/testjail \
                           destination:/zroot/iocage/jails

Presuming that iocage is installed on both hosts, that the zfs mount points are as indicated above, that the source jail is shutdown, and that testjail does not exist on the destination host.

We are trying to get a dragonfly mta (dma) client to use STARTTLS with our mailhub. We created a self-signed certificate and key using openssl

openssl req -new -newkey rsa:4096 -x509 -sha256 -set_serial 201912200501 -days 3650 -nodes -out x.crt -keyout x.key

and concatenated these into a pem file:

cat x.crt x.key > /usr/local/etc/pki/tls/private/x.pem ; chmod 600 /usr/local/etc/pki/tls/private/x.pem

In /etc/dma.conf we have this:

SECURETRANSFER
STARTTLS
CERTFILE = /usr/local/etc/pki/tls/private/x.pem

When we try to send to the mail hub dma reports this in /var/log/maillog:

Dec 20 16:15:54 gway05 dma[2813d.8018280f0]: trying remote delivery to smtp.hamilton.harte-lyne.ca [216.185.71.31] pref 0
Dec 20 16:15:54 gway05 dma[2813d.8018280f0]: SSL: Cannot load certificate `= /usr/local/etc/pki/tls/private/x.pem': error:140DC002:SSL routines:SSL_CTX_use_certificate_chain_file:system lib
Dec 20 16:15:54 gway05 dma[2813d.8018280f0]: remote delivery deferred

What are we doing wrong?

What is the reason that copying .bash_profile from the host system into the /root directory of an iocage thin jail does not create a file that is visible to the root user when logged on to that jail?

In other words, if I do this from the host system:

cp -p .bash_profile /zroot/iocage/jails/testjail/root/

Then ls -al /zroot/iocage/jails/testjail/root/.bash_profile shows that the file exists.

ls -al /zroot/iocage/jails/testjail/root/.bash_profile
-rwxr-xr-x  1 root  wheel  3274 Dec 12 15:42 /zroot/iocage/jails/testjail/root/.bash_profile

However, when I log on to testjail the file is not visible to the root user:

iocage console testjail
ls -a .bash_profile
ls: .bash_profile: No such file or directory

If I check the mounts on the host system then amoung other things I see this:

zroot/iocage/jails/testjail/root on /zroot/iocage/jails/testjail/root (zfs, local, noatime, nfsv4acls)

Which I believe is the source of my difficulty. How do I put a file into the /root directory of an iocage jail so that it is usable by the root user inside the jail?

CentOS-6.10

I have never run into this before:

sudo crontab -l -u thatuser
[sudo] password for thisuser: 

Authentication service cannot retrieve authentication info
You (thatuser) are not allowed to access to (crontab) because of pam configuration.

Why can I not list (or edit) another users crontab as root?

I wish to mount a remote data source locally as a fuse file system. This is listed as supported by lsvfs:

lsvfs
Filesystem                              Num  Refs  Flags
-------------------------------- ---------- -----  ---------------
devfs                            0x00000071     4  synthetic, jail
cd9660                           0x000000bd     0  read-only
procfs                           0x00000002     4  synthetic, jail
nfs                              0x0000003a     0  network
zfs                              0x000000de    17  jail, delegated-administration
msdosfs                          0x00000032     0  
ufs                              0x00000035     0  
fdescfs                          0x00000059     4  synthetic, jail
fusefs                           0x000000ed     0  synthetic, jail
nullfs                           0x00000029     3  loopback, jail
tmpfs                            0x00000087     0  jail

I have installed fusefs-sshfs in the jail. I have also created the mount point directory.

In the host's/etc/sysctl.conf I have security.jail.enforce_statfs=1; and in /etc/rc.conf I have kld_list="fuse" (which I believe is redundant but is there nonetheless).

In the (ez)jail configuration I allow allow.mount, allow.mount.nullfs, and allow.mount.fusefs.

Inside the jail I can establish an sftp link to the remote data source and change directory to OUT:

sftp -o IdentityFile=/var/data/theheart/.ssh/xxx_rsa_id     [email protected]
Connected to [email protected].
sftp> dir
OUT  bin  dev  etc  lib  usr

But I cannot mount that data source as a fuse ssh file system:

/usr/local/bin/sshfs -C -o uid=16701 -o gid=16701     -o reconnect -o IdentityFile=/var/data/theheart/.ssh/xxx_rsa_id        [email protected]:OUT /var/spool/xxx/pick_up
mount_fusefs: /dev/fuse on /var/spool/xxx/pick_up: Operation not permitted
fuse: failed to mount file system: No error: 0

Is this possible? The Jail(8) manpage implies that it is given the presence of the allow.mount.fusefs setting. If so then what step(s) am I missing?

FreeBSD-12
BIND-9.11

After some effort I have changed the error. Now I see this:

07-Jun-2019 18:01:25.299 zone parschecks/IN/public (unsigned): loaded serial 2019070701 (DNSSEC signed)
07-Jun-2019 18:01:25.299 dns_master_load: file format mismatch (not raw)
07-Jun-2019 18:01:25.299 zone parschecks.ca/IN/public (signed): loading from master file /usr/local/etc/namedb/master/parschecks.ca.hosts.signed failed: not implemented
07-Jun-2019 18:01:25.299 zone parschecks/IN/public (signed): not loaded due to errors.

Original question:

I have this domain which reports that its key has expired when I reload named:

Jun  7 15:32:24 dns38 named[19583]: /usr/local/etc/namedb/master/parschecks.ca.hosts:53: signature has expired
Jun  7 15:32:25 dns38 named[19583]: zone parschecks.ca/IN/public (signed): receive_secure_serial: unchanged

However I have manually signed this domain:

2019-06-07 15:26:34: dnssec-keygen -f KSK -a ECDSAP256SHA256 -n ZONE parschecks.ca
2019-06-07 15:26:50: dnssec-keygen -a ECDSAP256SHA256 -n ZONE parschecks.ca
2019-06-07 15:27:05: dnssec-signzone -N increment -S -o parschecks.ca parschecks.ca.hosts Kparschecks.ca.+013+37572

And the hosts files seem to have been updated:

-rw-r--r--  1 bind  bind     609 Mar 12 12:59 Kparschecks.ca.+008+29077.key
-rw-------  1 bind  bind    1776 Mar 12 12:59 Kparschecks.ca.+008+29077.private
-rw-r--r--  1 bind  bind     479 Mar 12 12:59 Kparschecks.ca.+008+32223.key
-rw-------  1 bind  bind    1200 Mar 12 12:59 Kparschecks.ca.+008+32223.private
-rw-r--r--  1 bind  bind     479 Feb 19 21:17 Kparschecks.ca.+008+43116.key
-rw-------  1 bind  bind    1200 Feb 19 21:17 Kparschecks.ca.+008+43116.private
-rw-r--r--  1 bind  bind     346 Jun  7 15:24 Kparschecks.ca.+013+35858.key
-rw-------  1 bind  bind     187 Jun  7 15:24 Kparschecks.ca.+013+35858.private
-rw-r--r--  1 bind  bind     346 Jun  7 15:26 Kparschecks.ca.+013+37572.key
-rw-------  1 bind  bind     187 Jun  7 15:26 Kparschecks.ca.+013+37572.private
-rw-r--r--  1 bind  bind     345 Jun  7 15:26 Kparschecks.ca.+013+50724.key
-rw-------  1 bind  bind     187 Jun  7 15:26 Kparschecks.ca.+013+50724.private
-rw-r--r--  1 bind  bind     344 Jun  7 15:27 dsset-parschecks.ca.
-rw-r--r--  1 bind  bind    9515 Apr 18 12:03 parschecks.ca.hosts
-rw-r--r--  1 bind  bind     512 Mar 22 17:28 parschecks.ca.hosts.jbk
-rw-r--r--  1 bind  bind    2395 Apr 18 12:28 parschecks.ca.hosts.jnl
-rw-r--r--  1 bind  bind   15960 Jun  7 15:32 parschecks.ca.hosts.signed
-rw-r--r--  1 bind  bind  128161 Jun  7 15:43 parschecks.ca.hosts.signed.jnl

named.conf contains this:

zone "parschecks.ca" {
type master;
file "/usr/local/etc/namedb/master/parschecks.ca.hosts";
key-directory "/usr/local/etc/namedb/master/";
auto-dnssec maintain;
inline-signing yes;
};

We are in the process of moving to inline signing but we have not managed to get it working as yet. If we remove the auto maintain clauses from the zone entry in named.conf the zone file is still reported as being expired.

rndc -s 127.0.0.1 reload parschecks.ca
zone reload up-to-date

Nothing has been changed in the hosts file. But it will not load after resigning. What step am I missing?

We have a stealth master which has several zone secured with DNSSEC. We recently upgraded to 9.11 and enabled auto-maintain and inline-update for DNSSEC. The initial zone resign and load went smoothly. However, when I now update the master zone records and serial number the changed zone is not transferred to the authoritative slaves. In fact I cannot find any evidence that the changes in the master zone file have had any effect whatsoever.

drill drill harte-lyne.ca gives this:

;; ANSWER SECTION:
harte-lyne.ca.  172800  IN  SOA dns01.harte-lyne.ca. nameservice.harte-lyne.ca. 2019040501 10800 3600 1209600 7200

but the serial number in the master file is this: 2019041603

rndc reload harte-lyne.ca produces this:
zone reload up-to-date

rndc freeze and thaw do not work as the zone is defined in named.conf as a master and not as a dynamic zone.

What is the technique used to cause bind to resign and reload a modified master zone file immediately following a manual update?

If I run rndc zonestatus then I get this:

# rndc zonestatus harte-lyne.ca
name: harte-lyne.ca
type: master
files: /usr/local/etc/namedb/master/harte-lyne.ca.hosts
serial: 2019041603
signed serial: 2019041617
nodes: 1198
last loaded: Tue, 16 Apr 2019 19:50:26 GMT
secure: yes
inline signing: yes
key maintenance: automatic
next key event: Wed, 17 Apr 2019 13:51:16 GMT
next resign node: _22._tcp.inet17.mississauga.harte-lyne.ca/NSEC
next resign time: Wed, 17 Apr 2019 13:46:37 GMT
dynamic: no
reconfigurable via modzone: no

This tells me that the zone is being updated and resigned on a schedule. But how do I force an immediate update and notify following a manual change to the master zone file?

The significance of the next resign node also escapes me. I have not been able to locate an explanation of this in the available documentation, including the 9.11 admin guide.

I am trying to understand how Bind manages DNSSEC zone key signatures without external intervention. Specifically what process (named?) detects that a zone signature is about to expire and what are the methods of detection and resigning.

Does named itself regularly poll all the zone keys and then spawns an update process? Are there settings beyond those listed below required to get auto-maintain to work? Does the update have to triggered by rndc or reloading named?

. . .
options {
  . . .
  dnssec-enable yes;
  key-directory "/usr/local/etc/namedb/master/";
  dnssec-validation auto;
. . .
}
. . .
zone example.com {
  type master;
  file "/usr/local/etc/namedb/master/example.com.hosts";
  key-directory "/usr/local/etc/namedb/master/";
  auto-dnssec maintain;
  inline-signing yes;
};

We use FreeBSD-12 and Bind-9.11.6. We have DNSSEC enabled for some of our domains. I wish to verify the signature expiry date for these zones. I cannot seem to locate any information on exactly how this is done. Can someone provide me with this information?

We have a server whose original PKI certificate was issued by a discontinued root CA. We have a replacement certificate issued from a different root authority chain. This site was set up some time ago with Strict-Transport-Security established.

The server key is 4096 bits. The old CA root private key is 1024 bits (it was issued in 2006).

How does one switch PKI keys and certificates for Strict-Transport-Security enabled sites? I have searched for information on this but have so far come up empty.

We have a usb memory stick that FreeBSD-11 will not mount because its file system is not clean. It is not clean because it was removed from an extension cable while it was mounted on a FreeBSD-11 system. However, there was no file activity that we are aware of at the time it was removed.

We cannot get fsck or fsck_ffs to find a superblock so these will not run. Even when we provide fsck_ffs -b with a superblock address found using newfs -N it does not consider the block location as a superblock.

How do we clear the dirty bit so that we can mount the device?

We run a private CA and employ both DNSSEC and DANE. Recently we decided to reissue our CA root and issuer keys as these were generated at 1024 bits when our PKI was set up in 2008. Our original TLSA RR pointed to the issuing CA as the trust anchor. However re-reading the RFCs and various DANE related commentary raises the question of whether the ROOT public key should be used instead.

We are presently trialling this idea parallel to our existing DANE records. When we use https://dane.sys4.de/smtp/ to validate then our existing server key checks out, but the new ROOT TLSA record is also reported even though we have not switched the server key over to the new certificate chain. Further, the new trust anchor TLSA RR is reported thus:

Usable TLSA Records

2, 1, 2 c26e0ec16a46a973[...]ce60eabc5adba90e - self signed certificate in certificate chain: (19)

Whereas the current TLSA RR for the same host is reported this way:

2, 0, 2 67274b3554289058[...]5fd3917510e6722a

The first record reported refers to the new Root CA. The second refers to the original Issuing CA (signed by the original Root CA).

When I check for the message self signed certificate in certificate chain: (19) the impression I form is that this is an error. However, if it is an error then exactly where does the CA Root public key fit into the DANE scheme?

I have the following set-up involving two KVM hosts and numerous virtual machine guests on each. The guests communicate to each other on both hosts via [192.168.216.0/24]. [192.168.216.42] is connected to [192.168.216.41] via a cross-over cable. Traffic between [192.168.216.0/24] addresses should not escape out onto the LAN. However, I want to ping [x.y.A.2] from [192.168.216.25].:

   ISP ethx[x.y.A.2/30] >-----< eth0[x.y.A.3/30]              |
              ISP                      GWAY                   |
                                eth1[x.y.z.1/24] >----------< |
                                       GWAY                   |
                                                              |
         br0[x.y.z.42/24] >---------------------------------< |
               KVM2                                           |
                                     br0[x.y.z.41/24] >-----< |
                                             KVM1             ~
      br1[192.168.216.42] >-----X-----< br1[192.168.216.41]
          |    KVM2                          KVM1        |
          |                                              |
          | >-----< eth1[192.168.216.21]                 |
          | >-----< eth1[192.168.216.25]                 |
                                                         |
                           eth1[192.168.216.221] >-----< |
                           eth1[192.168.216.223] >-----< |

IPTABLES on GWAY is set-up to masquerade outgoing 198.168.0.0/16.

I believe I will need to add a virtual i/f eth1[192.168.0.1/16] to GWAY:

ifcfg-eth1:192168
BOOTPROTO=none
BROADCAST=192.168.255.255
DEVICE=eth1:192168
IPADDR=192.168.0.1
IPV6INIT=no
NETMASK=255.255.0.0
NETWORK=192.168.0.0
#ONBOOT=yes
ONPARENT=yes

As well as a static route similar to:

route-eth1
192.168.216.0/24  via  x.y.z.42  dev  eth1

And on KVM2 I would need:

ifcfg-br0
BOOTPROTO="none"
DEFROUTE="yes"
DEVICE="br0"
GATEWAY="x.y.z.1"
IPADDR="x.y.z.42"
IPV4_FAILURE_FATAL="no"
IPV6INIT="no"
NAME="System br0"
NETMASK="255.255.255.0"
NETWORK="x.y.z.0"
NM_CONTROLLED="no"
ONBOOT="yes"
TYPE="Bridge"
USERCTL="no

ifcfg-br1
BOOTPROTO="none"
DEVICE="br1"
GATEWAY="x.y.z.42"
IPADDR="192.168.216.42"
IPV4_FAILURE_FATAL="no"
IPV6INIT="no"
NAME="System br1"
NETMASK="255.255.255.0"
NETWORK="192.168.216.0"
NM_CONTROLLED="no"
ONBOOT="yes"
TYPE="Bridge"
USERCTL="no

Am I anywhere close to what actually needs to be done?

We have an off-site warm standby backup host that I wish to periodically synchronise our imap server with using imapsync. I would like to know if it is possible to use RSA certificate authentication for the --authuser1 to --authuser2 login. If I use rsync over ssh then this poses no problem. But connecting to cyrus-imap through imapsync is somewhat more involved.

If not then what is the recommended way of passing the authuser passwords to the imapsync command when iteratively run inside a script?