IPv6 DNS Resolver with new Android phone failing

[bigtfromaz]

After purchasing a new phone I began to have problems with internet access from the phone. After a lot of rummaging I have determined that when the phone see IPv6 is available it seems to want to use it wherever possible.

I am using SLAAC and have the DHCPv6 server disabled for the moment. Cox is providing a single 64 bit prefix using prefix delegation. Their prefix changes way more frequently than it should. As an aside, I understand the reason for dynamic addresses in IPv4 but see no reason why ISPs continue the practice in IPv6.

My LAN (hn1) adapter in BSD has been configured with the the static address fe80::1:1 . That string does not appear in the pfSense configuration file.

The phone has been given fe80::1:1 as the IPv6 gateway address (by SLAAC) and as the DNS server (from me setting the DNS server in DHCPv6 RA settings. I chose to supply that address because I know it won't change.

So that the backdrop. Here is the issue:

When I run dnslookup from a Windows machine as follows, it fails:

ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

nslookup myhost.mydomain.com fe80::1:1
Server:  UnKnown
Address:  fe80::1:1

*** UnKnown can't find myhost.mydomain.com: Query refused

If I point to SLAAC address for the LAN interface (rather than fe0::1:1) It works:

ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

nslookup myhost.mydomain.com 2600:8800:1:e101:215:5dff:fe8b:6204

Server:  VGateway.obj-ex.com
Address:  2600:8800:1:e101:215:5dff:fe8b:6204

Non-authoritative answer:
Name:    hebertraid.obj-ex.com
Address:  192.168.176.60

The DNS Resolver is set to listen on all interfaces. Forwarding mode is disabled. The DNS Forwarder is disabled.

This is either a configuration issue, or a bug. As far as I can tell, the firewall rules are OK.

Any thoughts?

[Derelict]

You should not be being given the link-local address as a DNS server. You should be being given the interface address.

@bigtfromaz said:
The phone has been given fe80::1:1 as the IPv6 gateway address (by SLAAC) and as the DNS server (from me setting the DNS server in DHCPv6 RA settings. I chose to supply that address because I know it won't change.

That is a misconfiguration.

You can't use a link-local address like fe80::1:1 as a DNS server. You would have to use fe80::1:1%iface. There is no facility in SLAAC to give that extra interface information as the RDNSS field in the router advertisement is only 128 bits. Set nothing there. The RA will track the interface, giving the correct DNS server to the network clients.

Cox Las Vegas does IPv6 very well. They PD a /56 and honor the DUID. Recently, the PD even followed me when I moved somewhere else in the same service area. It hasn't changed for months.

Not sure why yours is not behaving nicely.

[bigtfromaz]

@Derelict Thank you for the reply. I took your advice and it's now assigning a routable address but I still have a problem.

I am using DNS Resolver with the default selection of "All" for incoming interfaces. My confusion arose from this snippet:

That lead me to believe the resolver would respond to requests to the "LAN Link-local" which is fe80::1:1. I see its failure to do so as a bug. Either that or "LAN Link-local" should be removed from the list-box.

I called Cox. They told me that residential service in Phoenix gets one 64-bit prefix. The person I talked to didn't know anything about DUIDs or their prefix assignment policies. Using Dynamic IP IPv6 prefixes in this use case creates an artificial need. Just guessing but, the shortage of IPv4 addresses motivated people to purchase business level service. ISPs don't want to give that up just because IPv6 eliminates the root cause. The righteous way would be for them to assign prefixes to accounts and define which DUIDs gets them. This way people can change routers or adapters without their whole network changing.

PS I am am working on ways to create safe consumer-level peer-to-peer apps without corporations in the middle and dynamic IP is an impediment.

[Derelict]

It is not a bug. You can't use a link local address as a DNS resolver for reasons already explained.

[bigtfromaz]

@Derelict Ok. Then why is are Link-Locals in the selection list? And, shouldn't the RA configuration screen reject fe80:: in the DNS Server text boxes?

[Derelict]

The probably should not be. But you can only prevent so much foot-shooting.

[bigtfromaz]

@Derelict The number of ways to shoot one's self in the foot is nearly infinite. However it's not foot-shooting when the UI presents something that can never be correct. So we can agree to disagree. I think there needs to be an edit and the list-box filtered.

Normally when I bring up a problem I would offer to be part of the solution. However I have rummaged around in your source code and my skill set is elsewhere. More of an apps for end-users guy (C#, Java, C++ and Xamarin) where I can't allow people to shoot themselves in the foot.

[Derelict]

macOS, at least, seems to do the right thing:

nameserver[0] : fe80::1:1%vlan0

Not sure whether that was received from an RA or DHCP since I am running that segment in Assisted mode (both).

You will also have to specifically pass link-local traffic (fe80::/10) to fe00::1:1 tcp/udp port 53 and add fe80::/10 to an unbound access list.

Link-local is not considered to be LAN Net so none of it is added automatically when you pass from LAN Net.