Commit Graph

253 Commits

Author SHA1 Message Date
Norman Maurer
9c6365ee95
Only try to use reflection to access default nameservers when using Java8 and lower (#9157)
Motivation:

We should only try to use  reflection to access default nameservers when using Java8 and lower as otherwise we will produce an Illegal reflective access warning like:

WARNING: Illegal reflective access by io.netty.resolver.dns.DefaultDnsServerAddressStreamProvider

Modifications:

Add Java version check before try to use reflective access.

Result:

No more warning when Java9+ is used.
2019-05-18 08:21:33 +02:00
Norman Maurer
f17bfd0f64
Only use static Exception instances when we can ensure addSuppressed … (#9152)
Motivation:

OOME is occurred by increasing suppressedExceptions because other libraries call Throwable#addSuppressed. As we have no control over what other libraries do we need to ensure this can not lead to OOME.

Modifications:

Only use static instances of the Exceptions if we can either dissable addSuppressed or we run on java6.

Result:

Not possible to OOME because of addSuppressed. Fixes https://github.com/netty/netty/issues/9151.
2019-05-17 22:23:02 +02:00
Norman Maurer
1672b6d12c
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:37:11 +02:00
Norman Maurer
6ee8b651e6
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:06 +02:00
Norman Maurer
df20a125aa
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:06:52 +02:00
root
ba06eafa1c [maven-release-plugin] prepare for next development iteration 2019-04-30 16:42:29 +00:00
root
49a451101c [maven-release-plugin] prepare release netty-4.1.36.Final 2019-04-30 16:41:28 +00:00
root
baab215f66 [maven-release-plugin] prepare for next development iteration 2019-04-17 07:26:24 +00:00
root
dfe657e2d4 [maven-release-plugin] prepare release netty-4.1.35.Final 2019-04-17 07:25:40 +00:00
Norman Maurer
075cf8c02e
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:42:04 +02:00
Norman Maurer
4b36a5b08b
Correctly calculate ttl for AuthoritativeNameServer when update existing records (#9051)
Motivation:

We did not correctly calculate the new ttl as we did forget to add `this.`

Modifications:

Add .this and so correctly calculate the TTL

Result:

Use correct TTL for authoritative nameservers when updating these.
2019-04-15 21:41:04 +02:00
Norman Maurer
dde3f561bc
Use ResolvedAddressTypes.IPV4_ONLY in DnsNameResolver by default if n… (#9048)
Motivation:

To closely mimic what the JDK does we should not try to resolve AAAA records if the system itself does not support IPv6 at all as it is impossible to connect to this addresses later on. In this case we need to use ResolvedAddressTypes.IPV4_ONLY.

Modifications:

Add static method to detect if IPv6 is supported and if not use ResolvedAddressTypes.IPV4_ONLY.

Result:

More consistent behaviour between JDK and our resolver implementation.
2019-04-15 13:07:05 +02:00
Norman Maurer
26cd59c328
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:19:54 +02:00
Norman Maurer
c0d3444f6d
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:13:53 +02:00
Norman Maurer
e63c596f24
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:44:23 +02:00
Norman Maurer
0ee067082b
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:41:28 +01:00
root
92b19cfedd [maven-release-plugin] prepare for next development iteration 2019-03-08 08:55:45 +00:00
root
ff7a9fa091 [maven-release-plugin] prepare release netty-4.1.34.Final 2019-03-08 08:51:34 +00:00
root
cf03ed0478 [maven-release-plugin] prepare for next development iteration 2019-01-21 12:26:44 +00:00
root
37484635cb [maven-release-plugin] prepare release netty-4.1.33.Final 2019-01-21 12:26:12 +00:00
Norman Maurer
df5eb060f7
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:06:44 +01:00
Norman Maurer
82ec6ba815
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:44 +01:00
kashike
6fdd7fcddb 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:24:34 +01:00
Norman Maurer
a3844da10b
NoClassDefFoundError on Android platform when try to use DefaultDnsServerAddressStreamProvider. (#8656)
Motivation:

Andoid does not contain javax.naming.* so we should not try to use it to prevent a NoClassDefFoundError on init.

Modifications:

Only try to use javax.naming.* to retrieve nameservers when not using Android.

Result:

Fixes https://github.com/netty/netty/issues/8654.
2018-12-14 21:31:21 +01:00
Feri73
5df235c083 Correcting Maven Dependencies (#8622)
Motivation:

Most of the maven modules do not explicitly declare their
dependencies and rely on transitivity, which is not always correct.

Modifications:

For all maven modules, add all of their dependencies to pom.xml

Result:

All of the (essentially non-transitive) depepdencies of the modules are explicitly declared in pom.xml
2018-12-06 09:01:14 +01:00
root
8eb313072e [maven-release-plugin] prepare for next development iteration 2018-11-29 11:15:09 +00:00
root
afcb4a37d3 [maven-release-plugin] prepare release netty-4.1.32.Final 2018-11-29 11:14:20 +00:00
Norman Maurer
d728a72e74
Combine flushes in DnsNameResolver to allow usage of sendmmsg to reduce syscall costs (#8470)
Motivation:

Some of transports support gathering writes when using datagrams. For example this is the case for EpollDatagramChannel. We should minimize the calls to flush() to allow making efficient usage of sendmmsg in this case.

Modifications:

- minimize flush() operations when we query for multiple address types.
- reduce GC by always directly schedule doResolveAll0(...) on the EventLoop.

Result:

Be able to use sendmmsg internally in the DnsNameResolver.
2018-11-21 06:42:40 +01:00
Norman Maurer
cb0d23923f
Refresh DNS configuration each 5 minutes. (#8468)
Motivation:

We should refresh the DNS configuration each 5 minutes to be able to detect changes done by the user. This is inline with what OpenJDK is doing

Modifications:

Refresh config every 5 minutes.

Result:

Be able to consume changes made by the user.
2018-11-16 10:37:29 +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
root
3e7ddb36c7 [maven-release-plugin] prepare for next development iteration 2018-10-29 15:38:51 +00:00
root
9e50739601 [maven-release-plugin] prepare release netty-4.1.31.Final 2018-10-29 15:37:47 +00: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
root
2d7cb47edd [maven-release-plugin] prepare for next development iteration 2018-09-27 19:00:45 +00:00
root
3a9ac829d5 [maven-release-plugin] prepare release netty-4.1.30.Final 2018-09-27 18:56:12 +00:00
Norman Maurer
b81c8ed55c
Use AuthoritativeDnsServerCache for creating the new redirect stream. (#8316)
* Use AuthoritativeDnsServerCache for creating the new redirect stream.

Motivation:

At the moment if a user wants to provide custom sorting of the nameservers used for redirects it needs to be implemented in two places. This is more complicated as it needs to be.

Modifications:

- Just delegate to the AuthoritativeDnsServerCache always as we fill it before we call newRedirectDnsServerStream anyway.

Result:

Easier way for the user to implement custom sorting.
2018-09-27 19:45:58 +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
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