Commit Graph

38 Commits

Author SHA1 Message Date
Stephane Landelle
b4be040f30 Introduce DnsCache API + DnsResolver extensibility
Motivation:
Caching is currently nested in DnsResolver.
It should also be possible to extend DnsResolver to ba able to pass a different cache on each resolution attemp.

Modifications:

* Introduce DnsCache, NoopDnsCache and DefaultDnsCache. The latter contains all the current caching logic that was extracted.
* Introduce protected versions of doResolve and doResolveAll that can be used as extension points to build resolvers that bypass the main cache and use a different one on each resolution.

Result:

Isolated caching logic. Better extensibility.
2016-01-08 14:46:47 +01:00
Xiaoyan Lin
a96d52fe66 Fix javadoc links and tags
Motivation:

There are some wrong links and tags in javadoc.

Modifications:

Fix the wrong links and tags in javadoc.

Result:

These links will work correctly in javadoc.
2015-12-26 08:34:31 +01:00
Stephane Landelle
8d4db050f3 Have hosts file support for DnsNameResolver, close #4074
Motivation:

On contrary to `DefaultNameResolver`, `DnsNameResolver` doesn't currently honor hosts file.

Modifications:

* Introduce `HostsFileParser` that parses `/etc/hosts` or `C:\Windows\system32\drivers\etc\hosts` depending on the platform
* Introduce `HostsFileEntriesResolver` that uses the former to resolve host names
* Make `DnsNameResolver` check his `HostsFileEntriesResolver` prior to trying to resolve names against the DNS server
* Introduce `DnsNameResolverBuilder` so we now have a builder for `DnsNameResolver`s
* Additionally introduce a `CompositeNameResolver` that takes several `NameResolver`s and tries to resolve names by delegating sequentially
* Change `DnsNameResolver.asAddressResolver` to return a composite and honor hosts file

Result:

Hosts file support when using `DnsNameResolver`.
Consistent behavior with JDK implementation.
2015-12-17 15:15:42 +01:00
Stephane Landelle
6393506b97 Extract SocketAdress logic from NameResolver
Motivation:

As discussed in #4529, NameResolver design shouldn't be resolving SocketAddresses (or String name + port) and return InetSocketAddresses. It should resolve String names and return InetAddresses.
This SocketAddress to InetSocketAddresses resolution is actually a different concern, used by Bootstrap.

Modifications:

Extract SocketAddress to InetSocketAddresses resolution concern to a new class hierarchy named AddressResolver.
These AddressResolvers delegate to NameResolvers.

Result:

Better separation of concerns.

Note that new AddressResolvers generate a bit more allocations because of the intermediate Promise and List<InetAddress>.
2015-12-14 14:03:50 +01:00
Trustin Lee
2fefb2f79c Make DnsNameResolverGroup non-final and overridable
Motivation:

There's no way to override the default settings of the DnsNameResolvers
created by DnsNameResolverGroup because DnsNameResolverGroup is final.

Modifications:

- Make DnsNameResolverGroup non-final
- Add a new overridable protected method 'newResolver()' so that a user
  can override it to create an alternative DnsNameResolver instance or
  set the non-default properties

Result:

A user can configure the DnsNameResolver.
2015-12-07 19:40:01 +09:00
Anuraag Agrawal
a3bdd8c948 Don't cycle DNS servers while cycling DNS record types.
Motivation:

Each server should be checked for every record type. Currently, if there
are only two configured servers and the first is down, it is impossible
to query for IPv4 addresses because the second server is only ever
queried for type AAAA.

Modifications:

Do not cycle DNS servers while cycling DNS record types (A and AAAA)

Result:

Name resolution is less fragile when the number of available DNS servers
is 2.
2015-12-07 18:32:39 +09:00
Norman Maurer
2ecce8fa56 [maven-release-plugin] prepare for next development iteration 2015-11-10 22:59:33 +01:00
Norman Maurer
6a93f331d3 [maven-release-plugin] prepare release netty-4.1.0.Beta8 2015-11-10 22:50:57 +01:00
Trustin Lee
120ffaf880 Use separate query ID space for different DNS servers
Related: #3972

Motivation:

DnsNameResolver limits the number of concurrent in-progress DNS queries
to 65536 regardless the number of DNS servers it communicates with. When
the number of available DNS servers are more than just one, we end up
using much less (65536 / numDnsServers) query IDs per DNS server, which
is non-optimal.

Modifications:

- Replace the query ID and context management with
  DnsQueryContextManager
  - Eash DNS server gets its own query ID space

Result:

Much bigger query ID space, and thus there's less chance of getting the
'query ID space exhaustion' error
2015-11-09 15:25:13 -08:00
Trustin Lee
07d861c5ff Fix a bug where DnsNameResolver attempts to send extra queries
Motivation:

When DnsNameResolverContext succeeds to get the address(es), it cancels
the promise of other queries in progress.

Unlike expectation, DnsNameResolverContext.query() attempts to retry
even when the query has failed due to cancellation.

As a result, the resolver sends unnecessary extra queries to a DNS
server and then tries to mark the promised that's been fulfilled
already, leading to unnecessarily verbose 'failed to notify success to a
promise' messages.

Modifications:

Do not perform an extra query when the previous query has failed due to
cancellation

Result:

DnsNameResolver does not send unnecessary extra queries and thus does
not log the 'failed to notify success to a promise' message.
2015-10-30 08:16:24 +01:00
Norman Maurer
42e6b8fa86 [#4289] Use a mock DNS Server for dns tests.
Motivation:

As relaying on external DNS Server can result to test-failures we should better use a mock DNS Server for the dns tests.

Modifications:

- Refactor the DnsNameResolverTest to use a mock DNS Server which is using apacheds.
- Allow to disable adding an opt resources as some servers not support it.

Result:

More stable testsuite.
2015-10-10 20:27:34 +02:00
Norman Maurer
2ff2806ada [maven-release-plugin] prepare for next development iteration 2015-10-02 09:03:29 +02:00
Norman Maurer
5a43de10f7 [maven-release-plugin] prepare release netty-4.1.0.Beta7 2015-10-02 09:02:58 +02:00
Trustin Lee
115d3576be Update the public DNS server list
Motivation:

Some DNS servers in DnsNameResolverTest are outdated and some of them
returns NoError for non-existent domains.

Modifications:

- Update the DNS server list from http://meo.ws/dnsrec.php again
- Update the web-scraper script

Result:

DnsNameResolverTest.testNegativeTtl() should not fail anymore.
2015-09-25 11:33:33 +09:00
Norman Maurer
34de2667c7 [maven-release-plugin] prepare for next development iteration 2015-09-02 11:45:20 +02:00
Norman Maurer
2eb444ec1d [maven-release-plugin] prepare release netty-4.1.0.Beta6 2015-09-02 11:36:11 +02:00
Trustin Lee
e1bf9d6257 Fix unintended timeout in negative DNS lookup cache test
Motivation:

DNS lookups in DnsNameResolverTest can take longer than expected due to
retries. The hard limit of 5 seconds is being applied to
testNegativeTtl(), making the first uncached lookup cause a timeout.

Modifications:

Do not use JUnit's Timeout annotation but implement simple timeout
mechanism that apples only to cached lookups.

Result:

testNegativeTtl() should not fail when an initial negative lookup
requires a retry.
2015-08-29 11:40:32 +09:00
Trustin Lee
d45ad9ec68 Add a bunch of OpenNIC DNS servers for more reliable DNS tests 2015-08-28 21:36:38 +09:00
Trustin Lee
73f472b65d Fix DNS lookup hang / Remove Comodo Secure DNS
Motivation:

- DNS lookup sometimes hang because it does not call
  tryToFinishResolve()
- Comodo Secure DNS handles negative lookup incorrectly.

Modifications:

- Add missing tryToFinishResolve()
- Remove Comodo Secure DNS servers from the list

Result

- DNS lookup does not hang on non-existent domain names
- More reliable DnsNameResolverTest
2015-08-27 12:52:29 +09:00
Trustin Lee
75efe016d6 Add more public DNS servers to DnsNameResolverTest
so that we have more chance of passing the test when some DNS servers
are unavailable or throtlling us.
2015-08-27 12:25:38 +09:00
Trustin Lee
719d1dbad1 Replace infinite Iterable/Iterator with dedicated types
Related: #4065

Motivation:

DnsNameResolver was using a special Iterable/Iterator implementation
that yields an infinite stream of DNS server addresses. However, this
seems to cause confusion.

Modifications:

- Make DnsServerAddresses an abstract class with an abstract stream()
  method that returns DnsServerAddressStream
- Add DnsServerAddressStream that yields DNS server address infinitely
- Remove DnsServerResolver(Group) constructors that accept only a single
  server address, which wasn't very useful in practice
- Extract the DnsServerAddresses implementations to top level
- DnsServerAddresses.defaultAddresses() now returns DnsServerAddresses.
  - Add DnsServerAddresses.defaultAddressList() instead

Result:

Less confusion and more explicitness
2015-08-26 17:38:43 +09:00
Trustin Lee
ad0b7ca56d Add a test case for DNS resolver cache for negative loopups
Related issue: #4065
2015-08-18 18:44:51 +09:00
Trustin Lee
1856ab3a35 Make DnsNameResolverTest.testQueryMx() more robust
Motivation:

DNS servers seem to reply with ServFail(2) response code when it is
busy.

Modifications:

- Retry when response code is ServFail instead of failing the test
- Try all DNS servers instead of retrying twice only

Result:

testQueryMx() is less likely to fail due to public DNS server problems
2015-08-18 18:26:11 +09:00
Trustin Lee
fdfe3149ba Provide more control over DnsNameResolver.query() / Add NameResolver.resolveAll()
Related issues:
- #3971
- #3973
- #3976
- #4035

Motivation:

1. Previously, DnsNameResolver.query() retried the request query by its
own. It prevents a user from deciding when to retry or stop. It is also
impossible to get the response object whose code is not NOERROR.

2. NameResolver does not have an operation that resolves a host name
into multiple addresses, like InetAddress.getAllByName()

Modifications:

- Changes related with DnsNameResolver.query()
  - Make query() not retry
    - Move the retry logic to DnsNameResolver.resolve() instead.
  - Make query() fail the promise only when I/O error occurred or it
    failed to get a response
  - Add DnsNameResolverException and use it when query() fails so that
    the resolver can give more information about the failure
  - query() does not cache anymore.

- Changes related with NameResolver.resolveAll()
  - Add NameResolver.resolveAll()
  - Add SimpleNameResolver.doResolveAll()

- Changes related with DnsNameResolver.resolve() and resolveAll()
  - Make DnsNameResolveContext abstract so that DnsNameResolver can
    decide to get single or multiple addresses from it
  - Re-implement cache so that the cache works for resolve() and
    resolveAll()
  - Add 'traceEnabled' property to enable/disable trace information

- Miscellaneous changes
  - Use ObjectUtil.checkNotNull() wherever possible
  - Add InternetProtocolFamily.addressType() to remove repetitive
    switch-case blocks in DnsNameResolver(Context)
  - Do not raise an exception when decoding a truncated DNS response

Result:

- Full control over query()
- A user can now retrieve all addresses via (Dns)NameResolver.resolveAll()
- DNS cache works only for resolve() and resolveAll() now.
2015-08-18 17:40:13 +09:00
Norman Maurer
d1344345bb DnsResolver.resolve(...) fails when ipaddress is used.
Motivation:

DnsResolver.resolve(...) fails when an InetSocketAddress is used that was constructed of an ipaddress string.

Modifications:

Don't try to lookup when the InetSocketAddress was constructed via an ipaddress.

Result:

DnsResolver.resolve(...) works in all cases.
2015-07-18 17:14:05 +02:00
Trustin Lee
311532feb0 Fix IllegalReferenceCountException in DnsNameResolver
Related: #3797

Motivation:

There is a race condition where DnsNameResolver.query() can attempt to
increase the reference count of the DNS response which was released
already by other thread.

Modifications:

- Make DnsCacheEntry a top-level class for clear access control
- Use 'synchronized' to avoid the race condition
  - Add DnsCacheEntry.retainedResponse() to make sure that the response
    is never released while it is retained
  - Make retainedResponse() return null when the response has been
    released already, so that DnsNameResolver.query() knows that the
    cached entry has been released

Result:

The forementioned race condition has been fixed.
2015-06-03 19:17:56 +09:00
Norman Maurer
f23b7b4efd [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
Norman Maurer
871ce43b1f [maven-release-plugin] prepare release netty-4.1.0.Beta5 2015-05-07 14:20:38 -04:00
Trustin Lee
63a02fc04e Revamp DNS codec
Motivation:

There are various known issues in netty-codec-dns:

- Message types are not interfaces, which can make it difficult for a
  user to implement his/her own message implementation.
- Some class names and field names do not match with the terms in the
  RFC.
- The support for decoding a DNS record was limited. A user had to
  encode and decode by him/herself.
- The separation of DnsHeader from DnsMessage was unnecessary, although
  it is fine conceptually.
- Buffer leak caused by DnsMessage was difficult to analyze, because the
  leak detector tracks down the underlying ByteBuf rather than the
  DnsMessage itself.
- DnsMessage assumes DNS-over-UDP.
- To send an EDNS message, a user have to create a new DNS record class
  instance unnecessarily.

Modifications:

- Make all message types interfaces and add default implementations
- Rename some classes, properties, and constants to match the RFCs
  - DnsResource -> DnsRecord
  - DnsType -> DnsRecordType
  - and many more
- Remove DnsClass and use an integer to support EDNS better
- Add DnsRecordEncoder/DnsRecordDecoder and their default
  implementations
  - DnsRecord does not require RDATA to be ByteBuf anymore.
  - Add DnsRawRecord as the catch-all record type
- Merge DnsHeader into DnsMessage
- Make ResourceLeakDetector track AbstractDnsMessage
- Remove DnsMessage.sender/recipient properties
  - Wrap DnsMessage with AddressedEnvelope
  - Add DatagramDnsQuest and DatagramDnsResponse for ease of use
  - Rename DnsQueryEncoder to DatagramDnsQueryEncoder
  - Rename DnsResponseDecoder to DatagramDnsResponseDecoder
- Miscellaneous changes
  - Add StringUtil.TAB

Result:

- Cleaner APi
- Can support DNS-over-TCP more easily in the future
- Reduced memory footprint in the default DnsQuery/Response
  implementations
- Better leak tracking for DnsMessages
- Possibility to introduce new DnsRecord types in the future and provide
  full record encoder/decoder implementation.
- No unnecessary instantiation for an EDNS pseudo resource record
2015-05-01 11:33:16 +09:00
Norman Maurer
fce0989844 [maven-release-plugin] prepare for next development iteration 2015-03-03 02:06:47 -05:00
Norman Maurer
ca3b1bc4b7 [maven-release-plugin] prepare release netty-4.1.0.Beta4 2015-03-03 02:05:52 -05:00
Trustin Lee
79bb200f59 Remove thepiratebay.se from the test domain list
.. due to its instability
2014-12-22 22:35:17 +09:00
Trustin Lee
23db94f5a1 Fix Java 6 compatibility issue in DnsNameResolver
Related: #3173

Motivation:

DnsNameResolver was using InetSocketAddress.getHostString() which is
only available since Java 7.

Modifications:

Use InetSocketAddress.getHostName() in lieu of getHostString() when the
current Java version is less than 7.

Result:

DnsNameResolver runs fine on Java 6.
2014-12-06 22:31:44 +09:00
Jay
2769ad428a Check the bindFuture before writing a DNS query
Related: #3149

Motivation:

DnsQueryContext, using the DatagramChannel bound in DnsNameResolver,
blindly writes to the channel without checking the bind future for
success.

Modifications:

Check the bindFuture before writing a DNS query to a DatagramChannel

Result:

Bug fixed
2014-12-01 19:46:18 +09:00
Trustin Lee
c0079840be Improve DnsNameResolverTest.testResolveA()
Motivation:

DnsNameResolver.testResolveA() tests if the cache works as well as the usual DNS protocol test.  To ensure the result from the cache is identical to the result without cache, it compares the two Maps which contain the result of cached/uncached resolution.  The comparison of two Maps yields an expected behavior, but the output of the comparison on failure is often unreadable due to its long length.

Modifications:

Compare entry-by-entry for more comprehensible test failure output

Result:

When failure occurs, it's easier to see which domain was the cause of the problem.
2014-10-25 17:29:06 +09:00
Trustin Lee
e1787e6876 Fix another resource leak in DnsNameResolver
- Fix a bug in cache expiration task; wrong object was being released
- Added more sanity checks when caching an entry
2014-10-17 11:40:06 +09:00
Trustin Lee
c811d50d61 Fix resource leak in DnsNameResolver 2014-10-16 17:57:32 +09:00
Trustin Lee
e848066cab Name resolver API and DNS-based name resolver
Motivation:

So far, we relied on the domain name resolution mechanism provided by
JDK.  It served its purpose very well, but had the following
shortcomings:

- Domain name resolution is performed in a blocking manner.
  This becomes a problem when a user has to connect to thousands of
  different hosts. e.g. web crawlers
- It is impossible to employ an alternative cache/retry policy.
  e.g. lower/upper bound in TTL, round-robin
- It is impossible to employ an alternative name resolution mechanism.
  e.g. Zookeeper-based name resolver

Modification:

- Add the resolver API in the new module: netty-resolver
- Implement the DNS-based resolver: netty-resolver-dns
  .. which uses netty-codec-dns
- Make ChannelFactory reusable because it's now used by
  io.netty.bootstrap, io.netty.resolver.dns, and potentially by other
  modules in the future
  - Move ChannelFactory from io.netty.bootstrap to io.netty.channel
  - Deprecate the old ChannelFactory
  - Add ReflectiveChannelFactory

Result:

It is trivial to resolve a large number of domain names asynchronously.
2014-10-16 17:05:20 +09:00