Avoid PTR lookup for loopback DNS resolution#4814
Open
oneby-wang wants to merge 1 commit into
Open
Conversation
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
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.
Descriptions of the changes in this PR:
Motivation
BookKeeper's
DNS.reverseDnscurrently performs a DNS PTR lookup for IPv4 loopback addresses such as127.0.0.1. A loopback address is local-only, so asking an external DNS server for1.0.0.127.in-addr.arpais unnecessary and can add avoidable network cost.This also makes local tests depend on router-specific DNS behavior. Some DNS servers return
NXDOMAINquickly for this PTR query, for example:However, some home routers do not return a standard DNS response for the same query:
In that environment, ordinary DNS resolution still works, for example
dig @192.168.1.1 google.comsucceeds. The issue is specific to reverse lookup of the loopback PTR record.I encountered this while running Pulsar's broker
AuditorLedgerCheckerTest, which starts multiple local BookKeeper bookies. The local bookie startup path tried to resolve the loopback interface address, the router DNS timed out on the PTR query for127.0.0.1, and the test could not start. Switching DNS to8.8.8.8made the test start again because that resolver returns quickly.Since loopback addresses are not externally meaningful, BookKeeper should not query external DNS for their PTR records. It can return the already cached local hostname, matching the existing fallback used by
DNS.getHostswhen no hostname can be determined.Changes
DNS.reverseDnswhen the IPv4 address is loopback.getPtrAttributesso the DNS query layer can be mocked in tests.DNSTestcoverage that simulates a DNS timeout and verifies127.0.0.1does not call the PTR lookup path.Tests
mvn -pl bookkeeper-server -Dtest=org.apache.bookkeeper.net.DNSTest -DfailIfNoTests=false test