[
https://issues.apache.org/jira/browse/HADOOP-20020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18127000#comment-18127000
]
ASF GitHub Bot commented on HADOOP-20020:
-----------------------------------------
smengcl opened a new pull request, #8820:
URL: https://github.com/apache/hadoop/pull/8820
Generated-by: Claude Code (Opus 5.5)
### Description of PR
`DNS.reverseDns` reads `attribute.get("PTR").get()` without a null check.
When a DNS server answers the reverse query with NOERROR but no PTR record (a
NODATA answer), JNDI returns no `PTR` attribute and `reverseDns` throws
`NullPointerException`. Its callers, `DNS.getHosts` and
`DNSDomainNameResolver.getHostnameByIP`, only catch `NamingException`, so the
exception escapes instead of falling back. Through `getHostnameByIP` it reaches
`SecurityUtil.getServerPrincipal(String, InetAddress)` and
`ServiceAuthorizationManager.authorize`.
This PR throws `NameNotFoundException` in that case, the exception JNDI
already throws when the name does not exist (NXDOMAIN). Answers that carry a
PTR record are handled as before. IPv4 and IPv6 addresses are affected alike.
### How was this patch tested?
Added `TestDNS#testReverseDnsWithoutPtrRecord`. It starts a small DNS
responder on a loopback UDP port that answers every query with NOERROR and no
records, and checks that the reverse lookup of an IPv4 and an IPv6 address
fails with `NameNotFoundException`. On trunk the test fails with the
`NullPointerException`.
`mvn test -Dtest='TestDNS,TestSecurityUtil,TestNetUtils'` in `hadoop-common`
with JDK 17: 91 tests run, 0 failures, 0 errors, 0 skipped.
### For code changes:
- [x] Does the title of this PR start with the corresponding JIRA issue id
(e.g. 'HADOOP-17799. Your PR title ...')?
- [ ] Object storage: Have the integration tests been executed and the
endpoint
declared according to the connector-specific documentation? *Note:
Automated CI
testing doesn't cover all cases so manual testing with cloud storage
is still
required.*
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the `LICENSE`, `LICENSE-binary`,
`NOTICE-binary` files?
### AI Tooling
Contains content generated by Claude Code.
- [x] The PR includes the phrase "Contains content generated by <tool>"
where <tool> is the name of the AI tool used.
- [x] My use of AI contributions follows the ASF legal policy
https://www.apache.org/legal/generative-tooling.html
🤖 Generated with [Claude Code](https://claude.com/claude-code)
> DNS.reverseDns throws NullPointerException when the answer has no PTR record
> ----------------------------------------------------------------------------
>
> Key: HADOOP-20020
> URL: https://issues.apache.org/jira/browse/HADOOP-20020
> Project: Hadoop Common
> Issue Type: Bug
> Reporter: Siyao Meng
> Assignee: Siyao Meng
> Priority: Major
>
> {{DNS.reverseDns}} reads {{attribute.get("PTR").get()}} without a null check.
> When the DNS server answers the reverse query with NOERROR but no PTR record
> (a NODATA answer), JNDI returns no PTR attribute and {{reverseDns}} throws
> {{NullPointerException}}.
> The callers, {{DNS.getHosts}} and {{DNSDomainNameResolver.getHostnameByIP}},
> only catch {{NamingException}}, so the exception escapes instead of falling
> back. Through {{getHostnameByIP}} it reaches
> {{SecurityUtil.getServerPrincipal(String, InetAddress)}} and
> {{ServiceAuthorizationManager.authorize}}. A name that does not exist
> (NXDOMAIN) already fails with {{NameNotFoundException}} and is handled.
> Throw {{NameNotFoundException}} when the answer has no PTR record. This
> applies to IPv4 and IPv6 addresses alike. It was seen with a resolver that
> answers NODATA for the {{ip6.arpa}} name of {{::}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
