fix(dns): resolve names under a numeric ending - #100
Merged
Conversation
The registry sells `.2600`. The resolver refused to resolve anything
under it:
alt.2600 28 forwarded -> NXDOMAIN from upstream
seo.rank 28 moshpit(backfill) -> answered
`moshpitCandidate` rejected every all-numeric ending outright, so a
registered name was never even looked up. Buying an ending that cannot
resolve is the worst possible failure: the registry takes the money and
the name is dead, with nothing in any log to say why.
The rule was protecting against address literals — `1.2.3.4` must never
be read as `3.4` in this namespace, or whoever registered `.4` could
intercept traffic meant for a machine. But the dotted-quad guard above it
already covers that, and the blanket version caught a much larger class
than it needed to.
Narrowed to what is actually address-shaped: a name whose *every* label is
numeric. `10.0.0.1` and `192.168` stay rejected; `alt.2600` resolves. The
registry still decides whether a name exists — this is only the shape
filter, and it should exclude what can never be a name rather than what
merely looks unusual.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
vu1nz Security Review0 finding(s) in PR #? No security issues found. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The registry sells
.2600. The resolver refused to resolve anything under it.moshpitCandidaterejected every all-numeric ending outright (policy.ts:65), so a registered name was never looked up.alt.2600is registered, points at2604:a880:400:d1:0:4:c3fe:1, and does not resolve — the registry takes the money and the name is dead, with nothing in any log saying why.Why the rule existed
Address literals.
1.2.3.4must never be read as3.4in this namespace, or whoever registered.4could intercept traffic meant for a machine. That is a real attack and the guard has to stay.But the dotted-quad check on the line above already covers it, and the blanket numeric-ending rule caught a far larger class than it needed to.
The narrower rule
A name whose every label is numeric is address-shaped. A numeric ending under a real label can only ever be a name.
10.0.0.1,1.2.3.4192.168,12.34alt.2600The registry still decides whether the name exists. This is only the shape filter, and it should exclude what can never be a name rather than what merely looks unusual.
Tests
Two new, plus one updated:
scrambled.123was asserted non-candidate, which is exactly the behaviour being changed, so it is rewritten rather than worked around. The address cases are asserted explicitly so the protection cannot be lost silently.144 pass, 0 fail.