Re: [Dnsmasq-discuss] CNAME caching issue in Dnsmasq(2.76)

[Simon Kelley]

On 21/01/2019 07:33, Yossi Boaron wrote:

> 
> Is this dnsmasq limitation is just due to lack of support in code/bug? 
> or it requires massive architectural changes of dnsmasq?
> If it's the first one, I can try to fix this issue.
> 

It's the second, unfortunately. a DNS query can be answered from an
upstream source, or locally, but not by a mixture of both.

Simon.


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

Re: [Dnsmasq-discuss] 3 secs dhcp delay

[Simon Kelley]

On 21/01/2019 08:59, Harald Dunkel wrote:
> On 1/18/19 10:36 AM, Harald Dunkel wrote:
>>
>> Do you think dnsmasq could watch/ping its IP address range while it is
>> idle, caching the result? It might examine the local arp table as well:
>> If there is an entry with matching MAC and IP address, isn't it
>> reasonable
>> to assume that the IP address is not in use somewhere else?
>>
> 
> PS: I found https://tools.ietf.org/html/rfc5227 on the web. Interesting
> read, but probably it won't help to avoid the delay.

RFC5227 is an elaboration of the ARP-based method.

Using ARP probes works at the client, but it's never applicable for the
server, because the server may not be located in the same
broadcast-domain as the client(s). Using DHCP relay, the server can be
on another subnet entirely. This is why servers use ICMP for conflict
detection, as it's a routable protocol.


> 

Simon.


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

Re: [Dnsmasq-discuss] 3 secs dhcp delay

[Simon Kelley]

On 21/01/2019 11:49, Roy Marples wrote:

> 
>> Will dnsmasq offer another IP address in case it receives a decline?
> 
> It does with my testing, unless I hardcode the hardware address to a
> fixed IP. This results in an infinite loop, but there's no real way
> around that.


It's supposed to give up on the fixed IP, log a message and allocate a
pool IP instead under that circumstance. If you can repeat this I'd be
interested in the details, as it's a bug.


Cheers,


Simon.



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

Re: [Dnsmasq-discuss] 3 secs dhcp delay

[Roy Marples]

On 21/01/2019 08:59, Harald Dunkel wrote:

But AFAICS strongswan's dhcp plugin doesn't, and
surely it is not alone.


Use another DHCP client that does then?
There's no reason why dhcpcd can't work with StrongSwan. You even get a 
DHCPv6 client for free which StrongSwan doesn't support.



Will dnsmasq offer another IP address in case it receives a decline?


It does with my testing, unless I hardcode the hardware address to a 
fixed IP. This results in an infinite loop, but there's no real way 
around that.


Roy

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

Re: [Dnsmasq-discuss] 3 secs dhcp delay

[Harald Dunkel]

On 1/18/19 10:36 AM, Harald Dunkel wrote:


Do you think dnsmasq could watch/ping its IP address range while it is
idle, caching the result? It might examine the local arp table as well:
If there is an entry with matching MAC and IP address, isn't it reasonable
to assume that the IP address is not in use somewhere else?



PS: I found https://tools.ietf.org/html/rfc5227 on the web. Interesting
read, but probably it won't help to avoid the delay.

I would agree that it should the job of the client to make sure that
the IP address is not in use yet, and to reply with a DHCPDECLINE to
the dhcp server. But AFAICS strongswan's dhcp plugin doesn't, and
surely it is not alone.

Will dnsmasq offer another IP address in case it receives a decline?


Thanx anyway. Keep on your good work

Harri

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

Re: [Dnsmasq-discuss] CNAME caching issue in Dnsmasq(2.76)

[Yossi Boaron]

Hi Simon,

Thanks a lot for a prompt response.
Unfortunately, I can't have both (CNAME and host) entries in upstream
neither in dnsmasq.

I'll add a few words about what I need to do,
As Openstack tenant, I run an application that composed of few VMs,  the
VMs communicate with other VMs using hostname (the one that defined CNAME)
and VMs may recreate on the fly (means VM's IP changed).

>From one side, as OpenStack tenant I'm not allowed to add CNAME entries to
dnsmasq and from the other side, since the VMs IPs may change dynamically
it isn't practical to store the target IPs in the upstream server.

So, having the CNAME in upstream server and VMs IPs in dnsmasq is the most
suitable solution for me.

Is this dnsmasq limitation is just due to lack of support in code/bug?
or it requires massive architectural changes of dnsmasq?
If it's the first one, I can try to fix this issue.

Thanks
Yossi


‫בתאריך יום ב׳, 21 בינו׳ 2019 ב-0:29 מאת ‪Simon Kelley‬‏ <‪
si...@thekelleys.org.uk‬‏>:‬

> It's a known limitation. The  actual limitation is that a CNAME and it's
> target must both either originate from an upstream server, or both
> originate from the dnsmasq local configuration. Mixing sources (ie CNAME
> from upstream and target from dnsmasq, or vice-versa) is not allowed.
>
> The commonest situation, when a CNAME is defined in dnsmasq's
> configuration whose target comes from upstream, is noted a a problem in
> the man page, but that doesn't mention what you're doing, defining the
> CNAME upstream but the target in dnsmasq. It should probably do that.
>
> Workaround is to add the CNAME to the dnsmasq configuration.
>
> Cheers,
>
> Simon.
>
>
>
>
> On 20/01/2019 11:03, Yossi Boaron wrote:
> >
> > Hi All,
> > I have the following DNS topology (In my Openstack deployment):
> > VM --> DNSMASQ --> external DNS server
> > domain name= shiftstack.com , and Dnsmasq 2.76
> > is used at this Openstack deployment.
> >
> > I run the following test:
> > 1. Define CNAME record at external DNS server
> >
> > ostest-etcd-5.shiftstack.com .
> >  IN   CNAMEostest-master-2
> >
> > 2. while 'ostest-master-2' is defined in --addn-hosts at Dnsmasq:
> > the relevant entry:
> > 10.0.1.214  ostest-master-2.shiftstack.com
> > . ostest-master-2
> >
> > 3. next step, I tried to resolve 'ostest-etcd-5.shiftstack.com
> > .' from the VM.
> > I expected that dig ostest-etcd-5.shiftstack.com
> > . should be replied with the
> > ostest-master-2 IP (10.0.1.214).
> >
> > Actual behavior:
> > When I run dig (see 1)  just for type A, Dnsmasq replied only with the
> > CNAME entry and doesn't return ostest-master-2 IP address.
> >
> > But when I run dig (see 2) for types  and A (at this order), I can
> > see that Dnsmasq resolves  ostest-master-2 IP address as expected.
> >
> > It seems to me like an issue of CNAME caching  at Dnsmasq (2.76),
> > Is it a known issue?
> >
> > Thanks in advance
> > Yossi
> >
> >
> > [1]
> > $ dig +noedns  ostest-etcd-5.shiftstack.com
> > .  A
> >
> > ; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>>
> > +noedns ostest-etcd-5.shiftstack.com
> > . A
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13837
> > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> >
> > ;; QUESTION SECTION:
> > ;ostest-etcd-5.shiftstack.com .
> > IN  A
> >
> > ;; ANSWER SECTION:
> > ostest-etcd-5.shiftstack.com .
> > 3600 IN   CNAME   ostest-master-2.shiftstack.com
> > .
> >
> > ;; Query time: 2 msec
> > ;; SERVER: 10.0.0.2#53(10.0.0.2)
> > ;; WHEN: Sun Jan 20 09:52:48 UTC 2019
> > ;; MSG SIZE  rcvd: 118
> >
> > $
> >
> > [2]
> > $ dig +noedns ostest-etcd-5.shiftstack.com
> > .
> >   ostest-etcd-5.shiftstack.com
> > .  A
> >
> > ; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>>
> > +noedns ostest-etcd-5.shiftstack.com
> > .
> >  ostest-etcd-5.shiftstack.com .
> A
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63573
> > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> >
> > ;; QUESTION SECTION:
> > ;ostest-etcd-5.shiftstack.com .
> > IN  
> >
> > ;; ANSWER SECTION:
> > ostest-etcd-5.shiftstack.com .
> > 3600 IN   CNAME   ostest-master-2.shiftstack.com
> > .
> >
> > ;; Query time: 3 msec
> > ;; SERVER: 10.0.0.2#53(10.0.0.2)
> > ;; WHEN: Sun Jan 20