Commit Graph

10 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
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
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
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
359beff56f Choose ipv4 or ipv6 google dns servers as default fallback based on the settings for this system / jvm
Motivation:

We should not use ipv4 google dns servers if the app is configured to run ipv6.

Modifications:

Use either ipv4 or ipv6 dns servers depending on the system config.

Result:

More correct behaviour
2017-07-26 20:33:52 +02:00
Norman Maurer
34fdc7a33e Skip invalid hostnames when construct default dns servers to use.
Motivation:

When the hostname portion can not be extracted we should just skip the server as otherwise we will produce and exception when trying to create the InetSocketAddress.

This was happing when trying to run the test-suite on a system and using java7:

java.lang.IllegalArgumentException: hostname can't be null
	at java.net.InetSocketAddress.checkHost(InetSocketAddress.java:149)
	at java.net.InetSocketAddress.<init>(InetSocketAddress.java:216)
	at io.netty.util.internal.SocketUtils$10.run(SocketUtils.java:171)
	at io.netty.util.internal.SocketUtils$10.run(SocketUtils.java:168)
	at java.security.AccessController.doPrivileged(Native Method)
	at io.netty.util.internal.SocketUtils.socketAddress(SocketUtils.java:168)
	at io.netty.resolver.dns.DefaultDnsServerAddressStreamProvider.<clinit>(DefaultDnsServerAddressStreamProvider.java:74)
	at io.netty.resolver.dns.DnsServerAddressesTest.testDefaultAddresses(DnsServerAddressesTest.java:39)

Modifications:

Skip if hostname can not be extracted.

Result:

No more java.lang.ExceptionInInitializerError.
2017-07-25 08:43:53 +02:00
Norman Maurer
486f962252 Respect DNS port that is specified via JNDI
Motivation:

JNDI allows to specify an port so we should respect it.

Modifications:

Use the specified port and if none is specifed use 53.

Result:

Correct handling of JNDI configured DNS.
2017-07-25 08:26:59 +02:00
Norman Maurer
a0fcb72e5d Use jndi-dns to obtain default name servers
Motivation:

Using reflection to obtain the default name servers may fail in Java9 and also in previous Java versions if a SecurityManager is present.

Modifications:

Try using jndi-dns to obtain default name servers and only try using reflection if this fails.

Result:

Be able to detect default name servers in all cases. Fixes [#6347].
2017-04-19 12:24:06 +02:00
Scott Mitchell
155983f1a1 DNS move JDK DNS resolution out of DnsServerAddresses static initialization
Motivation:
DnsServerAddresses loads the default DNS servers used for DNS resolution in a static initialization block. This is subject to blocking and may cause unexpected delays. We can move this initialization to DefaultDnsServerAddressStreamProvider where it is more expected to load the JDK's default configuration.

Modifications:
- Move all the static initialization from DnsServerAddresses to DefaultDnsServerAddressStreamProvider
- Deprecate static methods in DnsServerAddresses which have moved to DefaultDnsServerAddressStreamProvider
- Remove usage of deprecated methods in DnsServerAddresses

Result:
Usage of JDK's blocking DNS resolver is not required to use resolver-dns.
2017-04-06 18:09:58 -07:00
Scott Mitchell
e074df2ae6 DNS Resolve ambiguity in which DNS servers are used during resolution
Motivation:
Recently DnsServerAddressStreamProvider was introduced to allow control for each query as to which DNS server should be used for resolution to respect the local host's default DNS server configuration. However resolver-dns also accepts a stream of DNS servers to use by default, but this stream is not host name aware. This creates an ambiguity as to which method is used to determine the DNS server to user during resolution, and in which order. We can remove this ambiguity and provide a more general API by just supporting DnsServerAddressStreamProvider.

Modifications:
- Remove the fixed DnsServerAddresses and instead only accept a DnsServerAddressStreamProvider.
- Add utility methods to help use DnsServerAddressStreamProvider for a single entry, a list of entries, and get the default for the current machine.

Result:
Fixes https://github.com/netty/netty/issues/6573.
2017-03-31 15:29:49 -07:00