Tag: section

youtube-dl 的恢復與後續 GitHub 的處理模式

youtube-dl 被下架的事情後續又有不少進展了 (先前寫過「youtube-dl 被 RIAA 用 DMCA 打下來的事件」這篇)，主要是 GitHub 恢復了 youtube-dl 的 Git Repository，然後丟出了一篇文章解釋過程，以及後續的作法：「Standing up for developers: youtube-dl is back」。

要注意這次的事件完全是法律戰，所以裡面發生的敘述都是各自的說法，大家可以自己解讀...

GitHub 的這篇文章是由 Abby Vollmer 發表的，從 LinkedIn 上的資料也可以看到他以前的經歷都是法律相關，現在在 GitHub 的頭銜是「Director of Platform Policy and Counsel」，而這篇的用字也可以看出來很小心。

首先 GitHub 認為下架的原因是 Section 1201：

Section 1201 dates back to the late 1990s and did not anticipate the various implications it has for software use today. As a result, Section 1201 makes it illegal to use or distribute technology (including source code) that bypasses technical measures that control access or copying of copyrighted works, even if that technology can be used in a way that would not be copyright infringement. Circumvention was the core claim in the youtube-dl takedown.

而 GitHub 後續恢復 youtube-dl 的原因是收到 EFF 代表 youtube-dl 開發者所做的 counter notice：「2020-11-16-RIAA-reversal-effletter.pdf」。

照以往這種把事情搞超大的慣例，RIAA 應該是不會有後續的動作，所以就 youtube-dl 這件事情來說應該是差不多告一段落。

GitHub 後續針對 Section 1201 提出了兩個改善措施，一個是重新設計 Section 1201 的處理方式，另外一個是 GitHub 自己投入資金，降低 developer 的負擔。

但整件事情背後的問題主要是在 DMCA 的設計，讓濫發 takedown notice 的人很難受罰，在這點沒有改善之前，同樣的劇碼應該都還是會繼續上演。

PChome 修正了問題，以及 RFC 4074 的說明

早些時候測試發現 PChome 已經修正了之前提到的問題：「PChome 24h 連線會慢的原因...」、「PChome 24h 連線會慢的原因... (續篇)」，這邊除了整理一下以外，也要修正之前文章裡的錯誤。

在 RFC 4074 (Common Misbehavior Against DNS Queries for IPv6 Addresses) 裡面提到了當你只有 IPv4 address 時，DNS server 要怎麼回應的問題。

在「3. Expected Behavior」說明了正確的作法，當只有 A RR 沒有 AAAA RR 的時候，應該要傳回 NOERROR，而 answer section 裡面不要放東西：

Suppose that an authoritative server has an A RR but has no AAAA RR for a host name. Then, the server should return a response to a query for an AAAA RR of the name with the response code (RCODE) being 0 (indicating no error) and with an empty answer section (see Sections 4.3.2 and 6.2.4 of [1]). Such a response indicates that there is at least one RR of a different type than AAAA for the queried name, and the stub resolver can then look for A RRs.

在「4.2. Return "Name Error"」裡提到，如果傳回 NXDOMAIN (3)，表示查詢的這個名稱完全沒有 RR，而不僅僅限於 AAAA record，這就是我犯的錯誤 (在前面的文章建議傳回 NXDOMAIN)：

This type of server returns a response with RCODE 3 ("Name Error") to a query for an AAAA RR, indicating that it does not have any RRs of any type for the queried name.

With this response, the stub resolver may immediately give up and never fall back. Even if the resolver retries with a query for an A RR, the negative response for the name has been cached in the caching server, and the caching server will simply return the negative response. As a result, the stub resolver considers this to be a fatal error in name resolution.

Several examples of this behavior are known to the authors. As of this writing, all have been fixed.

PChome 這次的修正回應了正確的值 (而不是我提到的 NXDOMAIN)：

$ dig shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw

; <<>> DiG 9.9.5-3ubuntu0.16-Ubuntu <<>> shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<<<- opcode: QUERY, status: NOERROR, id: 40767
;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;shopping.gs1.pchome.com.tw.    IN      AAAA

;; AUTHORITY SECTION:
gs1.pchome.com.tw.      5       IN      SOA     ns1.gs1.pchome.com.tw. root.dns.pchome.com.tw. 20171123 3600 3 3600 5

;; Query time: 16 msec
;; SERVER: 210.242.216.91#53(210.242.216.91)
;; WHEN: Fri Nov 24 01:44:52 CST 2017
;; MSG SIZE  rcvd: 134

另外 RFC 也有一些其他的文件可以參考，像是 RFC 2308 (Negative Caching of DNS Queries (DNS NCACHE))、RFC 4697 (Observed DNS Resolution Misbehavior) 以及 RFC 8020 (NXDOMAIN: There Really Is Nothing Underneath)，這些文件描述了蠻多常見的問題以及正確的處理方法，讀完對於現在愈來愈複雜的 DNS 架構有不少幫助。