I live in the Portland, OR (PDX) area.
On Monday morning Comcast was doing some maintenance and the inet went down for a few hours.
Came back online and everything appeared to be fine except the Cable TV service.
Most of the channels had garbage on the display and many times the message about the inet being down was being displayed too.
Most of these issues have since been cleared up but now I’m seeing many frequent disconnections from many popular web sites like Youtube for instance.
Anybody seen this and know of the cause ?
I do have cell notifications turned on and they sent a message earlier today about an outage they were fixing.
But the DNS is still problematic.
I setup my LAN computers to have static IP addresses and I’m not losing any LAN connections just that trying to ping Googles Public DNS at 8.8.8.8 will many times drop some or all of the packets.
Same goes for Cloudflares at 1.1.1.1
Currently I’m on my work shift and trying to work cases in between the random disconnects.
Hoping that somebody may have some insite.
Also note that all my local computers are running Windows 10 or 11 Pro.
Is it only dns servers that drop packets, or anything in the wider internet?
Have you reported the issues you’re having to Comcast (for all the good it will do)?
Yes seems to only be the DNS, I can ping either 8.8.8.8 or 1.1.1.1 and it will sometimes drop one or all 4 packets with the Windows Ping command.
It is pretty random as it doesn’t do it all the time, many times it will return all 4 packets.
I could use the -t switch to do a continuous ping test.
I wish there was an equivalent mtr command in Powershell.
I use this on all out customers servers and terminals when I suspect some kind of WAN issue on their end.
I MAY have resolved this matter, so with all the recent Comcast maintenance that has occurred, I just power cycled the modem and now the DNS to both Google and Cloudflare seem to not be so erratic.
I’m doing a ping -t 8.8.8.8 for about 15 minutes to see if anything drops, then will repeat with Cloudflare.
1 Like
I can now confirm I needed to power cycle the modem, I bet it needed to refresh the DOCSIS config file after their recent maintenance.
2 Likes
Most of comcast “outages” are their dns servers crapping out or whatever DPI they do on unencrypted dns traffic crapping out.
Since I switched to full on TLS encrypted DNS traffic and local dns recursive resolvers with caching comcast has become remarkably reliable. Couple Raspberry PI’s and unbound is all you need.
1 Like
Thanks for the feedback, it does however mean you have to do extra work and setup to get this to be a more reliable connection.
I may look into this but for the time being power cycling the modem only takes a few minutes if even that.
Such is life I am afraid. There are things where effort will improve your life. DNS is the easiest thing to optimize to improve your perceived internet speed. So not only will it isolate you from comcast tomfoolery, it will improve your perceived internet speed as well.
server:
# send minimal amount of information to upstream servers to enhance privacy
qname-minimisation: yes
interface: 192.168.86.4
access-control: 192.168.86.0/16 allow
access-control: 2601:647:6300:6CB1::/64 allow
do-ip4: yes
do-udp: yes
do-tcp: yes
do-ip6: yes
# You want to leave this to no unless you have *native* IPv6. With 6to4 and
# Terredo tunnels your web browser should favor IPv4 for the same reasons
prefer-ip6: no
# Use this only when you downloaded the list of primary root servers!
# If you use the default dns-root-data package, unbound will find it automatically
#root-hints: "/var/lib/unbound/root.hints"
# Trust glue only if it is within the server's authority
harden-glue: yes
# Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
harden-dnssec-stripped: yes
# Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
# see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
use-caps-for-id: no
edns-buffer-size: 1232
# Perform prefetching of close to expired message cache entries
# This only applies to domains that have been frequently queried
prefetch: yes
prefetch-key: yes
serve-expired: yes
serve-expired-ttl: 86400 # one day, in seconds
serve-expired-client-timeout: 1000
# One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
num-threads: 1
# Ensure kernel buffer is large enough to not lose messages in traffic spikes
so-rcvbuf: 4m
so-reuseport: yes
msg-cache-slabs: 2
rrset-cache-slabs: 2
infra-cache-slabs: 2
key-cache-slabs: 2
# more outgoing connections
# depends on number of cores: 1024/cores - 50
outgoing-range: 950
# more cache memory, rrset=msg*2
rrset-cache-size: 100m
msg-cache-size: 50m
# with libevent
outgoing-range: 8192
num-queries-per-thread: 4096
# Ensure privacy of local IP ranges
private-address: 192.168.86.0/16
private-address: 169.254.0.0/16
private-address: 172.16.0.0/12
private-address: 10.0.0.0/8
private-address: fd00::/8
private-address: fe80::/10
tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
minimal-responses: yes
local-zone:
host.example.com transparent
local-data:
"host.example.com A 192.168.86.2"
forward-zone:
name: "."
forward-tls-upstream: yes
# Cloudflare
forward-addr: 1.1.1.1@853#cloudflare-dns.com
forward-addr: 1.0.0.1@853#cloudflare-dns.com
forward-addr: 2606:4700:4700::1111@853#cloudflare-dns.com
forward-addr: 2606:4700:4700::1001@853#cloudflare-dns.com
Simple unbound config to use cloudflare dns with tls
2 Likes
Very nice, again thanks for the feedback and guidance
@eousphoros, I would like to eventually set up a system to get my DNS records directly from the Root DNS Servers instead of Cloudflare. I wonder if that is possible.
You can but both kinds of encrypted dns support is pretty limited across them.
It’s been about 15 years since I ran a root name server, and since then I have only barely kept up with it. However if I wanted to hit the roots directly today while maximizing privacy, it would probably look something like this
Home dns cache -(tls)> aws (only cause I have infra there already, any cloud would work) recursive resolver pointed at root name servers with a task to periodically refresh the list of root addresses. Maybe even a few of them spread across different rotating source ips and propagate updates back to a central dns cache that your home hits?
There would be more to it like prefetching, handling root server outages, etc but the point I’m trying to make is using cloud flare is probably better for privacy than hitting the roots directly. If you do want to hit the roots do it by way of a proxy so you can consistently encrypt your dns transit to keep your isp out of it and route it through a non local ip address so the root servers can’t profile you as easily.
1 Like
Yeh, good ol comcast, Looks like something started happening at the end of july
Ah, well I get notifications on my cell about any outages or maintenance, they were doing some of this on Monday morning when the main outage occurred.
They stating replacing and upgrading equipment.
It appears they are still tweaking things.
1 Like
Yeah, seems like the maintenance was initially causing an issue but is all working properly now.