|
![]() | 作者: eastone [eastone]
![]() |
登录 |
举一个例子: 条件: 1。存在:abc@xxx.com.tw 2。对应的WEB可以访问:www.xxx.com.tw 3。可以ping 出www.xxx.com.tw的IP地址 4。确定该服务器被托管在中心机房; 5。我通过浏览器访问该IP地址,确是另外一个网站的内容。 经过X-scan扫描,却发现没有开放25/110端口? 怎么样能够得到邮件系统的真实IP地址呢? |
地主 发表时间: 01/25 10:32 |
![]() | 回复: NetDemon [netdemon] ![]() |
登录 |
由以上条件可以得出这是一台虚拟主机 要得到xxx.com.tw的邮件服务器地址,请用nslookup C:\>nslookup Default Server: abc.gdabc.net.cn Address: 202.96.xxx.xxx >set q=mx xxx.com.tw |
B1层 发表时间: 01/25 18:49 |
![]() | 回复: eastone [eastone] ![]() |
登录 |
还是不行,过程如下: c:\nslookup default Server:ns.szptt.net.cn Address:202.96.134.133 > st q=mx > www.xxx.com.tw Server: ns.szptt.net.cn Address:202.96.134.133 xxx.com.tw primary name server=tcsy-1 responsible mail addr=admin serial=11 refresh=900(15 mins) retry=600(10 mins) expire=86400 (1 day) default TTL=3600 (1 hour) > 或者直接 nslookup www.xxx.com.tw Server:ns.szptt.net.cn Address: 202.96.134.133 Non-authoritative answre: name:www.xxx.com.tw Address:xxx.xxx.xxx.xxx 该IP地址和直接Ping的一样。 这样还是不行啊。 |
B2层 发表时间: 01/27 09:58 |
![]() | 回复: NetDemon [netdemon] ![]() |
登录 |
首先,看东西要仔细。 细心,是搞技术必备条件 我的回复是 ########### #set q=mx #xxx.com.tw ########### 你的操作是 ########## #set q=mx #www.xxx.com.tw ########## 你这样的操作,nslookup默认得出www.xxx.com.tw这台主机的IP 当你set q=mx 之后。nslookup得出www.xxx.com.tw这个域的邮件服务器地址,注意:我说的是www.xxx.com.tw这个域。也就是说,得出如果你要给abc@www.xxx.com.tw发信时,要发到那个服务器上。而实际上,你要查的好像是abc@xxx.com.tw而不是abc@www.xxx.com.tw吧 [此贴被 NetDemon(netdemon) 在 01月29日01时48分 编辑过] |
B3层 发表时间: 2003-01-29 01:59:48 |
![]() | 回复: gefujian [gefujian] ![]() |
登录 |
多谢版主! |
B4层 发表时间: 01/29 11:11 |
![]() | 回复: laievf [laievf] ![]() |
登录 |
我看的是一头露水~~~~~55555~~~~ |
B5层 发表时间: 02/01 00:02 |
![]() | 回复: merlin [merlin] ![]() |
登录 |
明白。 |
B6层 发表时间: 02/01 12:10 |
![]() | 回复: baboo [baboo] ![]() |
登录 |
请问nslookup是什么命令?dos下的吗?还是专门软件的?谢啦 |
B7层 发表时间: 02/08 14:48 |
![]() | 回复: jacker [jacker] ![]() |
登录 |
虚拟主机,网站与邮件服务器IP不同,可以先查出托管中心的IP,(一般会在虚拟网站在卖广告:) 相关域名服务器IP [此贴被 路小佳(jacker) 在 02月09日23时03分 编辑过] |
B8层 发表时间: 2003-02-09 23:24:03 |
![]() | 回复: greenwater [greenwater] ![]() |
登录 |
老大: 你好! 你能不能详细地介绍一下nslookup呢? 谢谢! greenwater |
B9层 发表时间: 05/03 16:57 |
![]() | 回复: sunshine [bysx] ![]() |
登录 |
我来回答你的问题,我想 administrator说的是不错的,但他忽视了一个很重要的问题,我想细心的人可以看出你用nslookup的时候,有一个default server,你的default server对于目标服务器并不是权威的,所以你找不到,在你去nslookup以前,最好先去一些nic whois一下,找出对目标权威的dns server.其实查点是一个很精致很雅致的活,如何你对这个有兴趣,可以和我联系,我的 Email:by.sx@163.com |
B10层 发表时间: 05/13 21:30 |
![]() | 回复: NetDemon [netdemon] ![]() |
登录 |
/* 我来回答你的问题,我想 administrator说的是不错的,但他忽视了一个很重要的问题,我想细心的人可以看出你用nslookup的时候,有一个default server,你的default server对于目标服务器并不是权威的,所以你找不到,在你去nslookup以前,最好先去一些nic whois一下,找出对目标权威的dns server.其实查点是一个很精致很雅致的活,如何你对这个有兴趣,可以和我联系,我的 Email:by.sx@163.com */ 可能性1:你根本不完全清楚DNS Server的工作原理,这点请自行查阅相关RFC文档。http://www.20cn.org/rfc/ 可能性2:你根本不充分了解nslookup的功能,这个请自行man。我不明白为什么你认为要做先做那些查询系统本来也要做的工作。(对于找不找得到的问题,不是在defaultserver上的答案权不权威的问题) 和DNS相关的RFC 952: DOD INTERNET HOST TABLE SPECIFICATION 1032: DOMAIN ADMINISTRATORS GUIDE 1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE 1034: DOMAIN NAMES - CONCEPTS AND FACILITIES 1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION 1101: DNS Encoding of Network Names and Other Types 1122: Requirements for Internet Hosts -- Communication Layers 1123: Requirements for Internet Hosts -- Application and Support 1183: New DNS RR Definitions (AFSDB, RP, X25, ISDN and RT) 1348: DNS NSAP RRs 1535: A Security Problem and Proposed Correction With Widely Deployed DNS Software 1536: Common DNS Implementation Errors and Suggested Fixes 1537: Common DNS Data File Configuration Errors 1591: Domain Name System Structure and Delegation 1611: DNS Server MIB Extensions 1612: DNS Resolver MIB Extensions 1706: DNS NSAP Resource Records 1712: DNS Encoding of Geographical Location 1750: Randomness Recommendations for Security 1876: A Means for Expressing Location Information in the Domain Name System 1982: Serial Number Arithmetic 1995: Incremental Zone Transfer in DNS 1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) 2052: A DNS RR for specifying the location of services (DNS SRV) 2104: HMAC: Keyed-Hashing for Message Authentication 2119: Key words for use in RFCs to Indicate Requirement Levels 2133: Basic Socket Interface Extensions for IPv6 2136: Dynamic Updates in the Domain Name System (DNS UPDATE) 2137: Secure Domain Name System Dynamic Update 2163: Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM) 2168: Resolution of Uniform Resource Identifiers using the Domain Name System 2181: Clarifications to the DNS Specification 2230: Key Exchange Delegation Record for the DNS 2308: Negative Caching of DNS Queries (DNS NCACHE) 2317: Classless IN-ADDR.ARPA delegation 2373: IP Version 6 Addressing Architecture 2374: An IPv6 Aggregatable Global Unicast Address Format 2375: IPv6 Multicast Address Assignments 2418: IETF Working Group Guidelines and Procedures 2535: Domain Name System Security Extensions 2536: DSA KEYs and SIGs in the Domain Name System (DNS) 2537: RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) 2538: Storing Certificates in the Domain Name System (DNS) 2539: Storage of Diffie-Hellman Keys in the Domain Name System (DNS) 2540: Detached Domain Name System (DNS) Information 2541: DNS Security Operational Considerations 2553: Basic Socket Interface Extensions for IPv6 2671: Extension Mechanisms for DNS (EDNS0) 2672: Non-Terminal DNS Name Redirection 2673: Binary Labels in the Domain Name System 2782: A DNS RR for specifying the location of services (DNS SRV) 2825: A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols 2826: IAB Technical Comment on the Unique DNS Root 2845: Secret Key Transaction Authentication for DNS (TSIG) 2874: DNS Extensions to Support IPv6 Address Aggregation and Renumbering 2915: The Naming Authority Pointer (NAPTR) DNS Resource Record 2929: Domain Name System (DNS) IANA Considerations 2930: Secret Key Establishment for DNS (TKEY RR) 2931: DNS Request and Transaction Signatures ( SIG(0)s ) 3007: Secure Domain Name System (DNS) Dynamic Update 3008: Domain Name System Security (DNSSEC) Signing Authority 3090: DNS Security Extension Clarification on Zone Status 3110: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) 全部看完之后再来和我讨论这个问题! |
B11层 发表时间: 05/26 22:14 |
![]() | 回复: sunshine [bysx] ![]() |
登录 |
你说的那些文档我都可以背下了,还是我来告诉你nslookup的一些基本原理吧,当你启动nslookup的时候,它会告诉你它正在使用的dns,但这通常是我们所在机构的dns,也就是你的isp提供的dns,很显然,它通常不是对目标的权威服务器,我来告诉你正确的应该怎么做: 一:whois target.com 你会得到一些dns,mx,联系号码等一些信息。(当然,有时你得指定whois服务器,否则你可能查不到。多试几个就可以了。) 二:nslookup >server newdns (你whois得来的dns) >set type=any >ls -d target.com. 注意ls -d target.com后有个点,表示这是一个全限定域名。 行了,运气好的话你会得到一个hinfo和一个mx的记录. 如果你还得不到的话就煽我耳光。 nslookup不象你的web dns请求那样会进行多重请求的。 内部dns的最大错误配置是允许不受信任的internet用户执行dns区域传送,不过那是其他的问题了。 我在重复一下我的观点:一次成功的攻击查点是必须而且是必要的。 |
B12层 发表时间: 05/28 21:05 |
![]() | 回复: NetDemon [netdemon] ![]() |
登录 |
你难道没有觉得你文不对题么? 楼主问题和你说的有关系么? 他得不到IP是因为操作不正确而不是defautlserver的答案不权威 你把ls -d target.com 换为 ls -d www.target.com看看什么效果不就清楚了? isp提供的DNS如果不执行dns区域传送那是什么isp?如果没有本地zone,不会向root请求,那叫什么DNS?哈哈 其实从你的回答就明显的告诉我们,你根本还是没看RFC的 //nslookup不象你的web dns请求那样会进行多重请求的// 这句话的错误大到什么程度你知道不??? 首先web dns是什么东西?我想你指得是ie的查询操作吧? 但这个和多重请求有关系么?有没有多重请求是Server的事情,和客户没关系,呵呵~~,或者你把ls -d target.com 换为target.com.那么在isp的DNS上你是会得到答案的。那么由此说明nslookup进行了多重操作? 本人觉得技术上最恶心的事情莫过于把一些大多数人不了解但实际上是空开的技术标准的东西换一个名字,搞得神神秘秘的糊弄人 |
B13层 发表时间: 05/28 21:53 |
![]() | 回复: TomyChen [quest] ![]() |
登录 |
我还从来没听说有人敢背RFC文档的。WHY?这东西是用来参考,而不是用来背的~就比如能把路由协议等一系统理论式的东东倒着背的人,未必能把一个网络架起来。原因?自己想吧 |
B14层 发表时间: 05/29 14:47 |
![]() | 回复: q70213526 [q70213526] ![]() |
登录 |
我的妈啊,这不是我来的地方,快跑!!!!!!!!!!!!!!!1 |
B15层 发表时间: 05/31 14:29 |
![]() | 回复: sunshine [bysx] ![]() |
登录 |
我想问个很蠢的问题,如果所有的dns都能找到你要的信息,那server指令有什么用? |
B16层 发表时间: 05/31 19:28 |
![]() | 回复: root_bug [root_bug] ![]() |
登录 |
修练一段时间再来看这!先闪! |
B17层 发表时间: 06/08 14:48 |
![]() | 回复: hacants [hacants] ![]() |
登录 |
不理解,能否告诉我研究这些是干什么用的? CMD怎么说whois不是内部命令? |
B18层 发表时间: 06/16 08:54 |
![]() | 回复: xiean [xiean] ![]() |
登录 |
/* 我想问个很蠢的问题,如果所有的dns都能找到你要的信息,那server指令有什么用?*/ 比如我是某某ISP的管理员,我需要测试公司提供给用户的几个dns是否运行正常,那样是不是我应该改本机的 /etc/resolv.conf 呢?还是仅用一个命令来指定测试的 DNS Server? /* 用nslookup的时候,有一个default server,你的default server对于目标服务器并不是权威的,所以你找不到,在你去nslookup以前,最好先去一些nic whois一下,找出对目标权威的dns server. */ 要是一个 ISP 的 dns 居然不会轮巡,那还叫 isp 啊,又或者说你所用的 dns 服务器,它的数据不更新的?如果更新又是从哪来的?难不成是管理员手动?那 zone 文件里的 $TTL 值又是给你干啥的? nic whois 是指域名注册后,解析域名的 ns,所有的更改信息都会发送到根域,也就是 '.' 域,并在 48 小时内,全世界的dns服务器会以树型结构更新这个信息,楼主所说的邮件服务器解析,好像没必要,也没意义这样吧 [此贴被 邪・安(xiean) 在 06月21日00时16分 编辑过] |
B19层 发表时间: 06/21 00:22 |
|
20CN网络安全小组版权所有
Copyright © 2000-2010 20CN Security Group. All Rights Reserved.
论坛程序编写:NetDemon
粤ICP备05087286号