Re: [Dnsmasq-discuss] Defending IP address

2023-05-05 Thread Geoff Back 
Hi Johan,

On 05/05/2023 08:40, Johan Vromans wrote:
> Hi,
>
> I have a number of IoT devices. Occasionally, when they try to set up the
> DHCP lease, some of them send wrong packets. The device effectively claims
> the IP address of the DHCP server. From the system log:
>
> May  4 05:39:59 srv1 dhcpcd[449]: eth0: hardware address
> xx:xx:xx:xx:xx::ce claims 192.168.1.10
>
> where 192.168.1.10 is the address of the DHCP server.
>
> If a second package arrives within 10 seconds,
>
> May  4 05:40:08 srv1 dhcpcd[449]: eth0: hardware address
> xx:xx:xx:xx:xx::e7 claims 192.168.1.10
>
> dnsmasq shuts down the network connection
Actually, it is dhcpcd that drops the address, not dnsmasq.

> dhcpcd[449]: eth0: 10 second defence failed for 192.168.1.10
> dnsmasq-dhcp[24169]: DHCPRELEASE(eth0) 192.168.1.96 xx:xx:xx:xx:xx::e7 
> avahi-daemon[373]: Withdrawing address record for 192.168.1.10 on eth0.
> avahi-daemon[373]: Leaving mDNS multicast group on interface eth0.IPv4 with
> address 192.168.1.10. avahi-daemon[373]: Interface eth0.IPv4 no longer
> relevant for mDNS. dhcpcd[449]: eth0: deleting route to 192.168.1.0/24
> dhcpcd[449]: eth0: deleting default route via 192.168.1.1
>
> and slowly the LAN collapses.
>
> How can I prevent dnsmasq from EVER giving up its own IP address?

Set static IP on the interface and do not run dhcpcd.  The problem is
with dhcpcd releasing the address, not with dnsmasq.

Cheers,

Geoff.

>
> -- Johan
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


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

Re: [Dnsmasq-discuss] Dynamic address config?

2022-11-26 Thread Geoff Back 
Hello,

How about adding:

alias labssh='ssh -i ~/.ssh/id_rsa.work'

to your shell profile (.bashrc or whatever)?  Then you can just do
'labssh ' and the alias expansion makes ssh use the
appropriate ID file.

Regards,

Geoff.

Geoff Back
What if we're all just characters in someone's nightmares?

On 26/11/2022 13:14, Feng Shao wrote:
> Thanks for the reply Petr.
> Let me explain more about the motivation: I am a developer and our
> testers test the code on various environments, including VMs on cloud
> and k8s worker nodes from cloud providers. These machines and IPs are
> not provisioned/allocated by dnsmasq. For cost reason, these
> environments only lives for a short period of time, like one week or
> so, and testers provision these IPs directly without awareness of
> network administrators, that’s also why we don’t configure hostname
> for these machines in DNS system. Also I can not know in advance the
> list of possible IPs.
>
> Whenever tester find some issue or need help, they give me the IP of
> the environments and I need to ssh to that environment. Because I will
> probably login to that same machine several times since the testers
> are testing my code on that machine recently, I want to setup
> passwordless login. So I  normally ssh-copy-id -i <~/.ssh/id_rsa.work
> <http://id_rsa.work>> first, then ssh to that machine. In order to
> instruct ssh to use my ssh key when connecting to that IP, I have
> below lines in my .ssh/config:
>
> Host *.mylab
>   User root
>   IdentityFile ~/.ssh/id_rsa.wor <http://id_rsa.work/>k
>
> And lines like below in /etc/hosts:
> address=/123.123.123.123
> <http://123.123.123.123>.mylab/123.123.123.123 <http://123.123.123.123/>
> address=/123.123.123.12 <http://123.123.123.123>4.mylab/123.123.123.12
> <http://123.123.123.123/>4
>
> So that I can now “ssh 123.123.123.123.mylab” 
>
> As you can see, the problem here is, whenever a new IP comes, I need
> to add a new entry in /etc/hosts. So what I want is any .mylab is
> resolved to .
>
> A key pair can be specified when creating VM on cloud, but I can not
> ask every tester add my ssh key pair when creating VM.
>
>
> Petr Menšík 于2022年11月25日 周五19:52写道：
>
> Did you know that dnsmasq registers all hosts by their name, if
> they send their own hostname when requesting DHCP from dnsmasq?
> Just use domain=mylab and have that host send hostname. It would
> make using names possible without any additional configuration.
>
> I do not get what is the advantage of having IP suffixed by some
> domain. It looks like IP address, but it is even longer. Names of
> machines should be easy to remember or use, I doubt that would be
> the case here.
>
> I think we have new feature conf-script, which can generate
> dnsmasq configuration on the output. But I doubt we have a
> possible code for what you describe. Could you please describe
> more about intended usage? Why isn't using just hostname for each
> host enough? Using dhcp-host seems enough for similar uses.
>
> I think DLZ plugins for BIND9 are able to do similar things to
> your request, but that would be very heavy-weight solution. I
> think more motivation for your current design should be shared,
> because I do not understand advantage of your solution.
>
> Cheers,
> Petr
>
> On 11/23/22 06:47, Feng Shao wrote:
>> There are a bunch of machines in our lab, and we normally don't
>> have DNS records configured for them, only accessing by IP. In
>> order to ssh to them with key auth, I have a config in my
>> .ssh/config like 
>>
>> Host *.mylab
>>   User root
>>   IdentityFile ~/.ssh/id_rsa.work <http://id_rsa.work/>
>>
>> and I have some "address=/123.123.123.123
>> <http://123.123.123.123>.mylab/123.123.123.123
>> <http://123.123.123.123/>" line in dnsmasq.conf. The problem here
>> is I need to add an entry whenever a new IP comes.
>>
>> Can this configuration be dynamically? For example,
>> "address=/*.mylab/somecmd %1", where "somecmd" is a external
>> command and %1 will be replaced by the name in A/ request. So
>> that for any DNS request to *.mylab, dnsmasq invoke this external
>> command and pass the name as argument, the output of external
>> command, which will be interpreted as IPv4/IPv6 addr then
>> responsed to client?
>>
>> ___
>> Dnsmasq-discuss mailing list
>> Dnsma

Re: [Dnsmasq-discuss] Does dnsmasq support cname within same domain?

2022-03-07 Thread Geoff Back 
On 07/03/2022 18:20, Simon Kelley wrote:
> A quick test of the current development code fails to reproduce this, 
> which is puzzling.
>
>
> One thing to check:  having a dhcp-host line which associates an address 
> with a name is not enough to make this work: there needs to be an active 
> DHCP lease in place to be able to resolve client1.test.example.com. If 
> leases are coming and going, that can be enough to confuse tests.
Hi Simon,

Given this:

domain=example.com
dhcp-host=11:22:33:44:55:66,10.1.1.2,myhost
cname=alias.example.com,myhost.example.com

Then it would appear that dnsmasq has enough information to respond to a
lookup for alias.example.com with full information; since the
information that would be returned to the query is unchanged by whether
there is a lease or not, I would have expected it to do so.

However, if I am reading the above correctly, that's not the case and
there has to be an active lease on 'myhost' for dnsmasq to return the
assigned IP.

Assuming I have that right, I'm sure there's a good reason; could you
enlighten me/us as to why?

Thanks,

Geoff.

>
> Do you see the same effect if you use host-record to define the address 
> of client1?
>
>
> Simon.
>
>   alias.test.example.com>,alias.dummy.example.com
>> ,client1.test.example.com
>> 
>>
>>
>> No, it behaves the same as I use two separate cname lines:
>> different domain alias resolves, and same domain alias doesn't.
>> Did it work for you? If so, what version of dnsmasq do you use?
>>
>> Thanks!
>> Frank
>>
>>
>> ___
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss@lists.thekelleys.org.uk
>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


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

Re: [Dnsmasq-discuss] Does dnsmasq support cname within same domain?

2022-03-02 Thread Geoff Back 
On 02/03/2022 22:38, Frank Liu wrote:
>
>
> On Wed, Mar 2, 2022 at 2:13 PM Donald Muller 
> wrote:
>
>
> What if you try
>
> cname=alias.test.example.com
> ,client1.test.example.com
> ,alias.dummy.example.com
> ,client1.test.example.com
> 
>
> Does it work?
>
>
> No, dnsmasq fails to start, with "CNAME loop" error.
>
> Can anyone try to add cname for same domain, and see if it works for you?
> Assuming your dhcp domain is internal.yourcompany.com
> , with an existing dhcp client
> client1, please add
> cname=testalias.internal.yourcompany.com
> ,client1.internal.yourcompany.com
> 
> and check if testalias.internal.yourcompany.com
>  resolves?
>
> Thanks!
> Frank

With 2.86, I have found that cname works if the target is declared in a
"host-record" line, but not if it is DHCP assigned.  Even if it's given
a fixed IP address in a "dhcp-host" line.

Cheers,

Geoff.
>
>
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


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

Re: [Dnsmasq-discuss] The filterwin2k option will make the dig command fail to query SOA.

2022-01-01 Thread Geoff Back 


On 01/01/2022 15:27, Andreas Metzler wrote:
> On 2022-01-01 Aaron Jones  wrote:
>> On 01/01/2022 05:30, Hongyi Zhao wrote:
>>> If I enable the filterwin2k option, the dig command will fail to query
>>> SOA, say, for the following ones:
>>> $ dig +short SOA bp.hyddns.xyz
>>> www.hyddns.xyz.
>>> $ dig +short SOA hyddns.xyz
>>> donald.dnspod.net. freednsadmin.dnspod.com. 1640510300 3600 180 1209600 180
>>> When filterwin2k option is enabled, nothing will be returned by the
>>> above commands.
> [...]
>
>> This is working as designed. From the manpage [1]:
>> -f, --filterwin2k
>> Later versions of windows make periodic DNS requests which don't get
>> sensible answers from the public DNS and can cause problems by
>> triggering dial-on-demand links. This flag turns on an option to filter
>> such requests. The requests blocked are for records of types SOA and
>> SRV, and type ANY where the requested name has underscores, to catch
>> LDAP requests.
> [...]
>
> The manpage says "The requests blocked are for records [...] where
> the requested name has underscores". The test-query shown above is not
> for a name with underscores. So, afaict not working as documented.
>
> cu Andreas
>

I'm afraid you are misinterpreting the man page.  Without the part you
elided, as quoted above, it specifies that blocking is for **all**
queries of type SOA and SRV, plus the subset of queries with type=ANY
that contain underscores.

Regards,

Geoff.

-- 
Geoff Back
What if we're all just characters in someone's nightmares?
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Option 12 hostname sent to RPi seems incorrect

2021-10-27 Thread Geoff Back 
Hi Shrenik,

On 27/10/2021 16:38, Shrenik Bhura wrote:
> Hi Geoff, 
>
> I don't expect it to at all set a hostname.

I think this sentence points to the very heart of your problem.

I have been following this thread in detail.  Everything indicates that
the RPI device is getting an IP address set as hostname and sending that
to dnsmasq in the DHCP packet, which of course results in dnsmasq
correctly interpreting the "192" before the dot as the node part of the
hostname, as already pointed out by Matthias.

You said, earlier on:

/"Nothing on the server is configured to set the same.  The Raspberry Pi
client is netbooting, so nothing on the client side could be setting it."/

That's an invalid configuration.  All Linux-based systems - in fact all
POSIX systems - have a hostname, even if it is only "(none)" and pretty
much everything will break if there is not something set.  The same
applies to Windows, if you are netbooting that, and in fact every other
OS I have ever encountered that uses IP (which is a lot).

Something must always set the hostname, and it definitely looks like
yours is being set by the OS image you are netbooting.  If it's not
explicitly defined by the OS image, and also is not defined in the
dnsmasq DHCP parameters, then the OS image will likely be falling back
to using the IP address as a (unfortunate) last chance due to lack of
anything else.

If you are truly expecting that your RPI device can operate without
having a hostname of any kind, I'm afraid you are expecting something
that simply won't work and even if DHCP worked in that situation, pretty
much everything else you tried to run on the RPI would not work properly
either.

Regards,

Geoff.

> But yet something involved in the entire transaction is doing so i.e.
> setting the IP address as the hostname and in doing so it is getting
> it all wrong.
>
> Kindly read the thread to understand what's exactly going on.
>
> Regards,
> Shrenik
>
>
> On Wed, 27 Oct, 2021, 20:52 Geoff Back,  <mailto:ge...@demonlair.co.uk>> wrote:
>
> Hi Shrenik,
>
> Looking at that configuration file I see nothing that specifies
> the host name that the RPI device should initialise itself with. 
> Where do you expect it to obtain a hostname from, and what
> specific hostname are you expecting to set?
>
> Regards,
>
> Geoff.
>
>
> On 27/10/2021 14:06, Shrenik Bhura wrote:
>> > but my rpi machines received hostname set from dnsmasq. I used
>> static allocations only for my testing.
>>
>> Try without setting any.
>>
>> > Can you share at least relevant part of dnsmasq configuration?
>>
>> Config file attached below.
>>
>> > Does it have dhcp-host record for that machine?
>>
>> No, it doesn't.
>>
>> The results are the same for any RPi 4B or RPi 400. I have tested
>> with 3.
>> --
>>
>>
>> On Wed, 27 Oct 2021 at 17:46, Petr Menšík > <mailto:pemen...@redhat.com>> wrote:
>>
>> Hi,
>>
>> I would try tomorrow, but my rpi machines received hostname
>> set from dnsmasq. I used static allocations only for my
>> testing. Can you share at least relevant part of dnsmasq
>> configuration?
>>
>> Does it have dhcp-host record for that machine?
>>
>> On 10/25/21 16:00, Shrenik Bhura wrote:
>>>
>>> On Mon, 25 Oct, 2021, 01:24 Matthias May via
>>> Dnsmasq-discuss, >> <mailto:dnsmasq-discuss@lists.thekelleys.org.uk>> wrote:
>>>
>>> On 21/10/2021 13:05, Shrenik Bhura wrote:
>>> > May be the code that logs this line needs to be
>>> checked if it is just printing part of the complete
>>> hostname i.e. IP
>>> > address.
>>> >
>>>
>>> Hi Shrenik
>>>
>>> The code is doing what it is supposed to do.
>>>
>>> Please take a look at the definition of a hostname and
>>> what makes up an FQDN.
>>> * https://en.wikipedia.org/wiki/Hostname
>>> <https://en.wikipedia.org/wiki/Hostname>
>>> *
>>> https://en.wikipedia.org/wiki/Fully_qualified_domain_name
>>> <https://en.wikipedia.org/wiki/Fully_qualified_domain_name>
>>>
>>> Valid characters for hostnames are:
>>> * ASCII(7) letters from a to z
>>>

Re: [Dnsmasq-discuss] Option 12 hostname sent to RPi seems incorrect

2021-10-27 Thread Geoff Back 
Hi Shrenik,

Looking at that configuration file I see nothing that specifies the host
name that the RPI device should initialise itself with.  Where do you
expect it to obtain a hostname from, and what specific hostname are you
expecting to set?

Regards,

Geoff.


On 27/10/2021 14:06, Shrenik Bhura wrote:
> > but my rpi machines received hostname set from dnsmasq. I used
> static allocations only for my testing.
>
> Try without setting any.
>
> > Can you share at least relevant part of dnsmasq configuration?
>
> Config file attached below.
>
> > Does it have dhcp-host record for that machine?
>
> No, it doesn't.
>
> The results are the same for any RPi 4B or RPi 400. I have tested with 3.
> --
>
>
> On Wed, 27 Oct 2021 at 17:46, Petr Menšík  <mailto:pemen...@redhat.com>> wrote:
>
> Hi,
>
> I would try tomorrow, but my rpi machines received hostname set
> from dnsmasq. I used static allocations only for my testing. Can
> you share at least relevant part of dnsmasq configuration?
>
> Does it have dhcp-host record for that machine?
>
> On 10/25/21 16:00, Shrenik Bhura wrote:
>>
>> On Mon, 25 Oct, 2021, 01:24 Matthias May via Dnsmasq-discuss,
>> > <mailto:dnsmasq-discuss@lists.thekelleys.org.uk>> wrote:
>>
>> On 21/10/2021 13:05, Shrenik Bhura wrote:
>> > May be the code that logs this line needs to be checked if
>> it is just printing part of the complete hostname i.e. IP
>> > address.
>> >
>>
>> Hi Shrenik
>>
>> The code is doing what it is supposed to do.
>>
>> Please take a look at the definition of a hostname and what
>> makes up an FQDN.
>> * https://en.wikipedia.org/wiki/Hostname
>> <https://en.wikipedia.org/wiki/Hostname>
>> * https://en.wikipedia.org/wiki/Fully_qualified_domain_name
>> <https://en.wikipedia.org/wiki/Fully_qualified_domain_name>
>>
>> Valid characters for hostnames are:
>> * ASCII(7) letters from a to z
>> * The digits from 0 to 9
>> * The hyphen (-)
>> * A hostname may not start with a hyphen
>> * When following the old RFC 952, a hostname may not start
>> with a digit.
>>
>> The dot '.' is used to concatenate the different domain labels.
>>
>> In your case you are using an IP address as hostname which is
>> not a valid hostname.
>> The first dot in the name you provide is interpreted as
>> domain label separator, thus the hostname is 192.
>>
>>
>> BR
>> Matthias
>>
>>
>>
>> Hi All,
>>
>> Clarifying on the last two posts -
>>
>> > In your case you are using an IP address as hostname which is
>> not a valid hostname.
>>
>> > the problem here is the client looks to be misconfigured if it
>> is telling the
>> server its name is an IP address... they are very different...
>>
>> No, I am not using such an IP address anywhere as a hostname. 
>> Nothing on the server is configured to set the same. 
>> The Raspberry Pi client is netbooting, so nothing on the client
>> side could be setting it. 
>> Or may be it is something in the Raspberry Pi 4B and 400
>> netbooting firmware which could be responsible for this, if it is
>> not something wrong with dnsmasq? 
>>
>> See -
>> 
>> https://drive.google.com/file/d/1WmbdcjFf6OYU-lcwwHw2LM40eSEIvllL/view?usp=drivesdk
>> 
>> <https://drive.google.com/file/d/1WmbdcjFf6OYU-lcwwHw2LM40eSEIvllL/view?usp=drivesdk>
>>
>> May be something in the dns handling implementation within
>> dnsmasq which doesn't differentiate the absence of a hostname
>> uses the same IP address that has been served to the client to
>> play along, eventually truncating what it calculates as the
>> domain part (168.67.53) from the fqdn (i.e. after the first .
>> "dot"), and serving just the hostname (192). This sequence is
>> visible in the snap above.
>>
>> If this is still not clear then I suggest that the only way to
>> understand this situation best is by netbooting a RPi 4B yourself
>> from a dnsmasq powered authoritative dhcp server.
>>
>> Do note that this is not reproducible with a x86 client.
>>
>> @Petr Menšík <mailto:pemen...@redhat.com>  may

Re: [Dnsmasq-discuss] How may is too many CNAME references?

2021-09-27 Thread Geoff Back 


On 27/09/2021 13:24, Ercolino de Spiacico wrote:
>
> Thank you for the answer.
>
> In my case, since I'm compiling the adblock list via script that takes
> already care of the duplicates, this dnsmasq behaviour is redundant
> and actually unwanted because it causes issues. 
>
> Beside this, is there a specific reason why you force this check on
> CNAME only but not on A records? It seems inconsistent.
>
> I would suggest to switch this off by default for cases like mine and
> perhaps design a new option to force the duplicates check if wanted only.
>
> Thanks
>
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Hello,

The DNS standards require that a CNAME record is unique, but permit the
existence of multiple A records for the same name.  The difference is
because a CNAME can only be an alias for one possible target name, but
you can have multiple IP addresses assigned to the same name.  Since
there is no possible legitimate result if there is more than one entry
for the same CNAME, the checking is rather necessary.

Your case of a large list of CNAMEs that are pre-validated as unique is
the outlier case here.  I don't know whether it would be practical to
provide a special handler for your case, but I would suggest it is safe
to assume the checking for duplicates will remain the default since it
is fundamentally necessary in all the "typical" use cases.

I guess one possible approach might be, subject I suspect to a
controlling option, to change the way the CNAME records are loaded to
improve performance.  A two-pass process might be possible:
- Phase one: read all the records from your list and check each one
against pre-existing CNAME records, but *not *insert them into the data
structures.
- Phase two: insert all the records that have now been validated.

This would mean it no longer checked each CNAME against all previous
entries loaded out of your list, but would be completely dependent on
your list being guaranteed unique.

Only an idea, how practical this would be in the context of the current
code I don't know.

Regards,

Geoff.

-- 
Geoff Back
What if we're all just characters in someone's nightmares?


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

Re: [Dnsmasq-discuss] Upstream servers by host tag (or MAC)

2021-09-23 Thread Geoff Back 


On 23/09/2021 17:43, Michael wrote:
> On 9/23/21 04:35, Petr Menšík wrote:
>> Hi Hubert,
>>
>> it may work, if you would run two dnsmasq instances. One for children
>> with OpenDNS as upstream servers, another for everyone else.
>>
>> default instance:
>>
>> bind-interfaces
>> listen-address=10.1.0.1
>> server=8.8.8.8
>> domain=home.arpa
>> dhcp-option=option:dns-server,10.1.0.1,8.8.8.8
>> dhcp-option=tag:child,option:dns-server:10.1.0.2,208.67.222.123
>> ...
>>
>> children instance:
>>
>> bind-interfaces
>> listen-address=10.1.0.2
>> server=208.67.222.123
>> server=/home.arpa/10.1.0.1
>>
>> Because the second instance would forward local domain to main instance,
>> which also registers dhcp, they should be able to resolve any local
>> names. But other names would be served by different server.
>>
>> Children might have reserved different address range, but it might be
>> handy to be on shared broadcast link. Good for link-local address
>> resolution and easy local games setup. Not sure it is relevant anymore.
>>
>> Not sure if 10.1.0.2 can be on the same interface as 10.1.0.1. It would
>> work fine with just DNS, but I think dhcp requires interface=eth0 or
>> similar. Which would block the second instance from working correctly. I
>> think alternative address would have to be on different interface.
>>
> I do almost exactly this so I can confirm it works.
>
>
> I have one machine running docker.   On that machine, I run two 
> containers with their own IP addresses (macvlan).    .1 for the primary 
> including DHCP pointing to my main DNS.   Then the .2 version that 
> points to the safe DNS, but relays local name queries (and reverse) over 
> to the .1.
>
>
> Then in config as you highlighted above, I point the child machines to 
> the .2 and everything else to .1.
>
>
> It would be nice if you could use tags to point to different DNS 
> servers, but until that is an option, this works.
>
> Michael

I think using different upstream servers based on the requesting client
would be a problem because that would mean the same query would get
different results.  That would appear to be what you would like to see
(IIUC), but you then have all sorts of issues with the caches - there
would need to be separate caches for separate tag-selected servers, with
all the complexity involved in managing that.

Since running multiple copies of dnsmasq for DNS can be done on separate
IPs (I suggest with only one of them serving DHCP) I would tend to go
with that rather than adding multiple-cache complexity.

Regards,

Geoff.

>
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

-- 
Geoff Back
What if we're all just characters in someone's nightmares?

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

Re: [Dnsmasq-discuss] [PATCH] Optimize inserting records into server list.

2021-09-19 Thread Geoff Back 



On 19/09/2021 10:55, hev via Dnsmasq-discuss wrote:
> Signed-off-by: hev 
> ---
>  src/domain-match.c | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/src/domain-match.c b/src/domain-match.c
> index 8f29621..43862f8 100644
> --- a/src/domain-match.c
> +++ b/src/domain-match.c
> @@ -673,18 +673,11 @@ int add_update_server(int flags,
>   }
>else
>   {
> -   struct server *s;
> -
> memset(serv, 0, sizeof(struct server));
> 
> /* Add to the end of the chain, for order */
> -   if (!daemon->servers)
> - daemon->servers = serv;
> -   else
> - {
> -   for (s = daemon->servers; s->next; s = s->next);
> -   s->next = serv;
> - }
> +   serv->next = daemon->servers;
> +   daemon->servers = serv;
> 
>  #ifdef HAVE_LOOP
> serv->uid = rand32();

This patch reverses the order of the entries in the linked list so that
the most recently added is at the start instead of the end.
The comment /* Add to the end of the chain, for order */ suggests that
this matters.

Regards,

Geoff.

-- 
Geoff Back
What if we're all just characters in someone's nightmares?


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

Re: [Dnsmasq-discuss] Further thoughts/questions on failover

2021-09-02 Thread Geoff Back 


On 02/09/2021 15:30, Chris Green wrote:
> On Thu, Sep 02, 2021 at 02:58:44PM +0100, Kevin Tedder wrote:
>> Chris
>> You just need to update the /etc/resolv.conf file on each of your clients to
>> point them at both DNS's.
>>
>> e.g
>> nameserver 192.168.1.2
>> nameserver 192.168.1.3
>>
>> The client will now ask both DNS servers. It will get a response even if one
>> of them is off-line.
>>
> Does that work satisfactorily though?  OK, there's a secondary DNS
> server on the system but it won't have all the local systems' names in
> its cache will it?  My main reason for running a local DNS is so that
> all systems on my LAN have proper names.  These names will only be in
> the DNS instance which was their DHCP server as well won't they?

What about if each instance was set to forward queries for the local
domain to the other one?
So if each is configured with "domain=example.com", also add
"server=/example.com/" where on each server the  is
the IP of the other one?

I haven't tried this, but I believe example.com names known to the local
server would be returned immediately and any others would be forwarded
to the other one.

>
>> Your solution to move the SD card to another RPI is fine, unless the issue
>> is a corrupted SD Card.  Wasn't this the original issue that you are trying
>> to avoid?
>>
> I wasn't aiming to move the SD card, I was aiming to keep an 'as up to
> date as possible' image of the running DNS system.  Possibly, in
> addition, writing the image out to an actual, spare, SD card at
> intervals.
>
>
>> Personally, I'd rather have two systems fully operational all the time. To
>> discover that the back up solution is not working at the critical moment is
>> the same as not having a backup at all.
> Is there some way the two systems can share the client names supplied
> at DHCP time?
>
>
>> The added benefit is maintenance.  You can take one off-line to
>> update/upgrade whilst the other continues to provide service. 
>>  
> Yes, I quite agree there.
>

Cheers,

-- 
Geoff Back
What if we're all just characters in someone's nightmares?

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

Re: [Dnsmasq-discuss] Wildcards in tags

2021-08-25 Thread Geoff Back 

On 25/08/2021 15:33, Simon Kelley wrote:
> On 25/08/2021 13:08, Geoff Back wrote:
>> Good morning,
>>
>> TL;DR: I need to wildcard-match interface tags and can't see how.
>>
>> I currently have dnsmasq working on a Linux VPN server to provide DHCP
>> options to VPN clients by using these config elements to bind only the
>> vpn interfaces:
>>
>> 8<==8<
>> interface=ppp*
>> bind-dynamic
>> dhcp-range=10.99.0.254,static
>> dhcp-option=option:router
>> dhcp-option=6,10.99.0.254
>> dhcp-option=121,
>> dhcp-option=249,
>> 8<==8<
>>
>> This works just fine.  However, I now need to also run regular DHCP on
>> other interfaces with different options.  Tags seem like the perfect
>> solution to this.
>>
>> As I understand it, the interface on which the request is received
>> becomes a tag, which would seem fine, but as far as I can tell from the
>> source of version 2.85, the tag:xxx in dhcp-option etc do not support
>> wildcards like the 'interface' directive, so I cannot use e.g.
>>
>> dhcp-option=tag:ppp*,option:router
>>
>> So I figure OK, set another tag based on the interface tag to represent
>> a "group of interfaces", and I end up with this:
>>
>> 8<==8<
>>
>> # basic binding settings for all PPP interfaces plus two ethernets.
>> bind-dynamic
>> interface=ppp*
>> interface=lan2
>> interface=lan3
>>
>> # Set a tag for all requests on PPP interfaces.
>> # If I understand correctly requests on ppp2 (for example) set a tag ppp2,
>> # This should work according to docs but there could be dozens of ppp
>> # interfaces in use making this really long and adding a lot of checks
>> to every request.
>> tag-if=set:ppp,tag:ppp0
>> tag-if=set:ppp,tag:ppp1
>> tag-if=set:ppp,tag:ppp2
>> ... repeated as necessary ...
>>
>> # DHCP for all ppp interfaces
>> # match using tag set by tag-if above.
>> dhcp-range=tag:ppp,10.99.0.254,static
>> dhcp-option=tag:ppp,option:router
>> dhcp-option=tag:ppp,6,10.99.0.254
>> dhcp-option=tag:ppp,121,
>> dhcp-option=tag:ppp,249,
>>
>> # DHCP for lan2
>> # match to interface tag
>> dhcp-range=tag:lan2,10.0.0.1,10.0.0.99
>> dhcp-option=tag:lan2,option:router,10.0.0.254
>>
>> 8<==8<
>>
>> Instead of having to give large numbers of "tag-if=set:ppp,tag:ppp9"
>> lines for all the possible ppp interfaces, I would like to do this:
>>
>> # set 'ppp' tag for all PPP interfaces
>> tag-if=set:ppp,tag:ppp*
>>
>> Of course, allowing wildcards on all tag matches would work too, but my
>> thinking is that restricting wildcards to 'tag-if' avoids the
>> performance impact of potentially doing wildcard checks on every
>> 'dhcp-option' etc. during DHCP packet processing and instead it gets
>> done once through 'tag-if'.
>>
>> Have I missed something and there is already a way to do this?
>> Or if not, is it something that could be added?
>>
>> If it's an acceptable add, I can knock up a patch to do it but I'll have
>> to learn enough of the dnsmasq code first.
>>
>> Regards,
>>
>> Geoff.
>>
>
> Your solution sounds like a good one to me. I'd certainly take a patch,
> especially if it updated the man page too.
>
> To get started, look at run_tag_if() and match_netid() in
> src/dhcp-common.c match_netid() does the matching and is called all over
> the place, so you either need to replace the call to match_netid() in
> run_tag_if() with code that implements the wildcard matching, or extend
> match_netid to do wildcard matching when the third argument is 2 or
> something similar.
>
>
> Cheers,
>
> Simon.
>
>
>
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Hi Simon,

Attached is a patch against tag v2.86rc1 that implements wildcards in
--tag-if and updates the man page.

Cheers,

Geoff.

-- 
Geoff Back
What if we're all just characters in someone's nightmares?

--- build.orig/src/dhcp-common.c2021-08-25 14:32:43.0 +0100
+++ build/src/dhcp-common.c 2021-08-25 20:46:30.960959376 +0100
@@ -79,13 +79,49 @@
   return (msg->msg_flags & MSG_TRUNC) ?

Re: [Dnsmasq-discuss] Wildcards in tags

2021-08-25 Thread Geoff Back 


On 25/08/2021 21:09, Geoff Back wrote:
> On 25/08/2021 15:33, Simon Kelley wrote:
>> On 25/08/2021 13:08, Geoff Back wrote:
>>> Good morning,
>>>
>>> TL;DR: I need to wildcard-match interface tags and can't see how.
>>>
>>> I currently have dnsmasq working on a Linux VPN server to provide DHCP
>>> options to VPN clients by using these config elements to bind only the
>>> vpn interfaces:
>>>
>>> 8<==8<
>>> interface=ppp*
>>> bind-dynamic
>>> dhcp-range=10.99.0.254,static
>>> dhcp-option=option:router
>>> dhcp-option=6,10.99.0.254
>>> dhcp-option=121,
>>> dhcp-option=249,
>>> 8<==8<
>>>
>>> This works just fine.  However, I now need to also run regular DHCP on
>>> other interfaces with different options.  Tags seem like the perfect
>>> solution to this.
>>>
>>> As I understand it, the interface on which the request is received
>>> becomes a tag, which would seem fine, but as far as I can tell from the
>>> source of version 2.85, the tag:xxx in dhcp-option etc do not support
>>> wildcards like the 'interface' directive, so I cannot use e.g.
>>>
>>> dhcp-option=tag:ppp*,option:router
>>>
>>> So I figure OK, set another tag based on the interface tag to represent
>>> a "group of interfaces", and I end up with this:
>>>
>>> 8<==8<
>>>
>>> # basic binding settings for all PPP interfaces plus two ethernets.
>>> bind-dynamic
>>> interface=ppp*
>>> interface=lan2
>>> interface=lan3
>>>
>>> # Set a tag for all requests on PPP interfaces.
>>> # If I understand correctly requests on ppp2 (for example) set a tag ppp2,
>>> # This should work according to docs but there could be dozens of ppp
>>> # interfaces in use making this really long and adding a lot of checks
>>> to every request.
>>> tag-if=set:ppp,tag:ppp0
>>> tag-if=set:ppp,tag:ppp1
>>> tag-if=set:ppp,tag:ppp2
>>> ... repeated as necessary ...
>>>
>>> # DHCP for all ppp interfaces
>>> # match using tag set by tag-if above.
>>> dhcp-range=tag:ppp,10.99.0.254,static
>>> dhcp-option=tag:ppp,option:router
>>> dhcp-option=tag:ppp,6,10.99.0.254
>>> dhcp-option=tag:ppp,121,
>>> dhcp-option=tag:ppp,249,
>>>
>>> # DHCP for lan2
>>> # match to interface tag
>>> dhcp-range=tag:lan2,10.0.0.1,10.0.0.99
>>> dhcp-option=tag:lan2,option:router,10.0.0.254
>>>
>>> 8<==8<
>>>
>>> Instead of having to give large numbers of "tag-if=set:ppp,tag:ppp9"
>>> lines for all the possible ppp interfaces, I would like to do this:
>>>
>>> # set 'ppp' tag for all PPP interfaces
>>> tag-if=set:ppp,tag:ppp*
>>>
>>> Of course, allowing wildcards on all tag matches would work too, but my
>>> thinking is that restricting wildcards to 'tag-if' avoids the
>>> performance impact of potentially doing wildcard checks on every
>>> 'dhcp-option' etc. during DHCP packet processing and instead it gets
>>> done once through 'tag-if'.
>>>
>>> Have I missed something and there is already a way to do this?
>>> Or if not, is it something that could be added?
>>>
>>> If it's an acceptable add, I can knock up a patch to do it but I'll have
>>> to learn enough of the dnsmasq code first.
>>>
>>> Regards,
>>>
>>> Geoff.
>>>
>> Your solution sounds like a good one to me. I'd certainly take a patch,
>> especially if it updated the man page too.
>>
>> To get started, look at run_tag_if() and match_netid() in
>> src/dhcp-common.c match_netid() does the matching and is called all over
>> the place, so you either need to replace the call to match_netid() in
>> run_tag_if() with code that implements the wildcard matching, or extend
>> match_netid to do wildcard matching when the third argument is 2 or
>> something similar.
>>
>>
>> Cheers,
>>
>> Simon.
>>
>>
>>
>>
>> ___
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss@lists.thekelleys.org.uk
>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
> Hi Si

[Dnsmasq-discuss] Wildcards in tags

2021-08-25 Thread Geoff Back 
Good morning,

TL;DR: I need to wildcard-match interface tags and can't see how.

I currently have dnsmasq working on a Linux VPN server to provide DHCP
options to VPN clients by using these config elements to bind only the
vpn interfaces:

8<==8<
interface=ppp*
bind-dynamic
dhcp-range=10.99.0.254,static
dhcp-option=option:router
dhcp-option=6,10.99.0.254
dhcp-option=121,
dhcp-option=249,
8<==8<

This works just fine.  However, I now need to also run regular DHCP on
other interfaces with different options.  Tags seem like the perfect
solution to this.

As I understand it, the interface on which the request is received
becomes a tag, which would seem fine, but as far as I can tell from the
source of version 2.85, the tag:xxx in dhcp-option etc do not support
wildcards like the 'interface' directive, so I cannot use e.g.

dhcp-option=tag:ppp*,option:router

So I figure OK, set another tag based on the interface tag to represent
a "group of interfaces", and I end up with this:

8<==8<

# basic binding settings for all PPP interfaces plus two ethernets.
bind-dynamic
interface=ppp*
interface=lan2
interface=lan3

# Set a tag for all requests on PPP interfaces.
# If I understand correctly requests on ppp2 (for example) set a tag ppp2,
# This should work according to docs but there could be dozens of ppp
# interfaces in use making this really long and adding a lot of checks
to every request.
tag-if=set:ppp,tag:ppp0
tag-if=set:ppp,tag:ppp1
tag-if=set:ppp,tag:ppp2
... repeated as necessary ...

# DHCP for all ppp interfaces
# match using tag set by tag-if above.
dhcp-range=tag:ppp,10.99.0.254,static
dhcp-option=tag:ppp,option:router
dhcp-option=tag:ppp,6,10.99.0.254
dhcp-option=tag:ppp,121,
dhcp-option=tag:ppp,249,

# DHCP for lan2
# match to interface tag
dhcp-range=tag:lan2,10.0.0.1,10.0.0.99
dhcp-option=tag:lan2,option:router,10.0.0.254

8<==8<

Instead of having to give large numbers of "tag-if=set:ppp,tag:ppp9"
lines for all the possible ppp interfaces, I would like to do this:

# set 'ppp' tag for all PPP interfaces
tag-if=set:ppp,tag:ppp*

Of course, allowing wildcards on all tag matches would work too, but my
thinking is that restricting wildcards to 'tag-if' avoids the
performance impact of potentially doing wildcard checks on every
'dhcp-option' etc. during DHCP packet processing and instead it gets
done once through 'tag-if'.

Have I missed something and there is already a way to do this?
Or if not, is it something that could be added?

If it's an acceptable add, I can knock up a patch to do it but I'll have
to learn enough of the dnsmasq code first.

Regards,

Geoff.

-- 

Geoff Back
What if we're all just characters in someone's nightmares?


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