<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">If the names of the referred
nameservers are in the domain of the referral (e.g. *.example.com
nameservers referred for the example.com delegation), then it is
*mandatory* to fill in the Additional Section with the relevant
A/AAAA address records, since there is no other way for the
referral to work (chicken-and-egg problem).<br>
<br>
In most other cases, the contents of the Additional Section are
discretionary; the responding nameserver can fill in whatever it
thinks is "useful" to the requester. For security reasons, though,
the requester would be wise to only pay attention to those records
in the Additional Section that are within the "bailiwick" of the
original question, otherwise they might accept something
untrustworthy into their cache (the whole "bailiwick" thing is
confusing, but
<a class="moz-txt-link-freetext" href="http://www.linuxjournal.com/content/understanding-kaminskys-dns-bug">http://www.linuxjournal.com/content/understanding-kaminskys-dns-bug</a>
explains it fairly well).<br>
<br>
The decision of what nameserver, among several, gets picked for
resolving iterative queries for a particular domain, is only
tangentially related to Additional Section processing, since NS
records can be fetched or seen in a variety of ways, and they are
(as Chris responded) selected via an adaptive algorithm based on
SRTT (smoothed round-trip time). Even that, however, has been
proven to be somewhat susceptible to attack:
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<p class="MsoNormal"><span
style="font-family:"Verdana","sans-serif";color:black"><a
href="http://securityintelligence.com/subverting-binds-srtt-algorithm-derandomizing-ns-selection/">http://securityintelligence.com/subverting-binds-srtt-algorithm-derandomizing-ns-selection/</a><o:p></o:p></span><br>
</p>
in order to steer traffic to particular nameservers, for purposes,
presumably, of DoS or to magnify the effect of a subset of
nameservers having been compromised.<br>
<br>
- Kevin<br>
<br>
On 1/19/2014 10:30 PM, houguanghua wrote:<br>
</div>
<blockquote cite="mid:BAY173-W40250D3B05F6947E2D26DDBBA50@phx.gbl"
type="cite">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:微软雅黑
}
--></style>
<div dir="ltr">Dear all,<br>
<br>
Would you please tell me which RFC depicts the policy of
'additional section'? and how bind server deals with 'additional
section'? <br>
<br>
Sometimes the number of 'additional section' is more than numbe
of 'authority section'. I don't know how local bind server will
do when receiving these additional sections. <br>
Local Bind server may:<br>
--
pick one name server randomly<br>
<div><span style="font:/normal Tahoma; color: rgb(0, 0, 0);
text-transform: none; text-indent: 0px; letter-spacing:
normal; word-spacing: 0px; float: none; display: inline
!important; white-space: normal; orphans: 2; widows: 2;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width:
0px;"><span> -- or </span>use sophisticated policies that
"score" name servers and pick more often the ones that
replied faster</span></div>
<br>
Which is right?<br>
<br>
Thanks!<br>
Guanghua<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Please visit <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list
bind-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a></pre>
</blockquote>
<br>
</body>
</html>