Ben Vitale wrote: > > I don't believe I am using conntrack - not even sure what that is. In short, ip_conntrack = connection tracking modules for established/related packets. Typically associated with a firewall configuration. i.e. netfilter/iptables. firewall# lsmod | grep conntrack ...snip... ip_conntrack 17864 6 [ipt_state ipt_helper ipt_conntrack ipt_REDIRECT ipt_MASQUERADE ip_nat_irc ip_nat_ftp iptable_nat ip_conntrack_irc ip_conntrack_ftp] > > At this point, I am inclined to think that I just didn't notice this > occasional DNS slowdown when I was on FC1, and then when the hype > about IPv6-related problems showed up in FC2, I noticed that I had > similar problems. > > Comcast probably just sucks every now and then. DNS servers (especially at ISP's) can get slow at times. FWIW: I run my own DNS server at this end. Sometimes I see slow response times to queries. This could be caused by: 1) Slow query result from the root name servers 2) Slow query result from the SOA/NS for the domain name being queried. 3) My DSL line being saturated at the time of the query. But once the query is cached, the next query response for the same domain is always fast. i.e. Not cached query... [root@excelsior log]# dig comcast.net ...snip... ;; Query time: 77 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Aug 5 12:15:06 2004 ;; MSG SIZE rcvd: 142 Cached query... [root@excelsior log]# dig comcast.net ...snip... ;; Query time: 10 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Aug 5 12:15:22 2004 ;; MSG SIZE rcvd: 142 My point being, there are times the 77msec response to the non-cached query above could be 200+msec the next day or even a few seconds from the last query (using different domain query). Using dig +trace, can help pinpoint the bottleneck when the query results are consistantly slow, but I have found that a slow response time from one of the root name servers or the NS server for the domain are usually just a temporary condition. YMMV BTW: For reference, I have a 768/128 DSL line at my end. Steve Cowles
