Weird Comcast DNS Issues

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 :slight_smile:

@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

Quad9_last_864000
L3-1_last_864000
CloudflareDNS1_last_864000
OpenDNS1_last_864000
GoogleDNS1_last_864000

Last ten days of my prober box doing latency tests to the main public dns resolvers. Cloudflare consistently comes out on top latency/reliability wise. Unfortunately it looks like the last week has been a bit rough for comcast so these graphs aren’t as useful as they could have been.

1 Like

Yeh, good ol comcast, Looks like something started happening at the end of july
google
facebook

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

So…business as usual?

Yeah, seems like the maintenance was initially causing an issue but is all working properly now.