Skip to main content ↑ ↓
Topic: Trouble with DNS on fresh Artix Base install OpenRC, connmand, (dhcpd?) (Read 4476 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Trouble with DNS on fresh Artix Base install OpenRC, connmand, (dhcpd?)

Reply #15 –
Quote from: lotuskip – on
1. Use the actual IP of the server to work around DNS issues, something like
Code: [Select]
pacman-key --keyserver 195.201.47.43 --recv-keys 034F7776EF5E0C613D2F7934D29FBD5F93C0CFC3
(that's the IP for keys.openpgp.org; note that pacman-key is just a wrapper for gpg)

this works! But so does
Code: [Select]
pacman-key --keyserver keys.openpgp.org --recv-keys 034F7776EF5E0C613D2F7934D29FBD5F93C0CFC3
Interestingly though:
Code: [Select]
 gpg --keyserver keys.openpgp.org --recv-keys 034F7776EF5E0C613D2F7934D29FBD5F93C0CFC3
does NOT work. So maybe --keyserver is entirely removed in gpg now and it's falling back on the faulty config. In which case the config for gpg which has the correct nameservers is possibly not being used by base gpg or by yay, because the one I've been editing is /etc/pacman.d/gnupg/gpg.conf as per the recommendation in this thread. I don't know if there even are any other gpg configs on my system though, I looked through /etc and couldn't find any. But also pacman-key must not be correctly using (or I haven't written it right) the config in /etc/pacman.d/gnupg/gpg.conf because it doesn't work without a specific --keyserver supplied.

Quote from: gripped – on
How do you connect to the internet?
If you haven't installed any firewall, messed with iptables, or changed the connman configuration then your system blocking the traffic to the keyserver, in at least one direction, seems improbable but one way to help rule it out would be to test the gpg commands after booting from the installation iso. If they don't work it's your network. If they do it's your system.
Yeah I don't think I've messed with anything in iptables and I haven't installed any firewalls. I might've edited some connman thing at some point but quite honestly I think I changed it back and I don't think it changed anything when I did it.

I booted from the installation iso and tried the commands that have worked and the ones that haven't worked. The behavior was basically the same. Keep in mind I was on ethernet but it was the same network. The pacman-key commands above worked, but when I replaced the ip with keys.openpgp.org it no longer worked. gpg was just as faulty as it is on my current install, same errors and everything.

Quote from: gripped – on
Also connecting to the internet in a different way. For instance making sure my phone was not connected to my local wifi and using it to connect to the internet either by wifi hotspot or usb or bluetooth etc.
Hotspot has the same behavior as my normal wifi connction, Same errors and same successes.

Quote from: ####### – on
e-failed-server-indicated-a-failure
I am not 100% sure without knowing your setup, but resolv.conf is probably getting regenerated every time you boot or connect if you are using dhcp and not a manually configured static connection. The file creation time should confirm this, so if you make a backup too you can certainly experiment with the content quite safely, but check any mods are not overwritten.
Usually if you don't configure your own nameserver, this defaults to whatever your router is using for it's DNS nameserver I think.

yes it's definitely getting regenerated every time, it does seem to be some default DNS nameserver (127.0.0.1) that probably is inaccurate. But that's all resolv.conf has in it... just that incorrect nameserver (aswell as ::1). However DNS works for like normal things, I can ping servers and everything normal, it's just this gpg thing that kicks something into not working.

Please let me know if there's any more information that could be useful which I could provide.

Re: Trouble with DNS on fresh Artix Base install OpenRC, connmand, (dhcpd?)

Reply #16 –
Quote from: Ducky – on
because the one I've been editing is /etc/pacman.d/gnupg/gpg.conf as per the recommendation in this thread
No the one you (may)need to edit for the gpg keys which you need to build packages with yay is:
~/.gnupg/gpg.conf
which probably doesn't exist yet but you can create it.

Your dns sounds flaky.
127.0.0.1 is probably connman
You can find, I think , the dns server connman is using with
Code: [Select]
grep -r Nameservers /var/lib/connman/
which is probaby your router.
So maybe log into your router and see if you can edit the dns server.
Because especially if the router is automatically using the ISP provided dns server then that could be your issue as they sometimes block stuff or sometimes they are just shit.

As a workaround  setup ~/gnupg/gpg.conf to use a keyserver that works for you either by domain or ip whichever works.

Re: Trouble with DNS on fresh Artix Base install OpenRC, connmand, (dhcpd?)

Reply #17 –
How about setting up the network correctly first before going onto the next step, which is not with conman but with dhcpcd


and visually check the /etc/resolve file

until that is stable, you are shooting live fish in the bathtub.  The fish escape but the tub is destroyed.  There are too many moving parts here to debug it, and gentleman posing the inquiry doesn't really have enough background to explain his situation clearly..

they need bind for dig, dhcpcd, the network settings in /etc/conf.d/net set correctly, the output for dmesg, ip ro, and ip -4 add


Until he can ping a computer outside his network, he is just blind.

Re: Trouble with DNS on fresh Artix Base install OpenRC, connmand, (dhcpd?)

Reply #18 –
Quote from: gripped – on
No the one you (may)need to edit for the gpg keys which you need to build packages with yay is:
~/.gnupg/gpg.conf
which probably doesn't exist yet but you can create it.
Ok I edited that gpg.conf and it works but only if I use the ip of the keyserver, which is not ideal obviously.

Quote from: gripped – on
Your dns sounds flaky.
127.0.0.1 is probably connman
You can find, I think , the dns server connman is using with
Code: [Select]
grep -r Nameservers /var/lib/connman/
which is probaby your router.
Ran grep, returned nothing. Pretty sure you're right about that command though, so I think I have no nameservers set up?
Quote from: gripped – on
So maybe log into your router and see if you can edit the dns server.
Because especially if the router is automatically using the ISP provided dns server then that could be your issue as they sometimes block stuff or sometimes they are just shit.
Logged into the router, it says it's using the ISP provided dns, and it could be that but I'd really like to verify that that's actually the issue. I've been using arch based linux on this network for 3 years now and have had no similar issues. I feel like it's probably my system and I'd rather my system be resilient to any network rather than tailoring the network to my system because it's a laptop.

Quote from: mrbrklyn – on
and visually check the /etc/resolve file
contents below:
Code: [Select]
# Generated by Connection Manager
nameserver ::1
nameserver 127.0.0.1

Quote from: mrbrklyn – on
they need bind for dig, dhcpcd, the network settings in /etc/conf.d/net set correctly, the output for dmesg, ip ro, and ip -4 add
Code: [Select]
 cat /etc/conf.d/net | grep -v '^[[:space:]]*#'
returns nothing, so that file isn't doing anything

what specifically do you want from dmesg? I'm not just going to send that entire dump here.

ip ro:
Code: [Select]
default via 172.16.0.1 dev wlan0
127.0.0.0/8 via 127.0.0.1 dev lo
172.16.0.0/24 dev wlan0 proto kernel scope link src 172.16.0.81
172.16.0.1 dev wlan0 scope link

ip -4 add
Code: [Select]
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 172.16.0.81/24 brd 172.16.0.255 scope global wlan0
       valid_lft forever preferred_lft forever

Please let me know what else to provide.

Re: Trouble with DNS on fresh Artix Base install OpenRC, connmand, (dhcpd?)

Reply #19 –
Your DNS is just broken
Run dhcpcd

if it doesn't work, your dhcpd server on the router is broken


Also

ping 172.16.0.1
and then ping
ping 8.8.8.8

Code: [Select]
flatbush:[ruben]:~$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  home2.mrbrklyn.com (10.0.0.37)  0.518 ms  0.480 ms  0.417 ms
 2  ool-60391751.static.optonline.net (96.57.23.81)  2.459 ms  3.092 ms  3.917 ms
 3  10.240.176.237 (10.240.176.237)  15.089 ms  16.294 ms  16.654 ms
 4  433be036.cst.lightpath.net (67.59.241.54)  16.850 ms  17.391 ms  17.426 ms
 5  ool-4353dd1e.dyn.optonline.net (67.83.221.30)  24.554 ms  24.685 ms ool-4353dd1c.dyn.optonline.net (67.83.221.28)  23.487 ms
 6  63.142.20.0 (63.142.20.0)  26.115 ms 64.15.4.108 (64.15.4.108)  23.158 ms 451be070.cst.lightpath.net (65.19.99.112)  22.924 ms
 7  64.15.1.153 (64.15.1.153)  25.746 ms  15.168 ms  20.065 ms
 8  * * *
 9  * * *
10  dns.google (8.8.8.8)  23.761 ms  24.530 ms  23.820 ms

If those don't work, your routers is completely either broken, or it is intentionally blocking you.

You want to look at your dmesg results to see that your wireless is working

Quote
I booted from the installation iso and tried the commands that have worked and the ones that haven't worked. The behavior was basically the same. Keep in mind I was on ethernet but it was the same network.
maybe not... put it back on the wire.

Re: Trouble with DNS on fresh Artix Base install OpenRC, connmand, (dhcpd?)

Reply #20 –
If it was the same from the iso it's not your system it's the network. imho.
Try another name server on the router. Clouldflare's 1.1.1.1 and Google's 4.4.4.4 are not ideal in the long run but are fine while you get it working. Then find a more privacy respecting name server.
Your ISP's dns server is the worst option. Well it is in my country. They block stuff and they have to record everything by law.

Re: Trouble with DNS on fresh Artix Base install OpenRC, connmand, (dhcpd?)

Reply #21 –
Quote from: mrbrklyn – on
Your DNS is just broken
Run dhcpcd

dhcpcd is running, same behavior.

Quote from: mrbrklyn – on
if it doesn't work, your dhcpd server on the router is broken
I run servers off of this network which use dhcpd and I've never had issues, idk if that's much information but I don't even know how I would go about fixing something as contained as that.

Quote from: mrbrklyn – on
ping 172.16.0.1
and then ping
ping 8.8.8.8
both of these ping fine, no issues.

Quote from: mrbrklyn – on
Code: [Select]
flatbush:[ruben]:~$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  home2.mrbrklyn.com (10.0.0.37)  0.518 ms  0.480 ms  0.417 ms
 2  ool-60391751.static.optonline.net (96.57.23.81)  2.459 ms  3.092 ms  3.917 ms
 3  10.240.176.237 (10.240.176.237)  15.089 ms  16.294 ms  16.654 ms
 4  433be036.cst.lightpath.net (67.59.241.54)  16.850 ms  17.391 ms  17.426 ms
 5  ool-4353dd1e.dyn.optonline.net (67.83.221.30)  24.554 ms  24.685 ms ool-4353dd1c.dyn.optonline.net (67.83.221.28)  23.487 ms
 6  63.142.20.0 (63.142.20.0)  26.115 ms 64.15.4.108 (64.15.4.108)  23.158 ms 451be070.cst.lightpath.net (65.19.99.112)  22.924 ms
 7  64.15.1.153 (64.15.1.153)  25.746 ms  15.168 ms  20.065 ms
 8  * * *
 9  * * *
10  dns.google (8.8.8.8)  23.761 ms  24.530 ms  23.820 ms
I get a similar output, ending in dns.google.

Quote from: mrbrklyn – on
You want to look at your dmesg results to see that your wireless is working
I don't see any errors or warnings related to wireless.

Quote from: mrbrklyn – on
maybe not... put it back on the wire.
what?

Quote from: gripped – on
If it was the same from the iso it's not your system it's the network. imho.
Try another name server on the router. Clouldflare's 1.1.1.1 and Google's 4.4.4.4 are not ideal in the long run but are fine while you get it working. Then find a more privacy respecting name server.
Your ISP's dns server is the worst option. Well it is in my country. They block stuff and they have to record everything by law.
I'm in the U.S. so the isp dns is evil and traced obviously, but they normally won't block this kind of stuff on my isp. Anyways I changed the DNS servers to 1.1.1.1 and 8.8.8.8 and it didn't change the gpg behavior. Is there something more revealing I could use rather than just running gpg commands to test my DNS? In all scenarios I can ping just about every server I can think of, so using my DNS for normal things seems to work fine. It's like gpg itself is failing to use the DNS.

Re: Trouble with DNS on fresh Artix Base install OpenRC, connmand, (dhcpd?)

Reply #22 –
Quote from: Ducky – on
In all scenarios I can ping just about every server I can think of, so using my DNS for normal things seems to work fine. It's like gpg itself is failing to use the DNS.
If you can do that with both domain names and ip addresses, and the same is true of an iso, then either it's a problem with the wider network or the iso is broken and creating broken systems.
As no other reports of this issue have been seen yet it's probably the former.
It might not be dns ? Try traceroute to the domain as well.
A while ago some people were unable to access the Artix archives (i think it was that) because their traffic was getting blocked along the route.

Other than that idk.

Re: Trouble with DNS on fresh Artix Base install OpenRC, connmand, (dhcpd?)

Reply #23 –
I did a bit more digging on my own and I'm pretty sure it's not DNS. I think it's instead that TLS is failing. I can make any keyserver work if I specify for it to use hkp:// instead of hkps://. My CA certs seem to be ok and my config files are as follows:

~/.gnupg/dirmngr.conf
Code: [Select]
verbose
log-file /tmp/dirmngr.log
disable-ipv6
debug ipc,network,gnutls
hkp-cacert /etc/ssl/certs/ca-certificates.crt

~/.gnupg/gpg.conf
Code: [Select]
keyserver-options auto-key-retrieve
keyserver hkp://keyserver.ubuntu.com:80

With this config it works, but as soon as I try to use hkps (default) it fails. Is there anything I might be able to do about this? dirmngr errors are extremely unhelpful:

Code: [Select]
DBG: chan_6 -> OK Dirmngr 2.4.7 at your service, process 7128
connection from process 7126 (1000:1000)
DBG: chan_6 <- GETINFO version
DBG: chan_6 -> D 2.4.7
DBG: chan_6 -> OK
DBG: chan_6 <- KEYSERVER --clear hkps://keys.openpgp.org // btw this fails with any server using hkps://. not just openpgp
DBG: chan_6 -> OK
DBG: chan_6 <- KS_GET -- 0x034F7776EF5E0C613D2F7934D29FBD5F93C0CFC3
command 'KS_GET' failed: Server indicated a failure <Unspecified source>
DBG: chan_6 -> ERR 219 Server indicated a failure <Unspecified source>
DBG: chan_6 <- BYE
DBG: chan_6 -> OK closing connection

Re: Trouble with DNS on fresh Artix Base install OpenRC, connmand, (dhcpd?)

Reply #24 –
Quote from: Ducky – on
Quote from: mrbrklyn – on
Your DNS is just broken
Run dhcpcd

dhcpcd is running, same behavior.

Quote from: mrbrklyn – on
if it doesn't work, your dhcpd server on the router is broken
I run servers off of this network which use dhcpd and I've never had issues, idk if that's much information but I don't even know how I would go about fixing something as contained as that.

Quote from: mrbrklyn – on
ping 172.16.0.1
and then ping
ping 8.8.8.8
both of these ping fine, no issues.

Quote from: mrbrklyn – on
Code: [Select]
flatbush:[ruben]:~$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  home2.mrbrklyn.com (10.0.0.37)  0.518 ms  0.480 ms  0.417 ms
 2  ool-60391751.static.optonline.net (96.57.23.81)  2.459 ms  3.092 ms  3.917 ms
 3  10.240.176.237 (10.240.176.237)  15.089 ms  16.294 ms  16.654 ms
 4  433be036.cst.lightpath.net (67.59.241.54)  16.850 ms  17.391 ms  17.426 ms
 5  ool-4353dd1e.dyn.optonline.net (67.83.221.30)  24.554 ms  24.685 ms ool-4353dd1c.dyn.optonline.net (67.83.221.28)  23.487 ms
 6  63.142.20.0 (63.142.20.0)  26.115 ms 64.15.4.108 (64.15.4.108)  23.158 ms 451be070.cst.lightpath.net (65.19.99.112)  22.924 ms
 7  64.15.1.153 (64.15.1.153)  25.746 ms  15.168 ms  20.065 ms
 8  * * *
 9  * * *
10  dns.google (8.8.8.8)  23.761 ms  24.530 ms  23.820 ms
I get a similar output, ending in dns.google.

Quote from: mrbrklyn – on
You want to look at your dmesg results to see that your wireless is working
I don't see any errors or warnings related to wireless.

Quote from: mrbrklyn – on
maybe not... put it back on the wire.
what?

Quote from: gripped – on
If it was the same from the iso it's not your system it's the network. imho.
Try another name server on the router. Clouldflare's 1.1.1.1 and Google's 4.4.4.4 are not ideal in the long run but are fine while you get it working. Then find a more privacy respecting name server.
Your ISP's dns server is the worst option. Well it is in my country. They block stuff and they have to record everything by law.
I'm in the U.S. so the isp dns is evil and traced obviously, but they normally won't block this kind of stuff on my isp. Anyways I changed the DNS servers to 1.1.1.1 and 8.8.8.8 and it didn't change the gpg behavior. Is there something more revealing I could use rather than just running gpg commands to test my DNS? In all scenarios I can ping just about every server I can think of, so using my DNS for normal things seems to work fine. It's like gpg itself is failing to use the DNS.


Your DNS is almost guaranteed to be messed up.  And /etc/resolv of 127.0.0.1 means you are your own DNS server.  Unless you are running a caching DNS server like unbound, that is almost guaranteed to be not right.  Since you can ping outside the gateway, that means the routing information is correct.

EXACTLY what is your /etc/resolv after using DHCPCD on the WIRE.

It doesn't help to jump around like a rabbit.  Fix the DNS first.  And the wifi and the wire can be different.  In fact, it is often different networks.

I want to see the routing while on the WIRE and the routing while on the wireless and the /etc/resolve in both cases so we can get to the bottom of this.

You can fix this quickly if you really have zero patience by hand writing the DNS to point to 1.1.1.1 .   But it is not ideal.

BTW - if that doesn't work you have some kind of packet filtering going on within the gateway (or locally).

 

Re: Trouble with DNS on fresh Artix Base install OpenRC, connmand, (dhcpd?)

Reply #25 –
Quote
Logged into the router, it says it's using the ISP provided dns, an

FWIW, I don't know what that means.  DNS entries are dot quads (or maybe IP6) not secret messages.

Please help us to help you.  Simplify the networking problem first.  Fix one thing at a time.

Re: Trouble with DNS on fresh Artix Base install OpenRC, connmand, (dhcpd?)

Reply #26 –
this is what it looks like when the ethernet or network is inhently broken on the hardware level in dmesg

Quote
[1801734.458682] r8169 0000:03:00.0 eth1: link up
[1801770.175376] r8169 0000:03:00.0 eth1: link down
[1801772.470348] r8169 0000:03:00.0 eth1: link up
[1801831.468479] r8169 0000:03:00.0 eth1: link down
[1801833.834295] r8169 0000:03:00.0 eth1: link up
[1801834.341637] r8169 0000:03:00.0 eth1: link down
[1801837.105939] r8169 0000:03:00.0 eth1: link up

or like this
Quote
[1704965.044460] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[1705001.156645] r8169 0000:06:00.0 eth0: Link is Down
[1705003.477366] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[1705060.541493] r8169 0000:06:00.0 eth0: Link is Down
[1705062.863310] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[1705063.920784] r8169 0000:06:00.0 eth0: Link is Down
[1705066.407702] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[1705475.160681] r8169 0000:06:00.0 eth0: Link is Down
[1705479.253604] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[1705520.168595] r8169 0000:06:00.0 eth0: Link is Down
[1705522.679159] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[1705550.962098] r8169 0000:06:00.0 eth0: Link is Down
[1705553.366772] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[1705589.030633] r8169 0000:06:00.0 eth0: Link is Down
[1705591.298389] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[1705650.200821] r8169 0000:06:00.0 eth0: Link is Down
[1705652.631635] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[1705653.139648] r8169 0000:06:00.0 eth0: Link is Down
[1705655.861461] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx

Re: Trouble with DNS on fresh Artix Base install OpenRC, connmand, (dhcpd?)

Reply #27 –
Quote from: mrbrklyn – on
EXACTLY what is your /etc/resolv after using DHCPCD on the WIRE.
On ethernet ("Wire")
Code: [Select]
# Generated by dhcpcd from eth0.dhcp
# /etc/resolv.conf.head can replace this line
nameserver 172.16.0.1
# /etc/resolv.conf.tail can replace this line

On wifi
Code: [Select]
# Generated by dhcpcd from wlan0.dhcp
# /etc/resolv.conf.head can replace this line
nameserver 172.16.0.1
# /etc/resolv.conf.tail can replace this line

they're the same.


Quote from: mrbrklyn – on
I want to see the routing while on the WIRE and the routing while on the wireless and the /etc/resolve in both cases so we can get to the bottom of this.
I ran the same tests as I did above in this thread. I got identical results for both. Check above posts for outputs.

Quote from: mrbrklyn – on
You can fix this quickly if you really have zero patience by hand writing the DNS to point to 1.1.1.1 .   But it is not ideal.
Did this above. Got the exact same errors as I have been reporting.

Quote from: mrbrklyn – on
FWIW, I don't know what that means.  DNS entries are dot quads (or maybe IP6) not secret messages.

Please help us to help you.  Simplify the networking problem first.  Fix one thing at a time.

This is a fairly simple thing that even I understand. The DNS server my system uses is provided by the router. My DNS requests get sent to the router to be sent to the DNS server. My router allows the user to enter DNS servers, but can also request DNS servers from my ISP which are subject to change. By default it is set to receive the DNS server from the ISP. I manually set it above to 1.1.1.1 and 8.8.8.8 for testing and received the same errors as I continue to report. The router's interface does not make the DNS server provided by the ISP readily visible.

Quote from: mrbrklyn – on
this is what it looks like when the ethernet or network is inhently broken on the hardware level in dmesg

Quote
[1801734.458682] r8169 0000:03:00.0 eth1: link up
[1801770.175376] r8169 0000:03:00.0 eth1: link down
[1801772.470348] r8169 0000:03:00.0 eth1: link up
[1801831.468479] r8169 0000:03:00.0 eth1: link down
[1801833.834295] r8169 0000:03:00.0 eth1: link up
[1801834.341637] r8169 0000:03:00.0 eth1: link down
[1801837.105939] r8169 0000:03:00.0 eth1: link up

or like this
Quote
[1704965.044460] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[1705001.156645] r8169 0000:06:00.0 eth0: Link is Down
[1705003.477366] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[1705060.541493] r8169 0000:06:00.0 eth0: Link is Down
[1705062.863310] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[1705063.920784] r8169 0000:06:00.0 eth0: Link is Down
[1705066.407702] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[1705475.160681] r8169 0000:06:00.0 eth0: Link is Down
[1705479.253604] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[1705520.168595] r8169 0000:06:00.0 eth0: Link is Down
[1705522.679159] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[1705550.962098] r8169 0000:06:00.0 eth0: Link is Down
[1705553.366772] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[1705589.030633] r8169 0000:06:00.0 eth0: Link is Down
[1705591.298389] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[1705650.200821] r8169 0000:06:00.0 eth0: Link is Down
[1705652.631635] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[1705653.139648] r8169 0000:06:00.0 eth0: Link is Down
[1705655.861461] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx



Neither of these fail states are present in my dmesg output.

The fact that all of these tests seem to pass really makes me think my DNS is fine. I haven't seen anything that directly points to a DNS failure and I've instead seen a lot of things that point to an inability of dirmngr under gpg to establish a secure hkps connection with my selected keyserver.

Re: Trouble with DNS on fresh Artix Base install OpenRC, connmand, (dhcpd?)

Reply #28 –
Quote
This is a fairly simple thing that even I understand. The DNS server my system uses is provided by the router. My DNS requests get sent to the router to be sent to the DNS server. My router allows the user to enter DNS servers, but can also request DNS servers from my ISP which are subject to change. By default it is set to receive the DNS server from the ISP. I manually set it above to 1.1.1.1 and 8.8.8.8 for testing and received the same errors as I continue to report. The router's interface does not make the DNS server provided by the ISP readily visible.

DNS is dot quads which is you case is

# /etc/resolv.conf.head can replace this line
nameserver 172.16.0.1

Now you need dig tools

dig +trace keyserver.ubuntu.com

or whatever server you are trying to resolve.


PUTTING 1.1.1.1 in /etc/resolve will bypass your routers DNS settings.

 man resolv.conf

As I said, which I do not recommend unless your router is screwing you up... which is NOT impossible.
https://public-dns.info/nameserver/us.html

Re: Trouble with DNS on fresh Artix Base install OpenRC, connmand, (dhcpd?)

Reply #29 –
Quote from: mrbrklyn – on
Quote
This is a fairly simple thing that even I understand. The DNS server my system uses is provided by the router. My DNS requests get sent to the router to be sent to the DNS server. My router allows the user to enter DNS servers, but can also request DNS servers from my ISP which are subject to change. By default it is set to receive the DNS server from the ISP. I manually set it above to 1.1.1.1 and 8.8.8.8 for testing and received the same errors as I continue to report. The router's interface does not make the DNS server provided by the ISP readily visible.

DNS is dot quads which is you case is

# /etc/resolv.conf.head can replace this line
nameserver 172.16.0.1

Now you need dig tools

dig +trace keyserver.ubuntu.com

or whatever server you are trying to resolve.


PUTTING 1.1.1.1 in /etc/resolve will bypass your routers DNS settings.

 man resolv.conf

As I said, which I do not recommend unless your router is screwing you up... which is NOT impossible.
https://public-dns.info/nameserver/us.html




It is POSSIBLE for the router to allow pings and filter port 53 to block DNS.  Airports are famous for this.  It is also possible that routers just blow up and stop working correctly in seemingly  illogical ways.