php / php/php-src

Weird behaviour for DNS resolution

オープン
#14,245 コメント 2 件 リアクション 2 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

Bug Category: DNS Status: Needs Triage
主要言語
C
スター
40.4k
フォーク
8.2k
平均マージ
2日 15時間
マージ済み PR(30日)
103

説明

Description

I have look on the internet and see very little talk about this so it's possible that my php is wrongly configure but I have failed to find a directive related to this.

The following code:

Not sure where the code is located, my C understanding is pretty weak and I'm an ops guy.
I think it's around here : https://github.com/php/php-src/blob/master/ext/standard/dns.c

What I see :

When a php process does a dns query for both A and AAAA type, if A is valid but AAAA is empty, both records are not stored in cache and therefor the next request will trigger a dns query for both type again.
It seems like the empty AAAA response triggers an invalidation in the cache for both A and AAAA record. This behaviour floods the network needlessly.
I have notice this behaviour both on VMs or on containers, and from a wide range of php versions (5.6 to 8.3) or OS versions (Debian 9/10/11/12, Ubuntu 16/18/20/22 or Alpine 3.18/3.19).
I can provide this graph to illustrate better what I'm saying (Yellow and Green line are AAAA and A type) :
Screenshot 2024-05-15 at 14-47-35 CoreDNS - Kubernetes - Dashboards - Grafana

What I would expect :

In my opinion, once a A record have been successfully retrieved, it should be stored in cache and the AAAA should not invalidate it. And maybe once the A record expires it should try again both resolution (A and AAAA).

I have tested successfully to disable ipv6 in kernel for VMs and it drastically reduces the number of DNS query sent by applications (see graph below) and looks like the A response is stored in cache. This is a possible solution for VMs but complicated one in a Kubernetes environment.

Screenshot 2024-05-15 at 14-47-27 Unbound - System - Dashboards - Grafana

PHP Version

8.3

Operating System

No response

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

ext/standard/dns.c から始め、A レコードはあるが AAAA レコードがないホスト名で PHP 8.3 の動作を再現します。A と AAAA の応答がどのようにキャッシュまたは無効化されるかを追跡し、その後、AAAA の応答が空の場合でも有効な A の結果がキャッシュに残るよう、対象を絞ったカバレッジを追加または更新します。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
c, php
領域
backend, networking
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
静か
明瞭さ
説明が足りない
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。