DNS请求Scapy（Python）
我编写了一个创建DNS数据包并发送的代码。数据包模拟nslookup -type = soa facebook.com 8.8.8.8命令。 但是由于某种原因，我从“ nslookup”命令返回的内容中得到了不同的答案。
我的代码DNS服务器输出：“ a.ns.c10r.facebook.com”
nslookup -type = soa facebook.com 8.8.8.8.8命令 dns服务器：“ a.ns.facebook.com”
- 我的最终目标是获得网站DNS服务器，因此我能够获得网站IP地址的权威答案 带有DNS包。
这是我的代码：
from scapy.all import *
from scapy.layers.dns import DNS, DNSQR
from scapy.layers.inet import IP, UDP
def main():
dns_server_request = IP(dst='8.8.8.8') / UDP(dport=53) / DNS(rd=1, qd=DNSQR(qname='www.facebook.com', qtype='SOA'))
ans = sr1(dns_server_request, verbose=0)
ans.show()
if __name__ == "__main__":
main()
有人知道我在做什么错，我该如何解决？
- （我的代码未通过方式工作的DNS服务器）
I wrote a code that creates a dns packet and sends it. The packet simulates the nslookup -type=soa facebook.com 8.8.8.8 command for example.
But for some reason I get a different answer from what the 'nslookup' command returns.
my code dns server output: "a.ns.c10r.facebook.com"
the dns server from nslookup -type=soa facebook.com 8.8.8.8 command: "a.ns.facebook.com"
- my final goal is to get a site dns server so I would be able to get an authoritative answer for the site ip address
with a dns packet.
this is my code:
from scapy.all import *
from scapy.layers.dns import DNS, DNSQR
from scapy.layers.inet import IP, UDP
def main():
dns_server_request = IP(dst='8.8.8.8') / UDP(dport=53) / DNS(rd=1, qd=DNSQR(qname='www.facebook.com', qtype='SOA'))
ans = sr1(dns_server_request, verbose=0)
ans.show()
if __name__ == "__main__":
main()
someone know what am I doing wrong and how can I fix it?
- (the dns server that my code is giving not working by the way)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
TL; DR：您想查询Apex域，Facebook.com，
而不是www。
（1.），好吧，您正在使用
nslookup作为开始者。 :-)当然可以从该工具中获得有用的结果
给予一点照顾。
但我强烈建议您更喜欢
DIG对于您所有的交互式查询。
有点像使用
tcpdump端口域，因为它默认显示出您 everything
从给定的名称服务器回来了。
（2.）您查询的域很重要。
请注意，“ www”是一个指向
在star-mini.c10r.facebook.com上。
而且由于FB是一件大衣服，
事实证明，有一个削减区域可以支撑
命名空间的那一部分，
因此，它有自己的bailiwick。
好问题！
为我们提供可爱的 mre 。
很明显你在做什么，
无需澄清评论。
值得注意的是，不需要mname
在SOA中回应您的查询。
严格来说，这是一个私人安排AXFR细节
恰好在查询结果中暴露了这种情况。
许多区域都会有一个所谓的“隐藏大师”
响应NS设置的成员
但是不会回应一般的INET客户。
当您发现一个新区域时，
与您发布的SOA结果一样，
最合适的事情
查询该区域的NS设置吗？
询问其授权的名称服务器。
您当然可以也可以查询mname nameServer，
但是如果没有回答，不要感到惊讶
或寄回拒绝。
请注意，
DIG +TRACE +NORECURSE可以弄清楚很有帮助
哪些名字服务员在bailiwick
对于一些深嵌套的区域名称。
tl;dr: You wanted to query the apex domain, facebook.com,
rather than www.
(1.) Well, you're using
nslookup, for starters. :-)One can, of course, obtain useful results from that tool
given a bit of care.
But I strongly recommend that you prefer
digfor all your interactive queries.
It is a bit like using
tcpdump port domain,in that it defaults to showing you everything
that came back from the given nameserver.
(2.) The domain you query matters.
Note that "www" is a CNAME pointing
at star-mini.c10r.facebook.com.
And since FB is a large outfit,
it turns out there's a zone cut to support
that part of the namespace,
so it has its own bailiwick.
Good question!
Kudos for offering us a lovely MRE.
It's very clear what you're doing,
no need for clarifying comments.
It's worth noting that there is no requirement for MNAME
in an SOA to respond to your queries.
It is strictly a private arrangement AXFR detail
that happens to be exposed in query results.
Many zones will have a so-called "hidden master"
that responds to members of the NS set
but won't respond to general inet clients.
When you discover a new zone,
as with that SOA result you posted,
the most appropriate thing to do
is query that zone's NS set and
interrogate its delegated nameservers.
You can of course also query the MNAME nameserver,
but don't be surprised if it doesn't answer
or sends back REFUSED.
Note that
dig +trace +norecursecan be quite helpful in figuring out
which nameservers are in bailiwick
for some deeply nested zone name.