Direct query to the server for a zone's SOA record fails
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 9
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
A query to the server for a zone's own SOA record returns NXDOMAIN, when I would expect it to return the SOA record for the zone. This appears to happen because the SOA record is in the Zone's soa property, not an element of the Zone's records array, so a match is not found by lookup() in Utopia\DNS\Zone\Resolver.
A possible fix would be to add an explicit check for a query for the SOA record in Utopia\DNS\Zone\Resolver::lookup() after the check for zero queries, just before selecting the best matching records.
// Return the zone's SOA record
if (($question->type === Record::TYPE_SOA) && ($question->name === $zone->name) {
return Message::response(
header: $query->header,
responseCode: Message::RCODE_NOERROR,
questions: $query->questions,
answers: [$zone->soa],
authoritative: true,
recursionAvailable: false
);
}
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in Utopia\DNS\Zone\Resolver::lookup(), after the zero-query check and before selecting the best matching records. Verify the behavior for a query whose type is SOA and whose name matches the zone; done means the response returns the zone's SOA record with NOERROR and authoritative status instead of NXDOMAIN.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 74/100