Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1940732 - Names on IPv4 network sometimes resolve to IPv6 addresses
Summary: Names on IPv4 network sometimes resolve to IPv6 addresses
Keywords:
Status: CLOSED DUPLICATE of bug 1940715
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-03-19 02:43 UTC by David Sebek
Modified: 2021-03-19 06:58 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-03-19 06:58:44 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description David Sebek 2021-03-19 02:43:41 UTC
Description of problem:
My computer has a link-local IPv6 address, but it only has IPv4 access to the internet. It seems that domain names are sometimes resolved to IPv6 addresses instead of IPv4 adresses. In such cases, commands like dnf and flatpak fail and complain that the network is unreachable.

Version-Release number of selected component (if applicable):
systemd 248 (v248~rc4-1.fc34)

How reproducible:
Run "dnf --refresh upgrade" or "flatpak install XX" on an updated Fedora 34 installation. Sometimes it works, sometimes it fails because it cannot reach the network.

Steps to Reproduce:
1. Connect the computer to a router that supports IPv6 but the connection to the internet provider is IPv4 only.
2. Install Fedora 34 (I used Fedora-Workstation-Live-x86_64-34-20210317.n.0.iso)
3. Install updates (sudo dnf --refresh upgrade).
4. After a reboot, try running "sudo dnf --refresh upgrade" again. If it succeeds, try again in a few minutes until it fails.

Actual results:
"sudo dnf --refresh upgrade" fails with messages like this one:
Errors during downloading metadata for repository 'fedora-modular':
  - Curl error (7): Couldn't connect to server for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-34&arch=x86_64 []
Error: Failed to download metadata for repo 'fedora-modular': Cannot prepare internal mirrorlist: Curl error (7): Couldn't connect to server for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-34&arch=x86_64 []

At the same time, "ping mirrors.fedoraproject.org" returns "Network is unreachable", and I also could not access https://mirrors.fedoraproject.org from Firefox.

Expected results:
DNF and flatpak successfully download repository information and/or packages.

Additional info:
When "dnf --refresh upgrade" is failing, dig outputs:
[david@pc4 ~]$ dig mirrors.fedoraproject.org

; <<>> DiG 9.16.11-RedHat-9.16.11-5.fc34 <<>> mirrors.fedoraproject.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65515
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;mirrors.fedoraproject.org.	IN	A

;; ANSWER SECTION:
mirrors.fedoraproject.org. 48	IN	CNAME	wildcard.fedoraproject.org.
wildcard.fedoraproject.org. 48	IN	A	209.132.190.2
wildcard.fedoraproject.org. 48	IN	A	152.19.134.142
wildcard.fedoraproject.org. 48	IN	A	38.145.60.21
wildcard.fedoraproject.org. 48	IN	A	152.19.134.198
wildcard.fedoraproject.org. 48	IN	A	8.43.85.67
wildcard.fedoraproject.org. 48	IN	A	38.145.60.20
wildcard.fedoraproject.org. 48	IN	A	8.43.85.73
wildcard.fedoraproject.org. 48	IN	A	67.219.144.68
wildcard.fedoraproject.org. 48	IN	A	140.211.169.196
wildcard.fedoraproject.org. 48	IN	A	140.211.169.206

;; AUTHORITY SECTION:
wildcard.fedoraproject.org. 48	IN	AAAA	2605:bc80:3010:600:dead:beef:cafe:fed9
wildcard.fedoraproject.org. 48	IN	AAAA	2610:28:3090:3001:dead:beef:cafe:fed3
wildcard.fedoraproject.org. 48	IN	AAAA	2620:52:3:1:dead:beef:cafe:fed6
wildcard.fedoraproject.org. 48	IN	AAAA	2605:bc80:3010:600:dead:beef:cafe:feda
wildcard.fedoraproject.org. 48	IN	AAAA	2604:1580:fe00:0:dead:beef:cafe:fed1
wildcard.fedoraproject.org. 48	IN	AAAA	2620:52:3:1:dead:beef:cafe:fed7

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Mar 18 21:47:48 EDT 2021
;; MSG SIZE  rcvd: 405

When I run "curl --verbose https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-34&arch=x86_64", it seems to try those IPv6 addresses and fails with "Network is unreachable" because my internet connection is IPv4.

But sometimes everything works just fine. That happens when the output of the dig command does not contain the authoritative section with AAAA records. In such case, dnf works without any problem and the output of dig is:
[david@pc4 ~]$ dig mirrors.fedoraproject.org A

; <<>> DiG 9.16.11-RedHat-9.16.11-5.fc34 <<>> mirrors.fedoraproject.org A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29222
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;mirrors.fedoraproject.org.	IN	A

;; ANSWER SECTION:
mirrors.fedoraproject.org. 221	IN	CNAME	wildcard.fedoraproject.org.
wildcard.fedoraproject.org. 60	IN	A	38.145.60.21
wildcard.fedoraproject.org. 60	IN	A	152.19.134.142
wildcard.fedoraproject.org. 60	IN	A	209.132.190.2
wildcard.fedoraproject.org. 60	IN	A	8.43.85.73
wildcard.fedoraproject.org. 60	IN	A	8.43.85.67
wildcard.fedoraproject.org. 60	IN	A	140.211.169.196
wildcard.fedoraproject.org. 60	IN	A	140.211.169.206
wildcard.fedoraproject.org. 60	IN	A	67.219.144.68
wildcard.fedoraproject.org. 60	IN	A	38.145.60.20
wildcard.fedoraproject.org. 60	IN	A	152.19.134.198

;; Query time: 29 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Mar 18 21:53:51 EDT 2021
;; MSG SIZE  rcvd: 237

Comment 1 David Sebek 2021-03-19 02:54:24 UTC
This seems similar to the last few posts in Bug 1933433

Comment 2 Chris Murphy 2021-03-19 06:58:44 UTC

*** This bug has been marked as a duplicate of bug 1940715 ***


Note You need to log in before you can comment on or make changes to this bug.