代码改变世界

Java内部DNS查询实现和参数设置

2016-03-22 16:47  Loull  阅读(16103)  评论(3编辑  收藏  举报

一、Java内部DNS查询

Java使用域名查询时,用的自己内部的域名实现机制,最后都是交给InetAddress去做DNS解析。

源码分析参考:http://blog.arganzheng.me/posts/java-dns-lookup-internal.html

//域名查询
String dottedQuadIpAddress = InetAddress.getByName( "blog.arganzheng.me" ).getHostAddress();

//IP对应域名
InetAddress[] addresses = InetAddress.getAllByName("8.8.8.8"); // ip or DNS name
for (int i = 0; i < addresses.length; i++) {
    String hostname = addresses[i].getHostName();
    System.out.println(hostname);
}

 

 

二、JNDI DNS服务提供者设置(JNDI DNS service provider settings)

http://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html

sun.net.spi.nameservice.provider.<n>=<default|dns,sun|...>Specifies the name service provider that you can use. By default, Java will use the system configured name lookup mechanism, such as file, nis, etc. You can specify your own by setting this option. <n> takes the value of a positive number, it indicates the precedence order with a small number takes higher precendence over a bigger number. Aside from the default provider, the JDK includes a DNS provider named "dns,sun".

Prior to JDK 7, the first provider that was successfully loaded was used. In JDK 7, providers are chained, which means that if a lookup on a provider fails, the next provider in the list is consulted to resolve the name.

重点是这个参数,区分jdk版本,jdk7之前,只有第一个设置的provier生效;jdk7及其之后,provider链都生效,从第一个开始,指导解析成功。

Java有两个实现:

  Default:相当于设置System.setProperty("sun.net.spi.nameservice.provider.1", "default"); 具体解析过程是系统调用(getaddrinfo),依赖系统的DNS解析方式。

      getaddrinfo:https://linux.die.net/man/3/getaddrinfo

        Linux 系统如何处理名称解析: https://blog.arstercz.com/linux-%E7%B3%BB%E7%BB%9F%E5%A6%82%E4%BD%95%E5%A4%84%E7%90%86%E5%90%8D%E7%A7%B0%E8%A7%A3%E6%9E%90/

        getaddrinfo工作原理分析: https://www.cnblogs.com/battzion/p/4235562.html 

        resolv.conf文件更新了,getaddrinfo系统调用感知不到,它只会加载一次: https://stackoverflow.com/questions/19930037/an-issue-of-getaddrinfo-function-call-on-linux-platform  

    linux 默认的DNS方式是读取/etc/resolv.conf进行DNS解析。

      resolv.conf文件变更了,java进程感知不到,必须得程序重启才能生效

      Linux 系统如何处理名称解析: https://blog.arstercz.com/linux-%E7%B3%BB%E7%BB%9F%E5%A6%82%E4%BD%95%E5%A4%84%E7%90%86%E5%90%8D%E7%A7%B0%E8%A7%A3%E6%9E%90/

        修改 resolv.conf 里的 dns server, 多数运行的程序不会立即生效. Centos 7 系统中, glibc-2.17-202 版本合并了官方 glibc-2.25.90-18 的功能, 增加了自动检测 resolv.conf 修改功能, 如下:

# rpm -q --changelog glibc-2.17-260
...
* Fri Sep 29 2017 Florian Weimer <fweimer@redhat.com> - 2.17-202
....
- Detect and apply /etc/resolv.conf changes in libresolv (#1432085)

    mac 默认的方式是向网关请求获取DNS服务器,然后直接请求DNS服务器进行解析,没有读取/etc/resolv.conf。

  <dns,sun>:System.setProperty("sun.net.spi.nameservice.provider.1", "dns,sun"); 读取/etc/resolv.conf进行DNS解析,不同于默认的用getaddrinfo系统调用

    不同于“default”, 使用"dns,sun",每5分钟会读取一次/etc/resolv.conf,更新内存中的dns nameserver


sun.net.spi.nameservice.nameservers=<server1_ipaddr,server2_ipaddr ...>You can specify a comma separated list of IP addresses that point to the DNS servers you want to use. If the sun.net.spi.nameservice.nameservers property is not defined, then the provider will use any name servers already configured in the platform DNS configuration.


sun.net.spi.nameservice.domain=<domainname>This property specifies the default DNS domain name, for instance, eng.example.com. If the sun.net.spi.nameservice.domain property is not defined then the provider will use any domain or domain search list configured in the platform DNS configuration.

 

使用dnsjava的provider:

1. 工程添加dnsjava包。

2. 设置provider:System.setProperty("sun.net.spi.nameservice.provider.1","dns,dnsjava");

dnsjava的provider功能强大:

There's no standard way to determine what the local nameserver or DNS search
path is at runtime from within the JVM.  dnsjava attempts several methods
until one succeeds.

 - The properties 'dns.server' and 'dns.search' (comma delimited lists) are
   checked.  The servers can either be IP addresses or hostnames (which are
   resolved using Java's built in DNS support).
 - The sun.net.dns.ResolverConfiguration class is queried.
 - On Unix, /etc/resolv.conf is parsed.
 - On Windows, ipconfig/winipcfg is called and its output parsed.  This may
   fail for non-English versions on Windows.
 - As a last resort, "localhost" is used as the nameserver, and the search
   path is empty.

参考:

http://www.xbill.org/dnsjava/dnsjava-current/README

http://stackoverflow.com/questions/5668058/how-to-change-the-java-dns-service-provider

 

三、JVM DNS缓存

如果启动了security manager,则永久缓存,但一般情况下大家是不会去启动security manager的。

可以再程序里面设置不缓存,或者在启动参数里面设置

java.security.Security.setProperty("networkaddress.cache.ttl" , "0")

如果没有启动security manager,则要区分JDK版本:

1.5及其一下,java对DNS解析IP进行缓存,默认缓存超时时间为-1(在重启JVM前永久缓存)

1.6及其以上,缓存时间根据ttl。

参考:

http://docs.oracle.com/javase/1.5.0/docs/guide/net/properties.html

http://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html

设置ttl:在命令启动JVM的时候设置参数"-Dnetworkaddress.cache.ttl=60 -Dsun.net.inetaddr.ttl=60"

 

四、Linux服务器是否会对dns缓存,ttl是否有用?

linux本身是没有dns缓存的,想使用dns缓存的话需要自己安装一个服务程序NSCD.

$ ps aux | grep nscd 可以查看

相关问题:http://blogread.cn/it/article/7043?f=wb

 

五、nginx 自己实现了dns resolver,并且会对dns缓存

六、ping 未知域名的全过程(依赖于操作系统)

主机A,B(可不再同一网段),主机B有域名假设为www.baidu.com
首先:1. 本地主机A在命令行下执行"ipconfig/flushdns"命令来清空本地DNS高速缓存;
      2. 本地主机A在命令行下执行"arp -d"命令来清空arp缓存

然后,主机A执行ping www.baidu.com(即主机B的域名)

在此过程中都发生了那些报文交互?

思路:

  1.要执行ping命令主机A必须将域名转化为IP地址,故而一定会有DNS解析过程;
      2.在DNS解析之前,主机A一定要知道自己默认网关的MAC地址,这就要涉及到ARP解析的问题;
      3.ping命令本身是ICMP回显请求,故而肯定要有ICMP协议的回显请求交互。

以下是全过程:

(此处可参照“跨网段的ping过程”来看,此处假设DNS服务器和主机A不在同一网段,若二者在同一网段那么我想只需进行简单arp就可得到DNS服务器的mac不需经过网关)
1.主机A发送ARP请求报文目的mac为FFFFFF-FFFFFF,目的IP为网关的IP,要求获得网关的MAC地址;
2.路由器(主机A的默认网关)发送目的mac为A的mac,目的IP为A的IP的ARP回答报文,以告知A网关的mac地址;
3.A获得网关的mac地址后,就向网关发送一个DNS查询报文,其目的mac地址为网关的mac地址,目的IP为DNS服务器的IP地址;
4.网关收到DNS查询报文后,拆包检查发现是DNS查询于是将相应(查询)信息封装,向DNS服务器发送该报文,其目的IP地址为DNS服务器的IP,目的mac为下一跳的mac,解析域名IP地址此时就交给了DNS服务器;
5.经过DNS解析,主机A知道了所要ping的域名的ip地址;
6.剩下的ping过程就和ping一个特定的ip地址相同了,首先判断ping命令的目的B的IP地址是否和A在同一网段,若在同一网段则相当于同网段内ping,若不在同一网段,就是不同网段的ping只不过此时主机不需要再解析网关的mac地址了。

参考:

http://blog.sina.com.cn/s/blog_7c35df9b0100vomk.html