Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-04 Thread Oliver Freyermuth
Am 04.06.2018 um 23:27 schrieb Roy Marples:
> On 25/05/2018 13:07, Oliver Freyermuth wrote:
>> I fear the following is a design issue of DHCPv6, but I wonder if there's a 
>> way to overcome it with dnsmasq...
>>
>> When automatically deploying machines via PXE / network installer, there's 
>> usually first a DHCPv6 client running in the installer,
>> and afterwards (when the machine is installed) the "real" DHCPv6 client 
>> running on the machine.
>> Naturally, both will usually have different client DUIDs...
> 
> The partial solution to this, without any dnsmasq hackery OR DHCPv6 client 
> fixes, would be to seed the installed image with the duid from the installer.
> The only issue is if you re-run the installer it will create a new duid - 
> unless it performs a disk scan, finds the installation and then uses it. This 
> is an issue because there could be more than one installed target found, and 
> which to use?
> 
> NetBSD installer has been doing this with great success for some time now, no 
> reason why others cannot.

That's indeed a good point. It seems at least the Debian Installer is not doing 
that, I'm not 100% sure about RedHats kickstart, since I never had it in my 
test setup. 
But I know that some Linux installers, e.g. autoyast (openSUSE) also scrape 
existing installations for SSH host keys, to deploy them to the new 
installation. 
So the concept is certainly not new also for Linux, but apparently it has not 
made its way to the end just yet. 
I should probably go ahead at some point and open a bug report against 
Debian-Installer, and check out how Kickstart behaves. 

Of course, something which would fail in any case would be the approach to boot 
e.g. a temporary "bare-metal discovery" image to detect hardware, then the 
installer, and only then provision the machine. 
That's commonly done (see e.g. Foreman's discovery image). We're not doing that 
yet, but are planning to. 
The only solution for that would be RFC 6355, or using a type-3 DUID in the 
discovery image, since that's really volatile by design. 
Once we start to use the Foreman discovery image, I'll have a look what it 
does. 

Cheers,
Oliver

> 
> Roy

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-04 Thread Roy Marples

On 25/05/2018 13:07, Oliver Freyermuth wrote:

I fear the following is a design issue of DHCPv6, but I wonder if there's a way 
to overcome it with dnsmasq...

When automatically deploying machines via PXE / network installer, there's 
usually first a DHCPv6 client running in the installer,
and afterwards (when the machine is installed) the "real" DHCPv6 client running 
on the machine.
Naturally, both will usually have different client DUIDs...


The partial solution to this, without any dnsmasq hackery OR DHCPv6 
client fixes, would be to seed the installed image with the duid from 
the installer.
The only issue is if you re-run the installer it will create a new duid 
- unless it performs a disk scan, finds the installation and then uses 
it. This is an issue because there could be more than one installed 
target found, and which to use?


NetBSD installer has been doing this with great success for some time 
now, no reason why others cannot.


Roy

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-04 Thread Oliver Freyermuth
Am 04.06.2018 um 18:46 schrieb wkitt...@gmail.com:
> On 06/04/2018 07:36 AM, Oliver Freyermuth wrote:
>> Right now, I only know one could:
>> - Stop dnsmasq.
>> - Purge the lease from the leases-file.
>> - Restart dnsmasq.
> 
> 
> i think the process is:
> 
>   rewrite the leases file as needed
>   HUP dnsmasq
> 
> but i'm not positive... if not HUB, maybe one of the other signals... if none 
> of them, then something with DBUS...

I think this works for some separate files specified explicitly, e.g. 
dhcp-hostsfile, 
but the lease file is not reloaded on SIGHUP, but kept in memory and flushed 
from time to time... 
That's also what the manpage suggests in the "NOTES" section. 

I'm not sure if leases are destroyed when the corresponding entry in 
dhcp-hostsfile is removed and SIGHUP is sent. This might be a possibility,
but I would not expect that this destroys a still-valid lease. 

But indeed I find "RemoveDhcpLease" in:
https://github.com/imp/dnsmasq/blob/master/dbus/DBus-interface

This would certainly be a possibility :-). 

Cheers,
Oliver

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-04 Thread wkitty42

On 06/04/2018 07:36 AM, Oliver Freyermuth wrote:

Right now, I only know one could:
- Stop dnsmasq.
- Purge the lease from the leases-file.
- Restart dnsmasq.



i think the process is:

  rewrite the leases file as needed
  HUP dnsmasq

but i'm not positive... if not HUB, maybe one of the other signals... if none of 
them, then something with DBUS...



--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list unless*
   *a signed and pre-paid contract is in effect with us.*

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Wildcard CNAMEs - unexpected behaviour.

2018-06-04 Thread Stephen Howell
Hi,

I had some issues with the DHCP entries not being included when I made the
server authoritative for the .local domain, as I was populating .local from
DHCP leases in dnsmasq also.

Is this configuration of authoritative + DHCP entries supposed to work?

thanks
Stephen

On Sat, 2 Jun 2018 at 18:09 Simon Kelley  wrote:

> On 29/05/18 23:11, Stephen Howell wrote:
> > Hi,
> >
> > I'm an occasional sysadmin and I was looking to setup a round-robin
> > wildcard CNAME for a test project at home. I checked the dnsmasq docs
> > and saw:
> >
> > *--cname* as long as the record name is in the authoritative domain. If
> > the target of the CNAME is unqualified, then it is qualified with the
> > authoritative zone name. CNAME used in this way (only) may be wildcards,
> > as in
> >
> > *cname=*.example.com ,default.example.com
> > *
> >
> > *
> > *
> >
> > I figured out that the A records would need to be added as /etc/hosts
> > entries so I did so then added a couple of lines in my config to be
> > authoritative for this one zone and create the CNAME:
> >
> >
> > auth-zone=local,127.0.0.0/24,192.168.0.0/16,br-lan
> > 
> cname=*.k8s.local,app.k8s.local
> >
> > This *should* have created a DNS record that responds to queries for
> > "app2.k8s.local", "app3.k8s.local" etc. That does not happen, any
> > request for sub-domains below k8s.local returns empty data.
> >
> > Instead what I have is a record that responds to the *literal form* of
> > "*.k8s.local"!!
> >
> > $ dig *.k8s.local @192.168.0.2 
> >
> > ; <<>> DiG 9.11.3-1ubuntu1-Ubuntu <<>> *.k8s.local @192.168.1.1 <
> http://192.168.1.1>
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; WARNING: .local is reserved for Multicast DNS
> > ;; You are currently testing what happens when an mDNS query is leaked
> to DNS
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41245
> > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ;; QUESTION SECTION:
> > ;*.k8s.local. IN  A
> >
> > ;; ANSWER SECTION:
> > *.k8s.local.  0   IN  CNAME   app.k8s.local.
> > app.k8s.local.0   IN  A   192.168.1.11
> > app.k8s.local.0   IN  A   192.168.1.12
> > app.k8s.local.0   IN  A   192.168.1.13
> >
> > ;; Query time: 2 msec
> > ;; SERVER: 192.168.0.2#53(192.168.0.2)
> > ;; WHEN: Tue May 29 22:49:01 BST 2018
> > ;; MSG SIZE  rcvd: 115
> >
> > That is not a wildcard entry! Any idea what happened? DNSmasq is
> > 2.80test2 (current version from the OpenWRT repo).
>
>
> The query was for *.k8s.local, and that's what you got an answer for.
> That's quite correct. Try
>
> dig app.k8s.local @192.168.0.2
>
> Note that running in authoritative mode is a little more complex than
> you've configured: you'll need and auth-server config line as well, for
> instance, and probably a glue record elsewhere in the DNS.
>
>
> Cheers,
>
> Simon.
>
> >
> > I realise that the address=/domain.com/1.1.1.1
> >  form could be used, but that doesn't help
> > create a round-robin entry. How should a wildcard entry for multiple
> > backing hosts be created?
> >
> > Thanks
> > Stephen
> >
> >
> > ___
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss@lists.thekelleys.org.uk
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >
>
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-04 Thread Oliver Freyermuth
Am 04.06.2018 um 12:49 schrieb Roy Marples:
> On 03/06/2018 22:20, Simon Kelley wrote:
>> I agree that this is an annoying problem. In DHCPv6 even determining the
>> MAC address of a client is a slightly dodgy operation - there are
>> circumstances where it's not possible. That notwithstanding, dnsmasq
>> does it's best, and allows you to configure an address to allocated by
>> MAC address.
>>
>> The problem here is that the client changes DUID - the desired address
>> gets allocated by MAC address once, but when the DUID changes, the
>> address is already in use by a first DUID/IAID combination, so it can't
>> be allocated, even if the MAC address is the same.
> 
> The problem is how the DUID is generated, not the DUID itself.
> DUID-LL is not the default (and shouldn't be either).
> DUID-LLT is a good default, but comes with the aforementioned problems.
> 
> These problems are very nicely solved with RFC 6355 which adds DUID-UUID 
> where UUID is taken from the hosts firmware. The UUID can then be displayed 
> on the node alongside the MAC address for provisioning.
> https://tools.ietf.org/html/rfc6355
> 
> The downside is that no client I know of supports this and I keep meaning to 
> add support to dhcpcd for it.

This sounds like a really nice solution - it would be cool if this was added to 
dhclient and dhcpcd and systemd-networkd, and would be the default. 
This should then also fix the problem with automated deployments. 

Still, even if support for that is added, it will likely take some years until 
all components are fixed... 

> The other downside is that not all hosts have a retrievable UUID as it 
> depends on both the OS and host itself - for example some OS's present a UUID 
> based on the CPUID. Of course this only works if all OS's generate the same 
> UUID from the base data.
> 
> TL;DR - this isn't a dnsmasq issue and I agree with Simon that it should not 
> allow nor encourage RFC violations.

I fully agree it's not a dnsmasq issue (I already mentioned that in my first 
mail). I was mainly unaware of RFC6355 (which should indeed be *the* solution), 
and am convinced that a workaround on the DHCP server end is significantly 
easier to deploy for a full network than to get rid of all clients not yet 
using RFC6355, 
so I keep wondering whether an optional feature to violate the "old" RFCs would 
be feasible until all clients are fixed, which will surely take half a century 
or longer. 

Alternatively: 
Does somebody know of a clean way to administratively expire a lease handed out 
by dnsmasq? 
Then deployment tooling could forcefully expire an old lease when reinstalling 
a node, and after the final reboot in the installed OS. 

Right now, I only know one could:
- Stop dnsmasq.
- Purge the lease from the leases-file. 
- Restart dnsmasq. 

Is there a more convenient way? 

Cheers,
Oliver

> 
> Roy
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-04 Thread Roy Marples

On 03/06/2018 22:20, Simon Kelley wrote:

I agree that this is an annoying problem. In DHCPv6 even determining the
MAC address of a client is a slightly dodgy operation - there are
circumstances where it's not possible. That notwithstanding, dnsmasq
does it's best, and allows you to configure an address to allocated by
MAC address.

The problem here is that the client changes DUID - the desired address
gets allocated by MAC address once, but when the DUID changes, the
address is already in use by a first DUID/IAID combination, so it can't
be allocated, even if the MAC address is the same.


The problem is how the DUID is generated, not the DUID itself.
DUID-LL is not the default (and shouldn't be either).
DUID-LLT is a good default, but comes with the aforementioned problems.

These problems are very nicely solved with RFC 6355 which adds DUID-UUID 
where UUID is taken from the hosts firmware. The UUID can then be 
displayed on the node alongside the MAC address for provisioning.

https://tools.ietf.org/html/rfc6355

The downside is that no client I know of supports this and I keep 
meaning to add support to dhcpcd for it.
The other downside is that not all hosts have a retrievable UUID as it 
depends on both the OS and host itself - for example some OS's present a 
UUID based on the CPUID. Of course this only works if all OS's generate 
the same UUID from the base data.


TL;DR - this isn't a dnsmasq issue and I agree with Simon that it should 
not allow nor encourage RFC violations.


Roy

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss