#11 2011-06-18 17:32:23
Re: [問題]關於RT-N16的DNS轉送問題
http://www.mobile01.com/topicdetail.php … t=26411696
查到這裡也有人問一樣的問題~
狀況似乎也和我一樣~
很怪~
只有PPPOE會....
以前用SEEDNET DHCP完全沒問題~XD~
離線
#12 2011-06-18 17:47:23
Re: [問題]關於RT-N16的DNS轉送問題
tracert www.facebook.com
無法解析目標系統名稱 www.facebook.com。
ping www.facebook.com
Ping 要求找不到主機 www.facebook.com。請檢查名稱，然候再試一次。
nslookup
預設伺服器: unknown
Address: 192.168.1.1
> www.facebook.com
伺服器: unknown
Address: 192.168.1.1
未經授權的回答:
名稱: www.facebook.com
Address: 69.171.228.14
很怪問題，說是IP分享器的問題~
可是另一台用無線可以上~
這台用有線的不能上=.=
最後修改： hannahmo (2012-05-29 16:48:11)
離線
#14 2011-06-18 21:12:06
Re: [問題]關於RT-N16的DNS轉送問題
hannahmo 提到:
查日誌有出現這個~
Jun 18 11:24:03 unknown daemon.warn dnsmasq[834]: nameserver 168.95.192.1 refused to do a recursive query
其他沒什麼異狀~XD~XD~
參閱DNSMasq FAQ
Q: Dnsmasq sometimes logs "nameserver xxx.xxx.xxx.xxx refused
to do a recursive query" and DNS stops working. What's going on?
A: Probably the nameserver is an authoritative nameserver for a
particular domain, but is not configured to answer general DNS
queries for an arbitrary domain. It is not suitable for use by
dnsmasq as an upstream server and should be removed from the
configuration. Note that if you have more than one upstream
nameserver configured dnsmasq will load-balance across them and
it may be some time before dnsmasq gets around to using a
particular nameserver. This means that a particular configuration
may work for sometime with a broken upstream nameserver
configuration.
或許Tomato 三組DNS, 可改用Google DNS, OpenDNS, 或"手動"設定ISP DNS試試.
離線
#18 2011-06-20 23:39:20
Re: [問題]關於RT-N16的DNS轉送問題
C:\Users\Peierh＞ping 168.95.192.1
Ping 168.95.192.1 (使用 32 位元組的資料):
回覆自 168.95.192.1: 位元組=32 時間=27ms TTL=248
回覆自 168.95.192.1: 位元組=32 時間=27ms TTL=248
回覆自 168.95.192.1: 位元組=32 時間=27ms TTL=248
回覆自 168.95.192.1: 位元組=32 時間=27ms TTL=248
168.95.192.1 的 Ping 統計資料:
封包: 已傳送 = 4，已收到 = 4, 已遺失 = 0 (0% 遺失)，
大約的來回時間 (毫秒):
最小值 = 27ms，最大值 = 27ms，平均 = 27ms
C:\Users\Peierh＞ping 8.8.8.8
Ping 8.8.8.8 (使用 32 位元組的資料):
回覆自 8.8.8.8: 位元組=32 時間=27ms TTL=53
回覆自 8.8.8.8: 位元組=32 時間=27ms TTL=53
回覆自 8.8.8.8: 位元組=32 時間=26ms TTL=53
回覆自 8.8.8.8: 位元組=32 時間=26ms TTL=53
8.8.8.8 的 Ping 統計資料:
封包: 已傳送 = 4，已收到 = 4, 已遺失 = 0 (0% 遺失)，
大約的來回時間 (毫秒):
最小值 = 26ms，最大值 = 27ms，平均 = 26ms
C:\Users\Peierh＞ping 8.8.4.4
Ping 8.8.4.4 (使用 32 位元組的資料):
回覆自 8.8.4.4: 位元組=32 時間=26ms TTL=54
回覆自 8.8.4.4: 位元組=32 時間=25ms TTL=54
回覆自 8.8.4.4: 位元組=32 時間=25ms TTL=54
回覆自 8.8.4.4: 位元組=32 時間=25ms TTL=54
8.8.4.4 的 Ping 統計資料:
封包: 已傳送 = 4，已收到 = 4, 已遺失 = 0 (0% 遺失)，
大約的來回時間 (毫秒):
最小值 = 25ms，最大值 = 26ms，平均 = 25ms
我是覺得還好，因為看PING值回應來說，並不會慢~
上網在轉換的過程也很OK~
所以也算是不錯的解決方案~
離線
#19 2011-06-21 21:07:45
Re: [問題]關於RT-N16的DNS轉送問題
照理說, 到Google DNS查詢, 經過比較多的節點, 延遲應該更久才對. 不過, 看起來差不多.
我比較好奇的是, 為何中華電信的光世代客戶不能使用中華電信的DNS解析? 是Tomato韌體DNSMasq的問題? 還是DNS server的問題? 而不是如高層長官說的, 要白海豚自己轉彎, 自己找生路.
我非中華電信用戶, 所以在Tomato NTP server設定clock.hinet.net作網路校時, 會出現The following NTP servers have been automatically blocked by request from the server, 這我能理解, 所以改用clock.stdtime.gov.tw. 同樣的, 非中華電信用戶使用中華電信DNS, 作nslookup查詢, 若得到未經授權的答案, 這也合理. 但中華電信用戶, 怪了, 怎麼會是一樣的查詢答案? 正因為如此, 才會有上一篇的許多疑惑.
離線
#20 2011-06-21 21:38:36
Re: [問題]關於RT-N16的DNS轉送問題
hippo 提到:
照理說, 到Google DNS查詢, 經過比較多的節點, 延遲應該更久才對. 不過, 看起來差不多.
我比較好奇的是, 為何中華電信的光世代客戶不能使用中華電信的DNS解析? 是Tomato韌體DNSMasq的問題? 還是DNS server的問題? 而不是如高層長官說的, 要白海豚自己轉彎, 自己找生路.
我非中華電信用戶, 所以在Tomato NTP server設定clock.hinet.net作網路校時, 會出現The following NTP servers have been automatically blocked by request from the server, 這我能理解, 所以改用clock.stdtime.gov.tw. 同樣的, 非中華電信用戶使用中華電信DNS, 作nslookup查詢, 若得到未經授權的答案, 這也合理. 但中華電信用戶, 怪了, 怎麼會是一樣的查詢答案? 正因為如此, 才會有上一篇的許多疑惑.
我來試一下把DNS設到HINET，再來PING看看時間有沒有差~
我在猜想是中華的SERVER有做防攻擊，如果更新頻率高的話會被refuse~
過一段時間就會OK~
因為我之前有一次遇到不能開網頁，就丟著，過了二十分鐘按一下F5，就開起來了~
離線
相關討論主題
| 主題 | 回覆 | 點閱 | 最後發表 |
|---|---|---|---|
|
關於rt n16 repeater 和 wds 的問題？ 作者 changenhsin
|
0 | 7669 | 2013-05-09 19:09:11 作者 changenhsin |
