[20180427]SCAN_IP DNS 反向解析2.txt

[20180427]SCAN_IP DNS 反向解析2.txt

--//从Oracle 11gR2开始，引入SCAN(Single Client Access Name) IP的概念，相当于在客户端和数据库之间增加一层虚拟的网络服务层
--//，即是SCAN IP和SCAP IP Listener。在客户端的tnsnames.ora配置文件中，只需要配置SCAN IP的配置信息即可，客户端通过SCAN
--//IP、SCAN IP Listener来访问数据库。同之前各版本的RAC相比，使用SCAN IP的好处就是，当后台RAC数据库添加、删除节点时，客
--//户端配置信息无需修改。

--//当然这样配置DNS变成了实施RAC的重要步骤,在具体的实践的过程中,我遇到过一例问题,如果dns出现问题,会导致整个应用无法登录
--//或者登录很慢的情况,我以前遇到的问题就是IP反向解析的问题.通过测试说明问题.

1.环境:
SYS@dbcn1> @ &r/ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

2.测试1:
--//再client登录执行:
$ host 192.168.100.78
Host 78.100.168.192.in-addr.arpa. not found: 3(NXDOMAIN)

$ host gxqyydg4
Host gxqyydg4 not found: 3(NXDOMAIN)

--//可以发现client ip以及主机名无法解析.这并不重要,只要能解析scan name就ok了.

$ rlsql   system/xxxx@dm01-scan:1521/dbcn::dbcn1
SYSTEM@dm01-scan:1521/dbcn::dbcn1> select INSTANCE_NUMBER, INSTANCE_NAME from v$instance ;
INSTANCE_NUMBER INSTANCE_NAME
--------------- ----------------
              1 dbcn1


--//在服务端执行如下:
#  tcpdump -l  -i bondeth0   dst port 53  -nn -vv | tee -a /tmp/xx2.txt
....等....


#  grep " 78.100.168.192.in-addr.arpa" /tmp/xx2.txt
...
13:46:58.231168 IP (tos 0x0, ttl  64, id 10721, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.27561 > 192.168.dns1.com.53: [bad udp cksum 5522!]  9882+ PTR? 78.100.168.192.in-addr.arpa. (45)
13:50:21.600292 IP (tos 0x0, ttl  64, id 17482, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.51607 > 192.168.dns2.com.53: [bad udp cksum 41de!]  3259+ PTR? 78.100.168.192.in-addr.arpa. (45)
13:53:50.367461 IP (tos 0x0, ttl  64, id 29642, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.12386 > 192.168.dns2.com.53: [bad udp cksum e5bc!]  51020+ PTR? 78.100.168.192.in-addr.arpa. (45)
13:57:10.908366 IP (tos 0x0, ttl  64, id 33575, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.46524 > 192.168.dns2.com.53: [bad udp cksum 6e4a!]  46185+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:00:41.171634 IP (tos 0x0, ttl  64, id 47230, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.13441 > 192.168.dns2.com.53: [bad udp cksum 96ea!]  38268+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:04:03.672077 IP (tos 0x0, ttl  64, id 53122, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.45322 > 192.168.dns1.com.53: [bad udp cksum b43b!]  51161+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:07:28.770941 IP (tos 0x0, ttl  64, id 61613, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.48435 > 192.168.dns1.com.53: [bad udp cksum e22c!]  51842+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:10:52.191144 IP (tos 0x0, ttl  64, id 2889, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.12000 > 192.168.dns1.com.53: [bad udp cksum fe3a!]  19130+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:14:18.685992 IP (tos 0x0, ttl  64, id 12776, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.41413 > 192.168.dns2.com.53: [bad udp cksum 52c5!]  19836+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:17:43.471740 IP (tos 0x0, ttl  64, id 20954, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.60719 > 192.168.dns1.com.53: [bad udp cksum b40!]  34653+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:21:04.333640 IP (tos 0x0, ttl  64, id 25208, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.60793 > 192.168.dns1.com.53: [bad udp cksum 1910!]  46853+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:24:31.149256 IP (tos 0x0, ttl  64, id 35415, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.29278 > 192.168.dns2.com.53: [bad udp cksum 147c!]  50721+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:27:53.503998 IP (tos 0x0, ttl  64, id 41162, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.16994 > 192.168.dns1.com.53: [bad udp cksum c5c7!]  43632+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:31:26.386776 IP (tos 0x0, ttl  64, id 57437, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.63623 > 192.168.dns1.com.53: [bad udp cksum acf0!]  52067+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:35:02.562995 IP (tos 0x0, ttl  64, id 11469, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.40847 > 192.168.dns1.com.53: [bad udp cksum 8e73!]  41338+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:38:29.945939 IP (tos 0x0, ttl  64, id 22244, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.64566 > 192.168.dns2.com.53: [bad udp cksum 918e!]  10700+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:41:41.622086 IP (tos 0x0, ttl  64, id 17312, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.48216 > 192.168.dns1.com.53: [bad udp cksum 5ba3!]  21732+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:45:17.195075 IP (tos 0x0, ttl  64, id 36277, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.39889 > 192.168.dns2.com.53: [bad udp cksum 83fa!]  7743+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:48:52.259520 IP (tos 0x0, ttl  64, id 54734, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.40490 > 192.168.dns2.com.53: [bad udp cksum 21b1!]  25928+ PTR? 78.100.168.192.in-addr.arpa. (45)

--//可以发现间隔大约不到2XX秒,就存在1个IP反向解析.
--//注:生产系统存在2个DNS服务.

create table t ( a timestamp);
insert into t values ('2018/04/28 13:46:58.231168');
insert into t values ('2018/04/28 13:50:21.600292');
insert into t values ('2018/04/28 13:53:50.367461');
insert into t values ('2018/04/28 13:57:10.908366');
insert into t values ('2018/04/28 14:00:41.171634');
insert into t values ('2018/04/28 14:04:03.672077');
insert into t values ('2018/04/28 14:07:28.770941');
insert into t values ('2018/04/28 14:10:52.191144');
insert into t values ('2018/04/28 14:14:18.685992');
insert into t values ('2018/04/28 14:17:43.471740');
insert into t values ('2018/04/28 14:21:04.333640');
insert into t values ('2018/04/28 14:24:31.149256');
insert into t values ('2018/04/28 14:27:53.503998');
insert into t values ('2018/04/28 14:31:26.386776');
insert into t values ('2018/04/28 14:35:02.562995');
insert into t values ('2018/04/28 14:38:29.945939');
insert into t values ('2018/04/28 14:41:41.622086');
insert into t values ('2018/04/28 14:45:17.195075');
insert into t values ('2018/04/28 14:48:52.259520');
commit;

column interval format 00000.999999

WITH x
     AS (SELECT a - n_a interval
           FROM (  SELECT a, LAG (a) OVER (ORDER BY a) n_a
                     FROM t
                 ORDER BY a)
          WHERE n_a IS NOT NULL)
SELECT   EXTRACT (DAY FROM interval) * 86400
       + EXTRACT (HOUR FROM interval) * 3600
       + EXTRACT (MINUTE FROM interval) * 60
       + EXTRACT (SECOND FROM interval)
          interval
  FROM x;

  INTERVAL
----------
203.369124
208.767169
200.540905
210.263268
202.500443
205.098864
203.420203
206.494848
204.785748
200.8619
206.815616
202.354742
212.882778
216.176219
207.382944
191.676147
215.572989
215.064445
18 rows selected.

3.测试2:
--//我还测试scan ip,vip,真实IP的登录.
--//结果都是一样,都是间隔大约不到2XX秒,就存在1个IP反向解析.
 
4.如果client ip能反向解析呢?
--//修改DNS服务器,加入192.168.100.78的反向解析.
# cat /var/named/100.168.192.db
$TTL    86400
100.168.192.in-addr.arpa.       IN      SOA     xxxx.com. root 1 3H 15M 1W 1D

          IN NS    ns.xxxx.com.
..
78        IN PTR    gxqyydg4.com

# service named restart
Stopping named: .                                          [  OK  ]
Starting named:                                            [  OK  ]

$ rlsql   system/welcome1@dm01-scan:1521/dbcn::dbcn1
SYSTEM@dm01-scan:1521/dbcn::dbcn1> select INSTANCE_NUMBER, INSTANCE_NAME from v$instance ;
INSTANCE_NUMBER INSTANCE_NAME
--------------- ----------------
              1 dbcn1

SYSTEM@dm01-scan:1521/dbcn::dbcn1> select sysdate from dual ;
SYSDATE
-------------------
2018-04-28 15:41:00
...

SYSTEM@dm01-scan:1521/dbcn::dbcn1> select sysdate from dual ;
SYSDATE
-------------------
2018-04-28 15:50:23

#  grep " 78.100.168.192.in-addr.arpa" /tmp/xx2.txt | grep ^15:4
15:43:46.436878 IP (tos 0x0, ttl  64, id 6575, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.23866 > 192.168.dns1.com.53: [bad udp cksum 118d!]  51788+ PTR? 78.100.168.192.in-addr.arpa. (45)

--//可以发现只要反向解析正常,仅仅解析1次反向IP解析,以后就不再请求.而且会缓存一段时间,以后登录也不会出现反向请求.

总结:
#  grep -v 'in-addr.arpa.' /tmp/xx2.txt |wc
   1331   27999  210832
#  grep  'in-addr.arpa.' /tmp/xx2.txt |wc
  82971 2324151 17353436

--//大部分都是反向解析.
--//如果4400个客户端登录.假设220秒存在1次反向ip解析. 4400/220 = 20个/秒,平均每秒要从服务器发出20个请求,如果业务高峰每秒
--//200个连接请求,也就是每秒200次解析.这样业务要求并不大,大部分dns服务器都能撑得住,但是一旦出现问题,整个应用就出现停滞,
--//建议还是建立多个DNS,避免单点故障.

--//至于是否加入client 反向IP解析,可以减少DNS的请求,效益并不大,但是要注意DNS服务器网络带宽以及性能,建议还是考虑建立多台
--//dns服务器.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/267265/viewspace-2153532/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/267265/viewspace-2153532/