Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Target `.` in SRV records is returned as empty string instead

Open
#234 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
42/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
php
Domain
networking

Research direction

Start by tracing resolveAll() with Message::TYPE_SRV through the SRV response parsing path and compare handling of a target of "." with a normal hostname. Add a regression test for the _test2-style record and verify that the returned target is "." rather than an empty string.

Written by the indexing model from the issue text.

Description

bug

Hey all,

Opening this ticket following the suggestion of a maintainer of movim in https://github.com/movim/movim/issues/1408, which uses this lib. I'm not very good at PHP so please bear with me 😅

I believe there might be something wrong the way react dns returns data from SRV records. I have set up two test SRV records as follows:

_test1._tcp.nadia.moe. 300 IN SRV 1 1 6969 nadia.moe.
_test2._tcp.nadia.moe. 300 IN SRV 1 1 0 .

They should return the expected when querying it:

22:43:36 ~/Staging/react-dns-repro $> dig +short SRV _test1._tcp.nadia.moe
1 1 6969 nadia.moe.
22:44:14 ~/Staging/react-dns-repro $> dig +short SRV _test2._tcp.nadia.moe
1 1 0 .

Note the literal . when resolving _test2._tcp.nadia.moe. This . character is not present in the response from React/DNS:

<?php

use React\Dns\Config\Config;
use React\Dns\Resolver\Factory;
use React\Dns\Model\Message;

require __DIR__ . '/vendor/autoload.php';

$config = Config::loadSystemConfigBlocking();
if (!$config->nameservers) {
    $config->nameservers[] = '8.8.8.8';
}

$factory = new Factory();
$resolver = $factory->create($config);

$name='_test1._tcp.nadia.moe';
$resolver->resolveAll($name, Message::TYPE_SRV)->then(function (array $ips) use ($name) {
    var_dump($ips);
}, function (Exception $e) use ($name) {
    echo 'No IPv4 addresses for ' . $name . ': ' . $e->getMessage() . PHP_EOL;
});

$name='_test2._tcp.nadia.moe';
$resolver->resolveAll($name, Message::TYPE_SRV)->then(function (array $ips) use ($name) {
    var_dump($ips);
}, function (Exception $e) use ($name) {
    echo 'No IPv4 addresses for ' . $name . ': ' . $e->getMessage() . PHP_EOL;
});
array(1) {
  [0]=>
  array(4) {
    ["priority"]=>
    int(1)
    ["weight"]=>
    int(1)
    ["port"]=>
    int(6969)
    ["target"]=>
    string(9) "nadia.moe"
  }
}
array(1) {
  [0]=>
  array(4) {
    ["priority"]=>
    int(1)
    ["weight"]=>
    int(1)
    ["port"]=>
    int(0)
    ["target"]=>
    string(0) ""
  }
}

In the response above, one would expect target to be . instead of the empty string.

This is somewhat relevant because . has a special meaning for SRV records: As per https://datatracker.ietf.org/doc/html/rfc2782, clients must check for this value specified as a target, and understand by it that the service is not provided and should not attempt connection. In the case of movim, it is doing that in https://github.com/movim/movim/blob/5aaacc6b2e05f89fa41007cf7378a4568f648dde/linker.php#L144, but this check is failing as react dns does not return ., but an empty string.

I'm not entirely sure wheter this is expected behavior, but in case it was, perhaps it is worth stating somewhere.

Dominant language
PHP
Stars
542
Forks
62
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from reactphp/dns

All issues in reactphp/dns

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.