[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伺服器.
--//從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/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- redhat linux dns反向解析示例RedhatLinuxDNS
- 《DNS的正向反向解析》RHEL6DNS
- Linux的DNS域名解析服務（正向，反向，主從，分離）LinuxDNS
- 什麼是DNS解析？如何提升DNS解析安全？DNS
- DNS解析流程DNS
- DNS解析原理DNS
- 關於地址反向解析
- 詳解 DNS 解析DNS
- DNS域名解析DNS
- Dns解析(上) (轉)DNS
- Dns解析(下) (轉)DNS
- DNS解析為什麼不生效？DNS解析不生效原因分析DNS
- 如何判斷DNS解析故障？如何解決DNS解析錯誤？DNS
- DNS.com和DNS盾免費DNS解析、DNSPOD阿里公共DNS等DNS阿里
- DNS分層結構及DNS解析流程DNS
- 雲解析DNS有必要買嗎？雲解析DNS有什麼用？DNS
- DNS隧道技術解析DNS
- iOS 本地DNS解析方法iOSDNS
- DNS解析過程原理DNS
- 【中科三方】什麼是雲解析DNS？雲解析DNS有必要購買嗎？如何購買雲解析DNS？DNS
- 雲解析DNS如何實現智慧解析？DNS
- 解析最快的dns 最快最穩定的dnsDNS
- 什麼是DNS解析？DNS解析的過程是什麼樣的？DNS
- Oracle 11G 修改scan_ipOracle
- DNS解析是什麼？DNS解析在網路通訊中作用有哪些？DNS
- DNS直接解析域名與泛域名解析DNS
- Grafana展示DNS解析延時GrafanaDNS
- DNS域名解析過程DNS
- DNS域名解析服務DNS
- 國內DNS最快的伺服器 解析最快的dnsDNS伺服器
- DNS （域名解析伺服器）， DNS子域授權DNS伺服器
- dns解析狀態異常怎麼處理 dns解析異常怎麼修復DNS
- 【中科三方】什麼是雲解析DNS？雲解析DNS有必要購買嗎？DNS
- 雲解析DNS是什麼意思？雲解析DNS有什麼用？（中科三方）DNS
- DNS 解析除錯(dig & nslookup)DNS除錯
- 簡單理解DNS解析流程（一）DNS
- DNS的原理和解析過程DNS
- 超詳細 DNS 協議解析DNS協議