tcp error for address xxxx port 853
-
try 3 and filter for error in Message
-
No errors..
Feb 12 23:48:17 unbound 27548:3 debug: cache memory msg=66771 rrset=66949 infra=8306 val=0 Feb 12 23:48:17 unbound 27548:3 info: finishing processing for p14-bookmarks.icloud.com. A IN Feb 12 23:48:17 unbound 27548:3 info: query response was ANSWER Feb 12 23:48:17 unbound 27548:3 info: reply from <.> 9.9.9.9#853 Feb 12 23:48:17 unbound 27548:3 info: response for p14-bookmarks.icloud.com. A IN Feb 12 23:48:17 unbound 27548:3 info: iterator operate: chased to bookmarks.fe.apple-dns.net. A IN Feb 12 23:48:17 unbound 27548:3 info: iterator operate: query p14-bookmarks.icloud.com. A IN Feb 12 23:48:17 unbound 27548:3 debug: iterator[module 0] operate: extstate:module_wait_reply event:module_event_reply Feb 12 23:48:17 unbound 27548:3 debug: cache memory msg=66309 rrset=66537 infra=8306 val=0 Feb 12 23:48:17 unbound 27548:3 debug: sending to target: <.> 9.9.9.9#853 Feb 12 23:48:17 unbound 27548:3 info: sending query: bookmarks.fe.apple-dns.net. A IN Feb 12 23:48:17 unbound 27548:3 info: processQueryTargets: p14-bookmarks.icloud.com. A IN Feb 12 23:48:17 unbound 27548:3 info: resolving p14-bookmarks.icloud.com. A IN Feb 12 23:48:17 unbound 27548:3 info: query response was CNAME Feb 12 23:48:17 unbound 27548:3 info: reply from <.> 149.112.112.112#853 Feb 12 23:48:17 unbound 27548:3 info: response for p14-bookmarks.icloud.com. A IN Feb 12 23:48:17 unbound 27548:3 info: sanitize: removing extraneous answer RRset: bookmarks.fe.apple-dns.net. A IN Feb 12 23:48:17 unbound 27548:3 info: iterator operate: query p14-bookmarks.icloud.com. A IN Feb 12 23:48:17 unbound 27548:3 debug: iterator[module 0] operate: extstate:module_wait_reply event:module_event_reply Feb 12 23:48:17 unbound 27548:3 debug: cache memory msg=66309 rrset=66313 infra=8057 val=0 Feb 12 23:48:17 unbound 27548:3 debug: sending to target: <.> 149.112.112.112#853 Feb 12 23:48:17 unbound 27548:3 info: sending query: p14-bookmarks.icloud.com. A IN Feb 12 23:48:17 unbound 27548:3 info: processQueryTargets: p14-bookmarks.icloud.com. A IN Feb 12 23:48:17 unbound 27548:3 info: resolving p14-bookmarks.icloud.com. A IN Feb 12 23:48:17 unbound 27548:3 debug: iterator[module 0] operate: extstate:module_state_initial event:module_event_new Feb 12 23:48:16 unbound 27548:3 debug: cache memory msg=66309 rrset=66313 infra=8057 val=0 Feb 12 23:48:16 unbound 27548:3 info: finishing processing for _bookmarkdavs._tcp.p14-bookmarks.icloud.com. SRV IN Feb 12 23:48:16 unbound 27548:3 info: query response was NXDOMAIN ANSWER Feb 12 23:48:16 unbound 27548:3 info: reply from <.> 149.112.112.112#853 Feb 12 23:48:16 unbound 27548:3 info: response for _bookmarkdavs._tcp.p14-bookmarks.icloud.com. SRV IN Feb 12 23:48:16 unbound 27548:3 info: iterator operate: query _bookmarkdavs._tcp.p14-bookmarks.icloud.com. SRV IN Feb 12 23:48:16 unbound 27548:3 debug: iterator[module 0] operate: extstate:module_wait_reply event:module_event_reply Feb 12 23:48:16 unbound 27548:3 debug: cache memory msg=66072 rrset=66072 infra=8057 val=0 Feb 12 23:48:16 unbound 27548:3 debug: sending to target: <.> 149.112.112.112#853 Feb 12 23:48:16 unbound 27548:3 info: sending query: _bookmarkdavs._tcp.p14-bookmarks.icloud.com. SRV IN Feb 12 23:48:16 unbound 27548:3 info: processQueryTargets: _bookmarkdavs._tcp.p14-bookmarks.icloud.com. SRV IN Feb 12 23:48:16 unbound 27548:3 info: resolving _bookmarkdavs._tcp.p14-bookmarks.icloud.com. SRV IN Feb 12 23:48:16 unbound 27548:3 debug: iterator[module 0] operate: extstate:module_state_initial event:module_event_new Feb 12 23:47:21 unbound 27548:2 debug: cache memory msg=66072 rrset=66072 infra=7808 val=0 Feb 12 23:47:21 unbound 27548:2 info: DelegationPoint<.>: 0 names (0 missing), 2 addrs (0 result, 2 avail) parentNS Feb 12 23:47:21 unbound 27548:3 debug: cache memory msg=66072 rrset=66072 infra=7808 val=0 Feb 12 23:47:21 unbound 27548:2 debug: Forward zone server list: Feb 12 23:47:21 unbound 27548:3 info: DelegationPoint<.>: 0 names (0 missing), 2 addrs (0 result, 2 avail) parentNS Feb 12 23:47:21 unbound 27548:3 debug: Forward zone server list:Set to Level 3!
if I filter on errors there is NOTHING to show ;)
-
not for me :(
Feb 12 21:57:02 unbound 54983:3 debug: tcp error for address 9.9.9.9 port 853 Feb 12 21:57:02 unbound 54983:3 debug: tcp error for address 9.9.9.9 port 853 Feb 12 21:56:53 unbound 54983:3 debug: tcp error for address 149.112.112.112 port 853 Feb 12 21:56:53 unbound 54983:3 debug: tcp error for address 9.9.9.9 port 853 Feb 12 21:56:53 unbound 54983:3 debug: tcp error for address 149.112.112.112 port 853 Feb 12 21:56:50 unbound 54983:3 debug: tcp error for address 9.9.9.9 port 853 -
@chudak said in tcp error for address xxxx port 853:
error
Ok I found 1
Feb 12 23:50:42 unbound 27548:1 debug: sending to target: <.> 149.112.112.112#853 Feb 12 23:50:42 unbound 27548:1 info: sending query: wpad.nafta.cds.t-internal.com. A IN Feb 12 23:50:42 unbound 27548:1 info: processQueryTargets: wpad.nafta.cds.t-internal.com. A IN Feb 12 23:50:42 unbound 27548:1 info: iterator operate: query wpad.nafta.cds.t-internal.com. A IN Feb 12 23:50:42 unbound 27548:1 debug: iterator[module 0] operate: extstate:module_wait_reply event:module_event_noreply Feb 12 23:50:42 unbound 27548:1 debug: tcp error for address 149.112.112.112 port 853Well yeah that is not going to get an anwer ;) It asked for wpad.nafta.cds.t-internal.com
Prob just a timeout since it had to resolve it... When I ask again I get NX
And what is the REST OF THE LOG!!! What is before that error?
See in mine
debug: iterator[module 0] operate: extstate:module_wait_reply event:module_event_noreplySo what is NOT working here dude?? What doesn't resolve? Why do you have level 3 logging setup and looking for debug info?
-
Late here - have to go to bed..
-
Feb 12 22:02:34 unbound 54983:3 info: processQueryTargets: 241.4.231.195.in-addr.arpa. PTR IN Feb 12 22:02:34 unbound 54983:3 info: iterator operate: query 241.4.231.195.in-addr.arpa. PTR IN Feb 12 22:02:34 unbound 54983:3 debug: iterator[module 0] operate: extstate:module_wait_reply event:module_event_noreply Feb 12 22:02:34 unbound 54983:3 debug: tcp error for address 9.9.9.9 port 853 Feb 12 22:02:34 unbound 54983:3 debug: cache memory msg=115352 rrset=119761 infra=8306 val=0 Feb 12 22:02:34 unbound 54983:3 debug: sending to target: <.> 9.9.9.9#853 Feb 12 22:02:34 unbound 54983:3 info: sending query: 241.4.231.195.in-addr.arpa. PTR IN Feb 12 22:02:34 unbound 54983:3 info: processQueryTargets: 241.4.231.195.in-addr.arpa. PTR IN Feb 12 22:02:34 unbound 54983:3 info: resolving 241.4.231.195.in-addr.arpa. PTR IN Feb 12 22:02:34 unbound 54983:3 debug: iterator[module 0] operate: extstate:module_state_initial event:module_event_new Feb 12 22:02:32 unbound 54983:0 info: control cmd: stats_noreset -
johnpoz LAYER 8 Global Moderatorlast edited by johnpoz Feb 13, 2019, 11:38 AM Feb 13, 2019, 11:34 AM
@chudak said in tcp error for address xxxx port 853:
extstate:module_wait_reply event:module_event_noreply
Yeah exactly - see that with every error as well.
So lets ask again - What is NOT working? Whats the rest of the log did it finish the resolving of that? It just tried again, etc.
I don't think this is actual error, but just debug info.. Here is the thing once you put your shit inside an encrypted tunnel it becomes almost impossible to actually troubleshoot..
I can tell you what... Did a sniff... And see a shit ton of retrans when this is on..
Those are retrans on a FIN from quad9.. Why?? Have no idea.. Unbound not answering? Cuz he closed the session already? Are they extra answers from the extra NS in the anycast?
So lets ask again - WHAT is not working?? Or is it you looked in a debug log and don't like it saying error?
Trying to troubleshoot such an error is 9.9.9.9 when its also ANYCAST... So you don't know exactly which server is going to answer is going to be almost impossible.
You can tell you get answers from different NS in their anycast group because you get back different TTL when you do a query back to back..
;; QUESTION SECTION: ;241.4.231.195.in-addr.arpa. IN PTR ;; ANSWER SECTION: 241.4.231.195.in-addr.arpa. 5969 IN PTR host241-4-231-195.serverdedicati.aruba.it. ;; Query time: 14 msec ;; SERVER: 9.9.9.9#53(9.9.9.9)Do the query couple seconds later and you get a completely different TTL.. Tell me you got answer from a different cache!
So if you can name an actual dns record that is not resolving.. We can work with that, but working with what looks like WAD debug info?? And trying to think there is a problem is just pointless.
Im back to resolving... This is just pointless... I could give two shits if my ISP knows I did a query for www.pfsense.org
People don't seem to understand that this buys you nothing other then extra overhead, and now your just handing quad 9 EVERY single query you do.. Your isp can still tell where your going just from the SNI in the https request after you get the IP from dns. Are you using ESNI? ;)
-
@johnpoz said in tcp error for address xxxx port 853:
I don't think this is actual error, but just debug info.. Here is the thing once you put your shit inside an encrypted tunnel it becomes almost impossible to actually troubleshoot..
I actually suspect this too, debug info and message possibly wrongly tagged as error
So lets ask again - WHAT is not working?? Or is it you looked in a debug log and don't like it saying error?
Guilty, I just didn't like it's saying error. But also trying to make sure it works.
Im back to resolving... This is just pointless... I could give two shits if my ISP knows I did a query for www.pfsense.org
People don't seem to understand that this buys you nothing other then extra overhead, and now your just handing quad 9 EVERY single query you do.. Your isp can still tell where your going just from the SNI in the https request after you get the IP from dns. Are you using ESNI? ;)
This is above my pay grade, I am not an expert and can't comment if using Quad9 is good or bad idea. Wonder what Quad9 guys think about this. Maybe you are right and all this just waste of CPU power.
@johnpoz Thx for detail analysis !
-
Hi all.
I'm the Executive Director of Quad9, as well as an enthusiastic pfSense user for many years.
-
Using DNS-over-TLS is a good idea, in my book. Encryption of DNS data from your severs to the Quad9 arrays is useful, since your queries then get multiplexed into the query stream with many other users, making it very difficult to determine what your query was. The comment about ENSI above is true but I think insufficient as a reason not to use DNS-over-TLS. Just because some other protocol (HTTPS) is not fully privacy-shrouded doesn't mean you shouldn't try to encrypt everything you can. Despite efforts, the Internet is not all HTTP(s).
-
Quad9 operates an anycast array. There are multiple resolvers located in each POP. You'll probably fairly consistently be sent to a specific POP, but each session/query may reach a different resolver within that rack. Even if you reach different resolvers within a POP, this should not make a huge amount of difference - your local version of unbound should be doing the heavy lifting on caching, so once you get an answer, you should never ask Quad9 for it again until the TTL expires. Pro tip: if you want to know what city your queries are hitting, try "dig @9.9.9.9 CH TXT id.server" and you'll be handed back the exact name of the server to which that query was delivered. Contained in there is the airport code and optional number of the POP to which you're being delivered. If the location is far away from you, send mail to our support desk (support@quad9.net) and we can give you the name of the closest location. We can get you instructions on how to encourage your ISP to route you in a better way.
-
Unbound has some TLS problems that are being worked on. Currently, Unbound only sends a single DNS request over a TLS socket connection. As you may expect, this is quite inefficient. There's an open bug on this - comments are welcome. https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4089 I hope to see this fixed soon, and then moved into pfSense. This means (sadly) that Unbound with TLS is quite a bit slower than using UDP unencrypted at the moment. This may not even be notice-able to you; personal preference will dictate what you choose.
Even when this gets repaired, there is a maximum absolute session duration for a socket that will be encountered, and a maximum session duration for a socket with no queries. However, this should introduce no noticeable latency (a few ms round-trip divided by many seconds of hold time is very very small.) -
I see some of those "tcp error" messages in my logs if I turn up to "3 - debug" but there doesn't seem to be any negative effects visible elsewhere. I'm not sure what that's about, but there aren't any unexpected results or delays that I can see in the DNS lookups. This might be a logging fault? Or not - I'll look more closely at it in a bit, but since there seems to be no observable downside I'd say just keep your logging at a normal level.
-
If you're using DNS-over-TLS you can disable Experimental Bit 0x20 Support - you don't have to worry about someone re-writing your query in-flight.
JT
-
