Go Down

Topic: Ip number works but not http://arduino.local ? (Read 14391 times) previous topic - next topic

sonnyyu

More interesting, if I change dns  back to Google one then problem is gone.

Code: [Select]
8.8.8.8
8.8.4.4


Problem is ISP DNS has bug, send this to your ISP ask them fix their DNS. meantime use Google's one instead of.

chrisnet


More interesting, if I change dns  back to Google one then problem is gone.

Code: [Select]
8.8.8.8
8.8.4.4


Problem is ISP DNS has bug, send this to your ISP ask them fix their DNS. meantime use Google's one instead of.


I used this in both advanced TCP/IP settings and in the router DNS settings and I still can not get it to work.

here is the tracert -d 8.8.8.8
and the new ping arduino.local
Code: [Select]

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\Users\chris_000>tracert -d 8.8.8.8

Tracing route to 8.8.8.8 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    41 ms    11 ms    41 ms  74.134.176.1
  3    15 ms    17 ms    14 ms  74.128.45.5
  4    18 ms    18 ms    21 ms  65.29.31.54
  5    29 ms    27 ms    32 ms  65.189.140.166
  6    38 ms    34 ms    45 ms  107.14.19.58
  7    31 ms    30 ms    36 ms  66.109.6.165
  8    34 ms     *       35 ms  74.125.49.181
  9    40 ms    55 ms    41 ms  209.85.252.46
10    33 ms    39 ms    66 ms  72.14.236.148
11    41 ms    71 ms    47 ms  72.14.235.10
12    51 ms    54 ms    57 ms  72.14.238.74
13    50 ms    54 ms    49 ms  64.233.174.133
14     *        *        *     Request timed out.
15    45 ms    47 ms    46 ms  8.8.8.8

Trace complete.

C:\Users\chris_000>ping arduino.local

Pinging arduino.local [69.16.143.110] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 69.16.143.110:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\chris_000>

chrisnet

I changed the avahi-daemon.conf back to what it was and now it works with the google dns
Thanks for all your hard work!!!!!!!!

PCWorxLA


I changed the avahi-daemon.conf back to what it was and now it works with the google dns
Thanks for all your hard work!!!!!!!!
Those DNS servers should be irrelevant, a ".local" URL should not (and in fact, can not) be resolved by a public DNS server, that's why it is called "local" in the first place...

Ralf

sonnyyu

#34
Mar 03, 2014, 05:28 pm Last Edit: Mar 03, 2014, 06:04 pm by sonnyyu Reason: 1

...
Those DNS servers should be irrelevant, a ".local" URL should not (and in fact, can not) be resolved by a public DNS server, that's why it is called "local" in the first place...

Ralf


The public DNS server should never resolve .local domain, but unfortunately Time Warner does resolve .local domain as NXDOMAIN .


69.16.143.110 is coming from Time Warner Cable; it's the IP they return when their DNS should normally return NXDOMAIN.

209.18.47.61 is Time Warner's DNS:
Code: [Select]
dig @209.18.47.61 +short arduino.local

Code: [Select]
198.105.251.210
69.16.143.110


8.8.8.8 is Google's DNS:

Code: [Select]
dig @8.8.8.8 +short arduino.local

Code: [Select]


Quote
A few ISPs such as Optimum Online, Comcast, Time Warner, Cox Communications, RCN, Rogers, Charter Communications, Verizon, Virgin Media, Frontier Communications, Bell Sympatico, Airtel, and many others started the bad practice of DNS hijacking on non-existent domain name for making money by displaying the internet advertisements.


http://www.dnsknowledge.com/whatis/nxdomain-non-existent-domain-2/

Summary go here:

http://forum.arduino.cc/index.php?topic=188101.msg1617043#msg1617043

chrisnet

To find a fast DNS server see this program.
It also will show you if your DNS is hijacked from the command line!
Code: [Select]
https://code.google.com/p/namebench/

chrisnet

here is Time Warner's
Code: [Select]

209.18.47.62 RoadRunner NC-2 US dns-cac-lb-02.rr.com 79.18 173.2% 27.7 1887.2 0 0
NXDOMAIN Hijacking (www)
www.google.com is hijacked: 74.125.225.81, 74.125.225.82, 74.125.225.83, 74.125.225.84, 74.125.225.80
twitter.com appears incorrect: 199.59.149.230, 199.59.150.7, 199.59.148.82

here is google's
Code: [Select]

8.8.8.8 SYS-8.8.8.8 google-public-dns-a.google.com 69.15 212.8% 44.8 371.2 0 0
A backup DNS server for this system.
a.root-servers.net.: Timeout
twitter.com appears incorrect: 199.16.156.198, 199.16.156.38, 199.16.156.102
www.google.com is hijacked: 74.125.225.148, 74.125.225.146, 74.125.225.145, 74.125.225.144, 74.125.225.147


As you can see Time Warner's "NXDOMAIN Hijacking "!!!!
Google averaged 69.15 and Time Warner averaged 79.18 "lower is better"
And Time Warner's max is 1887.2 but Google max was only 371.

But here is what is funny Google 8.8.4.4
Code: [Select]

8.8.4.4 SYS-8.8.4.4 google-public-dns-b.google.com 53.87 49.2 0


This average is 53.87! I think that Ill try to put 8.8.4.4 is as the fist DNS and 8.8.8.8  as the second!

PCWorxLA



...
Those DNS servers should be irrelevant, a ".local" URL should not (and in fact, can not) be resolved by a public DNS server, that's why it is called "local" in the first place...

Ralf


The public DNS server should never resolve .local domain, but unfortunately Time Warner does resolve .local domain as NXDOMAIN .
a ".local" request should never get out to a public DNS server, TWC or not. If that goes out, it is an indication that your local DNS setup (either on the host you are making the request or at the router/firewall in front of it) is f***ed up...
A public DNS server simply can never get a valid answer to private IP, they simply know squat about any IP address in a range per RFC1918...

Ralf

chrisnet




...
Those DNS servers should be irrelevant, a ".local" URL should not (and in fact, can not) be resolved by a public DNS server, that's why it is called "local" in the first place...

Ralf


The public DNS server should never resolve .local domain, but unfortunately Time Warner does resolve .local domain as NXDOMAIN .
a ".local" request should never get out to a public DNS server, TWC or not. If that goes out, it is an indication that your local DNS setup (either on the host you are making the request or at the router/firewall in front of it) is f***ed up...
A public DNS server simply can never get a valid answer to private IP, they simply know squat about any IP address in a range per RFC1918...

Ralf


That's what we had thought as well but everything we checked out looked fine and as soon as I changed the DNS from Time Warner to Google everything works fine! If you have a suggestion as to what else it could be it would be welcomed!

PCWorxLA


That's what we had thought as well but everything we checked out looked fine and as soon as I changed the DNS from Time Warner to Google everything works fine! If you have a suggestion as to what else it could be it would be welcomed!
That change by itself can not make a difference.
Again, the ".local" suffix exists for a while for the explicit purpose to indicate that this is a host on the local LAN and no proper configured host should even try to do a DNS lookup of that name via a DNS server. Either you do not have your Bonjour service properly running (that's the Apple piece of shitoftware that is supposed to handle that properly) or you should have a router/firewall in front of your LAN that should handle that properly.
".local" as per RFC6762 is pretty much the URL equivalent of the "link-local" (164.254.0.0/16 IP range) "zero-configuration" definition/procedure per RFC3927.

What ever you did, you have been curing symptoms, not the source of the problem...

Ralf

chrisnet



That's what we had thought as well but everything we checked out looked fine and as soon as I changed the DNS from Time Warner to Google everything works fine! If you have a suggestion as to what else it could be it would be welcomed!
That change by itself can not make a difference.
Again, the ".local" suffix exists for a while for the explicit purpose to indicate that this is a host on the local LAN and no proper configured host should even try to do a DNS lookup of that name via a DNS server. Either you do not have your Bonjour service properly running (that's the Apple piece of shitoftware that is supposed to handle that properly) or you should have a router/firewall in front of your LAN that should handle that properly.
".local" as per RFC6762 is pretty much the URL equivalent of the "link-local" (164.254.0.0/16 IP range) "zero-configuration" definition/procedure per RFC3927.

What ever you did, you have been curing symptoms, not the source of the problem...

Ralf


Ok I was told from Time Warner that if I set my router to dynamically get the DNS addresses that it would indeed break your internal network "local", and to set your settings manual Static DNS 1 : 209.18.47.61 and Static DNS 2 : 209.18.47.62 and that this would fix my problem!!

And it did! Thanks for everyone's help!

Go Up