java 域名格式错误_记一次JAVA域名解析的故障

事件起因

某一天测试部门的同事反馈某一个后台应用接口无法访问，我们立即登陆相关服务器，查看后台日志，发现了如下信息：

<2018-04-28 16:59:02.713 ERROR 102603 --- [nio-8888-exec-2] o.a.c.c.C.[.[.[/].[dispatcherServlet] : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception

java.net.UnknownHostException: a.b.com: 未知的名称或服务

at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method) ~[na:1.8.0_152]

at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928) ~[na:1.8.0_152]

at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323) ~[na:1.8.0_152]

at java.net.InetAddress.getAllByName0(InetAddress.java:1276) ~[na:1.8.0_152]

at java.net.InetAddress.getAllByName(InetAddress.java:1192) ~[na:1.8.0_152]

at java.net.InetAddress.getAllByName(InetAddress.java:1126) ~[na:1.8.0_152]

at java.net.InetAddress.getByName(InetAddress.java:1076) ~[na:1.8.0_152]

at com.transfar.controller.GetDns.getip(GetDns.java:16) ~[classes!/:0.0.1-SNAPSHOT]

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_152]

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_152]

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_152]

at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_152]

at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:209) ~[spring-web-5.0.5.RELEASE.jar!/:5.0.5.RELEASE]

at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:136) ~[spring-web-5.0.5.RELEASE.jar!/:5.0.5.RELEASE]/>

由于该接口会访问一个内网域名地址，第一反应是域名解析的问题，在服务器上ping a.b.com，无法解析出IP地址，那问题就清楚了，随后立即联系网络人员解决域名解析的问题。

大约五分钟之后，网工反馈说域名解析已经添加，我在服务器上测试了下，确实已经正确解析出了IP，随后回复测试人员故障已恢复。

但是，事情总是很少一帆风顺的，大约两小时之后，测试人员反馈说故障依旧。很纳闷，再次登陆服务器查看日志，发现依然在报之前的错误，百思不得其解之下，选择重启了java应用，故障终于彻底解决。(对运维来说，一时解决不了的问题，重启一定是对的，但也是临时的。)

怀着不解的心情，决定一探到底。。

其实我当时第一反应就是jdk是不是缓存了dns解析，查看资料得到两个重要的参数(jdk1.8)说明:

文件位置：/usr/local/jdk1.8.0_152/jre/lib/security/java.security

The Java-level namelookup cache policy for successful lookups:

any negative value: caching forever

any positive value: the number of seconds to cache an address for

zero: do not cache

default value is forever (FOREVER). For security reasons, this caching is made forever when a security manager is set. When a security manager is not set, the default behavior in this implementation is to cache for 30 seconds.

NOTE:

setting this to anything other than the default value can have

serious security implications. Do not set it unless

you are sure you are not exposed to DNS spoofing attack.

networkaddress.cache.ttl=-1

#参数意义：设置jdk解析域名成功的缓存时间。

其他：设置缓存时间，单位秒

默认值：如果开启了-Djava.security.manager，默认是-1，如果未开启，默认是30s

The Java-level namelookup cache policy for failed lookups:

any negative value: cache forever

any positive value: the number of seconds to cache negative lookup results

zero: do not cache

In some Microsoft Windows networking environments that employ

the WINS name service in addition to DNS, name service lookups

that fail may take a noticeably long time to return (approx. 5 seconds).

For this reason the default caching policy is to maintain these

results for 10 seconds.

networkaddress.cache.negative.ttl=10

#参数意义：设置jdk解析域名失败的缓存时间。

-1：永久缓存

0：不缓存

其他：设置缓存时间，单位秒

下面做了一个测试，写成表格，对比了两个参数的影响，方便大家理解。

参数名

参数值

cache.ttl

-1

cache.negative.ttl

10

结果分析：

1、正常解析的域名被永久保存，即使dns修改过解析结果，程序解析出来的还是老的参数。

2、异常解析的域名，根据配置值每隔10秒发起一次解析请求。

分析结论

查看问题服务器的jdk配置，发现设置了networkaddress.cache.negative.ttl=10，但是从表象来看，并没有正常解析出IP，重启应用之后，才解决。所以跟参数的配置说明不一致，原因待查。