Closed Bug 884209 Opened 12 years ago Closed 12 years ago

for DNS, when IP6 address is specified for server, IP4 is used

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: LOFK, Unassigned)

References

(Blocks 1 open bug)

Details

In the case where only an IPV6 address is specified for the server to use in resolving DNS queries; the query is then done over the corresponding IPV4 address. This has only been tested for the local host addresses on the loopback device on GNU/Linux. In this test, In /etc/resolv.conf , the only DNS server is given as nameserver 00:00:00:00:00:00:01 . That remains static. Packet sniffing the traffic shows that DNS queries are done over IPV4. If the DNS server is unreachable by IPV4, this fails. Linux, by default will bridge IPV4 connections to IPV6. Transparent bridging of connections of different protocols is a security issue, which is why at least 1 BSD variety does not perform it by default. The behaviour of bridging IPV4 to IPV6 on Linux is determined by sysctl net.ipv6.bindv6only A value of 1 will cause listening IPV6 sockets to only receive IPV6 connections. A value of 0 will cause listening IPV6 sockets to receive IPV4 connections as well as IPV6. The value can be set by the utility `sysctl` or in configuration files read at system start up time. When there is no IPV4 address for the route, name resolution also fails. It does not fail immediately, but instead times out. This was tested with about:config settings set to default values network.dns.disableIPv6=false (default) network.dns.ipv4OnlyDomains="" (empty. default.) network.proxy.socks_remote_dns=false (default) I wished to test another application using NSPR and so tested the Chromium browser. It shows the same behaviour. Consider whether Bug 79242 is related. This was tested with the following builds: FireFox nightly trunk FireFox 21.0 IceWeasel 20.0 The version of LibNSPR installed on the system is 4.10.
Blocks: IPv6
00:00:00:00:00:00:01 is not a valid IPv6 address, it's missing a hextet. Marking invalid, please reopen if you see it using a valid IPv6 address.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
I have corrected the address for the resolver, retested, and verified that this report is invalid. I tested both with and without 127.0.0.1 as a loopback address.
You need to log in before you can comment on or make changes to this bug.