[DNSOP] dnsop - Requested sessions have been scheduled for IETF 108
Dear Tim Wicinski, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dnsop Session 1 (1:40 requested) Wednesday, 29 July 2020, Session I 1100-1240 Room Name: Room 3 size: 3 - dnsop Session 2 (0:50 requested) Wednesday, 29 July 2020, Session II 1300-1350 Room Name: Room 2 size: 2 - iCalendar: https://datatracker.ietf.org/meeting/108/sessions/dnsop.ics Request Information: - Working Group Name: Domain Name System Operations Area Name: Operations and Management Area Session Requester: Tim Wicinski Number of Sessions: 2 Length of Session(s): 100 Minutes, 50 Minutes Number of Attendees: 160 Conflicts to Avoid: Chair Conflict: dhc homenet dnssd dprive maprg add Technology Overlap: lamps dmarc acme trans intarea regext People who must be present: Suzanne Woolf Warren Ace Kumari Tim Wicinski Benno Overeinder Resources Requested: Special Requests: - ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
On Thu, Jul 2, 2020 at 9:14 AM Paul Hoffman wrote: > The interpretation of whether a partial RRset is allowed by 1035/2181 made > by JohnL, PaulV, and MukundS are all plausible and conflicting. RFC 1035 > and RFC 2181 are unclear about whether an RRset that is required in a reply > can be partial. > > draft-ietf-dnsop-glue-is-not-optional as it stands is probably not the > best place to update the understanding of the standards-level relationship > between partial RRsets, the TC bit, and what parts of a response are > required. Doing so is adventurous, time-consuming, and will almost > certainly cause multiple current implementations to be out of compliance. > > It is probably still worth doing, albeit carefully. A bad outcome would be > finishing the document due to exhaustion instead of consensus. > I agree with Paul H in this regard. Here's how I see it: the update to 1035 is necessary, but not sufficient (probably). Note that 1035 itself predates EDNS, so advice on TC alone is good, but for the population of DNS implementations doing EDNS, perhaps we could take advantage of its existence? There are a whole bunch of unused bits in the core element of the OPT RR (the place where the DO bit exists). That would be an excellent (IMHO) place to signal the situation here (partial glue truncation). Such a bit would hopefully disambiguate the cases where TC=1 is set, allowing for graceful handling (try to use the available glue, prepare for the failure case and retry over TCP if it does fail). Thoughts? Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
The interpretation of whether a partial RRset is allowed by 1035/2181 made by JohnL, PaulV, and MukundS are all plausible and conflicting. RFC 1035 and RFC 2181 are unclear about whether an RRset that is required in a reply can be partial. draft-ietf-dnsop-glue-is-not-optional as it stands is probably not the best place to update the understanding of the standards-level relationship between partial RRsets, the TC bit, and what parts of a response are required. Doing so is adventurous, time-consuming, and will almost certainly cause multiple current implementations to be out of compliance. It is probably still worth doing, albeit carefully. A bad outcome would be finishing the document due to exhaustion instead of consensus. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
On Thu, Jul 02, 2020 at 03:29:01PM +, Paul Vixie wrote: > On Thursday, 2 July 2020 14:50:24 UTC John R Levine wrote: > > On Thu, 2 Jul 2020, Paul Vixie wrote: > > > ... but our goal should be to allow smart initiators to avoid > > > retrying with TCP out of reflex. my recommendation of TC=0 is to suppress > > > reflexive TCP retries. > > I wouldn't disagree but it seems to me once again it's a tradeoff between > > performance and correctness. I'd prefer correctness, particularly since > > it seems that the option to use what's in a truncated referral gets you > > both. > > TC=1 will, on several DNS initiators whose architecture i know, automatically > trigger TCP fallback, without regard to what's in the various sections. that > is often a layering constraint in the software, where "get the response" has > the fallback logic, and "look at the response" comes after that's completed. > > > > 3. even without TC=1 you will know there's under-zonecut glue you didn't > > > receive, because you saw the NS RR, and the only path to the address RR is > > > through that NS RRset. > > > > Well, maybe. Even if you got one A record there might be others. > > no. truncation is on RRset boundaries. even in a truncated response, RRsets > are never broken up. if you have any A records for a name, you have them all. IIRC truncation on RRset boundaries is not defined. This is usually why initiators abandon the whole message when TC=1. E.g., from RFC 1035 section 7.4: > When a response is truncated, and a resolver doesn't know whether it > has a complete set, it should not cache a possibly partial set of RRs. implying that it may not be a complete set, and RFC 2181 section 9: > Where TC is set, the partial RRSet that would not completely fit may > be left in the response. When a DNS client receives a reply with TC > set, it should ignore that response, and query again, using a > mechanism, such as a TCP connection, that will permit larger replies. Mukund signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
On Thursday, 2 July 2020 14:50:24 UTC John R Levine wrote: > On Thu, 2 Jul 2020, Paul Vixie wrote: > > ... but our goal should be to allow smart initiators to avoid > > retrying with TCP out of reflex. my recommendation of TC=0 is to suppress > > reflexive TCP retries. > I wouldn't disagree but it seems to me once again it's a tradeoff between > performance and correctness. I'd prefer correctness, particularly since > it seems that the option to use what's in a truncated referral gets you > both. TC=1 will, on several DNS initiators whose architecture i know, automatically trigger TCP fallback, without regard to what's in the various sections. that is often a layering constraint in the software, where "get the response" has the fallback logic, and "look at the response" comes after that's completed. > > 3. even without TC=1 you will know there's under-zonecut glue you didn't > > receive, because you saw the NS RR, and the only path to the address RR is > > through that NS RRset. > > Well, maybe. Even if you got one A record there might be others. no. truncation is on RRset boundaries. even in a truncated response, RRsets are never broken up. if you have any A records for a name, you have them all. > Or if > you got an record but no A record and you're on an IPv4 network, you > can't tell whether there's a lurking A record or not, or vice-versa. > (See the glue for j.zdnscloud.com in the root.) that's why my proposal was to only avoid setting TC=1 if some minimal amount of glue does fit, specifically two RRsets of each address type ( and A). > If we do it your way, if any NS is in-zone and the lookups fail, you > *always* need to do a TCP query just to see if if the UDP response left > something out. in the statement, "if in-zone and failures then TCP" does not warrant the use of the word "always" which is either redundant (that's what if/then means) or misleading (failures aren't the norm). i am ok with having to use TCP when not all glue fits, and the part that does fit, refers to currently-unreachable servers. a zone for whom two of its servers, on all of their address types, are down is going to see serious slowdown due to timeouts. so, already a bad day well worth avoiding. getting additional TCP fallback is additive not multiplicative to the badness costs in that non-normal situation. > > R's, > John > > PS: I'm less worried about round-robin DNS, since then it's clearly a > deliberate decision by the parent to leave some of the answers out. here, round-robin is an access method used for populating a section, and in this case the section is additional-data not answer. so, round-robin and random-robin should behave similarly in the truncation path we're discussing, where i'm saying the truncation would be better off silent (TC=0). -- Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
On Thu, 2 Jul 2020, Paul Vixie wrote: until someone invents faster than light travel, round trips and remote state will be the second and third most expensive things on the internet. (the most expensive thing is complexity.) i think we can usefully discuss whether to set TC=1 if the only thing that won't fit is glue, but some glue did fit. but our goal should be to allow smart initiators to avoid retrying with TCP out of reflex. my recommendation of TC=0 is to suppress reflexive TCP retries. I wouldn't disagree but it seems to me once again it's a tradeoff between performance and correctness. I'd prefer correctness, particularly since it seems that the option to use what's in a truncated referral gets you both. 3. even without TC=1 you will know there's under-zonecut glue you didn't receive, because you saw the NS RR, and the only path to the address RR is through that NS RRset. Well, maybe. Even if you got one A record there might be others. Or if you got an record but no A record and you're on an IPv4 network, you can't tell whether there's a lurking A record or not, or vice-versa. (See the glue for j.zdnscloud.com in the root.) If we do it your way, if any NS is in-zone and the lookups fail, you *always* need to do a TCP query just to see if if the UDP response left something out. R's, John PS: I'm less worried about round-robin DNS, since then it's clearly a deliberate decision by the parent to leave some of the answers out. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
On Thursday, 2 July 2020 07:47:36 UTC Paul Vixie wrote: > On Thursday, 2 July 2020 01:18:16 UTC John Levine wrote: > > ... > > this is the draft where that issue would be decided, so it's good we're > talking about it. ... by the way, this is what kato and i, and later jabley, were trying to get at with https://datatracker.ietf.org/doc/draft-ietf-dnsop-respsize/ but it was like moving mud with a toothpick, so after eleven years (2003 to 2014) we gave it up. there are probably some good ideas in there, even now. -- Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
On Thursday, 2 July 2020 01:18:16 UTC John Levine wrote: > In article <9056955.dJ39pTEj9z@linux-9daj> you write: > >On Wednesday, 1 July 2020 09:41:49 UTC Jan Včelák wrote: > >> ... > > > >i think if you're using round robin or random selection, a subset is fine. > >if we had to codify this practice, i'd ask that at least two address > >records of each available kind be included (so, two 's, two A's) or > >else set TC=1. > I really don't like this. If you do that, you're going to have > failures when there are working servers but none of their addresses > happen to be in the glue subset in the response, and without TC=1 > there's no hint that there's more glue if you retry. this is the draft where that issue would be decided, so it's good we're talking about it. there are subtleties to the proposal you quoted, such that: 1. it is not possible to fetch the glue directly from the server who sent you the silently truncated delegation, all you can get is another referral. 2. you'll get a different subset of the available glue each time you retry, due to random ordering or round-robin. 3. even without TC=1 you will know there's under-zonecut glue you didn't receive, because you saw the NS RR, and the only path to the address RR is through that NS RRset. any full resolver who doesn't like the conditions detected in #3 above is free to either retry as in #2 above, or just fetch with TCP, since the silent truncation is unambiguously implied. > If a response with TC=1 has at least one record in the additional > section, that tells the client that the missing records are all glue. true to form, BIND4/8 did that, and no harm came of it, but it's difficult to standardize, and is not an optimization, it's a definite signal pattern meant to convey meaning. while 1035 does describe response construction order, that would have to be reiterated in case some responder has been adding things column wise rather than row wise, and has never had a complaint from it until the day somebody starts to depend on actual 1035 RRset stuffing order. this feels like pushing on a rope, but i know we have to do that sometimes. > So I think it would be OK in that case for the client to use what it's > got, but remember that if it can't contact any of the NS with the > A/ it's got, it can go back and get the rest. ...with TCP, i hope you meant. > Remember, if it's glue, there's no other way to get it. If it's worth > returning glue at all, it's worth providing all of it. until someone invents faster than light travel, round trips and remote state will be the second and third most expensive things on the internet. (the most expensive thing is complexity.) i think we can usefully discuss whether to set TC=1 if the only thing that won't fit is glue, but some glue did fit. but our goal should be to allow smart initiators to avoid retrying with TCP out of reflex. my recommendation of TC=0 is to suppress reflexive TCP retries. -- Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
