Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #88861 > unrolled thread

Any GNU/Linux Gurus. Need Help

Back to article view | Back to comp.os.linux.misc

Contents

  Any GNU/Linux Gurus. Need Help Leroy H <lh@somewhere.net> - 2026-07-16 02:12 +0000
    Re: Any GNU/Linux Gurus. Need Help "Carlos E. R." <robin_listas@es.invalid> - 2026-07-16 12:48 +0200
      Re: Any GNU/Linux Gurus. Need Help Andy Burns <usenet@andyburns.uk> - 2026-07-16 12:02 +0100
      Re: Any GNU/Linux Gurus. Need Help dillinger <dillinger@not.invalid> - 2026-07-16 20:23 +0200
    Re: Any GNU/Linux Gurus. Need Help Leroy H <lh@somewhere.net> - 2026-07-16 15:04 +0000
      Re: Any GNU/Linux Gurus. Need Help Andreas Eder <a_eder_muc@web.de> - 2026-07-16 22:45 +0200
        Re: Any GNU/Linux Gurus. Need Help Leroy H <lh@somewhere.net> - 2026-07-16 21:53 +0000
          Re: Any GNU/Linux Gurus. Need Help "Carlos E. R." <robin_listas@es.invalid> - 2026-07-17 14:38 +0200
          Re: Any GNU/Linux Gurus. Need Help Leroy H <lh@somewhere.net> - 2026-07-18 20:31 +0000
            Re: Any GNU/Linux Gurus. Need Help Richard Kettlewell <invalid@invalid.invalid> - 2026-07-18 22:50 +0100
              Re: Any GNU/Linux Gurus. Need Help Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-07-19 07:45 +0200
                Re: Any GNU/Linux Gurus. Need Help Richard Kettlewell <invalid@invalid.invalid> - 2026-07-19 10:14 +0100
                  Re: Any GNU/Linux Gurus. Need Help rbowman <bowman@montana.com> - 2026-07-19 18:51 +0000
                    Re: Any GNU/Linux Gurus. Need Help c186282 <c186282@nnada.net> - 2026-07-20 00:30 -0400
                      Re: Any GNU/Linux Gurus. Need Help rbowman <bowman@montana.com> - 2026-07-20 04:46 +0000
                        Re: Any GNU/Linux Gurus. Need Help Andy Burns <usenet@andyburns.uk> - 2026-07-20 07:49 +0100
                          Re: Any GNU/Linux Gurus. Need Help rbowman <bowman@montana.com> - 2026-07-20 07:06 +0000
                            Re: Any GNU/Linux Gurus. Need Help Andy Burns <usenet@andyburns.uk> - 2026-07-20 08:24 +0100
                              Re: Any GNU/Linux Gurus. Need Help rbowman <bowman@montana.com> - 2026-07-20 18:40 +0000
            Re: Any GNU/Linux Gurus. Need Help rbowman <bowman@montana.com> - 2026-07-19 01:31 +0000
              Re: Any GNU/Linux Gurus. Need Help Leroy H <lh@somewhere.net> - 2026-07-19 02:20 +0000
                Re: Any GNU/Linux Gurus. Need Help "Carlos E. R." <robin_listas@es.invalid> - 2026-07-19 21:55 +0200
                  Re: Any GNU/Linux Gurus. Need Help c186282 <c186282@nnada.net> - 2026-07-20 00:39 -0400
                  Re: Any GNU/Linux Gurus. Need Help The Natural Philosopher <tnp@invalid.invalid> - 2026-07-20 12:16 +0100
              Re: Any GNU/Linux Gurus. Need Help c186282 <c186282@nnada.net> - 2026-07-18 22:40 -0400

Page 1 of 2  [1] 2  Next page →

#88861 — Any GNU/Linux Gurus. Need Help

GNU/Linux serves my needs except for paying some bills.

It seems that some commercial sites, for whatever reason, do not
interact too kindly with GNU/Linux versions of the standard browsers.

For example, try this link with a recent install of the Firefox
browser:

<https://auth.proofing.statefarm.com/login-ui/login?>

Don't worry.  You don't need a StateFarm account.  But the link
should produce a "Server Not Found" error which is inexplicable.

As I indicated, this occurs with GNU/Linux Firefox and also with
GNU/Linux Iron browser (based on Google Chrome).

<https://www.srware.net/iron/>

So why is this happening?  What is so different about the GNU/Linux
environment that causes this to fail?

I am forced to use Firefox on Micro$lop Winblows (yecch!) to access
this site and pay my insurance bills.

I encourage any readers of this post to try to access the above link
with a GNU/Linux browser and report the result.

[toc] | [next] | [standalone]

#88869

Advocacy group and fu removed.

On 2026-07-16 04:12, Leroy H wrote:
> GNU/Linux serves my needs except for paying some bills.
> 
> It seems that some commercial sites, for whatever reason, do not
> interact too kindly with GNU/Linux versions of the standard browsers.
> 
> For example, try this link with a recent install of the Firefox
> browser:
> 
> <https://auth.proofing.statefarm.com/login-ui/login?>

I get the login request.

> 
> Don't worry.  You don't need a StateFarm account.  But the link
> should produce a "Server Not Found" error which is inexplicable.
> 
> As I indicated, this occurs with GNU/Linux Firefox and also with
> GNU/Linux Iron browser (based on Google Chrome).
> 
> <https://www.srware.net/iron/>

I get the site.

> 
> So why is this happening?  What is so different about the GNU/Linux
> environment that causes this to fail?
> 
> I am forced to use Firefox on Micro$lop Winblows (yecch!) to access
> this site and pay my insurance bills.
> 
> I encourage any readers of this post to try to access the above link
> with a GNU/Linux browser and report the result.
> 


-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#88870

Carlos E. R. wrote:

> Leroy H wrote:
>
>> try this link with a recent install of the Firefox
>> browser:
>>
>> <https://auth.proofing.statefarm.com/login-ui/login?>
> 
> I get the login request.
> 
>> Don't worry.  You don't need a StateFarm account.  But the link
>> should produce a "Server Not Found" error which is inexplicable.
>>
>> As I indicated, this occurs with GNU/Linux Firefox and also with
>> GNU/Linux Iron browser (based on Google Chrome).
>>
>> <https://www.srware.net/iron/>
> 
> I get the site.
Same here, and it goes through the motions of looking for a passkey that 
I don't possess.

[toc] | [prev] | [next] | [standalone]

#88874

On 16/07/2026 12:48, Carlos E. R. wrote:
> Advocacy group and fu removed.

Please don't, keep that crap out of here.

[toc] | [prev] | [next] | [standalone]

#88872

On Thu, 16 Jul 2026 10:16:06 -0400, jayjwa wrote:

> 
>> So why is this happening?  What is so different about the GNU/Linux
>> environment that causes this to fail?
>
> You likely have Javascript and/or cookies turned off or are using some
> other type of privacy setup.
>

It seems that the browser is not at fault.  I can use the "host"
command and the result is that it can't look up the site:

[~]# host auth.proofing.statefarm.com
Host auth.proofing.statefarm.com not found: 3(NXDOMAIN)

I am using a caching nameserver based on pdnsd and the problem
must be somewhere in the configuration for that.

[toc] | [prev] | [next] | [standalone]

#88875

On Do 16 Jul 2026 at 15:04, Leroy H wrote:

> host auth.proofing.statefarm.com

When I do this here I get the following:

host auth.proofing.statefarm.com
auth.proofing.statefarm.com is an alias for auth.proofing.ciam.c1.statefarm.
auth.proofing.ciam.c1.statefarm has address 143.204.181.75
auth.proofing.ciam.c1.statefarm has address 143.204.181.66
auth.proofing.ciam.c1.statefarm has address 143.204.181.4
auth.proofing.ciam.c1.statefarm has address 143.204.181.19

'Andreas

-- 
ceterum censeo redmondinem esse delendam

[toc] | [prev] | [next] | [standalone]

#88876

On Thu, 16 Jul 2026 22:45:49 +0200, Andreas Eder wrote:

> 
> When I do this here I get the following:
> 
> host auth.proofing.statefarm.com
> auth.proofing.statefarm.com is an alias for auth.proofing.ciam.c1.statefarm.
> auth.proofing.ciam.c1.statefarm has address 143.204.181.75
> auth.proofing.ciam.c1.statefarm has address 143.204.181.66
> auth.proofing.ciam.c1.statefarm has address 143.204.181.4
> auth.proofing.ciam.c1.statefarm has address 143.204.181.19
> 

Thanks for that.

The problem is in the DNS lookup.  The DNS server cannot lookup
the address.  This would thus occur with any browser.

As far as I can tell, on my system this is the only site that
has this problem.

I have to do some some network debugging, but since my insurance
bills are paid for the next year the matter is not urgent.

[toc] | [prev] | [next] | [standalone]

#88878

On 2026-07-16 23:53, Leroy H wrote:
> On Thu, 16 Jul 2026 22:45:49 +0200, Andreas Eder wrote:
> 
>>
>> When I do this here I get the following:
>>
>> host auth.proofing.statefarm.com
>> auth.proofing.statefarm.com is an alias for auth.proofing.ciam.c1.statefarm.
>> auth.proofing.ciam.c1.statefarm has address 143.204.181.75
>> auth.proofing.ciam.c1.statefarm has address 143.204.181.66
>> auth.proofing.ciam.c1.statefarm has address 143.204.181.4
>> auth.proofing.ciam.c1.statefarm has address 143.204.181.19
>>
> 
> Thanks for that.
> 
> The problem is in the DNS lookup.  The DNS server cannot lookup
> the address.  This would thus occur with any browser.
> 
> As far as I can tell, on my system this is the only site that
> has this problem.
> 
> I have to do some some network debugging, but since my insurance
> bills are paid for the next year the matter is not urgent.
> 


Firefox can do DNS lookup on its own, ignoring the system.


-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#88889

On Thu, 16 Jul 2026 21:53:25 +0000, Leroy H wrote:

>> 
>> host auth.proofing.statefarm.com
>>

Using tcpdump, after executing the above command I get the following
output:

16:14:36.246775 IP 192.168.0.2.43044 > 185.151.12.158.nntp: Flags [P.], seq 14:27, ack 38, win 84, length 13
16:14:36.276223 IP 185.151.12.158.nntp > 192.168.0.2.43044: Flags [P.], seq 38:75, ack 27, win 32, length 37
16:14:36.276236 IP 192.168.0.2.43044 > 185.151.12.158.nntp: Flags [.], ack 75, win 84, length 0
16:14:36.665930 IP 192.168.0.2.44054 > k.gtld-servers.net.domain: 4021+ [1au] A? auth.proofing.statefarm.com. (56)
16:14:36.665936 IP 192.168.0.2.6744 > g.gtld-servers.net.domain: 51172+ [1au] A? auth.proofing.statefarm.com. (56)
16:14:36.665939 IP 192.168.0.2.32558 > m.gtld-servers.net.domain: 19896+ [1au] A? auth.proofing.statefarm.com. (56)
16:14:36.684007 IP g.gtld-servers.net.domain > 192.168.0.2.6744: 51172- 0/2/3 (126)
16:14:36.684168 IP 192.168.0.2.40802 > ns29.statefarm.com.domain: 47344+ [1au] A? auth.proofing.statefarm.com. (56)
16:14:36.684174 IP 192.168.0.2.14053 > ns31.statefarm.com.domain: 49280+ [1au] A? auth.proofing.statefarm.com. (56)
16:14:36.693843 IP m.gtld-servers.net.domain > 192.168.0.2.32558: 19896- 0/2/3 (126)
16:14:36.693863 IP 192.168.0.2 > m.gtld-servers.net: ICMP 192.168.0.2 udp port 32558 unreachable, length 162
16:14:36.693941 IP k.gtld-servers.net.domain > 192.168.0.2.44054: 4021- 0/2/3 (126)
16:14:36.693948 IP 192.168.0.2 > k.gtld-servers.net: ICMP 192.168.0.2 udp port 44054 unreachable, length 162
16:14:36.726650 IP ns31.statefarm.com.domain > 192.168.0.2.14053: 49280 NXDomain*- 1/1/1 CNAME auth.proofing.ciam.c1.statefarm. (150)
16:14:36.727627 IP ns29.statefarm.com.domain > 192.168.0.2.40802: 47344 NXDomain*- 1/1/1 CNAME auth.proofing.ciam.c1.statefarm. (150)
16:14:36.727638 IP 192.168.0.2 > ns29.statefarm.com: ICMP 192.168.0.2 udp port 40802 unreachable, length 186
16:14:36.742853 IP 192.168.0.2.14016 > a.in-addr-servers.arpa.domain: 60595+ [1au] PTR? 53.128.80.206.in-addr.arpa. (55)
16:14:36.742858 IP 192.168.0.2.24600 > b.in-addr-servers.arpa.domain: 57973+ [1au] PTR? 53.128.80.206.in-addr.arpa. (55)
16:14:36.742863 IP 192.168.0.2.23261 > c.in-addr-servers.arpa.domain: 59832+ [1au] PTR? 53.128.80.206.in-addr.arpa. (55)
16:14:36.771093 IP a.in-addr-servers.arpa.domain > 192.168.0.2.14016: 60595- 0/6/1 (194)
16:14:36.771351 IP 192.168.0.2.42772 > r.arin.net.domain: 64579+ [1au] PTR? 53.128.80.206.in-addr.arpa. (55)
16:14:36.771356 IP 192.168.0.2.32885 > y.arin.net.domain: 15904+ [1au] PTR? 53.128.80.206.in-addr.arpa. (55)
16:14:36.771359 IP 192.168.0.2.52841 > u.arin.net.domain: 56067+ [1au] PTR? 53.128.80.206.in-addr.arpa. (55)
16:14:36.776027 IP b.in-addr-servers.arpa.domain > 192.168.0.2.24600: 57973- 0/6/1 (175)
16:14:36.776044 IP 192.168.0.2 > b.in-addr-servers.arpa: ICMP 192.168.0.2 udp port 24600 unreachable, length 211
16:14:36.790197 IP y.arin.net.domain > 192.168.0.2.32885: 15904- 0/2/1 (106)
16:14:36.790354 IP 192.168.0.2.27044 > ns29.statefarm.com.domain: 46867+ [1au] PTR? 53.128.80.206.in-addr.arpa. (55)
16:14:36.790359 IP 192.168.0.2.28719 > ns31.statefarm.com.domain: 33418+ [1au] PTR? 53.128.80.206.in-addr.arpa. (55)
16:14:36.791385 IP u.arin.net.domain > 192.168.0.2.52841: 56067- 0/2/1 (106)
16:14:36.791402 IP 192.168.0.2 > u.arin.net: ICMP 192.168.0.2 udp port 52841 unreachable, length 142
16:14:36.801217 IP r.arin.net.domain > 192.168.0.2.42772: 64579- 0/2/1 (106)
16:14:36.801232 IP 192.168.0.2 > r.arin.net: ICMP 192.168.0.2 udp port 42772 unreachable, length 142
16:14:36.831599 IP ns29.statefarm.com.domain > 192.168.0.2.27044: 46867*- 1/2/1 PTR ns29.statefarm.com. (120)
16:14:36.831908 IP 192.168.0.2.46132 > b.in-addr-servers.arpa.domain: 8679+ [1au] PTR? 53.132.80.206.in-addr.arpa. (55)
16:14:36.831915 IP 192.168.0.2.41237 > c.in-addr-servers.arpa.domain: 3055+ [1au] PTR? 53.132.80.206.in-addr.arpa. (55)
16:14:36.831918 IP 192.168.0.2.43857 > d.in-addr-servers.arpa.domain: 26916+ [1au] PTR? 53.132.80.206.in-addr.arpa. (55)
16:14:36.834464 IP ns31.statefarm.com.domain > 192.168.0.2.28719: 33418*- 1/2/1 PTR ns29.statefarm.com. (120)
16:14:36.834481 IP 192.168.0.2 > ns31.statefarm.com: ICMP 192.168.0.2 udp port 28719 unreachable, length 156
16:14:36.862281 IP b.in-addr-servers.arpa.domain > 192.168.0.2.46132: 8679- 0/6/1 (175)
16:14:36.862538 IP 192.168.0.2.40970 > r.arin.net.domain: 23958+ [1au] PTR? 53.132.80.206.in-addr.arpa. (55)
16:14:36.862543 IP 192.168.0.2.56934 > u.arin.net.domain: 52945+ [1au] PTR? 53.132.80.206.in-addr.arpa. (55)
16:14:36.862546 IP 192.168.0.2.1425 > y.arin.net.domain: 35005+ [1au] PTR? 53.132.80.206.in-addr.arpa. (55)
16:14:36.879654 IP u.arin.net.domain > 192.168.0.2.56934: 52945- 0/2/1 (106)
16:14:36.879811 IP 192.168.0.2.59606 > ns31.statefarm.com.domain: 48348+ [1au] PTR? 53.132.80.206.in-addr.arpa. (55)
16:14:36.879815 IP 192.168.0.2.6073 > ns29.statefarm.com.domain: 60233+ [1au] PTR? 53.132.80.206.in-addr.arpa. (55)
16:14:36.880862 IP y.arin.net.domain > 192.168.0.2.1425: 35005- 0/2/1 (106)
16:14:36.880878 IP 192.168.0.2 > y.arin.net: ICMP 192.168.0.2 udp port 1425 unreachable, length 142
16:14:36.890689 IP r.arin.net.domain > 192.168.0.2.40970: 23958- 0/2/1 (106)
16:14:36.890706 IP 192.168.0.2 > r.arin.net: ICMP 192.168.0.2 udp port 40970 unreachable, length 142
16:14:36.907018 IP d.in-addr-servers.arpa.domain > 192.168.0.2.43857: 26916- 0/6/1 (194)
16:14:36.907035 IP 192.168.0.2 > d.in-addr-servers.arpa: ICMP 192.168.0.2 udp port 43857 unreachable, length 230
16:14:36.919299 IP ns29.statefarm.com.domain > 192.168.0.2.6073: 60233*- 1/2/1 PTR ns31.statefarm.com. (120)
16:14:36.922015 IP ns31.statefarm.com.domain > 192.168.0.2.59606: 48348*- 1/2/1 PTR ns31.statefarm.com. (120)
16:14:36.922025 IP 192.168.0.2 > ns31.statefarm.com: ICMP 192.168.0.2 udp port 59606 unreachable, length 156
16:14:37.012194 IP c.in-addr-servers.arpa.domain > 192.168.0.2.23261: 59832- 0/6/1 (175)
16:14:37.012211 IP 192.168.0.2 > c.in-addr-servers.arpa: ICMP 192.168.0.2 udp port 23261 unreachable, length 211
16:14:37.089372 IP c.in-addr-servers.arpa.domain > 192.168.0.2.41237: 3055- 0/6/1 (175)
16:14:37.089389 IP 192.168.0.2 > c.in-addr-servers.arpa: ICMP 192.168.0.2 udp port 41237 unreachable, length 211
16:14:51.410202 ARP, Request who-has 192.168.0.2 (Broadcast) tell router, length 46
16:14:51.410209 ARP, Reply 192.168.0.2 is-at fc:aa:14:30:5c:23 (oui Unknown), length 28
16:14:51.410401 IP 185.151.12.158.nntp > 192.168.0.2.43044: Flags [.], ack 27, win 32, length 0
16:14:51.410408 IP 192.168.0.2.43044 > 185.151.12.158.nntp: Flags [.], ack 75, win 84, length 0

The same message occurs many times:

IP 192.168.0.2 > c.in-addr-servers.arpa: ICMP 192.168.0.2 udp port xxxxx unreachable

192.168.0.2 is the address of my machine on the LAN.

Unfortunately, I am not at all versed in network programming but the response
"192.168.0.2 > c.in-addr-servers.arpa" seems to indicate that my machine is telling
the nameserver that the (local?) UDP port is unreachable.

Any comments?

[toc] | [prev] | [next] | [standalone]

#88893

Leroy H <lh@somewhere.net> writes:
> The same message occurs many times:
>
> IP 192.168.0.2 > c.in-addr-servers.arpa: ICMP 192.168.0.2 udp port
> xxxxx unreachable
>
> 192.168.0.2 is the address of my machine on the LAN.
>
> Unfortunately, I am not at all versed in network programming but the
> response "192.168.0.2 > c.in-addr-servers.arpa" seems to indicate that
> my machine is telling the nameserver that the (local?) UDP port is
> unreachable.

Yes. 192.168.0.2 is rejecting the replies to the DNS queries it issued.

It’s consistent with a misconfigured local firewall.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#88905

Richard Kettlewell <invalid@invalid.invalid> wrote:
>Leroy H <lh@somewhere.net> writes:
>> The same message occurs many times:
>>
>> IP 192.168.0.2 > c.in-addr-servers.arpa: ICMP 192.168.0.2 udp port
>> xxxxx unreachable
>>
>> 192.168.0.2 is the address of my machine on the LAN.
>>
>> Unfortunately, I am not at all versed in network programming but the
>> response "192.168.0.2 > c.in-addr-servers.arpa" seems to indicate that
>> my machine is telling the nameserver that the (local?) UDP port is
>> unreachable.
>
>Yes. 192.168.0.2 is rejecting the replies to the DNS queries it issued.
>
>It’s consistent with a misconfigured local firewall.

It's regular behavior of Linux xtables. I don't know whether this
behavior also happens with the later nftables backend, but it has
something to do with the UDP state machine that is implemented with
the ESTABLISHED, RELATED packet classifications.

I am far from being sure, but I most often see this on high-latency
links like cell data when the answer comes like 20 seconds after the
query (when the connection tracking entry might already timed out).
Another hypothesis is that the local resolver queries multiple
servers, takes the quickest answer and then rejects the remaining
answers. But I think that might be unreasonable, why would the
software actively reject the answer instead of silently dropping it on
the floor.

I never investigated that in depth.

Greetings
Marc

P.S.: Oh, yes, and please, alwas run tcpdump with -np.
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#88906

Marc Haber <mh+usenetspam2616@zugschl.us> writes:
> Richard Kettlewell <invalid@invalid.invalid> wrote:

>> Yes. 192.168.0.2 is rejecting the replies to the DNS queries it issued.
>>
>> It’s consistent with a misconfigured local firewall.
>
> It's regular behavior of Linux xtables. I don't know whether this
> behavior also happens with the later nftables backend, but it has
> something to do with the UDP state machine that is implemented with
> the ESTABLISHED, RELATED packet classifications.
>
> I am far from being sure, but I most often see this on high-latency
> links like cell data when the answer comes like 20 seconds after the
> query (when the connection tracking entry might already timed out).

The RTTs are 30-40ms here.

> Another hypothesis is that the local resolver queries multiple
> servers, takes the quickest answer and then rejects the remaining
> answers. But I think that might be unreasonable, why would the
> software actively reject the answer instead of silently dropping it on
> the floor.

Using a separate socket for each outbound query and closing the
redundant ones would have that effect, I think. Seems rather inefficient
but consistent with what we see.


However, I think it is a side issue, swamping the real problem.
Stripping the packet capture down to the essentials:

> 16:14:36.665936 IP 192.168.0.2.6744 > g.gtld-servers.net.domain: 51172+ [1au] A? auth.proofing.statefarm.com. (56)
> 16:14:36.684007 IP g.gtld-servers.net.domain > 192.168.0.2.6744: 51172- 0/2/3 (126)

Querying the root for auth.proofing.statefarm.com. The response is:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43370
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
[..]
;; AUTHORITY SECTION:
statefarm.com.          172800  IN      NS      ns29.statefarm.com.
statefarm.com.          172800  IN      NS      ns31.statefarm.com.

;; ADDITIONAL SECTION:
ns29.statefarm.com.     172800  IN      A       206.80.128.53
ns31.statefarm.com.     172800  IN      A       206.80.132.53

> 16:14:36.684174 IP 192.168.0.2.14053 > ns31.statefarm.com.domain: 49280+ [1au] A? auth.proofing.statefarm.com. (56)
> 16:14:36.726650 IP ns31.statefarm.com.domain > 192.168.0.2.14053: 49280 NXDomain*- 1/1/1 CNAME auth.proofing.ciam.c1.statefarm. (150)

Querying ns31.statefarm.com for auth.proofing.statefarm.com. The response is:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36077
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; ANSWER SECTION:
auth.proofing.statefarm.com. 300 IN     CNAME   auth.proofing.ciam.c1.statefarm.

;; AUTHORITY SECTION:
statefarm.              300     IN      SOA     ns74-am.statefarm.com. root.statefarm.com. 53 10800 3600 2419200 300

What's supposed to happen next is following the CNAME reference to
auth.proofing.ciam.c1.statefarm, which works fine if I try it by hand,
and BIND manages fine as well. But there is no evidence in the packet
capture of the OP's system doing this.

I guess pdnsd has bugs relating to CNAMEs or to TLDs introduced after it
stopped being maintained, or both.

Why an insurance company needs a TLD is unclear but there don’t seem to
be any issues with it.

> P.S.: Oh, yes, and please, alwas run tcpdump with -np.

Agreed. All the PTR queries from tcpdump are also swamping the relevant
stuff.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#88907

On Sun, 19 Jul 2026 10:14:53 +0100, Richard Kettlewell wrote:

> Why an insurance company needs a TLD is unclear but there don’t seem to
> be any issues with it.

Like many companies they recently redesigned the site for the hell of it. 
Previously you could enter the policy number and pay the bill without 
logging in. After the redesign you had to create an account based on your 
phone number. I've had State Farm since New Hampshire revoked GEICO's 
license in the '80s. If anyone ever asked me for a telephone number in the 
ensuing years I certainly don't remember it. 

I called my agent. She verified I never had a phone number on record, 
added it, and sent me a registration link. That wasn't my primary reason 
for calling. State Farm had sent out a flurry of snail mail saying they 
were revampng their billing system. Previously you got a renewal notice 
well in advance of the renewal date. Under the new system the notices are 
sent much later. I knew my policy was up for renewal and had not received 
the bill yet and was worried. 

Cyber security and all that but online sites certainly are a joy to use 
these days. 

[toc] | [prev] | [next] | [standalone]

#88911

On 7/19/26 14:51, rbowman wrote:
> On Sun, 19 Jul 2026 10:14:53 +0100, Richard Kettlewell wrote:
> 
>> Why an insurance company needs a TLD is unclear but there don’t seem to
>> be any issues with it.
> 
> Like many companies they recently redesigned the site for the hell of it.
> Previously you could enter the policy number and pay the bill without
> logging in. After the redesign you had to create an account based on your
> phone number. I've had State Farm since New Hampshire revoked GEICO's
> license in the '80s. If anyone ever asked me for a telephone number in the
> ensuing years I certainly don't remember it.

   Look, it's NOT "better" - just Totalitarian
   State shit.

   And if they're only TAKING money ... why the
   fuck do they need more ID or captchas (which
   I'm getting too old to see well) ???

   THINKING about hiring some lawyers to file
   a group ADA complaint about the 'captchas'.
   Do NOT expect anyone over 65 to be able to
   spot where EVERY bit of the "bicycle" or
   whatever is in the damned half-inch images.

[toc] | [prev] | [next] | [standalone]

#88913

On Mon, 20 Jul 2026 00:30:50 -0400, c186282 wrote:

>    THINKING about hiring some lawyers to file a group ADA complaint
>    about the 'captchas'.
>    Do NOT expect anyone over 65 to be able to spot where EVERY bit of
>    the "bicycle" or whatever is in the damned half-inch images.

And yet you bitch about the proof of work CAPTCHAs like Anubis.

https://en.wikipedia.org/wiki/Anubis_(software)

[toc] | [prev] | [next] | [standalone]

#88915

rbowman wrote:

> And yet you bitch about the proof of work CAPTCHAs like Anubis.

Of the few sites I notice using Anubis, none of them has ever required 
me to 'interact' with it, I just get an interstitial page, and then it 
lets me in.

[toc] | [prev] | [next] | [standalone]

#88916

On Mon, 20 Jul 2026 07:49:19 +0100, Andy Burns wrote:

> rbowman wrote:
> 
>> And yet you bitch about the proof of work CAPTCHAs like Anubis.
> 
> Of the few sites I notice using Anubis, none of them has ever required
> me to 'interact' with it, I just get an interstitial page, and then it
> lets me in.

Precisely. C182282 was upset with Anubis and other newer CATCHAs even if 
he didn't have to identify all the squares with cats or try to decipher 
distorted text. 

https://www.youtube.com/watch?v=ituFNPXAaE8

Steve Earle & The Dukes - I Ain't Ever Satisfied

[toc] | [prev] | [next] | [standalone]

#88917

rbowman wrote:

> https://www.youtube.com/watch?v=ituFNPXAaE8

"The uploader has not made this video available in your country"
which doesn't make sense, considering that this works

<https://www.youtube.com/watch?v=IwhD9i9PlRU>
> Steve Earle & The Dukes - I Ain't Ever Satisfied

[toc] | [prev] | [next] | [standalone]

#88927

On Mon, 20 Jul 2026 08:24:26 +0100, Andy Burns wrote:

> https://www.youtube.com/watch?v=ituFNPXAaE8

Strange. I get the same message from the Netherlands via Tor. 

"Music video by Steve Earle & The Dukes performing I Ain't Ever Satisfied. 
(C) 1987 MCA Nashville, a Division of UMG Recordings, Inc."

The non-video link is also provided by UMG. Copyrights and digital media 
are weird. 

[toc] | [prev] | [next] | [standalone]

#88897

On Sat, 18 Jul 2026 20:31:28 +0000, Leroy H wrote:

> Unfortunately, I am not at all versed in network programming but the
> response "192.168.0.2 > c.in-addr-servers.arpa" seems to indicate that
> my machine is telling the nameserver that the (local?) UDP port is
> unreachable.

Perhaps you shouldn't have tried to set up DNS caching.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web