ptt.cc 偶而會解不出 IP 的問題

Update:感謝正妹 wens 幫忙,現在已經先上 workaround 了,狀況暫時解除...

最近發現 168.95.1.1 有時會找不到 ptt.cc 這個 domain (參考 gist:9995821),原因是 ptt.cc 在 whois 上登記的是:

Name Server: NS0.PTT.CC
Name Server: NS1.PTT.CC
Name Server: NSOUT1.PTT.CC

用 dig 對 cc 的 NS server 查詢也可以確認:

;; AUTHORITY SECTION:
ptt.cc.                 172800  IN      NS      ns0.ptt.cc.
ptt.cc.                 172800  IN      NS      ns1.ptt.cc.
ptt.cc.                 172800  IN      NS      nsout1.ptt.cc.

;; ADDITIONAL SECTION:
ns1.ptt.cc.             172800  IN      A       140.112.172.10
ns0.ptt.cc.             172800  IN      A       140.112.172.16
nsout1.ptt.cc.          172800  IN      A       112.121.80.227

但 ptt.cc 的三台 NS server 上都找不到 nsout1.ptt.cc:

; <<>> DiG 9.8.1-P1 <<>> nsout1.ptt.cc @140.112.172.10

;; AUTHORITY SECTION:
ptt.cc.                 300     IN      SOA     ns0.ptt.cc. contact.ptt.cc. 2013102501 3600 900 2419200 3600
; <<>> DiG 9.8.1-P1 <<>> nsout1.ptt.cc @140.112.172.16

;; AUTHORITY SECTION:
ptt.cc.                 300     IN      SOA     ns0.ptt.cc. contact.ptt.cc. 2013102501 3600 900 2419200 3600
; <<>> DiG 9.8.1-P1 <<>> nsout1.ptt.cc @112.121.80.227

;; AUTHORITY SECTION:
ptt.cc.                 300     IN      SOA     ns0.ptt.cc. contact.ptt.cc. 2013102501 3600 900 2419200 3600

於是就錯亂了...

可以先解決的方法是先把 nsout1.ptt.cc 加上去,然後再規劃要怎麼修改兩邊的 record (Ptt 這側的 A/NS record,與 cc 的 A/NS record)。

補充一下,ptt2.cc 也有同樣問題。

瀏覽器裡取得 Local IP 位置的方式

whatismybrowser.com 上看到 local IP address 時愣了一下,查了查資料後發現是 WebRTC 的功能:「Local IP discovery with HTML5 WebRTC: Security and privacy risk?」。

如果知道內網的 IP 後,再加上一堆問題設備,hmmm... 能做的事情好多啊 @_@

在「Can I use WebRTC Peer-to-peer connections?」可以看到 Google ChromeFirefox 都支援了...

看了看 chrome://flags 似乎沒解... 來想看看有沒有什麼其他反制的辦法 @_@

Firefox 可以參考「Where can I disable WebRTC and PeerConnection?」這邊提供的方法試看看,不過我沒測過,不知道到底有沒有效...

可口可樂公司取得 Mac Address...

Slashdot 上看到「Coca-Cola Reserves a Massive Range of MAC Addresses」:

  FC-D4-F2   (hex)		The Coca Cola Company
  FCD4F2     (base 16)		The Coca Cola Company
				One Coca Cola Plaza
				Atlanta GA 30313
				UNITED STATES

可以從「IEEE-SA - Registration Authority MA-L Public Listing」這邊查到...

所以可口可樂公司想要做什麼... @_@

用 Discoverable 藍牙裝置的資訊分析車流狀況...

前幾個禮拜在 Slashdot 上看到政府單位花了 54 萬美金建立藍牙監控網路,利用這些資訊可以分析出車流狀況:「Connecting To Unsecured Bluetooth Car Systems To Monitor Traffic Flow」,引用的報導在:「Bluetooth can help local traffic flow」。

有 3% 到 5% 的車流會有 Discoverable 模式的藍牙裝置,偵測這些 MAC address,就能夠判斷出車子行經的時間點與路線。

不過監控完後能幹什麼啊?我又想到 NSA 了...

SNI 支援 (單一 IP 多個 SSL Certificate)

Twitter 上看到 yllan 提到 SSL certificate 的問題:

這是看 client 對 Server Name Indication 的支援程度而決定的。

在維基百科說明中「Browsers with support for TLS server name indication」這段裡面列出來的瀏覽器,可以看出來其實最大的問題就是 Windows XP 上的 IE{6,7,8} 不支援。(但 Windows Vista 以及 Windows 7 的 IE{7,8} 支援 SNI)

手上一時間找不到 Windows XP + IE{6,7,8} 的數量,但 gs.statcounter.com 上有幾個數字可以參考。

首先是台灣 IE8 的用戶數量:

再來是 Windows XP 數量:

以這兩個圖的資料來看,還是不太能用啊... :o

ISP 架設 NAT 解決 IPv4 不夠的問題...

Slashdot 上看到 PlusNet 決定測試用 CGNAT (Carrier-grade NAT) 解決 IPv4 不夠的問題:「UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6」。

用超大型 NAT 並不是特別的新聞 (某些 mobile network 上就是這樣做),但 ISP 如果用在一般網路上則很有可能會跟客戶的 NAT device (可能是公司,也可能是家庭) 發生 Private Network 相同而導致問題。

2012 年 4 月的 RFC 6598 (IANA-Reserved IPv4 Prefix for Shared Address Space) 將 100.64.0.0/10 (Shared Address Space) 這個網段保留,拿來給營運 CGNAT 的 ISP 使用:

NetRange:       100.64.0.0 - 100.127.255.255
CIDR:           100.64.0.0/10
OriginAS:
NetName:        SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
NetHandle:      NET-100-64-0-0-1
Parent:         NET-100-0-0-0-0
NetType:        IANA Special Use

在 RFC 裡規定 100.64.0.0/10 只能拿來內部使用不得交換;如果要交換必須要有能力將不同介面的 100.64.0.0/10 當作不同網段 NAT (也就是 CGNAT 會做的事情):

In particular, Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces.

另外文件裡還定義了使用 100.64.0.0/10 時對 DNS 的過濾。

如果 CGNAT 上不能打洞,那麼很多應用就很苦了 (得靠 UDP hole punching 打洞,這還得在沒有 randomized NAT port 的情況下才打的通),不過非 P2P 的應用應該不會有問題...

會不會做一做之後就維持這個方式?IPv6 遙遙無期... XD

EC2 的 Public IP Range

AWS 會把 EC2 的 Public IP range 更新在 Community Forum 的公告區:「AWS Developer Forums: Amazon Elastic Compute Cloud」,目前是在「Announcement: Amazon EC2 Public IP Ranges」這頁 (每次更新可能會再開新的文章)。

因為這頁還算簡單,要抓出來使用的話可以用:

lynx -dump https://forums.aws.amazon.com/ann.jspa?annID=1182 | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/[0-9]+'

APNIC 手上的 IPv4 address 用完了...

亞太區 APNIC 手上的 IPv4 位置也分完了:「Asia Runs Out of IPv4 Addresses」。

也就是說,要跟 APNIC 拿 IPv4 address 沒得拿了,要 IPv4 address 得跟現有的這些人買,不然就得想辦法跨區要。

這個消息對今年兩個月後的 IPv6 測試有更高的期望了...