[Dnsmasq-discuss] [PATCH] RADV: Send same RDNSS address as in DHCPv6

Does the existing behaviour cause you problems? The rationale for why it
behaves the way it does is that link-local addresses are good IF client
and server are on the same link, since there's no possibility of
addresses changing or renumbering. A client getting DNS server addresses
from RADV is by definition on the same link as the server. One getting
DNS addresses by DHCP is not (there may be a DHCP relay involved) but
has DHCP to handle renumbering.

Cheers

Simon.

Post by Pali RohÃ¡r
Before this patch when both RADV and DHCPv6 is running and DNS server
address was not configured then RADV were sending link-local address and
DHCPv6 global address.
This patch change behaviour of RADV and when both RADV and DHCPv6 is
running without configured DNS server then in RADV RDNSS will be same
global address as in DHCPv6 instead link-local address.
---
man/dnsmasq.8 | 4 ++--
src/radv.c | 22 ++++++++++++++++++++++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index 6a121fe..bb588d3 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -1695,8 +1695,8 @@ the machine running dnsmasq. By default, the "managed address" bits are set, and
the "use SLAAC" bit is reset. This can be changed for individual
subnets with the mode keywords described in
.B --dhcp-range.
-RFC6106 DNS parameters are included in the advertisements. By default,
-the relevant link-local address of the machine running dnsmasq is sent
+RFC6106 DNS parameters are included in the advertisements. By default
+the relevant DHCPv6 address (or link-local when using SLAAC) of the machine running dnsmasq is sent
as recursive DNS server. If provided, the DHCPv6 options dns-server and
domain-search are used for the DNS server (RDNSS) and the domain serach list (DNSSL).
.TP
diff --git a/src/radv.c b/src/radv.c
index 39f1e92..15e116c 100644
--- a/src/radv.c
+++ b/src/radv.c
@@ -482,6 +482,28 @@ static void send_ra_alias(time_t now, int iface, char *iface_name, struct in6_ad
}
}
+ if (daemon->port == NAMESERVER_PORT && !done_dns && parm.link_pref_time != 0 && parm.other)
+ for (context = daemon->dhcp6; context; context = context->next)
+ if (context->if_index == iface && !IN6_IS_ADDR_UNSPECIFIED(&context->local6))
+ {
+ /* squash duplicates */
+ struct dhcp_context *c;
+ for (c = context->current; c; c = c->current)
+ if ((c->flags & CONTEXT_USED) &&
+ IN6_ARE_ADDR_EQUAL(&context->local6, &c->local6))
+ break;
+
+ if (!c)
+ {
+ done_dns = 1;
+ put_opt6_char(ICMP6_OPT_RDNSS);
+ put_opt6_char(3);
+ put_opt6_short(0);
+ put_opt6_long(min_pref_time);
+ put_opt6(&context->local6, IN6ADDRSZ);
+ }
+ }
+
if (daemon->port == NAMESERVER_PORT && !done_dns && parm.link_pref_time != 0)
{
/* default == us, as long as we are supplying DNS service. */

Pali Rohár

2016-01-01 21:07:12 UTC

Post by Simon Kelley
Does the existing behaviour cause you problems? The rationale for why
it behaves the way it does is that link-local addresses are good IF
client and server are on the same link, since there's no possibility
of addresses changing or renumbering. A client getting DNS server
addresses from RADV is by definition on the same link as the server.
One getting DNS addresses by DHCP is not (there may be a DHCP relay
involved) but has DHCP to handle renumbering.

Hi! Reason is to provide same data over DHCPv6 and over RA. This is
really useful to have consistency of connection data in whole network.

When different addresses are sent over DHCPv6 and RA, correct client
behaviour is to use both (different) addresses in DNS configuration.

But when I'm running one SW which doing everything needed for IPv6
client subnetwork configuration I would expect that this SW provide same
data over all channels. Currently redundant information over DHCPv6 and
RA is only DNS (for now).

--
Pali RohÃ¡r
***@gmail.com

Simon Kelley

2016-01-15 21:37:46 UTC

Post by Simon Kelley
Does the existing behaviour cause you problems? The rationale for
why it behaves the way it does is that link-local addresses are
good IF client and server are on the same link, since there's no
possibility of addresses changing or renumbering. A client
getting DNS server addresses from RADV is by definition on the
same link as the server. One getting DNS addresses by DHCP is not
(there may be a DHCP relay involved) but has DHCP to handle
renumbering.

Hi! Reason is to provide same data over DHCPv6 and over RA. This is
really useful to have consistency of connection data in whole
network.
When different addresses are sent over DHCPv6 and RA, correct
client behaviour is to use both (different) addresses in DNS
configuration.
But when I'm running one SW which doing everything needed for IPv6
client subnetwork configuration I would expect that this SW
provide same data over all channels. Currently redundant
information over DHCPv6 and RA is only DNS (for now).

You can certainly configure it to do that, the default does different
things for RA and DHCPv6 for the reasons I gave. Have you seen
problems with those values when using RA and DHCP? If so, that's a
bug, that needs to be fixed, but otherwise, the best solution for you
may be to configure dnsmasq rather than patching it.

Cheers,

Simon.

Pali Rohár

2016-01-16 15:10:07 UTC

Post by Simon Kelley
Does the existing behaviour cause you problems? The rationale for
why it behaves the way it does is that link-local addresses are
good IF client and server are on the same link, since there's no
possibility of addresses changing or renumbering. A client
getting DNS server addresses from RADV is by definition on the
same link as the server. One getting DNS addresses by DHCP is not
(there may be a DHCP relay involved) but has DHCP to handle
renumbering.

Hi! Reason is to provide same data over DHCPv6 and over RA. This is
really useful to have consistency of connection data in whole
network.
When different addresses are sent over DHCPv6 and RA, correct
client behaviour is to use both (different) addresses in DNS
configuration.
But when I'm running one SW which doing everything needed for IPv6
client subnetwork configuration I would expect that this SW
provide same data over all channels. Currently redundant
information over DHCPv6 and RA is only DNS (for now).

You can certainly configure it to do that, the default does different
things for RA and DHCPv6 for the reasons I gave. Have you seen
problems with those values when using RA and DHCP?

Problems? Not something which break functionality. Just that OS adds two
addresses (one l-l from RA and one from DHCPv6) to /etc/resolv.conf and
both addresses represent just one recursive DNS (that where is running
dnsmasq). Which I basically do not like as there is only one
recursive/forwarder DNS server.

Plus also that inconsistency on network that one configuration part of
IPv6 addresses (RA) send different information as another configuration
part (DHCPv6).

Post by Simon Kelley
If so, that's a
bug, that needs to be fixed, but otherwise, the best solution for
you may be to configure dnsmasq rather than patching it.

Ok, configuration option for behaviour which I want is also OK. But I
dot want to hardcode full IPv6 address of machine where is running
dnsmasq as this address can be changed in time (because it comes from
DHCPv6 prefix delegation). Option --dhcp-range has already fix for it,
it accept address suffix with constructor:<iface>.

But for specifying RDNSS option in dnsmasq it is not possible to set
global IPv6 address which comes from interface...

--
Pali RohÃ¡r
***@gmail.com

Simon Kelley

2016-01-20 20:03:50 UTC

Post by Simon Kelley
Does the existing behaviour cause you problems? The rationale
for why it behaves the way it does is that link-local
addresses are good IF client and server are on the same link,
since there's no possibility of addresses changing or
renumbering. A client getting DNS server addresses from RADV
is by definition on the same link as the server. One getting
DNS addresses by DHCP is not (there may be a DHCP relay
involved) but has DHCP to handle renumbering.

Hi! Reason is to provide same data over DHCPv6 and over RA.
This is
really useful to have consistency of connection data in whole
network.
When different addresses are sent over DHCPv6 and RA, correct
client behaviour is to use both (different) addresses in DNS
configuration.
But when I'm running one SW which doing everything needed for IPv6
client subnetwork configuration I would expect that this SW
provide same data over all channels. Currently redundant
information over DHCPv6 and RA is only DNS (for now).

You can certainly configure it to do that, the default does
different things for RA and DHCPv6 for the reasons I gave. Have
you seen problems with those values when using RA and DHCP?

Problems? Not something which break functionality. Just that OS
adds two addresses (one l-l from RA and one from DHCPv6) to
/etc/resolv.conf and both addresses represent just one recursive
DNS (that where is running dnsmasq). Which I basically do not like
as there is only one recursive/forwarder DNS server.
Plus also that inconsistency on network that one configuration part
of IPv6 addresses (RA) send different information as another
configuration part (DHCPv6).

Post by Simon Kelley
If so, that's a bug, that needs to be fixed, but otherwise, the
best solution for you may be to configure dnsmasq rather than
patching it.

Ok, configuration option for behaviour which I want is also OK. But
I dot want to hardcode full IPv6 address of machine where is
running dnsmasq as this address can be changed in time (because it
comes from DHCPv6 prefix delegation). Option --dhcp-range has
already fix for it, it accept address suffix with
constructor:<iface>.
But for specifying RDNSS option in dnsmasq it is not possible to
set global IPv6 address which comes from interface...

If you set the RDNSS address to be [::] then dnsmasq should substitute
a global address of the interface, for both DHCPv6 and RA.

Cheers,

Simon.

Pali Rohár

2016-10-02 09:55:51 UTC