Tag: name

Amazon CloudFront 要增加自訂網域名稱需要先過認證...

大概猜得到原因，總算是把這塊做下去了...

AWS 宣佈 CloudFront 增加自訂網域名稱需要先過認證才能啟用：「Amazon CloudFront enhances the security for adding alternate domain names to a distribution」，也就是把自己的 domain name 掛到 CloudFront 上需要先認證過。

這邊的認證需要用公開被信任的 SSL Certificate，而大多數人應該會直接拿 AWS 提供的 ACM 來用：

With this change, when you add an alternate domain name using the AWS Management Console or the CloudFront API, you will now need to attach a certificate to the distribution to confirm that you have authorized rights to use the alternate domain name. The certificate must be valid and come from a publicly trusted Certificate Authority like AWS Certificate Manager which provides public SSL/TLS certificates for free.

申請 ACM 也需要確認身分，印象中沒記錯的話是透過 DNS 或是 e-mail 認證。

會有這個改變是因為有一個 DDoS 的攻擊手法可以「造成困擾」。在沒有認證就可以增加網域名稱的情況下 (假設是 assets.gslin.com)，AWS 需要把不同帳號設定同一組 domain name (assets.gslin.com) 的 IP address 分開，這樣才能確保安全性。而 IPv4 address 是有限的，用很多帳號申請就有機會讓真正的 assets.gslin.com 擁有人想要用的時候沒有資源可以用。

其實在 Route53 也有類似的問題，但因為是個雞生蛋蛋生雞的問題，就更不好解決了，在 DNS 還沒設定好之前要怎麼確認身分是一個更頭痛的問題... e-mail 認證可能是一個方法，但流程上就多了不少步驟。

AWS 允許 Hybrid Cloud 下的 DNS Query

AWS 對於 Hybrid Cloud (混合雲，通常是講與傳統機房的混搭應用，也就是雲端跟地端的混搭) 推出兩個功能，一個是讓 AWS 的 DNS Resolver 對於某些 domain 可以回機房端查詢 (雲端查詢地端 domain)。另外一種是反過來，讓機房端的 DNS Resolver 可以查 AWS 這邊的資料 (地端查詢雲端 domain)：「New – Amazon Route 53 Resolver for Hybrid Clouds」。

兩者都可以自己幹，但就得花功夫自己架設，而且有很多細節得處理：

  • 建立 EC2 instance，在上面跑 Unbound，然後 EC2 instance 的 DNS servers 設定要指到這邊。
  • 由於 EC2 的 DHCP 服務沒有辦法指定發放的 IP range，所以為了多重意外而中獎 (關機的時候剛好有其他機器 DHCP 拿到這組 IP)，需要開獨立的 subnet 只放固定 IP 的服務。
  • 為了系統的穩定性，需要在兩個不同 AZ (或是三個) 架設這些 DNS Resolver，所以對應有兩個或是三個 subnet 得建立。

而地端到雲端通常會簡單一些，因為地端通常都已經有內部的 DNS Resolver 可以用，通常只需要在雲上面有 proxy 的角色就可以解決。

不過現在這些 AWS 都直接提供了：

常見的區域都可以用：

Hybrid Cloud is available today in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Sydney), Asia Pacific (Tokyo) and Asia Pacific (Singapore), with other commercial regions to follow.

費用的部分不算便宜 (跟自己弄三台 t3.nano 比起來)，但畢竟不需要自己管理，而且對於已經有機房的單位應該只是零頭而已：

Route 53 Resolver remains free for DNS queries served within your VPC. Resolver Endpoints use Elastic Network Interfaces (ENIs) costing $0.125 per hour. DNS queries that are resolved by a Conditional Forwarding Rule or a Resolver Endpoint cost $0.40 per million queries up to the first billion and $0.20 per million after that.

Cloudflare 成為域名註冊商...

Cloudflare 的老大 Matthew Prince 在自家 blog 上宣佈 Cloudflare 成為域名註冊商：「Introducing Cloudflare Registrar: Domain Registration You Can Love」。

原因是嫌其他家的安全性不夠，所以自己搞了一個把自家的域名都搬進去。現在則是提供服務開放讓大家用。

可以看到 cloudflare.com 用一陣子了：

   Domain Name: CLOUDFLARE.COM
   Registry Domain ID: 1542998887_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.cloudflare.com
   Registrar URL: http://www.cloudflare.com
   Updated Date: 2017-05-24T17:44:01Z
   Creation Date: 2009-02-17T22:07:54Z
   Registry Expiry Date: 2024-02-17T22:07:54Z
   Registrar: CloudFlare, Inc.
   Registrar IANA ID: 1910

不過 Amazon 跟 Google 也都有弄，未必一定要用 Cloudflare 的就是了：

   Registrar: Amazon Registrar, Inc.
   Registrar IANA ID: 468
   Registrar Abuse Contact Email: registrar-abuse@amazon.com
   Registrar Abuse Contact Phone: +1.2062661000
   Registrar: Google Inc.
   Registrar IANA ID: 895
   Registrar Abuse Contact Email: registrar-abuse@google.com
   Registrar Abuse Contact Phone: +1.8772376466

在 DHCP 的情境下強制指定 DNS servers

我在 Vultr 上的 Trac 自動開票程式有時候會爛掉，沒把票開出來，把 stderr 輸出到檔案後發現是找不到 hostname：

socket.gaierror: [Errno -3] Temporary failure in name resolution

看了看 /etc/resolv.conf 發現系統使用的 DNS server 設定是透過 DHCP 取得設定的。但 Vultr 只有提供一組 DNS server，當查不到東西時就爆掉了... 所以找了一下，看到「How to override the DHCP-provided nameserver?」這篇，但裡面是用「增加到前面的方式」，跟我想要改成只用 1.1.1.1 與 1.0.0.1 不太一樣。

知道目錄後拿關鍵字去 dhclient.conf 的 manpage 裡面找，就可以看到四種設定方式：

        default [ option declaration ] ;
        supersede [ option declaration ] ;
        prepend [ option declaration ] ;
        append [ option declaration ] ;

這四組看名字就大概知道用途了。接下來就是把對應的 interface 查出來以後，用 supersede 就搞定了：

    supersede domain-name-servers 1.1.1.1, 1.0.0.1;

重開機測試可以確認 /etc/resolv.conf 的內容改變了。接下來再來觀察看看還會不會有狀況...

Google Chrome 70 在測試移除 EV SSL 的名稱標籤...

Twitter 上看到的：

不知道是什麼背景決定做這個實驗... 盯一下這個消息的後續發展 @_@

找子網域的 subfinder

在「subfinder – 找子網域的工具」這邊看到的，專案是用 Golang 寫的，需要 Golang 1.10+ 才能裝... 這類工具在 PT 找入口時還蠻好用的。

裝完後馬上跑個熱門的 ./subfinder -d teamkp.tw 可以看到不多：

Total 4 Unique subdomains found for teamkp.tw

.teamkp.tw
donate.teamkp.tw
www.donate.teamkp.tw
www.teamkp.tw

加上 -v 則可以看到來源。

保護 TLS 的 Hostname

看到「Encrypted Server Name Indication for TLS 1.3」這個，由 Fastly、Cloudflare、Apple 的人聯手推出的 draft，想要保護 TLS 連線一開始明文傳輸的 hostname 部分。看起來是透過 DNS 發佈 public key，然後使用者用這把 public key 保護 hostname 的部分...

而 DNS 的部分可以透過 DNS over TLS 或是 DNS over HTTPS 來保護，這樣讓 ISP 沒有任何資訊可以看到 hostname，把暴露的資訊再降低...

來繼續關注這個技術...

一路從 MySQL 5.5 升級到 MySQL 8.0 的故事...

在「Migrating to MySQL 8.0 without breaking old application」這邊看到這個有趣的故事 XD 這是作者的應用程式 Drupal 從 MySQL 5.5 一路升級到 8.0 的過程記錄...

真正的問題發生在 5.7 到 8.0：

原因是 Drupal 用到關鍵字了：

In fact, this old Drupal, uses a table name that is now part of the reserved keywords. It’s always advised to verify what are the new keywords reserved for MySQL itself. New features can also mean new keywords sometimes.

修正後就好了：

話說依照「File:Drupal release timeline.png」這邊的資訊，Drupal 6.2 也十年左右了？應該是 PDO 剛開始要推廣的年代，不知道他跑哪個版本的 PHP...

另外 MySQL 的升級意外的順利？雖然是一步一步升，但沒遇到什麼大問題...

擋 mobile.twitter.com 上的廣告

在桌機上面用 mobile.twitter.com 速度比 twitter.com 快很多，所以平常用桌機時都是用 mobile 這個版本在逛，但因為 mobile 版本對 css name 有處理過，使得 uBlock Origin 這類軟體不好處理廣告的部份...

前陣子在日本的時候發現頁面上多了一堆廣告，本來以為是在日本用日本 IP address 才會有所以就沒有太在意，結果回台灣後發現也出現了... 看起來是 css name 又因為改版被改掉而使得原本的規則失效了...

網路上找其他方法看看有沒有方向，結果找到「Block "Promoted Tweets" on mobile.twitter.com · Issue #351 · uBlockOrigin/uAssets」這篇，雖然最後的 commit 還是用 css name 的方式，但在留言處 Jud 提到可以用 Procedural cosmetic filters 中的 XPath 解決：

mobile.twitter.com##:xpath(/html/body//div[@role="article"][.//text()[starts-with(., "Promoted")]])

這條規則不算難懂，先找出 <div role="article"> 的元素，然後判斷下面的節點有沒有文字化開頭後是 Promoted 的字串。

在還沒有更新規則之前，這個拿來擋一擋應該還行... 不過條件寫的有點簡單，可能會有誤判，也許改抓 div 的「Promoted by 」應該會比較好？也就是這樣：

mobile.twitter.com##:xpath(/html/body//div[@role="article"][.//div[text()[starts-with(., "Promoted by ")]]])

就先這樣搞吧...

用 Amazon Route 53 做 Service Discovery

Amazon Route 53 的新功能，可以解決以前自己要建立 Service Discovery 服務的工作：「Amazon Route 53 Releases Auto Naming API for Service Name Management and Discovery」。官方的文件在「Using Autonaming for Service Discovery」這邊。

不過目前有些限制，一個 namespace (domain name) 目前只能有五個服務：

DNS settings for up to five records.

然後 DNS 回應時，最多回八個 record：

When Amazon Route 53 receives a DNS query for the name of an instance, such as backend.example.com, it responds with up to eight IP addresses (for A or AAAA records) or up to eight SRV record values.

回應八個 record，但應該是可以註冊超過八個吧... (i.e. 每次都回不一樣)

自建服務 (像是 Cassandra 或是 ScyllaDB) 可以直接用這個服務掛上去，就不用自己架 Consul 了。

目前支援了這四區，亞洲不在這波提供範圍：

Amazon Route 53 Auto Naming is available in US East (N. Virginia), US East (Ohio), US West (Oregon), and EU (Ireland) regions.