On Fri, 2020-01-10 at 21:25 +0000, Simon Kelley wrote: > On 08/01/2020 09:32, Harald Jensås wrote: > > On Tue, 2020-01-07 at 21:51 +0000, Simon Kelley wrote: > > > On 23/12/2019 11:24, Harald Jensas wrote: > > > > Hi, > > > > > > > > The patch below is a slight alteration to a possible solution > > > > discussed in > > > > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q1/011289.html > > > > . > > > > > > > > My approach here does not require making dhcp-host conditional > > > > on a > > > > tag. However, making dhcp-host conditional on a tag would be a > > > > nice > > > > addition that could be introduced as a follow up to this to > > > > have a > > > > match on the tag of the final OS to keep the provisioned system > > > > consistently configured with a specific address can be very > > > > handy. > > > > For > > > > the Openstack use-case I am working in, this however is'nt > > > > necessary. > > > > > > > > I have confirmed that the patch below together with a small > > > > change > > > > in > > > > Openstack Ironic (see: https://review.opendev.org/700002) > > > > solved > > > > the > > > > long standing issue when doing network booting and node > > > > provisioning > > > > in combination with static only dhcp configuration. > > > > > > > > We are looking forward to comments and feedback regarding this > > > > approach. > > > > > > > > Thank you! > > > > > > > > > > If I've understood correctly, this looks like it might be a > > > viable > > > solution. Question: how many addresses do you configure for each > > > host, > > > and is this fragile if the boot process changes, for instance to > > > add > > > new > > > steps? > > > > Thank you for reviewing this! > > > > I have tested using 4 addresses in total, I should be able to do > > with 2 > > addresses with the workflow I tested with which is OVMF-UEFI->iPXE- > > > LinuxDeployRamdisk->Final OS. OVMF-UEFI uses two addresses just > > > to do > > PXE, but it is kind enough to release both addresses before > > executing > > the network boot program. Then iPXE uses one, and the deploy > > ramdisk > > one. Depending on wheater the deploy ramdisk does a release or not > > before rebooting a third address would be used by the final OS. > > (This > > is where dhcp-host conditional on a tag would be handy to control > > the > > address of the final OS.) > > > > In the openstack use case the dhcp-config is changed to have just a > > single dhcp-host entry prior to booting into the final os, > > openstack's > > networking service takes care of issuing a release during this step > > making sure the leased addresses are released. (This is why the > > dhcp- > > host conditional on a tag is'nt required in the openstack use case. > > > > The number of addresses is indeed fragile, adding another bootstep > > could increase the number of addresses needed. Also an unexpected > > reset > > of the booting system would lock up addresses that where not > > released, > > mainly problem with UEFI firmware that likes to generate new IAID's > > every time it boots ... > > > > As digression, Pali Rohár `honor assignment based on MAC address` > > patch is less fragile for this use case. I recognize it breaks > > other > > parts of the DHCPv6 RFC, see my comments on a previous post in this > > thread. Should we consider his approach if the patch can be re- > > worked > > to be an opt-in via configuration and a note in docs that the > > behaviour > > is not following RFC? > > Pali has done good work on this and I appreciate it. The objection to > that approach is both the RFC non-compliance, and also the fact that > it > absolutely depends on dnsmasq being able to determine the MAC > address > of a client. Doing that is fragile, and it would be good to have a > mechanism which didn't rely on it.
ack, if you ask me I think it is unfortunate that when rfc6939 was written it defines that the relay agent and servers obtain the link- layer address from the link-layer header of the DHCPv6 message. It implies that relay agents would have to operate on raw sockets, with all the security implications. But ... here we are and I shall refrain ranting about it more. > Does openstack rely on identifying a > host by MAC address, or could it be made to work if the DHCP server > didn't know the MAC address of a client? Even if openstack relies on > MAC > addresses (and I understand the provisioning reasons for doing that), > a > mechanism to support chain-netbooting without knowing MAC addresses > is a > more generally useful thing that one which only works when the MAC > address is determinable. > Yes, openstack does rely on the MAC address. Openstack cannot know the client id since an image booted is the users image, the cloud provider should'nt meddle with the users image. Using a dynamic range is also not a good option, due to the fact that openstack allow configuring dhcp highly available. With multiple dhcp servers on the same network we need to use static only configuration since there is nothing keeping lease databases between the dhcp servers. I can't think of any other id apart from the link-layer-address and a static only dhcp server configuration using the link-layer-address to control the boot of each client independently. I haven't seen any issues where neighbour discovery used to determine the mac address in dnsmasq failed for clients on the same link. > > > Could we add new syntax to dhcp-host which allows it to configure > > > a range of addresses, rather than having a number of dhcp-host > > > entries > > > for each stage of the boot process? That would be a bigger > > > change, > > > but > > > might be a neater solution? > > > > > > > I went for multiple dhcp-host entries because that accidentally > > happens > > to be what openstack neutron already write in the dnsmasq > > configuration > > when multiple ip addresses are added to a port in openstack. > > > > Supporting either a list of addresses or a range of addresses in > > the > > dhcp-host syntax might be neater. (I am biased to keeping it to > > multiple dhcp-host entries due to how openstack currently works, > > but it > > would be reasonably small work to change|fix openstack in case ...) > > > > If we add dhcp-host conditional on a tag, one could use short lease > > time, like 1m, on entries without a tag that the boot process uses. > > And > > a longer lease time on the entry tagged for the final os. Doing so > > could ease the issue of leases being held after an unexpected reset > > during boot process. An argument to keep the multiple dhcp-host > > entries? > > The best of all possible worlds might be both: a dhcp-host tagged to > be > active when the final OS is not the client, which gives out a set of > addresses on short leases, thus removing the steps-to-boot and lost > addresses fragilities: with IPv6 there could be a range of 128 or 256 > addresses to go at. Plus a dhcp-host tagged to be active only for the > final OS boot, with a long lease time and fixed address. > Agreed, I think the above is a workable solution outside of openstack. For openstack we need to provide a list of addresses, not a range. The reason for this is the highly available dhcp servers, using a range in such a configuration could lead to conflicts. As mentioned earlier the tag is'nt important for openstack since we can re-write the dhcp configuration before booting the final os. However, dnsmasq should'nt only aspire to make this work with openstack. My conclusion is that we need to support both a list of specific address and a range. > As a general principle, dnsmasq tries to not depend on the order of > configuration lines to control behaviour - in almost all cases the > behaviour is defined not to matter on order, and if order appears to > matter then the behaviour is, strictly speaking, undefined. I guess > that > what you have at the moment kind of violates that principle. > Ok, this is a valid argument. I agree that the patch need to be re- worked to avoid this issue. Looking at the code in src/option.c I propose we add support for the following syntax: a) A dhcp-host with a range: Uses 'range:' to indicate it's a range of addresses, and the hyphen is used to reparate the first|last address of the range. dhcp-host=<hwaddr>,range:<ipv6addr-start>-<ipv6addr-end>,<hostname>,... b) A dhcp-host with a list of addresses: Uses the fact that ipv6 addresses already need to be in brackets. dhcp-host=<hwaddr>,range:[<ipv6addr#1>][<ipv6addr#2>][<ipv6addr#3>][<ipv6addr#4>],<hostname>,... I will start working on this, it is going to take me quite a bit of time since I'm not an experienced C programmer. So there should be plenty of time to discuss the proposed config syntax etc. I still think the tag support can be added on top of supporting a range and list of addresses in dhcp-host entries later. > > > > I guess that the final adddress that the host ends up with > > > depends on > > > the number of addresses allocated by other parts of the boot > > > process, > > > but as the DNS entry ends up pointing to that final address (does > > > it? > > > - > > > need to check this) that's not a problem. > > > > > > > Yes, the final address of the host depend on the number of address > > that > > where allocated during the boot process. > > > > Good point regarding DNS, I did'nt check how DNS entries are > > maintained > > before you mentioned it. Your assumption that the DNS entry point > > to > > the last address leased is correct. See annotated log below. > > > > > > Jan 08 10:02:03 server.example.com systemd[1]: Started DNS caching > > server.. > > Jan 08 10:02:03 server.example.com dnsmasq[1444]: started, version > > 2.80-102-g7d04e17 cachesize 150 > > Jan 08 10:02:03 server.example.com dnsmasq[1444]: compile time > > options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 > > no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify > > dumpfile > > Jan 08 10:02:03 server.example.com dnsmasq-dhcp[1444]: DHCPv6, > > static leases only on fd12:3456:789a:1::afff, lease time 10m > > Jan 08 10:02:03 server.example.com dnsmasq[1444]: using only > > locally-known addresses for domain mydomain.net > > Jan 08 10:02:03 server.example.com dnsmasq[1444]: reading > > /etc/resolv.dnsmasq > > Jan 08 10:02:03 server.example.com dnsmasq[1444]: using only > > locally-known addresses for domain mydomain.net > > Jan 08 10:02:03 server.example.com dnsmasq[1444]: using nameserver > > 192.168.122.1#53 > > Jan 08 10:02:03 server.example.com dnsmasq[1444]: cleared cache > > > > /** No entries in the cache */ > > > > Jan 08 10:02:16 server.example.com dnsmasq[1444]: time 1578474136 > > Jan 08 10:02:16 server.example.com dnsmasq[1444]: cache size 150, > > 0/0 cache insertions re-used unexpired cache entries. > > Jan 08 10:02:16 server.example.com dnsmasq[1444]: queries forwarded > > 0, queries answered locally 0 > > Jan 08 10:02:16 server.example.com dnsmasq[1444]: queries for > > authoritative zones 0 > > Jan 08 10:02:16 server.example.com dnsmasq[1444]: pool memory in > > use 0, max 0, allocated 0 > > Jan 08 10:02:16 server.example.com dnsmasq[1444]: server > > 192.168.122.1#53: queries sent 0, retried or failed 0 > > Jan 08 10:02:16 server.example.com dnsmasq[1444]: > > Host Address > > Flags Expires > > Jan 08 10:02:16 server.example.com dnsmasq[1444]: > > bind > > F I > > > > /** Initial DHCPv6 request from OVMF UEFI is serviced, > > fd12:3456:789a:1::bacc is leased. */ > > > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14233087 > > available DHCPv6 subnet: fd12:3456:789a:1::aaaa/64 > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14233087 > > client MAC address: 52:54:00:3f:5c:c0 > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14233087 > > DHCPSOLICIT(eth1) > > 00:04:90:b3:fe:05:c8:ed:73:42:a5:7d:55:a0:4f:57:ed:5c > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14233087 > > DHCPADVERTISE(eth1) fd12:3456:789a:1::bacc > > 00:04:90:b3:fe:05:c8:ed:73:42:a5:7d:55:a0:4f:57:ed:5c host1 > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14233087 > > requested options: 23:dns-server > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14233087 > > tags: ctlplane-subnet, known, dhcpv6, eth1 > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14233087 > > sent size: 18 option: 1 client- > > id 00:04:90:b3:fe:05:c8:ed:73:42:a5:7d:55:a0... > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14233087 > > sent size: 14 option: 2 server- > > id 00:01:00:01:25:a8:56:f2:52:54:00:b5:b2:8f > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14233087 > > sent size: 40 option: 3 ia-na IAID=1073085951 T1=300 T2=525 > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14233087 > > nest size: 24 option: 5 iaaddr fd12:3456:789a:1::bacc PL=600 > > VL=600 > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14233087 > > sent size: 9 option: 13 status 0 success > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14233087 > > sent size: 1 option: 7 preference 0 > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14233087 > > sent size: 16 option: 23 dns-server fd12:3456:789a:1::1 > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14233087 > > sent size: 7 option: 39 FQDN host1 > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14298623 > > available DHCPv6 subnet: fd12:3456:789a:1::aaaa/64 > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14298623 > > client MAC address: 52:54:00:3f:5c:c0 > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14298623 > > DHCPREQUEST(eth1) > > 00:04:90:b3:fe:05:c8:ed:73:42:a5:7d:55:a0:4f:57:ed:5c > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14298623 > > DHCPREPLY(eth1) fd12:3456:789a:1::bacc > > 00:04:90:b3:fe:05:c8:ed:73:42:a5:7d:55:a0:4f:57:ed:5c host1 > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14298623 > > requested options: 23:dns-server > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14298623 > > tags: ctlplane-subnet, known, dhcpv6, eth1 > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14298623 > > sent size: 18 option: 1 client- > > id 00:04:90:b3:fe:05:c8:ed:73:42:a5:7d:55:a0... > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14298623 > > sent size: 14 option: 2 server- > > id 00:01:00:01:25:a8:56:f2:52:54:00:b5:b2:8f > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14298623 > > sent size: 40 option: 3 ia-na IAID=1073085951 T1=300 T2=525 > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14298623 > > nest size: 24 option: 5 iaaddr fd12:3456:789a:1::bacc PL=600 > > VL=600 > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14298623 > > sent size: 9 option: 13 status 0 success > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14298623 > > sent size: 16 option: 23 dns-server fd12:3456:789a:1::1 > > Jan 08 10:02:27 server.example.com dnsmasq-dhcp[1444]: 14298623 > > sent size: 21 option: 39 FQDN host1.mydomain.net > > > > /** DNS entry points to fd12:3456:789a:1::bacc */ > > > > Jan 08 10:02:32 server.example.com dnsmasq[1444]: time 1578474152 > > Jan 08 10:02:32 server.example.com dnsmasq[1444]: cache size 150, > > 0/0 cache insertions re-used unexpired cache entries. > > Jan 08 10:02:32 server.example.com dnsmasq[1444]: queries forwarded > > 0, queries answered locally 0 > > Jan 08 10:02:32 server.example.com dnsmasq[1444]: queries for > > authoritative zones 0 > > Jan 08 10:02:32 server.example.com dnsmasq[1444]: pool memory in > > use 0, max 0, allocated 0 > > Jan 08 10:02:32 server.example.com dnsmasq[1444]: server > > 192.168.122.1#53: queries sent 0, retried or failed 0 > > Jan 08 10:02:32 server.example.com dnsmasq[1444]: > > Host Address > > Flags Expires > > Jan 08 10:02:32 server.example.com dnsmasq[1444]: > > net > > F D Wed Jan 8 10:12:27 2020 > > Jan 08 10:02:32 server.example.com dnsmasq[1444]: > > host1.mydomain.net fd12:3456:789a:1::bacc > > 6FR D Wed Jan 8 10:12:27 2020 > > Jan 08 10:02:32 server.example.com dnsmasq[1444]: > > bind > > F I > > Jan 08 10:02:32 server.example.com dnsmasq[1444]: > > host1 fd12:3456:789a:1::bacc > > 6F D Wed Jan 8 10:12:27 2020 > > Jan 08 10:02:32 server.example.com dnsmasq[1444]: > > mydomain.net > > F D Wed Jan 8 10:12:27 2020 > > > > /** DHCPv6 request from OVMF UEFI PXE boot is serviced, > > fd12:3456:789a:1::aacc is leased. */ > > > > Jan 08 10:03:33 server.example.com dnsmasq-dhcp[1444]: 14364159 > > available DHCPv6 subnet: fd12:3456:789a:1::aaaa/64 > > Jan 08 10:03:33 server.example.com dnsmasq-dhcp[1444]: 14364159 > > vendor class: 343 > > Jan 08 10:03:33 server.example.com dnsmasq-dhcp[1444]: 14364159 > > client MAC address: 52:54:00:3f:5c:c0 > > Jan 08 10:03:33 server.example.com dnsmasq-dhcp[1444]: 14364159 > > DHCPSOLICIT(eth1) > > 00:04:90:b3:fe:05:c8:ed:73:42:a5:7d:55:a0:4f:57:ed:5c > > Jan 08 10:03:33 server.example.com dnsmasq-dhcp[1444]: 14364159 > > DHCPADVERTISE(eth1) fd12:3456:789a:1::aacc > > 00:04:90:b3:fe:05:c8:ed:73:42:a5:7d:55:a0:4f:57:ed:5c host1 > > Jan 08 10:03:33 server.example.com dnsmasq-dhcp[1444]: 14364159 > > requested options: 59:bootfile-url, 60:bootfile-param, 23:dns- > > server, > > Jan 08 10:03:33 server.example.com dnsmasq-dhcp[1444]: 14364159 > > requested options: 16:vendor-class > > Jan 08 10:03:33 server.example.com dnsmasq-dhcp[1444]: 14364159 > > tags: ctlplane-subnet, known, efi6, dhcpv6, eth1 > > Jan 08 10:03:33 server.example.com dnsmasq-dhcp[1444]: 14364159 > > sent size: 18 option: 1 client- > > id 00:04:90:b3:fe:05:c8:ed:73:42:a5:7d:55:a0... > > Jan 08 10:03:33 server.example.com dnsmasq-dhcp[1444]: 14364159 > > sent size: 14 option: 2 server- > > id 00:01:00:01:25:a8:56:f2:52:54:00:b5:b2:8f > > Jan 08 10:03:33 server.example.com dnsmasq-dhcp[1444]: 14364159 > > sent size: 40 option: 3 ia-na IAID=3217423454 T1=300 T2=525 > > Jan 08 10:03:33 server.example.com dnsmasq-dhcp[1444]: 14364159 > > nest size: 24 option: 5 iaaddr fd12:3456:789a:1::aacc PL=600 > > VL=600 > > Jan 08 10:03:33 server.example.com dnsmasq-dhcp[1444]: 14364159 > > sent size: 9 option: 13 status 0 success > > Jan 08 10:03:33 server.example.com dnsmasq-dhcp[1444]: 14364159 > > sent size: 1 option: 7 preference 0 > > Jan 08 10:03:33 server.example.com dnsmasq-dhcp[1444]: 14364159 > > sent size: 37 option: 59 bootfile-url t > > ftp://[fd12:3456:789a:1::1]/ipxe.efi > > Jan 08 10:03:33 server.example.com dnsmasq-dhcp[1444]: 14364159 > > sent size: 16 option: 23 dns-server fd12:3456:789a:1::1 > > Jan 08 10:03:33 server.example.com dnsmasq-dhcp[1444]: 14364159 > > sent size: 7 option: 39 FQDN host1 > > Jan 08 10:03:38 server.example.com dnsmasq-dhcp[1444]: 14429695 > > available DHCPv6 subnet: fd12:3456:789a:1::aaaa/64 > > Jan 08 10:03:38 server.example.com dnsmasq-dhcp[1444]: 14429695 > > vendor class: 343 > > Jan 08 10:03:38 server.example.com dnsmasq-dhcp[1444]: 14429695 > > client MAC address: 52:54:00:3f:5c:c0 > > Jan 08 10:03:38 server.example.com dnsmasq-dhcp[1444]: 14429695 > > DHCPREQUEST(eth1) > > 00:04:90:b3:fe:05:c8:ed:73:42:a5:7d:55:a0:4f:57:ed:5c > > Jan 08 10:03:38 server.example.com dnsmasq-dhcp[1444]: 14429695 > > DHCPREPLY(eth1) fd12:3456:789a:1::aacc > > 00:04:90:b3:fe:05:c8:ed:73:42:a5:7d:55:a0:4f:57:ed:5c host1 > > Jan 08 10:03:38 server.example.com dnsmasq-dhcp[1444]: 14429695 > > requested options: 59:bootfile-url, 60:bootfile-param, 23:dns- > > server, > > Jan 08 10:03:38 server.example.com dnsmasq-dhcp[1444]: 14429695 > > requested options: 16:vendor-class > > Jan 08 10:03:38 server.example.com dnsmasq-dhcp[1444]: 14429695 > > tags: ctlplane-subnet, known, efi6, dhcpv6, eth1 > > Jan 08 10:03:38 server.example.com dnsmasq-dhcp[1444]: 14429695 > > sent size: 18 option: 1 client- > > id 00:04:90:b3:fe:05:c8:ed:73:42:a5:7d:55:a0... > > Jan 08 10:03:38 server.example.com dnsmasq-dhcp[1444]: 14429695 > > sent size: 14 option: 2 server- > > id 00:01:00:01:25:a8:56:f2:52:54:00:b5:b2:8f > > Jan 08 10:03:38 server.example.com dnsmasq-dhcp[1444]: 14429695 > > sent size: 40 option: 3 ia-na IAID=3217423454 T1=300 T2=525 > > Jan 08 10:03:38 server.example.com dnsmasq-dhcp[1444]: 14429695 > > nest size: 24 option: 5 iaaddr fd12:3456:789a:1::aacc PL=600 > > VL=600 > > Jan 08 10:03:38 server.example.com dnsmasq-dhcp[1444]: 14429695 > > sent size: 9 option: 13 status 0 success > > Jan 08 10:03:38 server.example.com dnsmasq-dhcp[1444]: 14429695 > > sent size: 37 option: 59 bootfile-url t > > ftp://[fd12:3456:789a:1::1]/ipxe.efi > > Jan 08 10:03:38 server.example.com dnsmasq-dhcp[1444]: 14429695 > > sent size: 16 option: 23 dns-server fd12:3456:789a:1::1 > > Jan 08 10:03:38 server.example.com dnsmasq-dhcp[1444]: 14429695 > > sent size: 21 option: 39 FQDN host1.mydomain.net > > > > /** DNS entry now points to fd12:3456:789a:1::aacc */ > > > > Jan 08 10:03:39 server.example.com dnsmasq[1444]: time 1578474219 > > Jan 08 10:03:39 server.example.com dnsmasq[1444]: cache size 150, > > 0/0 cache insertions re-used unexpired cache entries. > > Jan 08 10:03:39 server.example.com dnsmasq[1444]: queries forwarded > > 0, queries answered locally 0 > > Jan 08 10:03:39 server.example.com dnsmasq[1444]: queries for > > authoritative zones 0 > > Jan 08 10:03:39 server.example.com dnsmasq[1444]: pool memory in > > use 0, max 0, allocated 0 > > Jan 08 10:03:39 server.example.com dnsmasq[1444]: server > > 192.168.122.1#53: queries sent 0, retried or failed 0 > > Jan 08 10:03:39 server.example.com dnsmasq[1444]: > > Host Address > > Flags Expires > > Jan 08 10:03:39 server.example.com dnsmasq[1444]: > > net > > F D Wed Jan 8 10:13:38 2020 > > Jan 08 10:03:39 server.example.com dnsmasq[1444]: > > host1.mydomain.net fd12:3456:789a:1::aacc > > 6FR D Wed Jan 8 10:13:38 2020 > > Jan 08 10:03:39 server.example.com dnsmasq[1444]: > > bind > > F I > > Jan 08 10:03:39 server.example.com dnsmasq[1444]: > > host1 fd12:3456:789a:1::aacc > > 6F D Wed Jan 8 10:13:38 2020 > > Jan 08 10:03:39 server.example.com dnsmasq[1444]: > > mydomain.net > > F D Wed Jan 8 10:13:38 2020 > > > > > > Good, that solves that question. > > > Cheers, > > Simon. > _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
