macOS の時刻がずれる (time.apple.com 側の問題)

dig はコマンドの使い方が間違ってます。

$ dig AAAA time.apple.com

または

$ dig -6 AAAA time.apple.com

としてください。 自分もそうでしたが、最初は -4/-6 オプションを誤解して使うんですよね。サーバーへの問い合わせが IPv4 か IPv6 の切り替えでしかありません。

dnsでipv6は切られたのでは？

DNS の内容が更新されるまで時間がかかる場合があるので何とも言えませんが、手元では投稿した内容のエラーを今も確認できます。

Google の公開 DNS (IPv4 アドレス 8.8.8.8) を使った結果。

$ dig AAAA @8.8.8.8 time.apple.com                                                                   [~

; <<>> DiG 9.10.6 <<>> AAAA @8.8.8.8 time.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63085
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;time.apple.com.			IN	AAAA

;; ANSWER SECTION:
time.apple.com.		2044	IN	CNAME	time.g.aaplimg.com.
time.g.aaplimg.com.	279	IN	AAAA	2403:300:a0c:4000::1f2
time.g.aaplimg.com.	279	IN	AAAA	2403:300:a16:4000::1f2
time.g.aaplimg.com.	279	IN	AAAA	2403:300:a0c:3000::1e2

;; Query time: 36 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Aug 28 11:45:20 JST 2024
;; MSG SIZE  rcvd: 156

sntp を使わない確認方法を提示しておきます。

ターミナルで以下のコマンドを実行します。

% sudo tcpdump -s0 port 123 -v

何行か表示されて停止しますが、そのままにしておいて「システム設定」にて「自動的に設定」を オフ > オンすると

tcpdump: listening on en0, link-type EN10MB (Ethernet), snapshot length 524288 bytes
06:03:38.887784 IP6 (flowlabel 0x10e00, hlim 64, next-header UDP (17) payload length: 56) [MacのIPv6アドレス].53507 > jptyo5-ntp-002.aaplimg.com.ntp: [bad udp cksum 0x1af5 -> 0xdf89!] NTPv4, Client, length 48
	Leap indicator:  (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
	Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
	  Reference Timestamp:  0.000000000
	  Originator Timestamp: 0.000000000
	  Receive Timestamp:    0.000000000
	  Transmit Timestamp:   3639175428.112116942 (2015-04-28T02:03:48Z)
	    Originator - Receive Timestamp:  0.000000000
	    Originator - Transmit Timestamp: 3639175428.112116942 (2015-04-28T02:03:48Z)

〜〜〜〜同様に10回繰り返し〜〜〜〜

06:04:07.469117 IP6 (flowlabel 0x00700, hlim 64, next-header UDP (17) payload length: 56) [MacのIPv6アドレス].63810 > jptyo5-ntp-003.aaplimg.com.ntp: [bad udp cksum 0x0ae5 -> 0x40be!] NTPv4, Client, length 48
	Leap indicator:  (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
	Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
	  Reference Timestamp:  0.000000000
	  Originator Timestamp: 0.000000000
	  Receive Timestamp:    0.000000000
	  Transmit Timestamp:   2604348082.425649434 (1982-07-12T22:01:22Z)
	    Originator - Receive Timestamp:  0.000000000
	    Originator - Transmit Timestamp: 2604348082.425649434 (1982-07-12T22:01:22Z)

時刻の取得要求は

[MacのIPv6アドレス].[ポート番号] > jptyo5-ntp-002.aaplimg.com.ntp

のような通信方向を含む行から開始します。 要求側の

Timestamp: 0.000000000

は問題ありません。

この時は jptyo5* に対して要求してましたが全て応答がなく、12回実行試行して時刻の取得に失敗していました。

-----------------------------------------------------------------------

次に、「タイムサーバー」を「ntp.nict.jp」に設定します。設定しただけでは何も起きないので、「自動的に設定」を オフ > オンすると

tcpdump: listening on en0, link-type EN10MB (Ethernet), snapshot length 524288 bytes
06:07:33.559362 IP6 (flowlabel 0x20c00, hlim 64, next-header UDP (17) payload length: 56) [MacのIPv6アドレス].ntp > ntp-a3.nict.go.jp.ntp: [bad udp cksum 0xc6ac -> 0x83db!] NTPv4, Client, length 48
	Leap indicator:  (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
	Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
	  Reference Timestamp:  0.000000000
	  Originator Timestamp: 0.000000000
	  Receive Timestamp:    0.000000000
	  Transmit Timestamp:   730811245.107559130 (1923-02-28T11:07:25Z)
	    Originator - Receive Timestamp:  0.000000000
	    Originator - Transmit Timestamp: 730811245.107559130 (1923-02-28T11:07:25Z)
06:07:33.588507 IP6 (flowlabel 0x20c00, hlim 23, next-header UDP (17) payload length: 56) ntp-a3.nict.go.jp.ntp > [MacのIPv6アドレス].ntp: [udp sum ok] NTPv4, Server, length 48
	Leap indicator:  (0), Stratum 1 (primary reference), poll 0 (1s), precision -20
	Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: NICT
	  Reference Timestamp:  3934213653.000000000 (2024-09-01T21:07:33Z)
	  Originator Timestamp: 730811245.107559130 (1923-02-28T11:07:25Z)
	  Receive Timestamp:    3934213653.599730595 (2024-09-01T21:07:33Z)
	  Transmit Timestamp:   3934213653.599731419 (2024-09-01T21:07:33Z)
	    Originator - Receive Timestamp:  +3203402408.492171464
	    Originator - Transmit Timestamp: +3203402408.492172288

時刻が取得出来ると

ntp-a3.nict.go.jp.ntp > [MacのIPv6アドレス].ntp

のような通信方向を含む行から開始します。

要求と取得がペアになって表示されるハズです。

Transmit Timestamp が妙なので調べると、timed が作る Transmit Timestamp (送信時刻)はデタラメなようです。

この時は jptyo5* に対して要求してましたが全て応答がなく、12回実行試行

12回分の Transmit Timestamp データ

Transmit Timestamp: 3639175428.112116942 (2015-04-28T02:03:48Z)

Transmit Timestamp: 1159763816.521661893 (1936-10-02T04:36:56Z)

Transmit Timestamp: 609940164.511747985 (1919-05-01T11:49:24Z)

Transmit Timestamp: 3070283426.161944434 (1997-04-17T16:30:26Z)

Transmit Timestamp: 564215719.450580559 (1917-11-18T06:35:19Z)

Transmit Timestamp: 1944782976.817570838 (1961-08-18T01:29:36Z)

Transmit Timestamp: 4143608924.734486378 (2031-04-22T10:28:44Z)

Transmit Timestamp: 3840108894.944841893 (2021-09-08T16:54:54Z)

Transmit Timestamp: 1944782976.817570838 (1961-08-18T01:29:36Z)

Transmit Timestamp: 4143608924.734486378 (2031-04-22T10:28:44Z)

Transmit Timestamp: 3840108894.944841893 (2021-09-08T16:54:54Z)

Transmit Timestamp: 3054071124.936905150 (1996-10-12T01:05:24Z)

Transmit Timestamp: 739358827.234980664 (1923-06-07T09:27:07Z)

Transmit Timestamp: 359806168.791733457 (1911-05-28T10:09:28Z)

Transmit Timestamp: 2604348082.425649434 (1982-07-12T22:01:22Z)

Transmit Timestamp 領域の未初期化かな？

sudo sntp -S ntp.nict.jp を実行したときの tcpdump 出力

要求の送信データ

Leap indicator:  (0), Stratum 0 (unspecified), poll 0 (1s), precision 0

Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)

  Reference Timestamp:  0.000000000

  Originator Timestamp: 0.000000000

  Receive Timestamp:    0.000000000

  Transmit Timestamp:   3934335555.499169999 (2024-09-03T06:59:15Z)

    Originator - Receive Timestamp:  0.000000000

    Originator - Transmit Timestamp: 3934335555.499169999 (2024-09-03T06:59:15Z)

時刻の受信データ

Leap indicator:  (0), Stratum 1 (primary reference), poll 0 (1s), precision -20

Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: NICT

  Reference Timestamp:  3934335555.000000000 (2024-09-03T06:59:15Z)

  Originator Timestamp: 3934335555.499169999 (2024-09-03T06:59:15Z)

  Receive Timestamp:    3934335555.523330043 (2024-09-03T06:59:15Z)

  Transmit Timestamp:   3934335555.523330863 (2024-09-03T06:59:15Z)

    Originator - Receive Timestamp:  +0.024160043

    Originator - Transmit Timestamp: +0.024160863

この送受信が正常なデータでしょう。

timed の場合、"Originator - XXXX Timestamp" の計算もデタラメになるのが気になります。

Reference Timestamp しか使用していないのなら、0.x 秒程度の誤差が生じるのも納得です。

実用上は問題ないでしょうけど。

ありがとうございます。

time.apple.com の日本地域固有の問題だと思うので、英語圏の方々では確認できないと思います。

確実に同期できない条件を見つけました。

ターミナルから

dig AAAA time.apple.com

を実行して

time.g.aaplimg.com.	144	IN	AAAA	2403:300:a0c:4000::1e2
time.g.aaplimg.com.	144	IN	AAAA	2403:300:a0c:4000::1f2
time.g.aaplimg.com.	144	IN	AAAA	2403:300:a16:4000::1f2  << 「a16 が最後」

となっている時です。

テクニカルな説明も出来ます(ソケット プログラミングの話になります)が、ここでは控えます。

今はうちでもipv6が安定して使えるようになりました。

それはなによりです。もし、python3 が使用可能ならば、ターミナルから以下のコマンドを実行してみてください。 time.apple.com の IP アドレス 一覧が出てきます。 dig (DNS プロトコルを直接使うもの) とは違い、多くのアプリケーション ソフトウェアがサーバー名から IP アドレスを取得する方法です。

% python3 -c "import socket,sys;[print(i[4][0]) for i in socket.getaddrinfo(sys.argv[1],'')];" time.apple.com

手元で実行した結果は

2403:300:a16:3000::1f2
2403:300:a16:3000::1f2
2403:300:a0c:4000::1f2
2403:300:a0c:4000::1f2
2403:300:a0c:3000::1e2
2403:300:a0c:3000::1e2
17.253.68.123
17.253.68.123
17.253.68.251
17.253.68.251
17.253.68.253
17.253.68.253

となりました。sntp にしても timed にしても、この一覧からどれを使うか?という処理を実行しています。

sntp のバージョンによって異なるのは、この一覧からの選択方法の違いを意味します。(IPv4 を優先することもできます)

残念ながら、timed は先頭 3 つだろうことが分かりました。システムから重複で返ってくることで

2403:300:a0c:4000::1f2
2403:300:a0c:4000::1f2
2403:300:a0c:3000::1e2
2403:300:a0c:3000::1e2
2403:300:a16:3000::1f2
2403:300:a16:3000::1f2
〜〜〜略〜〜〜

となったとき、IPv6 で唯一応答する 2403:300:a16:3000::1f2 が先頭 3 つに含まれないので、確実に時刻同期に失敗するという訳です。

timed は定期的[1024秒=約17分置きかな?]に時刻取得を試みています。何処にアクセスしているかは tcpdump を使った方法が確実な手段になります。その通信相手が IPv4 / IPv6 か確認するには

% sudo tcpdump -s0 -i en0 port 123 -n

を実行して待機させて、「自動的に設定」を OFF > ON すると初期の時刻取得を開始するので、取得出来ていれば

17:53:00.296644 IP6 [[[Macのアドレス]]].60716 > 2403:300:a16:3000::1f2.123: NTPv4, Client, length 48
17:53:00.358330 IP6 2403:300:a16:3000::1f2.123 > [[[Macのアドレス]]].60716: NTPv4, Server, length 48

のような情報が1行ずつ出てきます。時刻が取得できなければ2行目 ("NTPv4, Server"を含む行) がありません。

IPv6 の接続をリンクローカルのみ(実質的にオフ)にして IPv4 だけにすると

17:50:37.480123 IP [[[Macのアドレス]]].50290 > 17.253.68.125.123: NTPv4, Client, length 48
17:50:37.510464 IP 17.253.68.125.123 > [[[Macのアドレス]]].50290: NTPv4, Server, length 48

のようになります。長時間 tcpdump を実行したままにすると取得失敗の有無を確認できると思います。

Rondo_1 さんによる書き込み：

Apple 側のプライオリティ

タイムサーバーの運用については問題なしと判断しているのではないか?という懸念があります。

tcpdump の内容から timed は必ず 3 つの時刻の取得要求を実行しています。

(「自動的に設定」のオフ>オン 時はリトライを含め最大4セット [3x4=12要求]を実行)

DNS に登録されている IPv4 と IPv6 のアドレスも 3 つずつです。

すると、timed は 3 つの IP アドレスに対して取得要求を実行する仕様と認識されているのでは?ということです。

そのうち一つが応答するので障害は発生しないと判断していても不思議ではありません。

しかし、実態は timed から macOS への「time.apple.com の IP アドレス変換要求」に対して重複した IP アドレス返しています。

これで 2 つの IP アドレス(1つは重複)に対して取得要求を実行していて、応答しないサーバーだけを相手にする結果が生じています。

この齟齬は timed 担当プログラマすら気付いていない可能性が低くありません。(というのも重複排除は timed が行う内容になるからです)

憶測だらけなので、フィードバックやサポートには連絡できませんが...

追認ありがとうございます。

2403:300:a16:3000::1f2 krsel6-ntp-001.aaplimg.com

は、うちでも成功率は低くありません。時々

2403:300:a16:4000::1f2 krsel6-ntp-002.aaplimg.com

が出てきますが、こちらは成功率が下がります。

しかし、 これらが getaddrinfo で取得するリストの先頭 3 つの中に入ってなければ timed は同期に確実に失敗します。

iPad も通信エラーで時刻がずれている旨のメッセージを時々出してまして、 iOS ではタイムサーバーが変更できないので、 Apple のタイムサーバーは正常化してくれないと困るんですよね...

サポートからもフィードバックもしてくれと言われましたが、問題確認可能な説明文(各種ログとかで簡単に膨れる)になると送信文字数制限に引っかかります(長いのは読んでられないということでしょうけど)。制限サイズを尋ねましたがご存知なかったようです。