How long does an old DNS A record live in stub resolver according to TTL?

Question

A cached DNS A record in a full resolver expires after the TTL has elapsed. A timer for TTL starts when the full resolve gets an answer from an authoritative name server.

So, how about stub resolvers? How about a full resolver that gets an answer from an upstream full resolver? If a full resolver returns the TTL value of the authoritative answer, a stub resolver will access an old server after the TTL of the authoritative answer (e.g. server relocation).

Result

• Full resolvers return TTL lower than the one in authoritative answer, according to the elapsed time from when the full resolver got an authoritative answer.
• Some full resolvers start TTL count irrelevantly to the TTL of the authoritative answer, but it's relatively small (60-300 seconds).

Examples

For example, the TTL of www.tut.ac.jp on ns1.tut.ac.jp (authoritative name server) is 43200.

satob@K690XN:/tmp$ dig www.tut.ac.jp a @ns1.tut.ac.jp

; <<>> DiG 9.16.48-Ubuntu <<>> www.tut.ac.jp a @ns1.tut.ac.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45864
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 945070fcdf30040054d73dfd66097241d24c3e11ae55afa3 (good)
;; QUESTION SECTION:
;www.tut.ac.jp.                 IN      A

;; ANSWER SECTION:
www.tut.ac.jp.          43200   IN      A       52.156.43.168

;; AUTHORITY SECTION:
tut.ac.jp.              43200   IN      NS      dns-x.sinet.ad.jp.
tut.ac.jp.              43200   IN      NS      ns0a.tut.ac.jp.
tut.ac.jp.              43200   IN      NS      ns1.tut.ac.jp.

;; ADDITIONAL SECTION:
ns1.tut.ac.jp.          43200   IN      A       133.15.20.16
ns0a.tut.ac.jp.         43200   IN      A       52.156.46.44

;; Query time: 10 msec
;; SERVER: 133.15.20.16#53(133.15.20.16)
;; WHEN: Sun Mar 31 23:25:05 JST 2024
;; MSG SIZE  rcvd: 184

But when you get an answer from a full resolver, the value of TTL is lower than 43200. (Note that 192.168.233.1 is my full resolver)

satob@K690XN:/tmp$ dig www.tut.ac.jp @192.168.233.1

; <<>> DiG 9.16.48-Ubuntu <<>> www.tut.ac.jp @192.168.233.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22876
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.tut.ac.jp.                 IN      A

;; ANSWER SECTION:
www.tut.ac.jp.          42992   IN      A       52.156.43.168

;; Query time: 0 msec
;; SERVER: 192.168.233.1#53(192.168.233.1)
;; WHEN: Sun Mar 31 23:26:07 JST 2024
;; MSG SIZE  rcvd: 58

Some full resolvers, for example, Google Public DNS (8.8.8.8), start TTL count from a smaller value (half of the original TTL?)

[cloudshell-user@ip-xx-xx-xx-xx ~]$ dig www.tut.ac.jp a @8.8.8.8

; <<>> DiG 9.16.48-RH <<>> www.tut.ac.jp a @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42917
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.tut.ac.jp.                 IN      A

;; ANSWER SECTION:
www.tut.ac.jp.          21600   IN      A       52.156.43.168

;; Query time: 159 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Mar 31 10:22:49 UTC 2024
;; MSG SIZE  rcvd: 58

AWS's full resolver used in CloudShell (10.0.0.2) returns TTL 300 for most of the queries.

[cloudshell-user@ip-xx-xx-xx-xx ~]$ dig www.tut.ac.jp

; <<>> DiG 9.16.48-RH <<>> www.tut.ac.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44459
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.tut.ac.jp.                 IN      A

;; ANSWER SECTION:
www.tut.ac.jp.          300     IN      A       52.156.43.168

;; Query time: 129 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Sun Mar 31 10:21:22 UTC 2024
;; MSG SIZE  rcvd: 58

Query for some domains served by CDN returns TTL 0. For example, a query for www.ipa.go.jp returns TTL 0.

satob@K690XN:/tmp$ dig www.ipa.go.jp

; <<>> DiG 9.16.48-Ubuntu <<>> www.ipa.go.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19943
;; flags: qr rd ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.ipa.go.jp.                 IN      A

;; ANSWER SECTION:
www.ipa.go.jp.          0       IN      CNAME   d2aiu9f88m0xez.cloudfront.net.
d2aiu9f88m0xez.cloudfront.net. 0 IN     A       13.33.174.6
d2aiu9f88m0xez.cloudfront.net. 0 IN     A       13.33.174.90
d2aiu9f88m0xez.cloudfront.net. 0 IN     A       13.33.174.89
d2aiu9f88m0xez.cloudfront.net. 0 IN     A       13.33.174.31
ns-130.awsdns-16.com.   0       IN      A       205.251.192.130
ns-1012.awsdns-62.net.  0       IN      A       205.251.195.244
ns-1045.awsdns-02.org.  0       IN      A       205.251.196.21
ns-1632.awsdns-12.co.uk. 0      IN      A       205.251.198.96

;; Query time: 0 msec
;; SERVER: 172.30.176.1#53(172.30.176.1)
;; WHEN: Mon Apr 01 00:05:29 JST 2024
;; MSG SIZE  rcvd: 329

In the authoritative server, TTL is set to 60. So it looks like some of the resolvers upstream from me rewrite TTL.

satob@K690XN:/tmp$ dig d2aiu9f88m0xez.cloudfront.net a @ns-1012.awsdns-62.net

; <<>> DiG 9.16.48-Ubuntu <<>> d2aiu9f88m0xez.cloudfront.net a @ns-1012.awsdns-62.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8904
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;d2aiu9f88m0xez.cloudfront.net. IN      A

;; ANSWER SECTION:
d2aiu9f88m0xez.cloudfront.net. 60 IN    A       13.33.174.6
d2aiu9f88m0xez.cloudfront.net. 60 IN    A       13.33.174.90
d2aiu9f88m0xez.cloudfront.net. 60 IN    A       13.33.174.89
d2aiu9f88m0xez.cloudfront.net. 60 IN    A       13.33.174.31

;; AUTHORITY SECTION:
d2aiu9f88m0xez.cloudfront.net. 172800 IN NS     ns-1012.awsdns-62.net.
d2aiu9f88m0xez.cloudfront.net. 172800 IN NS     ns-1045.awsdns-02.org.
d2aiu9f88m0xez.cloudfront.net. 172800 IN NS     ns-130.awsdns-16.com.
d2aiu9f88m0xez.cloudfront.net. 172800 IN NS     ns-1632.awsdns-12.co.uk.

;; Query time: 59 msec
;; SERVER: 205.251.195.244#53(205.251.195.244)
;; WHEN: Mon Apr 01 00:08:22 JST 2024
;; MSG SIZE  rcvd: 260

satob@K690XN:/tmp$ dig d2aiu9f88m0xez.cloudfront.net a @ns-1012.awsdns-62.net

「おそいひと」主演 住田雅清のインタビュー

昔、映画「おそいひと」主演の住田雅清がインタビューで「泥棒もスケベエもいます」みたいなことを言っていたのを覚えていて（関西の人だからか「スケベ」でなく「スケベエ」と言っていたのが印象的だった）、その資料が映画のオフィシャルサイト*1から見つけられなくて探していたんだけど、昔のx51.orgにあったのを見つけた。

https://web.archive.org/web/20120504090201/http://x51.org/x/07/12/2050.php

*1:http://osoihito.jp/top/index.html

資格試験のJustification Letter

各種のカンファレンスでは、決裁者に向けて「これを受講するとこんないいことがあるから、ぜひ自分に受講をさせてください」みたいな推薦文のテンプレートが提供されていて、これをJustification Letter*1と呼ぶ。

じゃぁIPAの情報処理技術者試験でも、同様のJustification Letterを提供するというのはどうだろう？

というのも、受験のための勉強は必要だし、受験費用は経費にできないみたい*2だし、日曜日に受験に出かける必要があるし……ということで、「家庭内で受験の決裁*3が得られず受験ができない」というケースが一定数あるんじゃないかと思うんです。

そのようなケースに対して定型文を提供することで、受験したいけど受験できないという人の需要を掘り返すとか、あるいは何がボトルネックになっていて受験できない*4のかを明らかにするとか、キャリアパスの代替案を提示する材料するとかができないだろうか？

*1:AWS Summitの場合: https://pages.awscloud.com/rs/112-TZM-766/images/AWS_Bahrain_Summit_Justification_Letter.pdf 、Black Hat USAの場合: https://www.blackhat.com/docs/us-19/justification-letter-2019.pdf

*2:一身専属であり、また仕業でもない。参考: https://www.yayoi-kk.co.jp/kaikei/oyakudachi/shikaku-keihi/ https://biz.moneyforward.com/tax_return/basic/53634/ https://www.tabisland.ne.jp/news/tax/2021/1130.html

*3:この場合の決済者は親とか配偶者とか

*4:たとえば「会社が受けろって言うのに、会社が受験費用を出さないのはおかしいだろ！だから受けない」みたいなケースがどれくらいあるか？を明らかにしたうえで、さらにそれに対して「税法上のこういう理由で会社が負担するとマズいんですよ」みたいな説明をする

Dan Abramovにビジネスロジックを開発させたらできそうなこと

Reactの共同開発者であるDan Abramovが「俺はなんでも知ってるわけじゃない」として書いたブログがある。

overreacted.io

「あれも知らない、これも知らない」という調子で書かれているのだが、じゃぁ（本人が専門分野だと言っているReactやJavaScript、忘れかけているけど昔やっていたC#は除くとして）どれくらいのことは「知っている」のだろう？ ウォーターフォール型プロセスで開発するエンタープライズアプリケーションのビジネスロジック開発チームに所属していたとしたら、どういうことができるんだろうか？というのを想像してみた。

まぁJavaScriptやReactのそれこそエキスパートなので、他言語でも「平均的プログラマ以前」みたいなレベルになることはないと思うのだが、それにしてもこれだけのことができる人がビジネスロジックの開発者全体の中にどれくらいいるんだろう？

• Unix commands and Bash: lsやcdはふつうに実行でき、実行したい処理の実現方法は調べられる（manは使えてるのか不明）。単純な内容であればシェルスクリプトを書ける。パイプも使えるので、コマンド間の連携のために都度テンポラリファイルを作るような変なスクリプトを書いてくることはないだろう。
• Low-level languages: Cでポインタを使った簡単なプログラムが読み書きできる（これは任意サイズの多次元配列が扱えるるということなので結構大きい。）。mallocは使えない。入出力用のデータ領域が引数で渡されてくるような関数なら書けそう。
• Networking stack: IPアドレスというものがあること、DNSでホスト名称とIPアドレスを対応させていることは分かっている。「ブラウザのアドレスバーにURLを入力したときに何が起こるか」の最初の部分は分かっているので、「なんか開発環境がインターネットに繋がらないんです」みたいなことは言ってこないだろう。
• Containers: これについては特に知識はなさそう。
• Serverless: これについては特に知識はなさそう。
• Microservices: これについては特に知識はなさそうだが、むしろ「多数のAPI間の相互呼び出しなだけでしょ？」ということを理解しており、利点も欠点もあるだろうと考えている（過度な期待を持っていない）点に好感が持てる。
• Python: 不明瞭な点が多いが「数年間使っていた」ということなので、パッケージ管理にはpipコマンドを使うというくらいは知っているのでは？
• Node backends: DBMSへのアクセスはしたことがないが、Expressを使って単純なサーバを作ったことはある。開発環境の構築を一部お願いするくらいはできそう。
• Native platforms: Objective Cを触ったことがあるということなのでMac上でのiOS向け開発環境について多少は知っていると思われる。JavaはC#からの類推で行ける範囲なら大丈夫そうという程度なので、簡単なビジネスロジックの読み書きはできるだろうが、開発環境の構築とかは逆に難しいかも。
• Algorithms: バブルソート、クイックソート、グラフの走査（おそらく深さ優先とか幅優先とか）程度の複雑さの処理を手書きできるので、業務色のない共通的な処理も書けそう。「二重ループにすると計算量はO(n²)」ということが理解できているので、計算量が爆上がりするような処理を書いてくる心配もしなくてよさそう。
• Functional languages: Clojure、Elm、OCamlのコードを何とかでも読むことはできる（これだけでもちょっとすごいのでは？）
• Functional terminology: MapReduceの概念を分かっているので、MapReduceを使っている箇所で「何に困っていてどうしたいのか」は理解できる（MapReduce？何それ？という人、いっぱいいるのでは？）。
• Modern CSS: FlexboxとかGridを使っていない、モダンでないCSSなら書ける。
• CSS Methodologies: 上記と同様で、生のCSSなら書ける。
• SCSS / Sass: 上記と同様で、生のCSSなら書ける。
• CORS: 特に知識はなさそうだが、少なくともCORSという制約があること、HTTPヘッダに設定をする必要があるということは分かっている（つまり、何が原因でCORSのエラーが起こっているのか分からず、アプリケーションのコードに変に手を入れたりする心配はない）。
• HTTPS / SSL: これについては「暗号化している」という以上の知識はなさそう。
• GraphQL: クエリを読める！
• Sockets: これについては特に知識はなさそうだが、（WebSocketかそれとも生のSocketsかは分からないが）リクエスト/レスポンスというモデル以外に通信の方法があるということは知っている。
• Streams: Rx Observablesは分かる。
• Electron: これについては特に知識はなさそう。
• TypeScript: 読めるけど書けない。
• Deployment and devops: FTPでのファイル送受信、OSのプロセスに関する理解や、プロセスをkillコマンドで強制終了させる方法は分かる。ps auxでkillする対象のPIDを調べたりもできそう。
• Graphics: これについては特に知識はなさそう。

システム開発に使用する言語の習得にかける時間の例

まったくの素人から平均的プログラマとなるまでの時間*1の他に、システム開発への採用可否を判断できるまでにはどれくらいの時間が必要か？というのもある。

全く見ず知らずの言語をシステム開発に採用するのはリスクが高い、一方で言語に完璧に精通してから開発を始めたのでは「達人にでもなるのを待ってから戦場に出るつもりか？」*2または「ベトナムに行く前に戦争が終わっちまうぞ」*3になってしまうので、じゃぁ世の中を見渡すとどれくらい学習した事例があるのか？というのを書いていく場所。

• The Economistのコンテンツ配信技術をGoで刷新する際、「最初の数ヶ月はGoの習得に費やし」た。*4

*1:https://satob.hatenablog.com/entry/2023/12/11/014522

*2:三浦建太郎「ベルセルク」

*3:「フルメタル・ジャケット」

*4:日本語訳 https://www.infoq.com/jp/articles/golang-the-economist/ だと最初の数ヶ月を純粋にGoの習得だけに費やしたように読めるが、原文 https://www.infoq.com/articles/golang-the-economist/ だとGoの習得に加えて外部コンサルタントとの協業・チームへの再加入もやっているように読めるので注意が必要