blocks|key|1085232|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|-4|4|5|6|B|7|@]|8|@]|9|$]]]|A|$]]

<blockquote>
When a DNS resolver lookup a domain/zone for an authoritative name server, does it take in all 6 records and cycle through them ?
</blockquote>
Yes, a proper recursive nameserver takes into account all nameservers and will try to query each time later the fastest one.
A rough algorithm is kind of:
<ul>
<li>from a cold start (no cache), try all of them randomly, record how fast they reply (you might need to separate the UDP case from the TCP case there)</li>
<li>after some time, start to use more frequently the fastest one based on previous replies</li>
<li>but note that you need to make sure not to stick indefinitely with any given nameserver, you have to try &quot;from time to time&quot; the other ones too. Why? Because the network topology can change, as well as the nameservers themselves. <code>ns3</code> might be the faster one today for your specific vantage point, but maybe tomorrow it is <code>ns5</code> instead; so you have to use the fastest one, but not always, just to make sure to be able to automatically discover any other one faster than the one you believe to be the fastest right now.</li>
</ul>
<blockquote>
If a resolver use the 1st NS server
</blockquote>
Stop here. Records are coming in a set, not a list. That is there is no inherent order in the DNS. Of course there is an order in the wire or display representation, but it does not come from the protocol.
Records sets are bags: you get records, without orders. In fact, you can see that many nameservers, for the exact same query, if there are multiple records in the reply, will order the records differently each time you query, exactly to combat client systems that would only take into account the first item and disregard the others.
<blockquote>
when that authoritative name server is not responding
</blockquote>
See algorithm above: if one of the nameservers in the <code>NS</code> set is not responding, you can consider it to be the same as &quot;replying as slowest from any other one&quot;. The client DNS has timeouts so it won't wait infinitely but mark this specific nameserver has too slow, and will switch to other ones.
So at first time you incur a penalty because the system has to try to contact that nameserver, wait a little (few seconds), retry and at some point stop using that nameserver. After that ramp, it will use the other nameservers and things will be fast. But the first time you have to discover a given nameserver is slow/not responding by really trying to contact it, you can't infer the problem without trying.
<blockquote>
Does that mean i need to set short TTL for NS records ?
</blockquote>
Maybe, but it is mostly irrelevant. Why? Because your <code>NS</code> records are published in the parent zone of your domain, to ensure the DNS delegation. They are published there with a TTL of course, as all records have a TTL attached to them, but they are published in a zone you don't control, hence you can NOT choose their TTL values!
(There is a complicated/not completely finished discussion here about those records, like <code>NS</code> that exist in two parts: the parent and the child, with the question &quot;which one is really authoritative&quot;? If the parent has a TTL of 1 week on <code>NS</code> records and you in your zone the same <code>NS</code> records have a TTL of 1 second, what should the recursive nameserver do? One might arrive to the conclusion that normally the child part of the delegation IS authoritative, so 1 second wins here; in practice multiple DNS implementations are &quot;parent-centric&quot; that is they use the data at the parent side, so 1 week wins there)
TTLs are always a trade-offs. Once known some people are immediately jumping to the conclusion that things work better with very low TTLs... which is true for some cases and not so much for others. Caches are good, if they were not there (aka: not using big enough TTLs) you are not resilient against any small problems, that would make everything vanish because caches would have expired the names already.
Also the TTL value has no (or little) impact for the algorithm above in cycling along all nameservers, trying with timeout and converging on the fastest one.
So if you look at what happens in TLD nameservers (that host <code>NS</code> records for all domains under that TLD) or in various recommendations, you will often see <code>NS</code> records with a TTL of 1 or 2 days.
<blockquote>
Any advise on how resolver DNS works with non-responsive NS and its TTL ?
</blockquote>
Each resolver does its own :-) This is not really specified by the protocol, it is an implementation detail. You can study source code for the one you can install, but probably won't be able to gather details about that from big public recursive DNS providers.
You can find more details though here:
<ul>
<li><a href="https://securityintelligence.com/subverting-binds-srtt-algorithm-derandomizing-ns-selection/" rel="nofollow noreferrer">https://securityintelligence.com/subverting-binds-srtt-algorithm-derandomizing-ns-selection/</a></li>
<li><a href="https://www.nanog.org/meetings/nanog54/presentations/Tuesday/Yu.pdf" rel="nofollow noreferrer">https://www.nanog.org/meetings/nanog54/presentations/Tuesday/Yu.pdf</a></li>
</ul>
RFC 1034 §5.3.3 does give some information too (note also that it takes into account one case you forgot: a given nameserver may have multiple IP addresses - today even it should always be the case, with one IPv4 and one IPv6 - and there is no guarantee you get results in the same amount of time with each):
<blockquote>
In addition to the names and addresses of the servers, the SLIST data
structure can be sorted to use the best servers first, and to insure
that all addresses of all servers are used in a round-robin manner. The
sorting can be a simple function of preferring addresses on the local
network over others, or may involve statistics from past events, such as
previous response times and batting averages.
</blockquote>
<blockquote>
Step 3 sends out queries until a response is received. The strategy is
to cycle around all of the addresses for all of the servers with a
timeout between each transmission. In practice it is important to use
all addresses of a multihomed host, and too aggressive a retransmission
policy actually slows response when used by multiple resolvers
contending for the same name server and even occasionally for a single
resolver. SLIST typically contains data values to control the timeouts
and keep track of previous transmissions.
</blockquote>
RFC 1035 §7.2 has this to say:
<blockquote>
To complete initialization of SLIST, the resolver attaches whatever
history information it has to the each address in SLIST. This will
usually consist of some sort of weighted averages for the response time
of the address, and the batting average of the address (i.e., how often
the address responded at all to the request). Note that this
information should be kept on a per address basis, rather than on a per
name server basis, because the response time and batting average of a
particular server may vary considerably from address to address. Note
also that this information is actually specific to a resolver address /
server address pair, so a resolver with multiple addresses may wish to
keep separate histories for each of its addresses. Part of this step
must deal with addresses which have no such history; in this case an
expected round trip time of 5-10 seconds should be the worst case, with
lower estimates for the same local network, etc.
</blockquote>
<blockquote>
Note that whenever a delegation is followed, the resolver algorithm
reinitializes SLIST.
</blockquote>
<blockquote>
The information establishes a partial ranking of the available name
server addresses. Each time an address is chosen and the state should
be altered to prevent its selection again until all other addresses have
been tried. The timeout for each transmission should be 50-100% greater
than the average predicted value to allow for variance in response.
</blockquote>
Also to finish and more specifically about this:
<blockquote>
As illustrated in this writeup from imperva
</blockquote>
This article you reference talks about the issue that happened for people using Dyn nameservers, when there was an outage.
Then, yes, if you use only Dyn nameservers you have a problem. As even if you change your zone to use other ones, the <code>NS</code> records TTL means your change won't be seen immediately. But that in reality does not say a lot about TTLs but just says a lot about DNS management: if you want to be resilient, for important zones, do not use a single DNS providers, but multiple ones (which of course mandates some coordination between them you can not just arbitrarily mix and match provider X and Y, and it is even more complicated if you through DNSSEC into the mix, but is possible).
That way, exactly because of the algorithm quickly drafted above, even if 2 out of 5 let us say nameserver are failing to reply completely because this specific provider has a problem, the other will take the load and make your domain work. There might be an extra delay at each new query for visitors (because all recursive nameservers can not immediately understand that they have to switch to specific nameservers because 2 out of 5 are down), and also more delays because the other 3 are overwhelmed with more queries than normal (the DNS is load balancing by default so in theory each nameserver gets roughly the same volume of queries), but still a reply will be given.
PS: not asked for, but as it is sometimes not clear, all records in a given recordset have to have the same TTL. The TTL is per record, but needs to be the same in a given recordset, which means for a given tuple of (name, record type) [and class, but no one uses anything besides <code>IN</code> as class]

If a zone has 6 NS records
When a DNS resolver lookup a domain/zone for an authoritative name server, does it take in all 6 records and cycle through them ?
If a resolver use the 1st NS server and cached it according to its TTL - when that authoritative name server is not responding, does the resolver still honor the TTL of the NS record ?
As illustrated in <a href="https://www.imperva.com/blog/is-dns-redundancy-the-right-answer" rel="nofollow noreferrer">this</a> writeup from imperva - it seems like even if the authoritative nameserver is not responding - the resolver will still try to use it until its TTL expires - how true it that ?
<blockquote>
Basically, in those cases where websites had multiple NS records, the resolution between them was impeded by the very way that DNS resolvers work. The resolver could have tried to reach the inactive Dyn server so long as the resolver’s cached NS-record was current, which would be true until the TTL of the NS-record expires
</blockquote>
Does that mean i need to set short TTL for NS records ?
Any advise on how resolver DNS works with non-responsive NS and its TTL ?
Thank you

DNS resolver vs NS record TTL

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

如果区域有6个NS记录当DNS解析器查找权威名称服务器的域/区域时，它是否接收所有6条记录并遍历它们？如果解析器使用第一个NS服务器并根据其TTL缓存它--当该权威名称服务器没有响应时，解析器是否仍然遵守NS记录的TTL？正如来自imperva的这书面版本所说明的--即使权威的名称服务器没有响应，解析器仍然会尝试使用它，直到TTL过期--这有多真实呢？基本上，在那些网站有多个NS记录的情况下，DN

问DNS解析器与NS记录TTL
EN

回答 1

Server Fault用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问DNS解析器与NS记录TTLEN