Hello,
I wanted to check with the forums first before I submitted a bug report. While using Network Manager with IPv6, I have noticed that the IPv4 entries for DNS are listed first before IPv6. IPv6 DNS really should be the primary before IPv4 when dual stacking.
ee@gundam:~> cat /etc/resolv.conf
search domain.local
nameserver 208.67.222.222
nameserver 208.67.220.220
nameserver 2620:0:ccc::2
I’m using DHCP for IPv4 and Autoconfig for IPv6.
Are you sure this is due to NM?
I could imagine that they are simply stored in the sequence the DHCP server provides them.
Or am I talking nuts now?
In my network configuration, I have two different DHCP servers running on a Cisco router. One is for DHCP and the other is for DHCPv6. My relevent IOS config is as follows:
ip dhcp pool pool172
import all
network 172.20.1.0 255.255.255.0
default-router 172.20.1.1
dns-server 208.67.222.222 208.67.220.220
domain-name domain.local
ipv6 dhcp pool poolv6
dns-server 2620:0:CCC::2
dns-server 2620:0:CCD::2
interface Vlan1
ipv6 nd other-config-flag
ipv6 dhcp server poolv6
This configuration accomplishes the following:
-IPv4 Address is assigned by DHCP
-IPv4 Options are assigned by DHCP
-IPv6 Address is assigned by SLAAC (Autoconfiguration, Router Advertisements, Etc.)
-IPv6 Options are assigned by DHCPv6
Section 4 of RFC 4477 talks about this a bit. It speaks on how it’s up to the client to take the information provided by the two different DHCP servers and applying it correctly. There may be a more relevent RFC on the issue. I’ll see if I can dig it up.
http://www.ietf.org/rfc/rfc4477.txt
I believe it’s up to the DHCP client(s) to interperate what’s given by the servers and put them into the proper place. However, I could be talking crazy too 
I see that you studied it much more then I.
My basic concern was that filing a bug is something when you want to be pretty sure that it is in the product you think (and that it is s bug, not a feature or wrong configuration or so). That is why I asked my silly question.
I guess that that is one of the reasons that you post this here, To get some confirmation that it is a bug and that it is a NM bug. Which is of course a good thing to do.
Now, I wonder what happens when you do not use NM, but test with “traditional with ifup”? I do not know if that is feasable for you, but you could then test if it is NM only, or maybe more general, and thus not an NM bug, but elsewhere (next question is then of course: who is the culprit 
).
On 2013-08-18 16:06, rRobot wrote:
> I believe it’s up to the DHCP client(s) to interperate what’s given by
> the servers and put them into the proper place. However, I could be
> talking crazy too
If it is up to the client to decide, the client may decide to use the
same order as it receives them. That is the impression I have, same as
Henk, about the order: on the cases I had two dns configured on the dhcp
server, I get them in the same order.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
Yeah, IPv6 has turned into main topics of study at the moment. I’d like to do some large scale deployments of it in the near future.
When setting this machine with ifup, I ended up not getting IPv6 DNS at all. Only IPv4. I got my IPv6 address via SLAAC just fine, but when sniffing it out, it doesn’t appear the DHCPv6 client even issued a request.
I had the ifup settings set to Zeroconf + DHCP for Both IPv4 and IPv6.
As said, I am not a real IPv6 expert. But I have a few facts here:
boven:~ # cat /etc/resolv.conf
### /etc/resolv.conf file autogenerated by netconfig!
#
# Before you change this file manually, consider to define the
# static DNS configuration using the following variables in the
# /etc/sysconfig/network/config file:
# NETCONFIG_DNS_STATIC_SEARCHLIST
# NETCONFIG_DNS_STATIC_SERVERS
# NETCONFIG_DNS_FORWARDER
# or disable DNS configuration updates via netconfig by setting:
# NETCONFIG_DNS_POLICY=''
#
# See also the netconfig(8) manual page and other documentation.
#
# Note: Manual change of this file disables netconfig too, but
# may get lost when this file contains comments or empty lines
# only, the netconfig settings are same with settings in this
# file and in case of a "netconfig update -f" call.
#
### Please remove (at least) this line when you modify the file!
search xs4all.nl
nameserver 194.109.6.66
nameserver 194.109.9.99
nameserver 194.109.104.104
boven:~ #
which are IPv4 addresses only. (BTw, I do not use DHCP).
boven:~ # host resolver.xs4all.nl
resolver.xs4all.nl has address 194.109.6.66
resolver.xs4all.nl has address 194.109.9.99
resolver.xs4all.nl has address 194.109.104.104
resolver.xs4all.nl has IPv6 address 2001:888:0:6::66
resolver.xs4all.nl has IPv6 address 2001:888:0:9::99
boven:~ #
and
boven:~ # host 2001:888:0:6::66
6.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.0.0.0.0.0.0.0.8.8.8.0.1.0.0.2.ip6.arpa domain name pointer resolver.xs4all.nl.
boven:~ #
Thus I am a bit at loss why you want an IPv6 addressed DNS server as first and foremost in your resolv.com. IMHO it does not make any difference in the results you get.
(As you see above the same DNS server might have IPv4 ad IPv6 addresses, this may also be the case in your list).
The above is of course not a solution for your sequence ppoblem, but I try to understand what you try to achieve in the hope to learn from it.
General rule of thumb when dual stacking is if a v6 service is available, try v6 first. The goal of IPv6 is to eventually depreciate IPv4 and stop using it all together. Every tool that I’ve used that is dual stack capable will use v6 if it’s available. If you’re truly dual stacking, try a traceroute to Google. It should prefer IPv6. While this setup technically doesn’t cause any issues resolving v6 addresses, that still doesn’t make it correct and follow the general convention of dual stacking.
I can try to dig up a document on this somewhere if it’s needed.
You mean this?
henk@boven:~> /usr/sbin/traceroute www.google.com
traceroute to www.google.com (2a00:1450:4001:806::1012), 30 hops max, 40 byte packets using UDP
1 2001:980:91a0:1:c225:6ff:fe4e:5981 (2001:980:91a0:1:c225:6ff:fe4e:5981) 4.710 ms 3.608 ms 2.514 ms
2 2001:888:1:1001::1 (2001:888:1:1001::1) 4.960 ms 4.979 ms 4.856 ms
3 2001:888:1:4024::1 (2001:888:1:4024::1) 5.207 ms 5.069 ms 5.004 ms
4 0.so-0-2-0.xr1.tc2.xs4all.net (2001:888:1:4000::1) 5.125 ms 0.ge-1-2-0.xr1.sara.xs4all.net (2001:888:1:4005::1) 4.947 ms 0.so-0-2-0.xr1.tc2.xs4all.net (2001:888:1:4000::1) 4.905 ms
5 amsix-router.google.com (2001:7f8:1::a501:5169:1) 5.438 ms 5.677 ms 5.407 ms
6 2001:4860::1:0:4b3 (2001:4860::1:0:4b3) 6.216 ms 2001:4860::1:0:8 (2001:4860::1:0:8) 5.567 ms 2001:4860::1:0:4b3 (2001:4860::1:0:4b3) 5.545 ms
7 2001:4860::8:0:519f (2001:4860::8:0:519f) 14.131 ms 2001:4860::8:0:51a0 (2001:4860::8:0:51a0) 5.491 ms 2001:4860::8:0:519f (2001:4860::8:0:519f) 11.970 ms
8 2001:4860::8:0:5038 (2001:4860::8:0:5038) 12.008 ms 2001:4860::8:0:5039 (2001:4860::8:0:5039) 12.572 ms 12.521 ms
9 2001:4860::1:0:4ca2 (2001:4860::1:0:4ca2) 13.248 ms 13.159 ms 14.652 ms
10 2001:4860:0:1::6eb (2001:4860:0:1::6eb) 12.917 ms 12.569 ms 12.987 ms
11 2a00:1450:8000:3b::3 (2a00:1450:8000:3b::3) 12.375 ms 2a00:1450:4001:806::1f (2a00:1450:4001:806::1f) 12.470 ms 11.917 ms
henk@boven:~>
My thought is “Why should order matter?”
DNS is a service invoked intermittently by the Client and whether IPv4 or IPv6 would be determined by the Client depending on networking configuration in use, not the other way around (eg Get name resolution before determining whether to use an IPv4 or IPv6 address).
So,
Unless I misunderstand how fundamental networking works relating to how DNS lookups are performed, I don’t see how IPv4/IPv6 order is relevant.
TSU
On 2013-08-19 18:46, tsu2 wrote:
> So,
> Unless I misunderstand how fundamental networking works relating to how
> DNS lookups are performed, I don’t see how IPv4/IPv6 order is relevant.
Because the DNS servers are queried in order, and the OP wants the DNS-6
to be listed before the DNS-4.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
Yes, that is what he wants. But apperently the several programs that add the DNS servers are doing that in the sequence they are run. The question is if this is by design. Now the OP thinks that is a bug (and wants to file a bug report somewhere). I doubt it is. My idea is that the answer would be something along the lines of: when you want it different, use a different DHCP server, or talk to the manager of your DHCP server. After all, when you want to use a DHCP server, you have to accept what it serves you.
Maybe I take this a bit easy because I have no problems using IPv4 DNS server addresses to get IIPv6 addresses foremost. And I do not doubt that when I change to the IPv6 addresses of my DNS servers in my /etc/resolv.conf, it will still work as smoothly.
And, I do not use DHCP because I like to manage these things myself, not depending on who is responsible for the DHCP server (well, I partly can configure it, e.g. to reserve a range of the IP addresses I use in the LAN).
On 2013-08-20 10:26, hcvv wrote:
>
> robin_listas;2580269 Wrote:
>> On 2013-08-19 18:46, tsu2 wrote:
>>> So,
>>> Unless I misunderstand how fundamental networking works relating to how
>>> DNS lookups are performed, I don’t see how IPv4/IPv6 order is
>> relevant.
>>
>> Because the DNS servers are queried in order, and the OP wants the
>> DNS-6 to be listed before the DNS-4.
> Yes, that is what he wants. But apperently the several programs that
> add the DNS servers are doing that in the sequence they are run.
Right.
> The
> question is if this is by design. Now the OP thinks that is a bug (and
> wants to file a bug report somewhere). I doubt it is.
I don’t think it is a bug. It might be the wrong design decision, perhaps.
If the RFCs say that it is up to the client to decide the order, well,
the decision is that… first listed is the first one that the system
learns about. And first queried is the first one in the list.
> My idea is that
> the answer would be something along the lines of: when you want it
> different, use a different DHCP server, or talk to the manager of your
> DHCP server. After all, when you want to use a DHCP server, you have to
> accept what it serves you.
>
> Maybe I take this a bit easy because I have no problems using IPv4 DNS
> server addresses to get IIPv6 addresses foremost. And I do not doubt
> that when I change to the IPv6 addresses of my DNS servers in my
> /etc/resolv.conf, it will still work as smoothly.
> And, I do not use DHCP because I like to manage these things myself,
> not depending on who is responsible for the DHCP server (well, I partly
> can configure it, e.g. to reserve a range of the IP addresses I use in
> the LAN).
My LAN router also, apparently, has two different DHCP servers; but I
can not set a DNS for IPv6.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
But,
I wonder whether a machine configured with an IPv6 address would really query an IPv4 DNS server with an IPv4 address using IPv4 networking?
I should think not… and if this is really happening would think this is a fundamental networking error in the OS.
So,
I do agree that for each type of networking (IPv4 vs IPv6) the order of nameservers is important but I highly doubt that listing IPv4 or IPv6 nameservers should be important (at least I assume that should be the case). At worse I would <expect> that the name lookup process might parse the listed nameservers discarding the IPv4 nameservers and not actually attempt to query the nameservers using IPv4 addresses, and this might requires some fractions of seconds and CPU cycles, properly optimized, I would expect the name lookup server list to be cached so repeated lookups might not be necessary (if runtime updates is desired, then hash the file to know whether a change has occurred).
TSU
On 2013-08-20 19:16, tsu2 wrote:
> So,
> I do agree that for each type of networking (IPv4 vs IPv6) the order of
> nameservers is important but I highly doubt that listing IPv4 or IPv6
> nameservers should be important (at least I assume that should be the
> case).
AFAIK Linux simply queries the first DNS server in the list for all
types of addresses (and only one server). When that server fails to give
results, then the second is asked, and only that server. Following
queries will be done to that server only.
At least that is what they explained to me years ago (and my memory can
be mistaken), and it is different of how Windows works when two servers
are listed.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
Exactly. That is when you interprete “fails to give results” as “no connection can be made” (because a negative answer to a an inquiry is also a result). That means that such a failure always involves a timeout (of several minutes) before the second one is tried.
It is not that difficult at all.
As you’ve described, IMO is a fundamental flaw related to the networking service, maybe more specifically nscd or whatever does the lookup and feeds the local nameserver cache.
Even if a machine configured with an IPv6 address tried to do an IPv4 lookup, it should take only a split second to determine no interface is available to make a network connection. Of course if a machine is configured with both IPv4 and IPv6 addresses then every nameserver listed should be looked up.
In this context I would agree that a bugzilla might be warranted.
TSU
I am not quite following you. It may be a misunderstanding about what is what.
What do you mean by “an IPv4 lookup”. A lookup using a DNS server that has an IPV4 address itself, or a gethostbyaddress lookup of a IPv4 address? And are get addressbyhost lookups outside this because you can get then IPv4 addresses, IPv6 addresses or both of them as solutions?
I am not quite following you here either. A system should never use every nameserver listed. It should use the first name server in /etc/resolv.conf. And when that times out it should use the second in the list. But never all.
A machine configured with only IPv4 or IPv6 addresses should never attempt to make a network connection (incl to a DNS server) if the remote address is the same type of addressing. It should not take “minutes” to timeout, only a split second or as long as it takes to try every configured network interface at worse.
Yes, I mis-spoke saying every ns entry should be tried, should have said every entry should be tried in order until one responds, but as I described should not be signiificantly affected by ordering IPv4 vs IPv6. Depends on whether the lookup is built on top of the networking client or side by side.
TSU
TSU
I do still not understand all what you say, but I am with you as you say that a not functioning DNS server can possibly be detected much faster then by a timeout of minutes. When a connection reject is recieved then a very fast switch to the second in the list can be done. That is correct.
I only thought about a timeout because I once experienced that problem. A system became unsuable because it timed out on every DNS request that tried the first server that was down. I exchanged the two entries in /etc/resolv.conf and the system immediatly started to become responsive again and within a short time executed all it’s delayed transactions. So it is something that can happen.