<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hello!<br>
</p>
<div class="moz-cite-prefix">On 1/4/19 3:43 PM, Edward Lewis wrote:<br>
</div>
<blockquote type="cite"
cite="mid:F394183E-A680-4CB6-98C4-3074F57AD7B8@icann.org">
<p class="moz-quote-pre" wrap="">This is an interesting
protocol-implementation question. What's being returned by the
server in this case is reasonable (according to the protocol)
but evidently less than useful.</p>
</blockquote>
<p>TL; DR: I think we should change the protocol _if_ it currently
allows that, even though it seems currently a rather rare edge
case.</p>
<p>Still, at a quick check I'm not yet convinced whether the
protocol allows that, due to RFC formulations being a bit vague:<br>
<blockquote type="cite">
<p class="newpage">The TC bit should be set in responses only
when an RRSet is required as a part of the response, but could
not be included in its entirety.<br>
</p>
</blockquote>
</p>
<blockquote type="cite">
<p class="newpage">Put whatever addresses are available into the
additional section, using glue RRs if the addresses are not
available from authoritative data or the cache.</p>
</blockquote>
<p><br>
</p>
<p>I'd really hate recommending additional resolver workarounds in
style: "the upstream server's (non-)replies are suspicious, let's
try turning off things like EDNS, case randomization, tweak buffer
length,... and see if it gets better". /cc <a
class="moz-txt-link-freetext" href="https://dnsflagday.net/">https://dnsflagday.net/</a></p>
<p>[1] <a class="moz-txt-link-freetext"
href="https://tools.ietf.org/html/rfc2181#section-9">https://tools.ietf.org/html/rfc2181#section-9</a><br>
[2] <a class="moz-txt-link-freetext"
href="https://tools.ietf.org/html/rfc6672#section-3.2">https://tools.ietf.org/html/rfc6672#section-3.2</a></p>
<p>--Vladimir</p>
</body>
</html>