[Dnsmasq-discuss] localise-queries on ipv6 server does not work with ipv4-only hosts

Dominik DL6ER dl6er at dl6er.de
Fri Jul 16 11:06:41 UTC 2021


there is some confusion about IPv4/IPv6 addresses and A/AAAA records
here, so I'll clarify a bit: You can make any query (may it be A or
AAAA) over IPv4 or IPv6 and there will be no difference (when
"localise-queries" is not used!). This is also the nomenclature used by
the dnsmasq man page.

On Fri, 2021-07-16 at 12:00 +0200, fda at gmx.de wrote:
> > > localise-queries
> > >     Return answers to DNS queries from /etc/hosts and --
> > > interface-name
> > > and --dynamic-host which DEPENDS ON THE INTERFACE over which the
> > > query
> > > was received.
> My "interface" has an ipv4 and an ipv6!
>  And im requesting BY ipv6 an ipv4 (as the host has no ipv6) at an
> interface
> which is in 1 of the subnets of the returned host.
> If this should not be supported ("bug") the manpage should be fixed
> and the word "interface" avoided. 

Yes, the man page could be updated to say "address" instead of
"interface" here to be crystal clear on this. It is still not wrong how
it is written.

> > > Currently this facility is limited to IPv4.
> Yes, im asking for an ipv4

No, you are not. You are asking for an A record. This comment refers to
the connection used to make the query.

As I already said above, you can make any query (may it be A or AAAA)
over IPv4 or IPv6 and there will be no difference when "localise-
queries" is NOT used. There will, however, be a difference when it is
used but only when asking over IPv4. This is what the man page says and
aligns perfectly with what you observe.

> > What you request would be adding an interface-dependent address
> > lookup:
> > is there any suitable IPv4 address on the same interface. However,a
> > few
> > things need to be clarified in this case: how to handle multiple
> > IPv4
> > addresses on the same interface each of which having a valid
> > record? It
> > is just not possible to localize queries in the same way when it is
> > not
> > clear which IPv4 subnet the client is in.
>  - Dnsmasq know the incomming/destination ip of the request.
>  - At daemon start it build and list with interfaces+all its ipV 4+6
>  - And if an ipv4 sould be returned by ipv6 this list is first used.
> In case it still fails (many subnets at 1 interfce) it could the old
> "return all" method be used
> I dont know dnsmasq source code, but it sound not so hard
> For the multi-subnets exists a workaround to make it fully working:
> assign only 1 IPv4 per IF and move the other IPv4s to "eth0:n" 

Yes, it does not sound hard, but it is not available. This is a request
for a new feature.

> > My advice: There is no advantage in reaching a DNS server
> > internally
> > over IPv6 in a dual-stack network. Ensure your clients query
> > dnsmasq
> > over IPv4 and your problem is solved in both the simplest and also
> > most
> > reliable way.
> I think i dont like it, as i want the DNS be reachable by  v4+v6, eg
> when ipv4 is down.
> Maybe i could use different hostnames for the same device in differen
> subnets. This is not so smart, devices could be switches by vlans.
> And this host in multiple subnets has some cnames

I've seen a lot of networks with interesting configurations. Network
admins tend to take painful ways too often. In like 99% of all cases a
DNS+DHCP server serves the goal better and causes a lot less
maintenance work. Will IPv4 ever be down in your network and IPv6 still
working fine? I somehow doubt this is a realistic threat. You do not
need to prepare for a worst case scenario that will never happen.

As always, this is just advise indented to be helpful to you. I'm not
intending the slightest to tell you how you should do things. I'm
merely pointing into the direction of least pain.

To me this is a new feature requested for dnsmasq (requesting to remove
an existing limitation stated in the man page) and not a bug report.

All developers are reading this mailing list. Feature submissions via
git patches are welcomed also on this list and are known to accelerate
feature realization drastically.


More information about the Dnsmasq-discuss mailing list