mknox
Well-Known Member
Thanks. The correlation may have more to do with the fact that when I'm home with the car, it is closer to peak internet usage time.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Strange network behavior... car incessantly attacking my nameserver
- Thread starter FlasherZ
- Start date
-
- Tags
- Model S User Interface
Thanks. The correlation may have more to do with the fact that when I'm home with the car, it is closer to peak internet usage time.
bollar
Disgruntled Member
green1
Active Member
That's quite possible, especially if you are on a cable provider instead of something like DSL
Anything in syslog reflect an error or warning from the parameter?
- - - Updated - - -
Okay, I just looked over your configuration again -- you're using forwarders... I suspect that in your case, your server is merely returning what your forwarders are sending to you and is not processing them (and that your forwarders are configured to have the standard large UDP query size). In my case, i don't use forwarders and my servers are playing the role of a recursive nameserver including root hints.
Any reason you're using forwarders? You might try disabling them and using the same root model instead.
thecloud
As rhythm raced inside, the ship came alive
It might be that both edns-udp-size and max-udp-size need to be set to 512 in the options configuration.
edns-udp-size is what this server will advertise when it's recursively querying other servers. (Not having it also set to 512 probably explains why bollar's server advertises 4096.)
max-udp-size is supposed to limit this server's responses to its clients. However, as FlasherZ said, it's possible that this doesn't affect responses which are received from forwarders... in which case, advertising a edns-udp-size of 512 to those upstream servers may cause them to limit their responses to you.
bollar
Disgruntled Member
Adding edns-udp-size 512; gave me:
It generated a new config error:
Code:
[FONT=Menlo]options {[/FONT][FONT=Menlo] directory "/Library/Server/named";[/FONT]
[FONT=Menlo] allow-recursion {[/FONT]
[FONT=Menlo] com.apple.ServerAdmin.DNS.public;[/FONT]
[FONT=Menlo] };[/FONT]
[FONT=Menlo] max-udp-size 512;[/FONT]
[FONT=Menlo] edns-udp-size 512;[/FONT]
[FONT=Menlo] allow-transfer {[/FONT]
[FONT=Menlo] none;[/FONT]
[FONT=Menlo] };[/FONT]
[FONT=Menlo] forwarders {[/FONT]
[FONT=Menlo] 208.67.222.222;[/FONT]
[FONT=Menlo] 208.67.220.220;[/FONT]
[FONT=Menlo] };[/FONT]
[FONT=Menlo]};[/FONT]It generated a new config error:
Code:
[FONT=Verdana]23-Feb-2016 15:38:06.241 reloading configuration succeeded[/FONT][/FONT]
23-Feb-2016 15:38:06.243 reloading zones succeeded
23-Feb-2016 15:38:06.287 zone 141.119.216.in-addr.arpa/IN/com.apple.ServerAdmin.DNS.public: has no NS records
23-Feb-2016 15:38:06.287 zone 141.119.216.in-addr.arpa/IN/com.apple.ServerAdmin.DNS.public: not loaded due to errors.
23-Feb-2016 15:38:06.288 all zones loaded
23-Feb-2016 15:38:06.288 runningthecloud
As rhythm raced inside, the ship came alive
That sounds like a different error to me, probably unrelated to the config options. Is there some separate file for that reverse zone (141.119.216.in-addr.arpa), and does it contain any NS records? I'd expect to see an entry like '@ IN NS yournameserver.yourdomain.' followed by a bunch of PTR records, one for each reverse mapping in that domain.
bollar
Disgruntled Member
It appears that I had a typo. Deleting the line and adding it again allowed the PTR records to load. The car still doesn't respond and here are the results of the dig.
[/FONT]
Code:
[FONT=Menlo]$ dig @127.0.0.1 +comment +bufsize=2048 vpn.vn.teslamotors.com[/FONT][FONT=Menlo]
[/FONT]
[FONT=Menlo]; <<>> DiG 9.8.3-P1 <<>> @127.0.0.1 +comment +bufsize=2048 vpn.vn.teslamotors.com[/FONT]
[FONT=Menlo]; (1 server found)[/FONT]
[FONT=Menlo];; global options: +cmd[/FONT]
[FONT=Menlo];; Got answer:[/FONT]
[FONT=Menlo];; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42151[/FONT]
[FONT=Menlo];; flags: qr rd ra; QUERY: 1, ANSWER: 26, AUTHORITY: 0, ADDITIONAL: 1[/FONT]
[FONT=Menlo]
[/FONT]
[FONT=Menlo];; OPT PSEUDOSECTION:[/FONT]
[FONT=Menlo]; EDNS: version: 0, flags:; udp: 512[/FONT]
[FONT=Menlo];; QUESTION SECTION:[/FONT]
[FONT=Menlo];vpn.vn.teslamotors.com. IN A[/FONT]
[FONT=Menlo]
[/FONT]
[FONT=Menlo];; ANSWER SECTION:[/FONT]
[FONT=Menlo]vpn.vn.teslamotors.com. 152 IN CNAME usvpn.vn.teslamotors.com.[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.10.208.49[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.10.208.45[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.11.133.40[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.11.133.38[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.10.208.44[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.11.133.29[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.10.208.47[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.11.133.22[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.10.208.75[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.11.133.27[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.11.133.39[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.11.133.24[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.10.208.51[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.11.133.12[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.10.208.42[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.10.208.46[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 205.234.27.198[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.11.133.23[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 205.234.27.234[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.11.133.30[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 205.234.27.254[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.11.133.28[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.10.208.50[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.10.208.48[/FONT]
[FONT=Menlo]usvpn.vn.teslamotors.com. 152 IN A 209.10.208.43[/FONT]
[FONT=Menlo]
[/FONT]
[FONT=Menlo];; Query time: 1 msec[/FONT]
[FONT=Menlo];; SERVER: 127.0.0.1#53(127.0.0.1)[/FONT]
[FONT=Menlo];; WHEN: Tue Feb 23 16:41:45 2016[/FONT]
[FONT=Menlo];; MSG SIZE rcvd: 471[/FONT]
[FONT=Menlo]thecloud
As rhythm raced inside, the ship came alive
Well, it's progress at any rate: you can see that the advertised EDNS udp size is now 512. Not sure why this isn't allowing the car to connect, but perhaps it's close enough to the limit to still cause a problem.
At this point, I'll admit that I ended up setting my server to be authoritative for the 'vn.teslamotors.com' domain so I could ensure the response being served to the car was much smaller than 512 bytes. My "db.vn.teslamotors.com" file is set up as a normal domain with SOA and NS records pointing to my local domain and nameserver, and then these entries:
Code:
vpn CNAME usvpn.vn.teslamotors.com.
usvpn 60 IN A 209.10.208.42
usvpn 60 IN A 209.10.208.43
usvpn 60 IN A 209.10.208.44
usvpn 60 IN A 209.10.208.45
usvpn 60 IN A 209.10.208.46
usvpn 60 IN A 209.10.208.47
usvpn 60 IN A 209.10.208.48
usvpn 60 IN A 209.10.208.49
usvpn 60 IN A 209.10.208.50
usvpn 60 IN A 209.10.208.51
usvpn 60 IN A 209.10.208.75There are other records in the vn.teslamotors.com domain as well, it might be breaking something to continue doing that - I don't think you want that as a fix long-term.
I heard back from some contacts within Tesla, they're looking at the issue and have asked me to reconfigure my server back to full-size queries.
I heard back from some contacts within Tesla, they're looking at the issue and have asked me to reconfigure my server back to full-size queries.
thecloud
As rhythm raced inside, the ship came alive
Totally agree. While I've never seen my car look up any name other than 'vpn' in the vn.teslamotors.com domain, there are likely going to be different CNAMEs for different geographic locations, and it's impossible to know what other names may exist here.
Good to know. I will do likewise tonight, and see if the problem persists.
In particular, the old API servers (portal.vn.teslamotors.com) used that domain. The new API servers use owner-api.teslamotors.com, so that's unlikely to affect the modern apps.
strider
Active Member
I'm using forwarders as that is how my Internet Security works - uses DNS to permit/deny/proxy requests through a cloud security platform. I'll try removing the forwarders and see if that changes it.
bollar, that may be affecting you as well since you're using forwarders too.
Last edited:
thecloud
As rhythm raced inside, the ship came alive
I've reverted my nameserver config so it's no longer setting max-udp-size or edns-udp-size, and is not serving a vn.teslamotors.com zone. So far, I haven't seen a recurrence of the connectivity-when-on-WiFi problems I was experiencing.
Looking closely at the older responses from last Friday and the responses I'm getting today which are accepted fine by the car (i.e. no repeated queries at 5-second intervals), the main difference appears to be that they've eliminated the Authority section of the response.
"bad" response on 2/20/2016 (car repeats its query for vpn.vn.teslamotors.com every 5 seconds):
"good" response on 2/24/2016 (car does not repeat its query for vpn.vn.teslamotors.com):
Notice that both responses contain 1 CNAME plus 25 address records, for a total of 26 answers. The older response also included 2 NS records. Eliminating these from the response seems to have saved enough room for the packet to come in under 512 bytes.
And it turns out this is another configurable option of the BIND server:
minimal-responses
If yes, then when generating responses the server will only add records to the authority and additional data sections when they are required (e.g. delegations, negative responses). This may improve the performance of the server. The default is no.
Still a couple of mysteries here:
1. FlasherZ's original problem output showed 26/0/0 (same number of Answers, no Authority or Additional records), yet with a reported size of 488 instead of 460. Where did that extra 28 bytes come from?
2. bollar is unable to connect to the car when it's on WiFi, yet his current dig output shows a size of 471 bytes (it's 26/0/1 because the EDNS opts pseudorecord is considered an Additional record); if this was issued as a standard DNS query (e.g.: dig @127.0.0.1 +comment +bufsize=0 vpn.vn.teslamotors.com) then it would come in at 460 bytes, just as I'm seeing. Are there still repeated 5-second queries from the car to your server?
Looking closely at the older responses from last Friday and the responses I'm getting today which are accepted fine by the car (i.e. no repeated queries at 5-second intervals), the main difference appears to be that they've eliminated the Authority section of the response.
"bad" response on 2/20/2016 (car repeats its query for vpn.vn.teslamotors.com every 5 seconds):
Code:
11:31:54.344931 IP 192.168.11.11.53 > 192.168.11.102.30306: 21672| 26/2/0 CNAME usvpn.vn.teslamotors.com., A 209.10.208.48, A 209.10.208.49, A 209.10.208.50, A 209.10.208.51, A 209.10.208.75, A 209.11.133.12, A 209.11.133.22, A 209.11.133.23, A 209.11.133.24, A 209.11.133.27, A 209.11.133.28, A 209.11.133.29, A 209.11.133.30, A 209.11.133.38, A 209.11.133.39, A 209.11.133.40, A 205.234.27.198, A 205.234.27.234, A 205.234.27.254, A 209.10.208.42, A 209.10.208.43, A 209.10.208.44, A 209.10.208.45, A 209.10.208.46, A 209.10.208.47 (506)"good" response on 2/24/2016 (car does not repeat its query for vpn.vn.teslamotors.com):
Code:
20:18:56.734788 IP 192.168.11.11.53 > 192.168.11.102.36208: 51046 26/0/0 CNAME usvpn.vn.teslamotors.com., A 205.234.27.198, A 205.234.27.234, A 205.234.27.254, A 209.10.208.42, A 209.10.208.43, A 209.10.208.44, A 209.10.208.45, A 209.10.208.46, A 209.10.208.47, A 209.10.208.48, A 209.10.208.49, A 209.10.208.50, A 209.10.208.51, A 209.10.208.75, A 209.11.133.12, A 209.11.133.22, A 209.11.133.23, A 209.11.133.24, A 209.11.133.27, A 209.11.133.28, A 209.11.133.29, A 209.11.133.30, A 209.11.133.38, A 209.11.133.39, A 209.11.133.40 (460)Notice that both responses contain 1 CNAME plus 25 address records, for a total of 26 answers. The older response also included 2 NS records. Eliminating these from the response seems to have saved enough room for the packet to come in under 512 bytes.
And it turns out this is another configurable option of the BIND server:
minimal-responses
If yes, then when generating responses the server will only add records to the authority and additional data sections when they are required (e.g. delegations, negative responses). This may improve the performance of the server. The default is no.
Still a couple of mysteries here:
1. FlasherZ's original problem output showed 26/0/0 (same number of Answers, no Authority or Additional records), yet with a reported size of 488 instead of 460. Where did that extra 28 bytes come from?
2. bollar is unable to connect to the car when it's on WiFi, yet his current dig output shows a size of 471 bytes (it's 26/0/1 because the EDNS opts pseudorecord is considered an Additional record); if this was issued as a standard DNS query (e.g.: dig @127.0.0.1 +comment +bufsize=0 vpn.vn.teslamotors.com) then it would come in at 460 bytes, just as I'm seeing. Are there still repeated 5-second queries from the car to your server?
thecloud
As rhythm raced inside, the ship came alive
And apparently I failed to knock on wood, as tonight the problem was back again:
Code:
20:50:38.511948 IP 192.168.11.102.4475 > 192.168.11.11.53: 12301+ A? vpn.vn.teslamotors.com. (40)
20:50:38.512786 IP 192.168.11.11.53 > 192.168.11.102.4475: 12301| 26/2/0 CNAME usvpn.vn.teslamotors.com., A 209.10.208.45, A 209.10.208.46, A 209.10.208.47, A 209.10.208.48, A 209.10.208.49, A 209.10.208.50, A 209.10.208.51, A 209.10.208.75, A 209.11.133.12, A 209.11.133.22, A 209.11.133.23, A 209.11.133.24, A 209.11.133.27, A 209.11.133.28, A 209.11.133.29, A 209.11.133.30, A 209.11.133.38, A 209.11.133.39, A 209.11.133.40, A 205.234.27.198, A 205.234.27.234, A 205.234.27.254, A 209.10.208.42, A 209.10.208.43, A 209.10.208.44 (506)
20:50:43.524008 IP 192.168.11.102.5707 > 192.168.11.11.53: 61028+ A? vpn.vn.teslamotors.com. (40)
20:50:43.525281 IP 192.168.11.11.53 > 192.168.11.102.5707: 61028| 26/2/0 CNAME usvpn.vn.teslamotors.com., A 209.10.208.44, A 209.10.208.45, A 209.10.208.46, A 209.10.208.47, A 209.10.208.48, A 209.10.208.49, A 209.10.208.50, A 209.10.208.51, A 209.10.208.75, A 209.11.133.12, A 209.11.133.22, A 209.11.133.23, A 209.11.133.24, A 209.11.133.27, A 209.11.133.28, A 209.11.133.29, A 209.11.133.30, A 209.11.133.38, A 209.11.133.39, A 209.11.133.40, A 205.234.27.198, A 205.234.27.234, A 205.234.27.254, A 209.10.208.42, A 209.10.208.43 (506)It turns out the difference is whether the request ends up getting forwarded to Comcast or Google. The former returns the extra 2 records in the Authority section for a 506-byte reply that puts the total packet size over 512 bytes. The latter always returns a 460-byte reply that the car accepts immediately.
I've now added this line to my server's config:
Code:
minimal-responses yes;Will see whether this solves it.
I'm willing to bet that Google has configured its servers to limit UDP responses to 512 bytes.
thecloud
As rhythm raced inside, the ship came alive
After watching my server logs for the past week, it appears that adding minimal-responses yes; to the options section of named.conf seems to have fixed the issue. My DNS server now always sends a minimal 26/0/0 reply to the car which is 460 bytes, even if the response from the forwarder has extra records in the authority or additional sections. Haven't had any repeated 5-second-interval lookups since I made the change.
That said, there's a new weird behavior. Sometimes, right after the vpn.vn.teslamotors.com. lookup, I'll see the car trying to look up the name server. which doesn't exist. I double-checked all files to ensure that name wasn't coming from my server somehow. Since there's no top-level server. domain, a NXDomain error is returned and the car doesn't ask again for a while.
This behavior seems to have started after installing the 2.12.126 update, although the timing might just be a coincidence. It doesn't happen after every lookup for vpn.vn.teslamotors.com., but when it does happen, it immediately follows that lookup. Very strange.
That said, there's a new weird behavior. Sometimes, right after the vpn.vn.teslamotors.com. lookup, I'll see the car trying to look up the name server. which doesn't exist. I double-checked all files to ensure that name wasn't coming from my server somehow. Since there's no top-level server. domain, a NXDomain error is returned and the car doesn't ask again for a while.
Code:
17:38:17.255639 IP 192.168.11.102.38337 > 192.168.11.11.53: 20896+ A? server. (24)
17:38:17.256168 IP 192.168.11.11.53 > 75.75.75.75.53: 62498+ [1au] A? server. (35)
17:38:17.279896 IP 75.75.75.75.53 > 192.168.11.11.53: 62498 NXDomain|$ 0/5/0 (476)
17:38:17.317130 IP 192.168.11.11.53 > 192.168.11.102.38337: 20896 NXDomain 0/1/0 (99)This behavior seems to have started after installing the 2.12.126 update, although the timing might just be a coincidence. It doesn't happen after every lookup for vpn.vn.teslamotors.com., but when it does happen, it immediately follows that lookup. Very strange.
bollar
Disgruntled Member
You're back to being on my "smartest person in the room" list. This is working for me!
thegruf
Active Member
I recall this thread from some time back.
Was there ever any response from Tesla to this issue?