listes at salort.eu
Thu Mar 25 17:35:51 UTC 2021
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:
> ;184.108.40.206.in-addr.arpa. IN PTR
> ;; ANSWER SECTION:
> 220.127.116.11.in-addr.arpa. 86400 IN PTR rn2-msbadger07105.apple.com.
> ;; Query time: 62 msec
> ;; SERVER: 18.104.22.168#53(22.214.171.124)
> 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:
;126.96.36.199.in-addr.arpa. IN PTR
;; ANSWER SECTION:
188.8.131.52.in-addr.arpa. 86400 IN PTR rn2-msbadger07105.apple.com.
;; Query time: 164 msec
;; SERVER: 184.108.40.206#53(220.127.116.11)
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).
More information about the bind-users