For de-multiplexing the responses off the socket the *only* field you should be using is the ID field. There are error conditions that result in only the DNS header being returned. All responses are *supposed* to be constucted in the DNS. Setting rcode to formerr/notimp and setting qr to 1 does *not* generate valid error messages despite some servers doing this.
For sanity checking responses you use other field like you do with UDP. Mark In message <2de38b36-6391-497d-832f-abd6ad192...@sinodun.com>, sara writes: > > --===============8675959396934527956== > Content-Type: multipart/alternative; > boundary="Apple-Mail=_432A5B83-C240-4934-9A74-E90B5F954451" > > > --Apple-Mail=_432A5B83-C240-4934-9A74-E90B5F954451 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=utf-8 > > > > On 10 Oct 2015, at 17:34, Stephane Bortzmeyer <bortzme...@nic.fr> = > wrote: > >=20 > > Joe, Stephane, (and I just saw Tim too) > > Many thanks for the detailed reviews. > > >=20 > > In the mean time, the issue I see is in section 7 "Since pipelined > > responses can arrive out-of-order, clients MUST match responses to > > outstanding queries using the ID field and port number." This has been > > recently discussed in the DPRIVE working group and seems questionable, > > specially for TCP (since the source and destination port are fixed for > > a given connection). Clients should use the ID field and > > QCLASS+QTYPE+QNAME instead, to demultiplex. > > > On this point, I agree that the wording could be clarified by talking = > about matching responses on a single TCP connection, rather than using = > port number. > > Section 6.2.1. of the draft says: > > "When sending multiple queries over a TCP connection clients MUST take > care to avoid Message ID collisions. In other words, they MUST not > re-use the DNS Message ID of an in-flight query.=E2=80=9D > > So under normal circumstances matching on just the Message ID should be = > sufficient for TCP, which was the reason the QCLASS+QNAME+QTYPE > part was removed when changing the =E2=80=98must' here to =E2=80=98MUST' = > in the last revision of this draft. > > However it is true that requiring matching on all the fields would be = > more consistent with Section 9 of RFC5452 (even though that document is = > mostly UDP focussed) and there seems to be consensus to do that.=20 > > Regards > > Sara.=20= > > --Apple-Mail=_432A5B83-C240-4934-9A74-E90B5F954451 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/html; > charset=utf-8 > > <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = > charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = > -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = > class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = > class=3D"">On 10 Oct 2015, at 17:34, Stephane Bortzmeyer <<a = > href=3D"mailto:bortzme...@nic.fr"; class=3D"">bortzme...@nic.fr</a>> = > wrote:</div><div class=3D""><br class=3D""></div></blockquote><div><br = > class=3D""></div>Joe, Stephane, (and I just saw Tim too)</div><div><br = > class=3D""></div><div>Many thanks for the detailed = > reviews.</div><div><br class=3D""><blockquote type=3D"cite" class=3D""><br= > class=3D"">In the mean time, the issue I see is in section 7 "Since = > pipelined<br class=3D"">responses can arrive out-of-order, clients MUST = > match responses to<br class=3D"">outstanding queries using the ID field = > and port number." This has been<br class=3D"">recently discussed in the = > DPRIVE working group and seems questionable,<br class=3D"">specially for = > TCP (since the source and destination port are fixed for<br class=3D"">a = > given connection). Clients should use the ID field and<br = > class=3D"">QCLASS+QTYPE+QNAME instead, to demultiplex.<br = > class=3D""></blockquote></div><div class=3D""><br class=3D""></div><div = > class=3D"">On this point, I agree that the wording could be clarified by = > talking about matching responses on a single TCP connection, rather than = > using port number.</div><div class=3D""><br class=3D""></div><div = > class=3D"">Section 6.2.1. of the draft says:</div><div class=3D""><br = > class=3D""></div><div class=3D"">"<span style=3D"widows: 1;" = > class=3D"">When sending multiple queries over a TCP connection clients = > MUST take</span></div><pre class=3D"newpage" style=3D"margin-top: 0px; = > margin-bottom: 0px; page-break-before: always; widows: 1;"><font = > face=3D"Helvetica" class=3D""> care to avoid Message ID collisions. In = > other words, they MUST not > re-use the DNS Message ID of an in-flight query.=E2=80=9D</font></pre><pr= > e class=3D"newpage" style=3D"margin-top: 0px; margin-bottom: 0px; = > page-break-before: always; widows: 1;"><font face=3D"Helvetica" = > class=3D""><br class=3D""></font></pre><pre class=3D"newpage" = > style=3D"margin-top: 0px; margin-bottom: 0px; page-break-before: always; = > widows: 1;"><font face=3D"Helvetica" class=3D"">So under normal = > circumstances matching on just the Message ID should be sufficient for = > TCP, which was the reason the QCLASS+QNAME+QTYPE</font></pre><div = > class=3D"">part was removed w<font face=3D"Helvetica" style=3D"widows: = > 1;" class=3D"">hen changing the =E2=80=98must' here to =E2=80=98MUST' in = > the last revision of this draft.</font></div><div class=3D""><span = > style=3D"widows: 1;" class=3D""><br class=3D""></span></div><div = > class=3D""><span style=3D"widows: 1;" class=3D"">However it is true that = > requiring matching on all the fields would be more consistent with = > Section 9 of RFC5452 (even though that document is mostly UDP = > focussed) </span><span style=3D"widows: 1;" class=3D"">and there = > seems to be consensus to do that</span><span style=3D"widows: 1;" = > class=3D"">. </span></div><div class=3D""><span style=3D"widows: = > 1;" class=3D""><br class=3D""></span></div><div class=3D""><span = > style=3D"widows: 1;" class=3D"">Regards</span></div><div class=3D""><span = > style=3D"widows: 1;" class=3D""><br class=3D""></span></div><div = > class=3D""><span style=3D"widows: 1;" = > class=3D"">Sara. </span></div></body></html>= > > --Apple-Mail=_432A5B83-C240-4934-9A74-E90B5F954451-- > > > --===============8675959396934527956== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --===============8675959396934527956==-- > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
