On Wed, 2020-06-03 at 15:35 +0300, Konstantin Gizdov wrote:
For your reference, here's the DNS records I see: $ nslookup search.cpan.org Server: ::1 Address: ::1#53
Non-authoritative answer: search.cpan.org canonical name = dualstack.osff.map.fastly.net. Name: dualstack.osff.map.fastly.net Address: 151.101.2.217 Name: dualstack.osff.map.fastly.net Address: 151.101.66.217 Name: dualstack.osff.map.fastly.net Address: 151.101.130.217 Name: dualstack.osff.map.fastly.net Address: 151.101.194.217 Name: dualstack.osff.map.fastly.net Address: 2a04:4e42::729 Name: dualstack.osff.map.fastly.net Address: 2a04:4e42:200::729 Name: dualstack.osff.map.fastly.net Address: 2a04:4e42:400::729 Name: dualstack.osff.map.fastly.net Address: 2a04:4e42:600::729
$ nslookup search.cpan.org Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: search.cpan.org canonical name = dualstack.osff.map.fastly.net. Name: dualstack.osff.map.fastly.net Address: 151.101.14.217 Name: dualstack.osff.map.fastly.net Address: 2a04:4e42:3::729 On my machine resolve.conf isn't a link. It's a file, so the Internet is accessible when running one or another or the Arch install in a systemd-nspawn container, even without the boot option. Maybe it's related to this, let alone that... # resolvectl status Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found. # systemctl status systemd-resolved ● systemd-resolved.service - Network Name Resolution Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-resolved.service(8) https://www.freedesktop.org/wiki/Software/systemd/resolved https://www.freedesktop.org/wiki/Software/systemd/writing-network-configurat... https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients # systemctl start systemd-resolved # systemctl status systemd-resolved ● systemd-resolved.service - Network Name Resolution Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled) Active: active (running) since Wed 2020-06-03 15:19:54 CEST; 5s ago Docs: man:systemd-resolved.service(8) https://www.freedesktop.org/wiki/Software/systemd/resolved https://www.freedesktop.org/wiki/Software/systemd/writing-network-configurat... https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients Main PID: 428640 (systemd-resolve) Status: "Processing requests..." Tasks: 1 (limit: 9399) Memory: 8.3M CGroup: /system.slice/systemd-resolved.service └─428640 /usr/lib/systemd/systemd-resolved Jun 03 15:19:53 archlinux systemd[1]: Starting Network Name Resolution... Jun 03 15:19:54 archlinux systemd-resolved[428640]: Positive Trust Anchors: Jun 03 15:19:54 archlinux systemd-resolved[428640]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Jun 03 15:19:54 archlinux systemd-resolved[428640]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arp> Jun 03 15:19:54 archlinux systemd-resolved[428640]: Using system hostname 'archlinux'. Jun 03 15:19:54 archlinux systemd[1]: Started Network Name Resolution. # resolvectl status Global LLMNR setting: yes MulticastDNS setting: yes DNSOverTLS setting: no DNSSEC setting: allow-downgrade DNSSEC supported: yes Current DNS Server: 192.168.1.1 DNS Servers: 192.168.1.1 Fallback DNS Servers: 1.1.1.1 9.9.9.10 8.8.8.8 2606:4700:4700::1111 2620:fe::10 2001:4860:4860::8888 DNS Domain: localdomain DNSSEC NTA: 10.in-addr.arpa 16.172.in-addr.arpa 168.192.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa corp d.f.ip6.arpa home internal intranet lan local private test Link 2 (enp3s0) Current Scopes: LLMNR/IPv4 LLMNR/IPv6 DefaultRoute setting: no LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: allow-downgrade DNSSEC supported: yes lines 3-51/51 (END) It doesn't solve the issue, but in the meantime the maintainer fixed the PKGBUILD. There still might be few PKGBUILDs using such a "search-"URL.