Re: [DNSOP] Clarifying referrals (#35)
Andrew Sullivan wrote: > > Joe Abley and I have just submitted a draft > (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/) > that is intended to capture the discussion here about referrals and > how to describe them. It is intended for BCP, and it discourages > upward referrals by authoritative servers. > > That leaves the task of the referrals definition. I have some new > text below: Regarding the definition of referrals from older RFCs, see my terminology review from May 2015: https://www.ietf.org/mail-archive/web/dnsop/current/msg14243.html As far as I can tell, RFC 1034 uses the term "referral" for downward referrals. For instance, section 4.2.1: To fix this problem, a zone contains "glue" RRs which are not part of the authoritative data, and are address RRs for the servers. These RRs are only necessary if the name server's name is "below" the cut, and are only used as part of a referral response. Section 4.3.1: A referral to name servers which have zones which are closer ancestors to the name than the server sending the reply. I think that quote implies that other less formal uses of "closer" specifically mean downward in the DNS tree. The downward meaning is most clear in the algorithm in section 4.3.2. Step 3 deals with authoritative data, and says: b. If a match would take us out of the authoritative data, we have a referral. This happens when we encounter a node with NS RRs marking cuts along the bottom of a zone. Step 4 is where upward referrals come from (when the cache only contains root hints and no authoritative zone matches the qname), but it does NOT use the term "referral": 4. Start matching down in the cache. If QNAME is found in the cache, copy all RRs attached to it that match QTYPE into the answer section. If there was no delegation from authoritative data, look for the best one from the cache, and put it in the authority section. Go to step 6. So I think unqualified "referral" means "downward referral" (from authoritative data); it's OK to use the term "upward referral" to mean a response from the cache that looks like a referral but doesn't help to answer the query. I have also seen the term "implicit referral" meaning the authority section from a recursive response, since the idea was that a downstream cache might use those records to answer future queries more efficiently (though doing that is no longer considered safe). Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Fisher: Northerly 3 or 4, increasing 5 or 6, then becoming cyclonic later. Moderate, occasionally rough in west. Showers, wintry later. Good, occasionally poor later. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
Hi, On Wed, Nov 29, 2017 at 11:16:28AM +, Tony Finch wrote: > > Regarding the definition of referrals from older RFCs, see my > terminology review from May 2015: > https://www.ietf.org/mail-archive/web/dnsop/current/msg14243.html Yes, it's your review that has caused this issue :) > I think that quote implies that other less formal uses of "closer" > specifically mean downward in the DNS tree. That's plausible. > So I think unqualified "referral" means "downward referral" (from > authoritative data) I'm not totally convinced, but I can certainly see the argument. If we added to the text I proposed something like, "Many people use the unqualified term 'referral' to mean only a downward referral," would that help? > answer the query. I have also seen the term "implicit referral" meaning > the authority section from a recursive response, since the idea was that a > downstream cache might use those records to answer future queries more > efficiently (though doing that is no longer considered safe). Hmm. It seems like we ought to add that point about implicit referral. I wonder how this is related to the "partial referral" Mark is talking about (see elsewhere in this thread). Thanks, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On Wed, Nov 29, 2017 at 01:14:13PM +1100, Mark Andrews wrote: > When the CNAME refers to a name that is out of zone and the target zone is > below > a zone that the server serves you will have CNAME (DNAME) + referral. > > 4.3.2 loops. This part I got. > pass 1 -> 3a (adds CNAME, AA is set as it matches the question > section, QNAME is updated). This is the CNAME response, yes, ok. > pass 2 -> 3b (we have a partial match with a bottom of zone cut which > adds the referral). > Right, and the authoritative server can't proceed, but the referral is necessary. Good, this is helpful, thanks. This also means, of course, that in such a response the answer section isn't empty. Is this why you call it a "partial referral"? Best regards, A > > On 29 Nov 2017, at 1:03 pm, Andrew Sullivan wrote: > > > > Hi Mark, > > > > On Wed, Nov 29, 2017 at 12:57:26PM +1100, Mark Andrews wrote: > >> You can answer only responses, you can have referral only responses, > >> you can partial answer + referral responses. > > > > Where in the algorithm in section 4.3.2 of 1034 (or other, derived > > cases like DNAME) is this "partial answer + referral responses" > > described? If this is well-defined somewhere, I want to refer to it. > > If it is not, I wish to describe it clearly, because it seems pretty > > obvious given the amount of discussion we've had on this topic that > > the notion of referral is nowhere near as clear as people seem to > > think it is. I'm not sure I understand your cryptic remark above, but > > I am certain I can't make it more comprehensible to others without > > you telling me that I'm wrong and need to do it over. So I'm > > appealing to you to try to make your view as clear as possible. > > > > Best regards, > > > > A > > > -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On Tue, Nov 28, 2017 at 07:08:01PM -0800, Paul Vixie wrote: > that's fatally unclear. So I gather :) > then the thing to say would be "a referral should always be downward, and if > a non-downward referral is received, it should be treated as a network data > configuration error". No, that is attempting to define away other kinds of referrals, which is precisely the discussion we were previously having (and why Joe and I wrote that other draft). The terminology draft should not, in my opinion, attempt to change any RFC; and, IMO, 1034 defines referrals in such a way that someone _could_ think that upward referrals are sometimes a normal part of operation. If we want to change the advice of what to do there, I think a different document is needed. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
1034 cannot be reasonably read that way. I am asking for a clarification not a rule change. On November 29, 2017 8:21:01 PM GMT+08:00, Andrew Sullivan wrote: >On Tue, Nov 28, 2017 at 07:08:01PM -0800, Paul Vixie wrote: >> that's fatally unclear. > >So I gather :) > >> then the thing to say would be "a referral should always be downward, >and if >> a non-downward referral is received, it should be treated as a >network data >> configuration error". > >No, that is attempting to define away other kinds of referrals, which >is precisely the discussion we were previously having (and why Joe and >I wrote that other draft). The terminology draft should not, in my >opinion, attempt to change any RFC; and, IMO, 1034 defines referrals >in such a way that someone _could_ think that upward referrals are >sometimes a normal part of operation. If we want to change the advice >of what to do there, I think a different document is needed. > >Best regards, > >A > >-- >Andrew Sullivan >a...@anvilwalrusden.com > >___ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
> On 29 Nov 2017, at 11:17 pm, Andrew Sullivan wrote: > > On Wed, Nov 29, 2017 at 01:14:13PM +1100, Mark Andrews wrote: >> When the CNAME refers to a name that is out of zone and the target zone is >> below >> a zone that the server serves you will have CNAME (DNAME) + referral. >> >> 4.3.2 loops. > > This part I got. > >> pass 1 -> 3a (adds CNAME, AA is set as it matches the question >> section, QNAME is updated). > > This is the CNAME response, yes, ok. > >> pass 2 -> 3b (we have a partial match with a bottom of zone cut which >> adds the referral). >> > > Right, and the authoritative server can't proceed, but the referral is > necessary. Good, this is helpful, thanks. This also means, of > course, that in such a response the answer section isn't empty. Is > this why you call it a "partial referral”? I said “partial answer + referral”, and yes. > Best regards, > > A > >>> On 29 Nov 2017, at 1:03 pm, Andrew Sullivan wrote: >>> >>> Hi Mark, >>> >>> On Wed, Nov 29, 2017 at 12:57:26PM +1100, Mark Andrews wrote: You can answer only responses, you can have referral only responses, you can partial answer + referral responses. >>> >>> Where in the algorithm in section 4.3.2 of 1034 (or other, derived >>> cases like DNAME) is this "partial answer + referral responses" >>> described? If this is well-defined somewhere, I want to refer to it. >>> If it is not, I wish to describe it clearly, because it seems pretty >>> obvious given the amount of discussion we've had on this topic that >>> the notion of referral is nowhere near as clear as people seem to >>> think it is. I'm not sure I understand your cryptic remark above, but >>> I am certain I can't make it more comprehensible to others without >>> you telling me that I'm wrong and need to do it over. So I'm >>> appealing to you to try to make your view as clear as possible. >>> >>> Best regards, >>> >>> A >>> >> > > -- > Andrew Sullivan > a...@anvilwalrusden.com > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- 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
Re: [DNSOP] Clarifying referrals (#35)
On Wed, Nov 29, 2017 at 02:37:20AM +, Evan Hunt wrote: > > I think the phrasing is unclear because "this response is not required to > work" is ambiguous. The response *itself* doesn't have to work? Or the > resolver can get along without this response? I took it to mean the > latter, but I see how it could be confusing. Yep, got it. > I'd suggest something like "this response is not strictly speaking > necessary, as it provides no information the resolver didn't already > have; resolution can succeed without it." How about, "This kind of response is not required for resolution or for correctly answering any query, and in practice some authoritative server operators will not return referral responses beyond those required for delegation"? Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On Wed, Nov 29, 2017 at 12:23:36PM +, P Vix wrote: > 1034 cannot be reasonably read that way. Sure it can. See the discussion in draft-sullivan-dnsop-refer-down and on the list not two weeks ago for how. I think it should _not_ be read that way, but an honest reader could read it that way, and the terminology document is not the place to rule on the way people should read a text. We're supposed to be doing description, not prescription. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
Andrew Sullivan wrote: > > I'm not totally convinced, but I can certainly see the argument. If > we added to the text I proposed something like, "Many people use the > unqualified term 'referral' to mean only a downward referral," would > that help? Well, I would say, s/many people/Paul Mockapetris/ :-) > > answer the query. I have also seen the term "implicit referral" meaning > > the authority section from a recursive response, since the idea was that a > > downstream cache might use those records to answer future queries more > > efficiently (though doing that is no longer considered safe). > > Hmm. It seems like we ought to add that point about implicit > referral. Oh, actually, (now I re-read my old definition properly) that term is used in RFC 2308 section 6. > I wonder how this is related to the "partial referral" Mark > is talking about (see elsewhere in this thread). They look similar but have different AA bits, if I understand correctly. An implicit referral comes from the cache whereas Mark's CNAME plus referral comes from authoritative data. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode North Utsire, South Utsire: Northerly or northeasterly 5 or 6, decreasing 4 at times. Moderate or rough. Wintry showers. Good occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
No, sir. Closer means downward. Nobody believes otherwise. Not even you, or Joe. The only person ever to get it wrong was me, and I have recanted. Please do not write anything that blurs or softens the clear language of downwards-ness in 1034. If you can't keep the clear spirit and intent of the existing document then please write nothing at all. On November 29, 2017 8:28:11 PM GMT+08:00, Andrew Sullivan wrote: >On Wed, Nov 29, 2017 at 12:23:36PM +, P Vix wrote: >> 1034 cannot be reasonably read that way. > >Sure it can. See the discussion in draft-sullivan-dnsop-refer-down >and on the list not two weeks ago for how. I think it should _not_ be >read that way, but an honest reader could read it that way, and the >terminology document is not the place to rule on the way people should >read a text. We're supposed to be doing description, not prescription. > >Best regards, > >A > > >-- >Andrew Sullivan >a...@anvilwalrusden.com > >___ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel
> On Nov 16, 2017, at 3:23 AM, tjw ietf wrote: > > This starts a Call for Adoption for draft-huston-kskroll-sentinel I support the document and will review and provide comments. Matt ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On Wed, Nov 29, 2017 at 01:55:29PM +, P Vix wrote: > Please do not write anything that blurs or softens the clear language of > downwards-ness in 1034. If you can't keep the clear spirit and intent of the > existing document then please write nothing at all. > I don't believe 1034 is anywhere near as clear as you are insisting it is; and the empirical evidence of that lack of clarity is the very thing you feel the need to recant. If the WG believes otherwise, then I think it is free to write the definition as it wishes, but only if it removes me as an editor of the terminology document. I do wish to make the definition clear, and I have no complaint where the definition might note that not every operator agrees about providing upward referrals (the text proffered already says that, I think). But I shall not include a change to the definition of referrals such that upward referrals are defined away. They exist, today, all over the Internet, and it would be extremely foolish lexicography to attempt to hide that. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
Andrew Sullivan wrote: > But I shall not include a change to the definition of referrals such > that upward referrals are defined away. They exist, today, all over the > Internet, and it would be extremely foolish lexicography to attempt to > hide that. Upward referrals exist, but bare "referral" is short for "downward referral". Other things that look like referrals (such as upward referrals or implicit referrals) have to have a qualifier. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Shannon, Rockall, Malin, Hebrides: North 5 to 7. Moderate or rough. Showers, but fair for a time later. Good, occasionally moderate. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On 29 Nov 2017, at 7:06, Tony Finch wrote: > Andrew Sullivan wrote: > >> But I shall not include a change to the definition of referrals such >> that upward referrals are defined away. They exist, today, all over the >> Internet, and it would be extremely foolish lexicography to attempt to >> hide that. > > Upward referrals exist, but bare "referral" is short for "downward > referral". Other things that look like referrals (such as upward > referrals or implicit referrals) have to have a qualifier. Yes, please. This is good formulation for our definitional problems. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On Wed, Nov 29, 2017 at 03:06:02PM +, Tony Finch wrote: > Upward referrals exist, but bare "referral" is short for "downward > referral". Other things that look like referrals (such as upward > referrals or implicit referrals) have to have a qualifier. +1 -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On Wed, Nov 29, 2017 at 07:25:53AM -0500, Andrew Sullivan wrote: > How about, "This kind of response is not required for resolution or > for correctly answering any query, and in practice some authoritative > server operators will not return referral responses beyond those > required for delegation"? Up to the comma looks fine. The part after the comma strikes me as over-wordy, and I suggest "and there is no requirement that authoritative servers send them". -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On 29 November 2017 at 12:17, Andrew Sullivan wrote: > On Wed, Nov 29, 2017 at 01:14:13PM +1100, Mark Andrews wrote: > > When the CNAME refers to a name that is out of zone and the target zone > is below > > a zone that the server serves you will have CNAME (DNAME) + referral. > > > > 4.3.2 loops. > > This part I got. > > > pass 1 -> 3a (adds CNAME, AA is set as it matches the question > section, QNAME is updated). > > This is the CNAME response, yes, ok. > > > pass 2 -> 3b (we have a partial match with a bottom of zone cut > which adds the referral). > > > > Right, and the authoritative server can't proceed, but the referral is > necessary. Good, this is helpful, thanks. This also means, of > course, that in such a response the answer section isn't empty. Is > this why you call it a "partial referral"? > And said referral could be to an arbitrary node in the DNS tree, i.e. possibly "upward"? Or am I missing something? > > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On Wed, Nov 29, 2017 at 09:18:39PM +, Dick Franks wrote: > > And said referral could be to an arbitrary node in the DNS tree, i.e. > possibly "upward"? > > Or am I missing something? That depends on whether you believe the later part of the algorithm in RFC 1034 (where it says to do things from the cache) is part of the "referral" part, particularly in a mixed-mode server where it has received a query with RD=0. The list appears to have strong feelings about that. It's why Joe and I wrote draft-sullivan-dnsop-refer-down. As I've said many times, I don't believe that settling that question is appropriate for the terminology document. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Security Considerations for RFC5011 Publishers Authors : Wes Hardaker Warren Kumari Filename: draft-ietf-dnsop-rfc5011-security-considerations-08.txt Pages : 18 Date: 2017-11-29 Abstract: This document extends the RFC5011 rollover strategy with timing advice that must be followed in order to maintain security. Specifically, this document describes the math behind the minimum time-length that a DNS zone publisher must wait before signing exclusively with recently added DNSKEYs. It contains much math and complicated equations, but the summary is that the key rollover / revocation time is much longer than intuition would suggest. If you are not both publishing a DNSSEC DNSKEY, and using RFC5011 to advertise this DNSKEY as a new Secure Entry Point key for use as a trust anchor, you probably don't need to read this document. This document also describes the minimum time-length that a DNS zone publisher must wait after publishing a revoked DNSKEY before assuming that all active RFC5011 resolvers should have seen the revocation- marked key and removed it from their list of trust anchors. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011-security-considerations-08 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-considerations-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5011-security-considerations-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 5011-security-considerations and the safetyMargin
Michael StJohns writes: > Ok - after thinking about it, it turns out to be fairly simple. Thanks for the math and text. Based on your text, I've added (back) the section on safetyMargin. Can you check the -08 version to see if I mis-spoke you at all? Note that I added a few more lines and rounded all the numbers up, since resolvers won't query in a fraction of an increment. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On 29 November 2017 at 21:23, Andrew Sullivan wrote: > On Wed, Nov 29, 2017 at 09:18:39PM +, Dick Franks wrote: > > > > And said referral could be to an arbitrary node in the DNS tree, i.e. > > possibly "upward"? > > > > Or am I missing something? > > That depends on whether you believe the later part of the algorithm in > RFC 1034 (where it says to do things from the cache) is part of the > "referral" part, particularly in a mixed-mode server where it has > received a query with RD=0. The list appears to have strong feelings > about that. It's why Joe and I wrote draft-sullivan-dnsop-refer-down. > Mark's example involved two unrelated (which I mistakenly referred to as arbitrary) zones, and a server having authoritative data for both. Cached data not involved. Until Mark's intervention, I was convinced that referrals were downwards only. I was trying to establish if this creates a counter-example, which might require me to unconvince myself. > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt
internet-dra...@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Domain Name System > Operations WG of the IETF. FYI, this contains the restructuring talked about during IETF100/dnsop as well the new safetyMargin concepts proposed by MSJ. I haven't done a complete double check on all my restructuring yet, so for the chairs especially: there will likely be a -09 very soon ready for second WGLC, but not this one. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
> On 29 Nov 2017, at 21:18, Dick Franks wrote: >> On 29 November 2017 at 12:17, Andrew Sullivan >> wrote: >> >> Right, and the authoritative server can't proceed, but the referral is >> necessary. Good, this is helpful, thanks. This also means, of >> course, that in such a response the answer section isn't empty. Is >> this why you call it a "partial referral"? > > And said referral could be to an arbitrary node in the DNS tree, i.e. > possibly "upward"? > > Or am I missing something? In this case we’re dealing with an authoritative answer containing a CNAME pointing out of the server’s authoritative data. If the server is authoritative only, then there are three cases: (1) the CNAME points to a child zone, so the authority section contains a referral - this is the partial answer plus referral case that Mark described; (2) the CNAME points to a different non-child zone and the server provides full answers, in which case the authority section contains the apex records of the zone containing the CNAME owner; or (3) same as (2) but the server sends minimal answers with an empty authority section. If it is a 1034 hybrid rec+auth server, the 4.3.2 algorithm step 4 requires the same referral in case (1) because there is a “delegation from authoritative data”; in case (2) you get an implicit referral from the cache (which can be upwards). Tony. -- f.anthony.n.finchhttp://dotat.at___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On 29 November 2017 at 23:13, Tony Finch wrote: > > > On 29 Nov 2017, at 21:18, Dick Franks wrote: > > On 29 November 2017 at 12:17, Andrew Sullivan > wrote: >> >> >> Right, and the authoritative server can't proceed, but the referral is >> necessary. Good, this is helpful, thanks. This also means, of >> course, that in such a response the answer section isn't empty. Is >> this why you call it a "partial referral"? >> > > And said referral could be to an arbitrary node in the DNS tree, i.e. > possibly "upward"? > > Or am I missing something? > > > In this case we’re dealing with an authoritative answer containing a CNAME > pointing out of the server’s authoritative data. > > If the server is authoritative only, then there are three cases: (1) the > CNAME points to a child zone, so the authority section contains a referral > - this is the partial answer plus referral case that Mark described; (2) > the CNAME points to a different non-child zone and the server provides full > answers, in which case the authority section contains the apex records of > the zone containing the CNAME owner; or (3) same as (2) but the server > sends minimal answers with an empty authority section. > > If it is a 1034 hybrid rec+auth server, the 4.3.2 algorithm step 4 > requires the same referral in case (1) because there is a “delegation from > authoritative data”; in case (2) you get an implicit referral from the > cache (which can be upwards). > I get the picture. Many thanks ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
> On 29 Nov 2017, at 23:13, Tony Finch wrote: > ... you get an implicit referral from the cache (which can be upwards). I just realised this might be a useful point. Normal (downward) referrals come from authoritative data, and indicate the server is saying to the client, you need to ask here next; on the other hand these special kinds of referrals come from the cache. An implicit referral comes in a full-fat RD=1 RA=1 answer, and indicates the server is telling the client where the answer came from; if RD=0 or RA=0 you can get an upward referral, which indicates the server is telling the client where the server would ask next in order to fill its cache. Normal (downward) referrals are instructions to iterative resolvers; implicit referrals and upward referrals are supposed to be cache-filling gossip (in the distributed systems sense of gossip protocols). Tony. -- f.anthony.n.finchhttp://dotat.at ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On Wed, Nov 29, 2017 at 11:34:12PM +, Tony Finch wrote: > > Normal (downward) referrals come from authoritative data, and indicate the > server is saying to the client, you need to ask here next; on the other hand > these special kinds of referrals come from the cache. An implicit referral > comes in a full-fat RD=1 RA=1 answer, and indicates the server is telling the > client where the answer came from; if RD=0 or RA=0 you can get an upward > referral, which indicates the server is telling the client where the server > would ask next in order to fill its cache. > I think that's correct. But what is not plain to me in my reading, insistent noises on the list notwithstanding, is whether the second ¶ in step 3.b of the algorithm in section 4.3.2 of RFC 1034 is still part of what "a referral" means. The ordinary English meaning, as far as I can tell, of that 3.b subsection is that everything one does as part of step 3.b is a referral response. The problem is that "Go to step 4" is part of that last ¶, not a new ¶, and so what I think is obscure in the algorithm text is whether the stuff you're copying into the response in step 4. I tend to agree that the other parts of STD 13 argues in favour of at least "upward referrals are a degenerate case" and maybe even "upward referrals are _not_ referrals in the bare word sense." But while I find that reading persuasive, there are two important facts to consider: for a long time, that was not actually the reading people adhered to, and there does not seem to have been a lot of complaining about it (indeed, even djb's remarks about DNS barely suggest this is a fault of the server, and AFAICT he thought that BIND was responsible for bubonic plague when he wrote those notes). Second, we should not expect, in fairness, an earnest reader to do the same synoptic reading that others have done, or to reach the same conclusion. It's at least as likely that such a reader will conclude that RFCs 1034 and 1035 are written with a certain lack of terminological rigour -- which is perhaps borne out by the effort we apparently need to make to clarify a term as fundamental as "referral". I don't think anyone in this discussion disagrees about how things _ought_ to operate. But in the terminology document, I think we have tried to preserve the meanings that persist on the Internet. I find it very hard to convince myself either that upward referrals are dead, or even that lots of people don't use "referral response" to mean "referral to the root". I encounter both of these ways of speaking with some regularity. Maybe my sample is really skewed; but I think it is at least as plausible that people who are clued into the DNS think that upward referrals are bad and that therefore all referrals must be down. > implicit referrals and upward referrals are supposed to be cache-filling > gossip (in the distributed systems sense of gossip protocols). > I like this observation. Thanks. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
andrew, et al, i see that the discussion continued overnight (i'm here in beijing) and i hope you can reach a consensus on the matter. here's my input to the terminology of referrals. --- According to RFC 1034 section 4.3.2 step 3 substep B, a referral "happens when we encounter a node with NS RRs marking cuts along the bottom of a zone" and is constructed by copying "the NS RRs for the subzone into the authority section of the reply" and putting "whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache." By this definition, an answer whose answer section is empty and whose authority section contains an NS RR set, is only a "referral" if the NS RRs refer to a subzone of an authority server's zone data. === in other words, we need not argue about what a supposedly reasonable person may be able to understand or misunderstand from the RFC 1034 text and then rephrase it in some way that may raise or lower the risk of misunderstanding, or change the results of understanding. all we need to is quote the actual 1034 text and hope that whatever supposedly reasonable person reads this document, will come to the same conclusions they came to when reading 1034. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
