Re: Any GNU/Linux Gurus. Need Help

Marc Haber <[email protected]> writes:
> Richard Kettlewell <[email protected]> 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/