Commit Graph

104 Commits

Author SHA1 Message Date
Norman Maurer
3577a52809 Ignore invalid entries in /etc/resolv.conf when parsing (#9697)
Motivation:

We should just ignore (and so skip) invalid entries in /etc/resolver.conf.

Modifications:

- Skip invalid entries
- Add unit test

Result:

Fix https://github.com/netty/netty/issues/9684
2019-10-22 14:34:17 +02:00
Nick Hill
a84bd61631 Fix DnsNameResolver TCP fallback test and message leaks (#9647)
Motivation

A memory leak related to DNS resolution was reported in #9634,
specifically linked to the TCP retry fallback functionality that was
introduced relatively recently. Upon inspection it's apparent that there
are some error paths where the original UDP response might not be fully
released, and more significantly the TCP response actually leaks every
time on the fallback success path.

It turns out that a bug in the unit test meant that the intended TCP
fallback path was not actually exercised, so it did not expose the main
leak in question.

Modifications

- Fix DnsNameResolverTest#testTruncated0 dummy server fallback logic to
first read transaction id of retried query and use it in replayed
response
- Adjust semantic of internal DnsQueryContext#finish method to always
take refcount ownership of passed in envelope
- Reorder some logic in DnsResponseHandler fallback handling to verify
the context of the response is expected, and ensure that the query
response are either released or propagated in all cases. This also
reduces a number of redundant retain/release pairings

Result

Fixes #9634
2019-10-14 16:34:18 +02:00
Norman Maurer
1a53df1031 Detect truncated responses caused by EDNS0 and MTU miss-match (#9468)
Motivation:

It is possible that the user uses a too big EDNS0 setting for the MTU and so we may receive a truncated datagram packet. In this case we should try to detect this and retry via TCP if possible

Modifications:

- Fix detecting of incomplete records
- Mark response as truncated if we did not consume the whole packet
- Add unit test

Result:

Fixes https://github.com/netty/netty/issues/9365
2019-08-17 09:58:40 +02:00
Norman Maurer
a1742d95da DnsNameResolverTest.testTruncated0(...) should only close socket once envelope is received (#9469)
Motivation:

We should only ever close the underlying tcp socket once we received the envelope to ensure we never race in the test.

Modifications:

- Only close socket once we received the envelope
- Set REUSE_ADDR

Result:

More robust test
2019-08-15 16:28:56 +02:00
Norman Maurer
780536ba72 Fix flaky DnsNameResolverTest.testTruncatedWithTcpFallback (#9262)
Motivation:

testTruncatedWithTcpFallback was flacky as we may end up closing the socket before we could read all data. We should only close the socket after we succesfully read all data.

Modifications:

Move socket.close() to finally block

Result:

Fix flaky test and so make the CI more stable again.
2019-06-21 09:29:15 +02:00
Norman Maurer
211dde4e08 Add support for TCP fallback when we receive a truncated DnsResponse (#9139)
Motivation:

Sometimes DNS responses can be very large which mean they will not fit in a UDP packet. When this is happening the DNS server will set the TC flag (truncated flag) to tell the resolver that the response was truncated. When a truncated response was received we should allow to retry via TCP and use the received response (if possible) as a replacement for the truncated one.

See https://tools.ietf.org/html/rfc7766.

Modifications:

- Add support for TCP fallback by allow to specify a socketChannelFactory / socketChannelType on the DnsNameResolverBuilder. If this is set to something different then null we will try to fallback to TCP.
- Add decoder / encoder for TCP
- Add unit tests

Result:

Support for TCP fallback as defined by https://tools.ietf.org/html/rfc7766 when using DnsNameResolver.
2019-05-17 14:47:10 +02:00
Norman Maurer
debc1cbc0a DnsNameResolver.resolveAll(DnsQuestion) should not try to filter duplicates (#9141)
Motivation:

https://github.com/netty/netty/pull/9021 did apply some changes to filter out duplicates InetAddress when calling resolveAll(...) to mimic JDK behaviour. Unfortunally this also introduced a regression as we should not filter duplicates when the user explicit calls resolveAll(DnsQuestion).

Modifications:

- Only filter duplicates if resolveAll(String) is used
- Add unit test

Result:

Fixes regressions introduces by https://github.com/netty/netty/pull/9021
2019-05-13 06:59:28 +02:00
Norman Maurer
83210c47ca Allow to have DnsNameResolver.resolveAll(...) notify as soon as the preferred records were resolved (#9136)
Motivation:

075cf8c02e introduced a change to allow resolve(...) to notify as soon as the preferred record was resolved. This works great but we should also allow the user to configure that we want to do the same for resolveAll(...), which means we should be able to notify as soon as all records for a preferred record were resolved.

Modifications:

- Add a new DnsNameResolverBuilder method to allow configure this (use false as default to not change default behaviour)
- Add unit test

Result:

Be able to speed up resolving.
2019-05-09 08:08:47 +02:00
Norman Maurer
0523c781e8 DnsNameResolver.resolve(...) should notify future as soon as one preferred record was resolved (#9050)
Motivation:

At the moment resolve(...) does just delegate to resolveAll(...) and so will only notify the future once all records were resolved. This is wasteful as we are only interested in the first record anyway. We should notify the promise as soon as one record that matches the preferred record type is resolved.

Modifications:

- Introduce DnsResolveContext.isCompleteEarly(...) to be able to detect once we should early notify the promise.
- Make use of this early detecting if resolve(...) is called
- Remove FutureListener which could lead to IllegalReferenceCountException due double releases
- add unit test

Result:

Be able to notify about resolved host more quickly.
2019-04-15 21:50:28 +02:00
Norman Maurer
54f102feb9 DnsNameResolver.resolveAll(...) should also contain non preferred addresses (#9044)
Motivation:

At the moment we basically drop all non prefered addresses when calling DnsNameResolver.resolveAll(...). This is just incorrect and was introduced by 4cd39cc4b3. More correct is to still retain these but sort the returned List to have the prefered addresses on the beginning of the List. This also ensures resolve(...) will return the correct return type.

Modifications:

- Introduce PreferredAddressTypeComperator which we use to sort the List so it will contain the preferred address type first.
- Add unit test to verify behaviour

Result:

Include not only preferred addresses in the List that is returned by resolveAll(...)
2019-04-15 10:33:04 +02:00
Norman Maurer
7c35781f4d
DefaultPromise may throw checked exceptions that are not advertised (#8995)
Motivation:

We should not throw check exceptions when the user calls sync*() but should better wrap it in a CompletionException to make it easier for people to reason about what happens.

Modifications:

- Change sync*() to throw CompletionException
- Adjust tests
- Add some more tests

Result:

Fixes https://github.com/netty/netty/issues/8521.
2019-04-10 07:15:31 +02:00
Norman Maurer
dbd2282abe DnsNameResolver should log in trace level if notification of the promise fails (#9022)
Motivation:

During investigating some other bug I noticed that we log with warn level if we fail to notify the promise due the fact that it is already full-filled. This is not correct and missleading as there is nothing wrong with it in general. A promise may already been fullfilled because we did multiple queries and one of these was successful.

Modifications:

- Change log level to trace
- Add unit test which before did log with warn level but now does with trace level.

Result:

Less missleading noise in the log.
2019-04-10 07:14:18 +02:00
Norman Maurer
4bd068edf0 DnsNameResolver.resolveAll(...) should not include duplicates (#9021)
Motivation:

DnsNameResolver#resolveAll(String) may return duplicate results in the event that the original hostname DNS response includes an IP address X and a CNAME that ends up resolving the same IP address X. This behavior is inconsistent with the JDK’s resolver and is unexpected to retrun a List with duplicate entries from a resolveAll(..) call.

Modifications:

- Filter out duplicates
- Add unit test

Result:

More consistent and less suprising behavior
2019-04-09 09:49:42 +02:00
Norman Maurer
7b5f4e0227 Add unit test for query TXT records. (#8923)
Motivation:

We did not have any unit tests that queries for TXT records.

Modifications:

Add unit test to query TXT records.

Result:

More test-coverage.
2019-03-09 21:42:09 +01:00
田欧
6222101924 migrate java8: use lambda and method reference (#8781)
Motivation:

We can use lambdas now as we use Java8.

Modification:

use lambda function for all package, #8751 only migrate transport package.

Result:

Code cleanup.
2019-01-29 14:06:05 +01:00
田欧
e941cbe27a remove unused import statement (#8792)
Motivation:
The code contained some unused import statements.

Modification:
Remove unused import statements.

Result:
Code cleanup
2019-01-28 16:50:15 +01:00
田欧
934a07fbe2 migrate java8 (#8779)
Motivation:

We can omit argument types when using Java8.

Modification:

Omit arguments where possible.

Result:

Cleaner code.
2019-01-28 05:55:30 +01:00
kezhenxu94
7b6336f1fd Java 8 Migration: remove uneccessary if statement (#8755)
Motivation:

As netty 4.x supported Java 6 we had various if statements to check for java versions < 8. We can remove these now.

Modification:

Remove unnecessary if statements that check for java versions < 8.

Result:

Cleanup code.
2019-01-25 08:57:11 +01:00
Norman Maurer
3d6e6136a9
Decouple EventLoop details from the IO handling for each transport to… (#8680)
* Decouble EventLoop details from the IO handling for each transport to allow easy re-use of code and customization

Motiviation:

As today extending EventLoop implementations to add custom logic / metrics / instrumentations is only possible in a very limited way if at all. This is due the fact that most implementations are final or even package-private. That said even if these would be public there are the ability to do something useful with these is very limited as the IO processing and task processing are very tightly coupled. All of the mentioned things are a big pain point in netty 4.x and need improvement.

Modifications:

This changeset decoubled the IO processing logic from the task processing logic for the main transport (NIO, Epoll, KQueue) by introducing the concept of an IoHandler. The IoHandler itself is responsible to wait for IO readiness and process these IO events. The execution of the IoHandler itself is done by the SingleThreadEventLoop as part of its EventLoop processing. This allows to use the same EventLoopGroup (MultiThreadEventLoupGroup) for all the mentioned transports by just specify a different IoHandlerFactory during construction.

Beside this core API change this changeset also allows to easily extend SingleThreadEventExecutor / SingleThreadEventLoop to add custom logic to it which then can be reused by all the transports. The ideas are very similar to what is provided by ScheduledThreadPoolExecutor (that is part of the JDK). This allows for example things like:

  * Adding instrumentation / metrics:
    * how many Channels are registered on an SingleThreadEventLoop
    * how many Channels were handled during the IO processing in an EventLoop run
    * how many task were handled during the last EventLoop / EventExecutor run
    * how many outstanding tasks we have
    ...
    ...
  * Implementing custom strategies for choosing the next EventExecutor / EventLoop to use based on these metrics.
  * Use different Promise / Future / ScheduledFuture implementations
  * decorate Runnable / Callables when submitted to the EventExecutor / EventLoop

As a lot of functionalities are folded into the MultiThreadEventLoopGroup and SingleThreadEventLoopGroup this changeset also removes:

  * AbstractEventLoop
  * AbstractEventLoopGroup
  * EventExecutorChooser
  * EventExecutorChooserFactory
  * DefaultEventLoopGroup
  * DefaultEventExecutor
  * DefaultEventExecutorGroup

Result:

Fixes https://github.com/netty/netty/issues/8514 .
2019-01-23 08:32:05 +01:00
Dmitriy Dumanskiy
7b92ff2500 Java 8 migration. Remove ThreadLocalProvider and inline java.util.concurrent.ThreadLocalRandom.current() where necessary. (#8762)
Motivation:

Custom Netty ThreadLocalRandom and ThreadLocalRandomProvider classes are no longer needed and can be removed.

Modification:

Remove own ThreadLocalRandom

Result:

Less code to maintain
2019-01-22 20:14:28 +01:00
田欧
9d62deeb6f Java 8 migration: Use diamond operator (#8749)
Motivation:

We can use the diamond operator these days.

Modification:

Use diamond operator whenever possible.

Result:

More modern code and less boiler-plate.
2019-01-22 16:07:26 +01:00
Norman Maurer
cd78d24761 Only handle NXDOMAIN as failure when nameserver is authoritive or no other nameservers are left. (#8731)
Motivation:

When using multiple nameservers and a nameserver respond with NXDOMAIN we should only fail the query if the nameserver in question is authoritive or no nameservers are left to try.

Modifications:

- Try next nameserver if NXDOMAIN was returned but the nameserver is not authoritive
- Adjust testcase to respect correct behaviour.

Result:

Fixes https://github.com/netty/netty/issues/8261
2019-01-18 21:07:11 +01:00
Norman Maurer
1fe931b6e2
Make it possible to use a wrapped EventLoop with a Channel (#8677)
Motiviation:

Because of how we implemented the registration / deregistration of an EventLoop it was not possible to wrap an EventLoop implementation and use it with a Channel.

Modification:

- Introduce EventLoop.Unsafe which is responsible for the actual registration.
- Move validation of EventLoop / Channel combo to the EventLoop
- Add unit test that verifies that wrapping works

Result:

Be able to wrap an EventLoop and so add some extra functionality.
2019-01-17 09:17:51 +01:00
Norman Maurer
c10ccc5dec
Tighten contract between Channel and EventLoop by require the EventLoop on Channel construction. (#8587)
Motivation:

At the moment it’s possible to have a Channel in Netty that is not registered / assigned to an EventLoop until register(...) is called. This is suboptimal as if the Channel is not registered it is also not possible to do anything useful with a ChannelFuture that belongs to the Channel. We should think about if we should have the EventLoop as a constructor argument of a Channel and have the register / deregister method only have the effect of add a Channel to KQueue/Epoll/... It is also currently possible to deregister a Channel from one EventLoop and register it with another EventLoop. This operation defeats the threading model assumptions that are wide spread in Netty, and requires careful user level coordination to pull off without any concurrency issues. It is not a commonly used feature in practice, may be better handled by other means (e.g. client side load balancing), and therefore we propose removing this feature.

Modifications:

- Change all Channel implementations to require an EventLoop for construction ( + an EventLoopGroup for all ServerChannel implementations)
- Remove all register(...) methods from EventLoopGroup
- Add ChannelOutboundInvoker.register(...) which now basically means we want to register on the EventLoop for IO.
- Change ChannelUnsafe.register(...) to not take an EventLoop as parameter (as the EventLoop is supplied on custruction).
- Change ChannelFactory to take an EventLoop to create new Channels and introduce ServerChannelFactory which takes an EventLoop and one EventLoopGroup to create new ServerChannel instances.
- Add ServerChannel.childEventLoopGroup()
- Ensure all operations on the accepted Channel is done in the EventLoop of the Channel in ServerBootstrap
- Change unit tests for new behaviour

Result:

A Channel always has an EventLoop assigned which will never change during its life-time. This ensures we are always be able to call any operation on the Channel once constructed (unit the EventLoop is shutdown). This also simplifies the logic in DefaultChannelPipeline a lot as we can always call handlerAdded / handlerRemoved directly without the need to wait for register() to happen.

Also note that its still possible to deregister a Channel and register it again. It's just not possible anymore to move from one EventLoop to another (which was not really safe anyway).

Fixes https://github.com/netty/netty/issues/8513.
2019-01-14 20:11:13 +01:00
Norman Maurer
6ed296b719 Correctly detect and handle CNAME loops. (#8691)
Motivation:

We do not correctly detect loops when follow CNAMEs and so may try to follow it without any success.

Modifications:

- Correctly detect CNAME loops
- Do not cache CNAME entries which point to itself
- Add unit test.

Result:

Fixes https://github.com/netty/netty/issues/8687.
2019-01-14 08:17:51 +01:00
kashike
c0aa1ea5c7 Fix minor spelling issues in javadocs (#8701)
Motivation:

Javadocs contained some spelling errors, we should fix these.

Modification:

Fix spelling

Result:

Javadoc cleanup.
2019-01-14 07:25:13 +01:00
Stephane Landelle
f4cf674f01 Fix NPE when trying to build a DnsNameResolver with a null resolvedAddressTypes (#8445)
Motivation:

It should be possible to build a DnsNameResolver with a null resolvedAddressTypes, defaulting then to DEFAULT_RESOLVE_ADDRESS_TYPES (see line 309).

Sadly, `preferredAddressType` is then called on line 377 with the original parameter instead of the instance attribute, causing an NPE when it's null.

Modification:

Call preferredAddressType with instance attribuet instead of constructor parameter.

Result:

No more NPE
2018-10-30 13:15:16 +01:00
Norman Maurer
2a4bb346cf
Correctly parse /etc/resolv.conf when contain multiple entries for searchdomain. (#8351)
Motivation:

ba594bcf4a added a utility to parse searchdomains defined in /etc/resolv.conf but did not correctly handle the case when multiple are defined that are seperated by either whitespace or tab.

Modifications:

- Correctly parse multiple entries
- Add unit test.

Result:

Correctly parse multiple searchdomain entries.
2018-10-12 05:00:32 +02:00
Norman Maurer
5650db5826
Add cache for CNAME mappings resolved during lookup of DNS entries. (#8314)
* Add cache for CNAME mappings resolved during lookup of DNS entries.

Motivation:

If the CNAMEd hostname is backed by load balancing component, typically the final A or AAAA DNS records have small TTL. However, the CNAME record itself is setup with longer TTL.

For example:
* x.netty.io could be CNAMEd to y.netty.io with TTL of 5 min
* A / AAAA records for y.netty.io has a TTL of 0.5 min

In current Netty implementation, original hostname is saved in resolved cached with the TTL of final A / AAAA records. When that cache entry expires, Netty recursive resolver sends at least two queries — 1st one to be resolved as CNAME record and the 2nd one to resolve the hostname in CNAME record.
If CNAME record was cached, only the 2nd query would be needed most of the time. 1st query would be needed less frequently.

Modifications:

Add a new CnameCache that will be used to cache CNAMEs and so may reduce queries.

Result:

Less queries needed when CNAME is used.
2018-09-27 17:05:35 +02:00
Matt Ayres
ba594bcf4a Fixed illegal reflective access by not relying on a sun.net.dns class. (#8318) (#8319)
Motivation

Applications should not depend on internal packages with Java 9 and later. This cause a warning now, but will break in future versions of Java.

Modification

This change adds methods to UnixResolverDnsServerAddressStreamProvider (following after #6844) that parse /etc/resolv.conf for domain and search entries. Then DnsNameResolver does not need to rely on sun.net.dns.ResolverConfiguration to do this.

Result

Fixes #8318. Furthermore, at least in my testing with Java 11, this also makes multiple search entries work properly (previously I was only getting the first entry).
2018-09-26 20:55:46 +02:00
Norman Maurer
9eb124bb62
Don't cause ClassCastException if registration fails during constructing DnsNameResolver. (#8280)
Motivation:

We should not try to cast the Channel to a DatagramChannel as this will cause a ClassCastException.

Modifications:

- Do not cast
- rethrow from constructor if we detect the registration failed.
- Add unit test.

Result:

Propagate correct exception.
2018-09-11 20:34:37 +02:00
Norman Maurer
bbb6e126b1
Correctly handle DNS redirects for NS servers that have no ADDITIONAL record (#8177)
Motiviation:

We incorrectly did ignore NS servers during redirect which had no ADDITIONAL record. This could at worse have the affect that we failed the query completely as none of the NS servers had a ADDITIONAL record. Beside this using a DnsCache to cache authoritative nameservers does not work in practise as we we need different features and semantics when cache these servers (for example we also want to cache unresolved nameservers and resolve these on the fly when needed).

Modifications:

- Correctly take NS records into account that have no matching ADDITIONAL record
- Correctly handle multiple ADDITIONAL records for the same NS record
- Introduce AuthoritativeDnsServerCache as a replacement of the DnsCache when caching authoritative nameservers + adding default implementation
- Add an adapter layer to reduce API breakage as much as possible
- Replace DnsNameResolver.uncachedRedirectDnsServerStream(...) with newRedirectDnsServerStream(...)
- Add unit tests

Result:

Our DnsResolver now correctly handle redirects in all cases.
2018-08-22 17:49:22 +02:00
Norman Maurer
f22781f176
Correctly handle hostnames with and without trailing dot in the DefaultDnsCache and use it for searchdomains. (#8181)
Motivation:

We should ensure we return the same cached entries for the hostname and hostname ending with dot. Beside this we also should use it for the searchdomains as well.

Modifications:

- Internally always use hostname with a dot as a key and so ensure we correctly handle it in the cache.
- Also query the cache for each searchdomain
- Add unit tests

Result:

Use the same cached entries for hostname with and without trailing dot. Query the cache for each searchdomain query as well
2018-08-10 08:53:59 +02:00
Norman Maurer
56eb1e92cc
Add tests to verify caches are cleared when the resolver is closed. (#8186)
Motivation:

55fec94592 fixed a bug where we did not correctly clear all caches when the resolver was closed but did not add a testcase.

Modifications:

Add testcase.

Result:

More tests.
2018-08-10 08:46:15 +02:00
Scott Mitchell
b3b04d0de2 DnsNameResolver hangs if search domain results in invalid hostname (#8180)
Motivation:
DnsNameResolver manages search domains and will retry the request with the different search domains provided to it. However if the query results in an invalid hostname, the Future corresponding to the resolve request will never be completed.

Modifications:
- If a resolve attempt results in an invalid hostname and the query isn't issued we should fail the associated promise

Result:
No more hang from DnsNameResolver if search domain results in invalid hostname.
2018-08-08 08:14:18 +02:00
Norman Maurer
83710cb2e1
Replace toArray(new T[size]) with toArray(new T[0]) to eliminate zero-out and allow the VM to optimize. (#8075)
Motivation:

Using toArray(new T[0]) is usually the faster aproach these days. We should use it.

See also https://shipilev.net/blog/2016/arrays-wisdom-ancients/#_conclusion.

Modifications:

Replace toArray(new T[size]) with toArray(new T[0]).

Result:

Faster code.
2018-06-29 07:56:04 +02:00
Norman Maurer
369d64c3e6
Always follow cnames even if a matching A or AAAA record was found. (#7919)
Motivation:

At the moment if you do a resolveAll and at least one A / AAAA record is present we will not follow any CNAMEs that are also present. This is different to how the JDK behaves.

Modifications:

- Allows follow CNAMEs.
- Add unit test.

Result:

Fixes https://github.com/netty/netty/issues/7915.
2018-05-09 13:48:20 +02:00
Norman Maurer
f01a590154
Enfore upper limit for minTtl when using DefaultCacheEntry. (#7920)
Motivation:

a598c3b69b added a upper limit for ttl but missed to also do the same for minTtl.

Modifications:

- Add upper limit for minTtl
- Add testcase.

Result:

No more IllegalArgumentException possible.
2018-05-09 08:57:20 +02:00
Norman Maurer
18b170bd7a
Cleanup resolver-dns test code. (#7916)
Motivation:

We had some stuff that could be cleaned up in the resolver-dns test classes.

Modifications:

Cleanup code.

Result:

Cleaner code.
2018-05-08 08:55:17 +02:00
Norman Maurer
d03bd44e9d
Add test for caching failed queries in DefaultDnsCache. (#7909)
Motivation:

We had no test that validated the handling of caching failures for DefaultDnsCache.

Modifications:

Add testcase.

Result:

More tests FTW.
2018-05-04 20:09:38 +02:00
Norman Maurer
b83328606f
DefaultDnsCache should store more then one Entry per hostname. (#7906)
Motivation:

Due a bug we did never store more then one address per hostname in DefaultDnsCache.

Modifications:

- Correctly store multiple entries per hostname
- Add tests

Result:

DefaultDnsCache correctly stores more then one entry. Also fixes https://github.com/netty/netty/issues/7882 .
2018-05-04 14:19:26 +02:00
Norman Maurer
a598c3b69b
Enforce sane upper limit for TTL in DefaultDnsCache. (#7907)
Motivation:

In b47fb81799 we limited the max supported delay to match what our internal implementat can support. Because of this it was possible that DefaultDnsCache produced an IllegalArgumentException when it tried to schedule a expiration > 3 years.

Modifications:

Limit the max supported TTL to 2 years which is safe for all our EventLoop implementations.

Result:

No more exceptions when adding records to the cache with a huge TTL.
2018-05-04 13:38:08 +02:00
Alexey Kachayev
c0ae5e697c DnsAddressResolverGroup to use pluggable DnsNameResolverBuilder (#7793)
Motivation:

Right now to customize DNS name resolver when using DnsAddressResolverGroup
one should subclass implementation and override newNameResolver method when
in fact it's possible to collect all settings in a DnsNameResolverBuilder
instance. Described in #7749.

Modifications:

- Added new constructor for DnsNameResolverBuilder in order to delay
  EventLoop specification

- Added copy() method to DnsNameResolverBuilder to provide an immutable
  copy of the builder

- Added new single-argument constructor for DnsAddressResolverGroup and
  RoundRobinDnsAddressResolverGroup accepting DnsNameResolverBuilder
  instance

- DnsAddressResolverGroup to build a new resolver using DnsNameResolverBuilder
  given instead of creating a new one

- Test cases to check that changing channelFactory after the builder was passed
  to create a DnsNameResolverGroup would not propagate to the name resolver

Result:

Much easier to customize DNS settings w/o subclassing DnsAddressResolverGroup
2018-04-26 08:04:01 +02:00
Anuraag Agrawal
4cd39cc4b3 Filter DNS results so they only contain the expected type when multiple types are present. (#7875)
Motivation:

Currently, if a DNS server returns a non-preferred address type before the preferred one, then both will be returned as the result, and when only taking a single one, this usually ends up being the non-preferred type. However, the JDK requires lookups to only return the preferred type when possible to allow for backwards compatibility.

To allow a client to be able to resolve the appropriate address when running on a machine that does not support IPv6 but the DNS server returns IPv6 addresses before IPv4 addresses when querying.

Modification:

Filter the returned records to the expected type when both types are present.

Result:

Allows a client to run on a machine with IPv6 disabled even when a server returns both IPv4 and IPv6 results. Netty-based code can be a drop-in replacement for JDK-based code in such circumstances.

This PR filters results before returning them to respect JDK expectations.
2018-04-19 10:52:22 +02:00
Trustin Lee
cd4594d292 Add DnsNameResolver.resolveAll(DnsQuestion) (#7803)
* Add DnsNameResolver.resolveAll(DnsQuestion)

Motivation:

A user is currently expected to use DnsNameResolver.query() when he or
she wants to look up the full DNS records rather than just InetAddres.

However, query() only performs a single query. It does not handle
/etc/hosts file, redirection, CNAMEs or multiple name servers.

As a result, such a user has to duplicate all the logic in
DnsNameResolverContext.

Modifications:

- Refactor DnsNameResolverContext so that it can send queries for
  arbitrary record types.
  - Rename DnsNameResolverContext to DnsResolveContext
  - Add DnsAddressResolveContext which extends DnsResolveContext for
    A/AAAA lookup
  - Add DnsRecordResolveContext which extends DnsResolveContext for
    arbitrary lookup
- Add DnsNameResolverContext.resolveAll(DnsQuestion) and its variants
- Change DnsNameResolverContext.resolve() delegates the resolve request
  to resolveAll() for simplicity
- Move the code that decodes A/AAAA record content to DnsAddressDecoder

Result:

- Fixes #7795
- A user does not have to duplicate DnsNameResolverContext in his or her
  own code to implement the usual DNS resolver behavior.
2018-03-29 22:01:25 +02:00
Shohei Kamimori
73f23c5faa Fix typos in docs.
Motivation:

There are same typos in the docs.

Modifications:

Fix typos. Docs only changing.

Result:

More correct docs.
2018-02-14 08:44:07 +01:00
Scott Mitchell
fe5c69bdd9 DnsNameResolverContext#followCname only uses first name server
Motivation:
When following a CNAME it is possible there are multiple name servers to query against. However DnsNameResolverContext#followCname explicitly only uses the first name server address when attempting the query. This may lead to resolution failures because we didn't try all the available name servers.

Modifications:
DnsNameResolverContext#followCname should not just try the first name server, but it should try all name servers

Result:
More complete CNAME resolution.
2018-02-01 09:31:07 +01:00
Norman Maurer
b874edbf65 DefaultDnsCache should expire all records per hostname when one TTL is reached.
Motivation:

At the moment DefaultDnsCache will expire each record dependong on its own TTL. This may result in unexpected results for the end-user especially if the user for example uses IPV4_PREFERED but the cached AAAA records has a higher TTL then the A records and so the A record was removed. In this case we would only return the AAAA record and not even try to refresh.

Modifications:

Always expire all records for a hostname when one TTL is reached.

Result:

Fixes [#7329]
2018-01-31 14:39:31 +01:00
Scott Mitchell
83bca87257
Update domains in DnsNameResolverTest
Motivation:
DnsNameResolverTest has not been updated in a while.

Modifications:
- Update the DOMAINS definition in DnsNameResolverTest

Result:
More current domain names.
2018-01-02 19:08:40 -05:00
Norman Maurer
c1b1d6268a Allow to detect failed query caused by an Timeout / IO error and also not cache these.
Motivation:

At the moment there is not way for the user to know if resolving a domain was failed because the domain was unkown or because of an IO error / timeout. If it was caused by an timeout / IO error the user may want to retry the query. Also if the query was failed because of an IO error / timeout we should not cache it.

Modifications:

- Add DnsNameResolverTimeoutException and include it in the UnkownHostException if the domain could not be resolved because of an timeout. This will allow the user to retry the query when inspecting the cause.
- Do not cache IO errors / timeouts
- Add unit test

Result:

Easier for users to implement retries for DNS querys and not cache IO errors / timeouts.
2017-11-23 10:56:41 +01:00