Timeout setting

[Julien Salort]

Le 25/03/2021 à 18:21, John W. Blue via bind-users a écrit :

> When I queried the authoritative server directly it worked:
>
> ;; QUESTION SECTION:
> ;111.250.179.17.in-addr.arpa.	IN	PTR
>
> ;; ANSWER SECTION:
> 111.250.179.17.in-addr.arpa. 86400 IN	PTR	rn2-msbadger07105.apple.com.
>
> ;; Query time: 62 msec
> ;; SERVER: 17.47.176.10#53(17.47.176.10)
>
> I would recommend that you too do a dig @ and see what you get.
>
> If it works then you can start examining your on prim configs .. if it does not work then you need to be using wireshark to figure out what is happening to the traffic.
>
> Either way you need to first break your troubleshooting into two parts .. on prim vs off prim and proceed from there.

Thank you for your answer.

If I query either authoritative server with dig, or the local recursive 
server, it works in both cases (though I get 164 msec, instead of your 
62 msec, presumably because I am based in Europe; I guess 100 msec to 
cross the Atlantic ocean is not too bad):

;; QUESTION SECTION:
;111.250.179.17.in-addr.arpa.    IN    PTR

;; ANSWER SECTION:
111.250.179.17.in-addr.arpa. 86400 IN    PTR rn2-msbadger07105.apple.com.

;; Query time: 164 msec
;; SERVER: 17.47.176.10#53(17.47.176.10)


Besides, I have other messages from the same source that do get 
delivered. Even the particular message that was originally rejected, was 
eventually accepted when the relay tried again later.

I have not been able to reproduce the timed out result from command 
line. It seems to be a rare occurrence. I have also an example with 
messages from this list: I usually receive them, but three messages from 
today failed (they have actually been sent to my backup mx, so I still 
received them in the end).


Julien