You are not logged in.
Following a recent update I lost the ability to connect to youtube via the Brave browser. Bizarrely, Firefox still works. I've been attempting to debug this and found that the Ipv6/Ipv4 is different from what the pihole says it should be.
From my host system:
nslookup youtube.com
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: youtube.com
Address: 142.251.46.206
Name: youtube.com
Address: 2607:f8b0:4005:812::200e
From my pihole:
nslookup youtube.com
Server: 2001:1608:10:25::1c04:b12f
Address: 2001:1608:10:25::1c04:b12f#53
Non-authoritative answer:
Name: youtube.com
Address: 142.251.163.91
Name: youtube.com
Address: 142.251.163.190
Name: youtube.com
Address: 142.251.163.136
Name: youtube.com
Address: 142.251.163.93
Name: youtube.com
Address: 2607:f8b0:4004:83f::200e
I'm a bit confused as to where my system is pulling this address from. My systemd-networkd settings are:
[Match]
Name=bond0
[Network]
DHCP=yes
DNS=[ipv6::addr]:5335%bond0#pihole ipv4.addr:5335#pihole
MulticastDNS=true
Domains=~. ~local
DNSSEC=allow-downgrade
DNSOverTLS=opportunistic
LLMNR=no
IPv6PrivacyExtensions=yes
LinkLocalAddressing=yes
Ipv6LinkLocalAddressGenerationMode=stable-privacy
Ipv6StableSecretAddress=secret
Ipv6AcceptRA=no
[Link]
Multicast=yes
[Route]
InitialCongestionWindow=10
InitialAdvertisedReceiveWindow=10
[DHCPV4]
UseDNS=no
Anonymize=yes
UseDomains=route
[DHCPV6]
useDNS=no
Anonymize=yes
UseDomains=route
I believe I've configured networkd properly to use my pihole as the dns server so I'm not sure why I'm getting back a different response from what my pihole is getting.
Looking at resolvectl it seems to think I'm going through quad9 ( this shouldn't be the case ). The non-pihole addresses are dns servers my router has been configured to use. I'm not sure why resolvectl is displaying them or why they would be used as I believe I've told it not to use dns servers advertised by the router.
Link 2 (bond0)
Current Scopes: DNS mDNS/IPv4 mDNS/IPv6
Protocols: +DefaultRoute -LLMNR +mDNS DNSOverTLS=opportunistic DNSSEC=allow-downgrade/supported
Current DNS Server: 9.9.9.11
DNS Servers: pi.addr#pihole 84.200.69.80 9.9.9.11 2001:1608:10:25::1c04:b12f
DNS Domain: ~. ~local
If anyone can spot a mistake in my configuration or have any idea why this might be happening, please let me know. I've been tweaking things for a while now to try to figure this out and I'm not sure what more I can do or what the problem even is.
Last edited by Corrupted (2023-01-06 03:59:30)
If we don't study the mistakes of the future, we're bound to repeat them for the first time.
Offline
I'm not tracking. What is the issue?
Those all see to be Google addresses, you are likely seeing the result of load balancing on the part of Google.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
I lost the ability to connect to youtube via the Brave browser
Though I'd start w/ brave's web-inspector (should be ctrl+shift+i) and/or wireshark to see what happens and whether the IP differences are the actual problem.
Looking at resolvectl it seems to think I'm going through quad9 ( this shouldn't be the case ).
resolved has this super-great habit that if a DNS server response fails, it moves on to the next DNS server until that fails as well (instead of starting the next request at the head of the cascade) - and that affects all clients (ie. one client makes a bogus request, the next one gets a less favorable DNS server)
https://divisionbyzero.net/systemd-resolved-is-broken/
The resolved DNS configuration actually depends on the filetype of /etc/resolv.conf
https://wiki.archlinux.org/title/Systemd-resolved#DNS
Offline
I'm not tracking. What is the issue?
Those all see to be Google addresses, you are likely seeing the result of load balancing on the part of Google.
Sure, sorry. About a week ago I lost the ability to ping any google service and the browser I use ( brave ) lost the ability to connect to youtube specifically. Pinging hangs forever, brave complains it couldn't resolve and if I try to yt-dlp a known url the tool either hangs or complains that the service is not known. This doesn't seem to happen on firefox and it's not clear to me why firefox is able to connect but my primary browser as well as my cmd tools are having trouble.
I've been poking around at my systemd-networkd configurations to see if I made a change that would explain the issues I've been running into but I can't pinpoint what might be causing this. On my local network I have a raspberry-pi that acts as a recursive dns server for everything on the network. if I ssh into the pihole and try pinging youtube it not only works but the IP it's resolving to is different from what I'm getting on my PC which I don't believe should be the case. My phone connects through the pihole and it also seems to be unaffected so the issue doesn't appear to be with the pihole.
resolvectl shows I'm using quad9. I didn't configure it to do this and I'm not sure why it's ignoring UseDNS=no and getting dns servers from the router anyways. Unless I miss-configured something the pihole should be the only dns server networkd/resolved attempts to use, the reason for this being that systemd will bypass blocking by moving on to a different dns if the pihole doesn't resolve.
I'm not sure why I'm suddenly running into issues with google specifically and why my systemd configuration seems to have broken in the last week or so. I suppose I choose a poor title for my post or misunderstood what the issue is. I honestly still don't understand what is broken or why Firefox is unaffected.
If we don't study the mistakes of the future, we're bound to repeat them for the first time.
Offline
The OP wrote:I lost the ability to connect to youtube via the Brave browser
Though I'd start w/ brave's web-inspector (should be ctrl+shift+i) and/or wireshark to see what happens and whether the IP differences are the actual problem.
Looking at resolvectl it seems to think I'm going through quad9 ( this shouldn't be the case ).
resolved has this super-great habit that if a DNS server response fails, it moves on to the next DNS server until that fails as well (instead of starting the next request at the head of the cascade) - and that affects all clients (ie. one client makes a bogus request, the next one gets a less favorable DNS server)
https://divisionbyzero.net/systemd-resolved-is-broken/The resolved DNS configuration actually depends on the filetype of /etc/resolv.conf
https://wiki.archlinux.org/title/Systemd-resolved#DNS
Thanks for the tips. I'll run wireshark and see if that shows anything. I checked the Brave inspector and it looks like a redirect is happening which fails after 3 seconds. This happens a couple times before it seems to give up.
My resolv.conf file is a symlink to /run/systemd/resolve/stub-resolve.conf
Journalctl is showing Transport endpoint is not connected errors followed by DNSSEC validation - failed-auxiliary errors. I think these are new but I'm not certain about that nor am I sure that it's related to the problem.
Last edited by Corrupted (2023-01-06 00:21:29)
If we don't study the mistakes of the future, we're bound to repeat them for the first time.
Offline
This was a case of big stupid, as it turns out.
The first issue was that DHCPV(4|6) wasn't recognized as valid. Discovered in the networkd journal. In addition to that almost all of the IP keys were wrong. Also discovered in the log. Fixed by adjusting casing. This removed the ipv6 and ipv4 dns servers from the bond0 interface.
The second issue was that the unbound configuration for the pihole as well as the set dns server was 'wrong'. This caused a communications error on 127.0.0.53 if I tried to nslookup any external address. Fixed by adding ::1 to the interface and re-adding the ipv4 address to the pihole.
The third issue was the port specified in the dns configuration. Unbound wasn't opening port 5335. That was for internal use. Removing the port (defaulting to 53?) fixed this.
I'm not sure why this ever worked with the number of mistakes there were but it appears to be fixed now. Marking solved.
If we don't study the mistakes of the future, we're bound to repeat them for the first time.
Offline