Commit Graph

214 Commits

Author SHA1 Message Date
root
a580dc7585 [maven-release-plugin] prepare for next development iteration 2018-08-24 06:36:33 +00:00
root
3fc789e83f [maven-release-plugin] prepare release netty-4.1.29.Final 2018-08-24 06:36:06 +00: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
2fa7a0aa57
Keep the amount of scheduled tasks for DefaultDnsCache at a minimum (#8187)
Motivation:

We are currently always remove all entries from the cache for a hostname if the lowest TTL was reached but schedule one for each of the cached entries. This is wasteful.

Modifications:

- Reimplement logic to schedule TTL to only schedule a new removal task if the requested TTL was actual lower then the one for the already scheduled task.
- Ensure we only remove from the internal map if we did not replace the Entries in the meantime.

Result:

Less overhead in terms of scheduled tasks for the DefaultDnsCache
2018-08-15 09:07:13 +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
55fec94592
Also clear the authoritativeDnsServerCache when closing the Channel. (#8174)
Motivation:

At the moment we only clear the resolveCache when the Channel is closed. We should also do the same for the authoritativeDnsServerCache.

Modifications:

Add authoritativeDnsServerCache.clear() to the Channel closeFuture.

Result:

Correctly clear all caches.
2018-08-06 08:31:17 +02:00
root
fcb19cb589 [maven-release-plugin] prepare for next development iteration 2018-07-27 04:59:28 +00:00
root
ff785fbe39 [maven-release-plugin] prepare release netty-4.1.28.Final 2018-07-27 04:59:06 +00:00
root
b4dbdc2036 [maven-release-plugin] prepare for next development iteration 2018-07-11 15:37:40 +00:00
root
1c16519ac8 [maven-release-plugin] prepare release netty-4.1.27.Final 2018-07-11 15:37:21 +00:00
root
7bb9e7eafe [maven-release-plugin] prepare for next development iteration 2018-07-10 05:21:24 +00:00
root
8ca5421bd2 [maven-release-plugin] prepare release netty-4.1.26.Final 2018-07-10 05:18:13 +00: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
a214f2eb96 Remove id from DnsQueryContextManager whenever the promise is fullfilled.
Motivation:

We did not handle the case when the query was cancelled which could lead to an exhausted id space. Beside this we did not not cancel the timeout on failed promises.

Modifications:

- Do the removal of the id from the manager in a FutureListener so its handled in all cases.
- Cancel the timeout whenever the original promise was full-filled.

Result:

Fixes https://github.com/netty/netty/issues/8013.
2018-06-27 10:20:59 +02:00
Norman Maurer
5e42e758be Also remove the id from the DnsQueryContextManager if query fails due parent Channel activation error.
Motivation:

Whenever we fail the query we should also remove the id from the DnsQueryContextManager.

Modifications:

Remove the id from the DnsQueryContextManager if we fail the query because the channel failed to become active.

Result:

More correct code.
2018-06-26 07:22:41 +02:00
Norman Maurer
64bb279f47 [maven-release-plugin] prepare for next development iteration 2018-05-14 11:11:45 +00:00
Norman Maurer
c67a3b0507 [maven-release-plugin] prepare release netty-4.1.25.Final 2018-05-14 11:11:24 +00: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
Norman Maurer
b75f44db9a [maven-release-plugin] prepare for next development iteration 2018-04-19 11:56:07 +00:00
Norman Maurer
04fac00c8c [maven-release-plugin] prepare release netty-4.1.24.Final 2018-04-19 11:55:47 +00: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
root
0a61f055f5 [maven-release-plugin] prepare for next development iteration 2018-04-04 10:44:46 +00:00
root
8c549bad38 [maven-release-plugin] prepare release netty-4.1.23.Final 2018-04-04 10:44:15 +00: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
Norman Maurer
69582c0b6c [maven-release-plugin] prepare for next development iteration 2018-02-21 12:52:33 +00:00
Norman Maurer
786f35c6c9 [maven-release-plugin] prepare release netty-4.1.22.Final 2018-02-21 12:52:19 +00:00
Norman Maurer
c6c0984b8e Ensure we always release the AddressEnvelope when doing DNS queries.
Motivation:

When we do DNS queries we need to ensure we always release the AddressEnvelope.

Modifications:

Also release the AddressEnvelope if the original resolution was done in the meantime and we did not cancel the extra query yet.

Result:

Should fix [#7713]
2018-02-20 12:06:21 +01: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
Norman Maurer
e71fa1e7b6 [maven-release-plugin] prepare for next development iteration 2018-02-05 12:02:35 +00:00
Norman Maurer
41ebb5fcca [maven-release-plugin] prepare release netty-4.1.21.Final 2018-02-05 12:02:19 +00:00
Scott Mitchell
46e66b45bd DnsNameResovlerContext#followCname sending extra queries
Motivation:
When following a CNAME response DnsNameResovlerContext may issue a A and AAAA query. However the DnsNameResolverContext would have already issued a A and AAAA query to get the CNAME response, and this may result in 2 additional A/AAAA queries per CNAME response.

Modifications:
- DnsNameResovlerContext#followCname shouldn't issue 2 queries, but instead just a single query with the same record type as the original query

Result:
No more duplicate queries as a result of CNAME responses.
2018-02-02 07:46:10 +01:00
Scott Mitchell
5257ec49ec DnsNameResolverContext reuse of DnsServerAddressStream without duplicate
Motivation:
DnsServerAddressStream provides an iterator like interface but maybe expected to start at a specific point upon each new usage. If a DnsServerAddressStream is re-used in multiple independent iterations the order of iteration maybe incorrect. DnsNameResolverContext has a fallback DnsServerAddressStream reference if the cache doesn't contain a hit, but it is shared across multiple independent iterations. This may lead to undesirable DNS query order.

Modifications:
- DnsNameResolverContext#getNameServers should duplicate the default DnsServerAddressStream

Result:
Consistent iteration over the default DnsServerAddressStream in DnsNameResolverContext.
2018-02-02 07:24:11 +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
Norman Maurer
e305488c5a Fix race-condition when using DnsCache in DnsNameResolver
Motivation:

The usage of DnsCache in DnsNameResolver was racy in general. First of the isEmpty() was not called in a synchronized block while we depended on synchronized. The other problem was that this whole synchronization only worked if the DefaultDnsCache was used and the returned List was not wrapped by the user.

Modifications:

- Rewrite DefaultDnsCache to not depend on synchronization on the returned List by using a CoW approach.

Result:

Fixes [#7583] and other races.
2018-01-23 08:04:33 +01:00
Norman Maurer
ea58dc7ac7 [maven-release-plugin] prepare for next development iteration 2018-01-21 12:53:51 +00:00
Norman Maurer
96c7132dee [maven-release-plugin] prepare release netty-4.1.20.Final 2018-01-21 12:53:34 +00:00
Norman Maurer
f3c6da32d7 Fix concurrency issue in DnsNameResolver when DefaultDnsCache is used.
Motivation:

We need to ensure we only call List.* methods in the synchronized block as the returned List may not be thread-safe.

Modifications:

Do not call isEmpty() outside of the synchronized block.

Result:

Fixes [#7583]
2018-01-17 06:08:36 +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
264a5daa41 [maven-release-plugin] prepare for next development iteration 2017-12-15 13:10:54 +00:00
Norman Maurer
0786c4c8d9 [maven-release-plugin] prepare release netty-4.1.19.Final 2017-12-15 13:09:30 +00:00
Norman Maurer
b2bc6407ab [maven-release-plugin] prepare for next development iteration 2017-12-08 09:26:15 +00:00