[Dnsmasq-discuss] WG: AW: AW: clients of DHCPv6 with constructed IPv6 address range are not notified on address range change

2018-10-18 Thread Andrey Vakhitov
Hello Simon,

the patch seems to work reliable, I've not seen any glitches so far. I'd 
suggest to apply it to main branch.

-Ursprüngliche Nachricht-
Von: Andrey Vakhitov  
Gesendet: Samstag, 6. Oktober 2018 20:31
An: 'Simon Kelley' ; 
'dnsmasq-discuss@lists.thekelleys.org.uk' 

Betreff: AW: AW: AW: [Dnsmasq-discuss] clients of DHCPv6 with constructed IPv6 
address range are not notified on address range change

Hello Simon,

>> I've reactivated the patch locally and observing it since 4 days. 
>> Todays night associated
>> IPv6 names got lost again directly during IP prefix change process, 
>> the log shows it clearly (see log 1). So I would vote again for 
>> retrying during some extended timeframe even if the host isn't reachable.

> OK, done. Patch is here:
>
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=ee1df06aabaa
> 8f212eaa7102f6d62cb25bfb35e9

Thanks a lot for your great support! I've applied the patch and will monitor 
the behaviour.

Best Regards,
--
Andrey Vakhitov

E-Mail:  and...@vakhitov.netStuttgart, Germany





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


Re: [Dnsmasq-discuss] [PATCH] DHCPv6: Add support for more than one hardware address per IPv6 address

2018-10-18 Thread Pali Rohár
On Saturday 02 June 2018 16:25:51 Pali Rohár wrote:
> On Saturday 02 June 2018 15:48:58 Pali Rohár wrote:
> > On Tuesday 23 May 2017 09:39:11 Pali Rohár wrote:
> > > On Monday 22 May 2017 23:11:02 Simon Kelley wrote:
> > > > On 12/05/17 16:32, Pali Rohár wrote:
> > > > > On Friday 12 May 2017 17:15:20 Simon Kelley wrote:
> > > > >> There are so many layers of quotes here that I've completely lost
> > > > >> track of what we were trying to achieve, and how to achieve it. My
> > > > >> memory is that we'd failed to come up with any consensus on either
> > > > >> of those.
> > > > > 
> > > > > Goal 1:
> > > > > 
> > > > > Ability to assign one IPv4 address to two different MAC addresses. 
> > > > > Currently it is possible by misusing concept of "more mac addresses" 
> > > > > (where IPv4 address can be "steal" by later DHCP client).
> > > > > 
> > > > > Goal 2:
> > > > > 
> > > > > Achieve Goal 1 also for DHCPv6.
> > > > > 
> > > > >> Using MAC addresses with DHCPv6 AT ALL is quite difficult - it's not
> > > > >> a concept that the RFCs deal with.
> > > > > 
> > > > > I read DHCPv6 RFC and it does not refuse assigning IPv6 address based 
> > > > > on 
> > > > > link layer MAC address. Anyway, this is already supported by dnsmasq.
> > > > > 
> > > > > But what I want to achieve has ability to assign one IPv6 address to 
> > > > > more MAC addresses at same time. This DHCPv6 RFC does not allow, but 
> > > > > in 
> > > > > some situations it is useful and I think such options could be 
> > > > > provided 
> > > > > by DHCPv6 server with explicit warning in documentation.
> > > > > 
> > > > >> Doing the sleight-of-hand trick
> > > > >> that works with DHCPv4 doesn't seem feasible to me for DHCPv6.
> > > > > 
> > > > > Do you completely disagree with fact that dnsmasq could support this 
> > > > > scenario for assigning one IP address to more network cards 
> > > > > (identified 
> > > > > by MAC address)? Or you just do not like my current implementation?
> > > > 
> > > > The whole point of DHCP is to avoid an IP address being used by more
> > > > than one network card. The current two-MAC addresses for one IP facility
> > > > in DHCPv4 doesn't contradict this. It's specified to be used only when
> > > > there's a guarantee that both MAC address are never simultaneously in 
> > > > use.
> > > 
> > > I know. But as I wrote, lot of people misuse this feature to assign one
> > > IPv4 address to more network cards. As there is use case for such state
> > > and dnsmasq can do it.
> > > 
> > > So instead of misusing that feature I'm asking how to implement it
> > > properly.
> > 
> > Hi Simon!
> > 
> > Do you have any opinion about this? Or do you fully disagree and such
> > feature should not be in dnsmasq?
> > 
> > > > Cheers,
> > > > 
> > > > Simon.
> > > > 
> > > > 
> > > > > 
> > > > > In previous email I wrote that Goal 2 can be achieved by storing 
> > > > > tuple 
> > > > > DUID, IAID, MAC address and IPv6 address into DHCPv6 leases file.
> > > > > 
> > > 
> > 
> > In IPv6 it is a more complicated, e.g. when network administrator wants
> > to assign one IPv6 address for specific computer.
> > 
> > Imagine that you have one computer with more OS (dua-boot) and each OS
> > has its own DUID and IAID (MAC address is stable).
> > 
> > Problem: dnsmasq assign IPv6 address to that computer when OS1 is
> > running. Computer is then rebooted to OS2 which has different DUID and
> > IAID. Therefore dnsmasq assigns a new (different) IPv6, because old one
> > is still "used" in server lease file.
> > 
> > To "solve" this problem it is either needed to extend dnsmasq to allow
> > assigning one IPv6 address to more DUIDs/IAIDs.
> > 
> > Or to assign IPv6 addresses based on MAC address and then dnsmasq leases
> > file needs to be extended to included also MAC address for IPv6
> > addresses.
> 
> Currently in lease file for DHCPv6 records there is line:
> 
>   expire_time iaid ipv6_addr hostname duid
> 
> and for DHCPv4 is:
> 
>   expire_time mac ipv4_addr hostname clid
> 
> To have similar format DHCPv6 records as DHCPv4 could be changed and
> extended for mac address to:
> 
>   expire_time mac ipv6_addr hostname duid iaid
> 
> Or to have iaid on same position, to:
> 
>   expire_time iaid ipv6_addr hostname duid mac
> 
> And then allow assigning IPv6 address for IAID and correctly from lease
> file for IPv6 address takes value relevant for configuration. E.g. when
> IPv6 address is assigned based on MAC address, took mac. When is
> assigned for DUID, then duid. And when iaid, then IAID.
> 
> So when configured this would allow "stealing" IPv6 address when there
> is one computer which uses two different DHPv6 clients with different
> DUIDs or IAIDs. (E.g. dual-boot Linux-Windows setup).
> 
> 
> Also this extended information in lease file could allow to implement
> that assigning one IPv6 address to more MAC addresses properly as in
> lease file would be all relevant information about dhcp client.

Hi Simon! Have you looked 

[Dnsmasq-discuss] Announce: dnsmasq-2.80

2018-10-18 Thread Simon Kelley
I just published dnsmasq-2.80, available at

http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.80.tar.gz

Changelog attached below.


Cheers,

Simon.


version 2.80
Add support for RFC 4039 DHCP rapid commit. Thanks to Ashram
Method for the initial patch and motivation.

Alter the default for dnssec-check-unsigned. Versions of
dnsmasq prior to 2.80 defaulted to not checking unsigned
replies, and used --dnssec-check-unsigned to switch
this on. Such configurations will continue to work as before,
but those which used the default of no checking will need to be
altered to explicitly select no checking. The new default is
because switching off checking for unsigned replies is
inherently dangerous. Not only does it open the possiblity of   
forged replies, but it allows everything to appear to be working
even when the upstream namesevers do not support DNSSEC, and in
this case no DNSSEC validation at all is occuring.

Fix DHCP broken-ness when --no-ping AND --dhcp-sequential-ip
are set. Thanks to Daniel Miess for help with this.

Add a facilty to store DNS packets sent/recieved in a
pcap-format file for later debugging. The file location
is given by the --dumpfile option, and a bitmap controlling
which packets should be dumped is given by the --dumpmask
option.

Handle the case of both standard and constructed dhcp-ranges on
the same interface better. We don't now contruct a dhcp-range if
there's already one specified. This allows the specified
interface to have different parameters and avoids advertising
the same prefix twice. Thanks to Luis Marsano for spotting this
case.

Allow zone transfer in authoritative mode if auth-peer is
specified, even if auth-sec-servers is not. Thanks to Raphaël
Halimi for the suggestion.

Fix bug which sometimes caused dnsmasq to wrongly return answers
without DNSSEC RRs to queries with the do-bit set, but only when
DNSSEC validation was not enabled.
Thanks to Petr Menšík for spotting this.

Fix missing fatal errors with some malformed options
(server, local, address, rebind-domain-ok, ipset, alias).
Thanks to Eugene Lozovoy for spotting the problem.

Fix crash on startup with a --synth-domain which has no prefix.
Introduced in 2.79. Thanks to Andreas Engel for the bug report.

Fix missing EDNS0 section in some replies generated by local
DNS configuration which confused systemd-resolvd. Thanks to
Steve Dodd for characterising the problem.

Add --dhcp-name-match config option.

Add --caa-record config option.

Implement --address=/example.com/# as (more efficient) syntactic
sugar for --address=/example.com/0.0.0.0 and
--address=/example.com/::
Returning null addresses is a useful technique for ad-blocking.
Thanks to Peter Russell for the suggestion.

Change anti cache-snooping behaviour with queries with the
recursion-desired bit unset. Instead to returning SERVFAIL, we
now always forward, and never answer from the cache. This
allows "dig +trace" command to work.

Include in the example config file a formulation which
stops DHCP clients from claiming the DNS name "wpad".
This is a fix for the CERT Vulnerability VU#598349.





signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss