This is a bug, for sure.
I can see exactly why this would happen with
address=/Computer1.example.org/10.0.0.10
but not with
host-record=Computer1.example.org,10.0.0.10,3600
Please could you recheck that you are seeing the problem with
--host-record? If you are, I've gone down the wrong track, but if you're
not, then the fix for this is fairly simple.
Cheers,
Simon.
On 22/07/2022 20:37, ryt 51V wrote:
Hi,
I am setting up dnsmasq as a local DHCPv6 server and DNS server. (I am
keeping my existing DHCPv4 server running on a separate appliance).
I am running into an issue in the following circumstances:
* auth-zone is enabled
* For a given device, there is a dhcp-host entry with the device's
DUID for an IPv6 address.
* The device is successfully obtaining this IPv6 address.
* There is an address or host-record entry for the same device's IPv4
address.
When querying the DNS server for the hostname, only the DHCPv6 IPv6
address is provided, not the IPv4 address from the address or
host-record entry.
This is problematic as I am trying to run a dual-stack network, and so
need both IPv4 and IPv6 addresses readily resolvable. That said, I am
not in any immediate need of help as using dynamic-host instead of
address or host-record is a suitable workaround. But it would be
helpful to find out whether I am missing some nuance in the
configuration, or whether this is a bug.
In more detail: Consider the following dnsmasq configuration (private
details have of course been modified)
no-resolv
domain=example.org <http://example.org>
#auth-zone=example.org <http://example.org>
#auth-server=server.example.org <http://server.example.org>,
dhcp-range=fd00::1000,fd00::ffff,64,1h
dhcp-host=id:00:00:00:01:23:45:67:89:AB:CD:EF:00:00:00, [fd00::10],
Computer1
address=/Computer1.example.org/10.0.0.10
<http://Computer1.example.org/10.0.0.10>
#host-record=Computer1.example.org
<http://Computer1.example.org>,10.0.0.10,3600
#dynamic-host=Computer1.example.org <http://Computer1.example.org>,
10.0.0.10,eth0
And assume:
* The server running dnsmasq has IPv4 10.0.0.1
* Computer1 has IPv4 10.0.0.10 (either static, or obtained from a
separate DHCPv4 server)
* Computer1 is successfully obtaining its IPv6 lease for fd00::10 from
dnsmasq
(1) In the state above, providing Computer1 has obtained its IPv6 lease
from dnsmasq, dnsmasq will provide both A and AAAA records for Computer1.
For example, using dig:
$ dig @10.0.0.1 <http://10.0.0.1> +short Computer1.example.org
<http://Computer1.example.org> A Computer1.example.org
<http://Computer1.example.org> AAAA
10.0.0.10
fd00::10
From my perspective this is expected behaviour.
(2) Now if you uncomment the auth-zone and auth-server lines, a DNS
query will *only* provide an AAAA record for the IPv6 address, and no A
record for the IPv4 address.
Again, using dig:
$ dig @10.0.0.1 <http://10.0.0.1> +short Computer1.example.org
<http://Computer1.example.org> A Computer1.example.org
<http://Computer1.example.org> AAAA
fd00::10
From my perspective this is unexpected behaviour. The address line
with the IPv4 address is for the authoritative domain, so I am unsure
why it would not be included.
(3) If you comment out the address line and uncomment the host-record
line, then DNS provides the same result as (2).
Again, this is unexpected behaviour. The host-record line is for the
authoritative domain.
(4) If you comment out the host-record line and uncomment the
dynamic-host line, then DNS provides the same result as (1).
This is expected behaviour and a suitable workaround to case (2)/(3).
Although it is odd that it's inconsistent with address and host-record
behaviour.
(5) I have also noticed that instead of using dig, one uses a Windows
nslookup, Windows will declare the response as non-authoritative for
case (4), but won't for case (2)/(3). Additionally if you remove the
dhcp-range and dhcp-host entries, nslookup will receive the IPv4 address
but again it will be marked as non-authoritative.
From my perspective, the behaviour in (2)/(3) is not correct (nor (5),
though I don't think that will really affect me that much). The
address/host-record entries are for the domain listed in auth-zone, and
so should be included as authoritative records.
Indeed the dnsmasq man page more explicitly suggests that (3) is
incorrect behaviour for host-record entries. It says that the
authoritative zone is populated with "IPv4 and IPv6 addresses from
/etc/hosts (and --addn-hosts ) and --host-record and --interface-name
and ---dynamic-host provided the address falls into one of the subnets
specified in the --auth-zone." (Explicitly adding a subnet to the
auth-zone line makes no difference to the above tests)
I have tested this with the same results with the following OS and
dnsmasq versions:
* Raspberry Pi OS Bullseye - dnsmasq 2.85-1 from RPi OS Repo
* Debian Bullseye - dnsmasq 2.85-1 from Debian Repo
* Debian Sid - dnsmasq 2.86-1.1 from Debian Repo
* Debain Sid - Latest dnsmasq from the Git repo as of 2022-07-22
Any help appreciated!
Kind regards,
ryt51v
_______________________________________________
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
