DNS returning IPv6 addresses can cause breakage

Networking DNS
1

Hi,

Request

Please don’t return return IPv6 addresses until IPFire supports IPv6.

Details

A number of programs and devices will default to IPv6 communication if an IPv6 address is returned for a DNS query. Some (like Firefox) can be changed to force IPv4 no matter what, while others (like my wife’s phone) can’t.

On my IPFire system I do DoT via recursor01.dns.lightningwirelabs.com. Here is proof of the query results:

user@host:~ $ host ubuntu.com recursor01.dns.lightningwirelabs.com 
Using domain server:
Name: recursor01.dns.lightningwirelabs.com
Address: 81.3.27.54#53
Aliases: 

ubuntu.com has address 91.189.88.180
ubuntu.com has address 91.189.88.181
ubuntu.com has IPv6 address 2001:67c:1360:8001::2b
ubuntu.com has IPv6 address 2001:67c:1360:8001::2c
ubuntu.com mail is handled by 10 mx.canonical.com.
user@host:~ $

I eventually gave up trying to force one of my Raspberry PI installations to use iPv4 for updates and now have to expose it to the Internet to do that — really not ideal.

Please just drop IPv6 DNS results. They have zero use behind an IPFire firewall at the moment.

:sunglasses:
John

1 Like
2

My current config:

image
image975×662 52.6 KB

1 Like
3

Hello John Botha b3taman,
Same behaviour here.
I’ve checked /etc/unbound/unbound.conf and it do contain the do-ip6: no as explained in unbound’s documentation, but clients+IPFire are still receiving AAAA values.
Did you solve the problem ?

4

Hallo @y96m7xoa9p

Welcome to the IPFire community.

Could you give some more details about what is breaking due to the ipv6 address.

5

Hello Adolf Belka, and thanx for reading,

  • IPFire’ red interface is on a IPv4 only network.
  • Clients of IPFire receive IPv4 addresses via DHCP and a “preferred” magically IPv6 (OS?) forged one.
  • Clients of IPFire receive DNS name resolution as IPv4 and/or IPv6.
  • Clients of IPFire try to access some hosts via IPv6, but it doesn’t work (–> here is the real problem).

The directions I’m searching now are :

  • Force IPv4 ONLY on client OS. While it is a viable solution for desktops (it works), it isn’t possible for laptops that go here and there and have to deal with other network configs.
  • Force IPv4 ONLY from DHCP server ? Didn’t find anything talking about that.
  • Remove AAAA answers from DNS queries (from IPFire as resolver, or from IPFire as server) ? That’s why I’m here…

Must say that I was wrong in my previous comment : the do-ip6: no is only forcing unbound to talk on IPv4, but doesn’t affect results that may be on IPv4, IPv6 or both.

There seems to be a solution (EDIT: I put a wrong link - changed) but it does break DNSSEC. So I’m almost sure it won’t work with IPFire, and didn’t read more…

I tried to use that post, but it didn’t give me much more results for now. What I did is adding
/etc/unbound/local.d/myconfig.conf
filled with

server:
   verbosity: 1
   log-queries: yes
#          Prints one line per query to the log, with the log timestamp and
#          IP address, name, type and class.  Default is no.  Note that  it
#          takes time to print these lines which makes the server (signifi-
#          cantly) slower.  Odd  (nonprintable)  characters  in  names  are
#          printed as '?'.
   log-replies: yes
#          Prints one line per reply to the log, with the log timestamp and
#          IP address, name, type, class, return  code,  time  to  resolve,
#          from  cache  and  response  size.   Default is no.  Note that it
#          takes time to print these lines which makes the server (signifi-
#          cantly)  slower.   Odd  (nonprintable)  characters  in names are
#          printed as '?'.
   log-tag-queryreply: yes
#          Prints  the  word  'query'  and  'reply'  with  log-queries  and
#          log-replies.   This makes filtering logs easier.  The default is
#          off (for backwards compatibility).

#  https://unix.stackexchange.com/questions/444282/how-to-disable-ip6-lookups-in-unbound
   local-zone: "ip6.arpa." refuse

but queries still answer with A and AAAA mixed.

Do you have any leads to follow?

6

Hallo V V

What clients are trying to access ipv6 and not trying ipv4 when it fails and what url or application is giving the problem result?

I have never had this type of issue. I have one system running Ubuntu and the rest all run Arch Linux and there has never been a problem trying to access a site due to ipv6 being used.
I would like to understand if it is really with an ipv6 address being given out or if there is some other underlying issue here.

Do you have any logs showing what is happening with the problem communications?

Yes, if it breaks dnssec then I am also sure it will stop dns working on IPFire

7

Debian’s apt ? and you’ll find hundreds of posts talking about that.

8

OK. There must be lots of people on this forum using apt on their client computers so you should get feedback on how they overcame the problem.

9

Hi all,

skimming through this thread, I think there are two implicit assumptions which require some clarification:

do-ip6: no does not have any impact on the actual DNS queries, but on the way these are asked - in this case, only via IPv4, never via IPv6. As stated in the man page:

do-ip6:

Enable or disable whether ip6 queries are answered or issued. Default is yes. If disabled, queries are not answered on IPv6, and queries are not sent on IPv6 to the internet nameservers. With this option you can disable the ipv6 transport for sending DNS traffic, it does not impact the contents of the DNS traffic, which may have ip4 and ip6 addresses in it.

This explains why AAAA DNS queries are still processed and answered despite do-ip6: no is set.

Second, the local-zone directive describe here won’t solve the problem, since *.ip6.arpa. is the namespace used for IPv6 reverse lookups, similar to *.in-addr.arpa. for IPv4. Refusing all queries does not have any effect on normal AAAA queries as well.

In general, I agree with @bonnietwin: This is out of scope for IPFire.

While IPFire in particular and any network security component in general cannot make broken things work again, we can at least try to mitigate the crappiness of a lot of cheap/misconfigured/misdesigned clients out there - to some extend. At some point, the side-effects and problems introduced by such fixes are greater than their benefit. Also, they reduce the pressure on device/client vendors to get their sh*t fixed, and not bring obviously broken hard- or software to the market, and let the internet community deal with it.

True, IPv6 is becoming more and more common. However, there will always be situations where it does not work - either because a network does not have IPv6 connectivity, or the destination’s IPv6 address is unreachable while IPv4 works (happens a lot), or because there are temporary IPv6 routing/peering issues in between, etc., etc., etc.

Bringing devices on the market which fail to work in such situations is - as @ms put it once - a masterclass of putting your head into the sand.

Therefore: Please complain to your vendor, whenever it’s a company or the apt developers. As much as we would like to do, we cannot save the world at or with IPFire. :slight_smile:

Thanks, and best regards,
Peter Müller

2 Likes
10

This is a problem for the operating system. Generally DNS transfers lots of different information - if you can reach the host you asked for is not a problem that DNS should solve.

In fact, you have an operating system that first of all should know whether it is has IPv6 connectivity, IPv4 connectivity, or both. If it has both, it should implement Happy Eyeballs.

Firefox does that for instance, so this rather looks like a bug than a design problem.

2 Likes
11

A post was split to a new topic: After to upgrade to release 180, pakfire does not work