Re: [DNSOP] Where in a CNAME chain is the QNAME?
On 29 Sep 2016, at 8:01, Robert Edmonds wrote: > Paul Hoffman wrote: >> Oddly, "owner name" is correct here. From RFC 1035, Section 3.2.1 which >> describes the format of resource records: > > Compare that section to the nearly identical §4.1.3, which replaces this > sentence: > > All RRs have the same top level format shown below: > > with: > > The answer, authority, and additional sections all share the same > format: a variable number of resource records, where the number of > records is specified in the corresponding count field in the header. > Each resource record has the following format: > > But, the "All RRs" part of §3.2.1 is still accurate, because an entry in > the question section is not a RR. > > There are some other differences between §3.2.1 and §4.1.3, for instance > §3 uses "owner name" while §4 uses "domain name" to describe the NAME > field, and the infamous signed vs. unsigned definition of the TTL field. Yes, I see that now. N'r mind... --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
Paul Hoffman wrote: > Oddly, "owner name" is correct here. From RFC 1035, Section 3.2.1 which > describes the format of resource records: Compare that section to the nearly identical §4.1.3, which replaces this sentence: All RRs have the same top level format shown below: with: The answer, authority, and additional sections all share the same format: a variable number of resource records, where the number of records is specified in the corresponding count field in the header. Each resource record has the following format: But, the "All RRs" part of §3.2.1 is still accurate, because an entry in the question section is not a RR. There are some other differences between §3.2.1 and §4.1.3, for instance §3 uses "owner name" while §4 uses "domain name" to describe the NAME field, and the infamous signed vs. unsigned definition of the TTL field. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
On Thu, Sep 29, 2016 at 10:36 AM, Paul Hoffman wrote: > On 28 Sep 2016, at 22:50, Robert Edmonds wrote: > > Stephane Bortzmeyer wrote: >> >>> On Mon, Sep 26, 2016 at 09:04:54AM -0400, >>> Matt Larson wrote >>> a message of 41 lines which said: >>> >>> I'd venture that more people familiar with the subject matter would define QNAME as the name in the question section of a DNS message. (That's my sense of the definition, FWIW.) >>> >>> What about adding this text to the Terminology section of the draft? >>> >>>"QNAME": it is defined in and >>>in , section 4.1.2, but, because >>target="RFC2308"/> provides a different definition, we repeat the >>>original one here: the QNAME is the owner name of the record in the >>>Question section. >>> >> >> The QNAME is a domain name, but is it an owner name? There is no owned >> record data in the question section (and the entries in the question >> section are not RRs). >> > > Oddly, "owner name" is correct here. From RFC 1035, Section 3.2.1 which > describes the format of resource records: > > All RRs have the same top level format shown below: > > 1 1 1 1 1 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > | | > / / > / NAME / > | | > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > | TYPE | > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > . . . > > where: > > NAMEan owner name, i.e., the name of the node to which this > resource record pertains. > Yes, Owner name is defined in terms of a resource record, i.e. the domain name that owns a resource record. But the question section has no resource record. It has 3 components of a potential resource record. -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
On 28 Sep 2016, at 22:50, Robert Edmonds wrote: Stephane Bortzmeyer wrote: On Mon, Sep 26, 2016 at 09:04:54AM -0400, Matt Larson wrote a message of 41 lines which said: I'd venture that more people familiar with the subject matter would define QNAME as the name in the question section of a DNS message. (That's my sense of the definition, FWIW.) What about adding this text to the Terminology section of the draft? "QNAME": it is defined in and in , section 4.1.2, but, because provides a different definition, we repeat the original one here: the QNAME is the owner name of the record in the Question section. The QNAME is a domain name, but is it an owner name? There is no owned record data in the question section (and the entries in the question section are not RRs). Oddly, "owner name" is correct here. From RFC 1035, Section 3.2.1 which describes the format of resource records: All RRs have the same top level format shown below: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ . . . where: NAMEan owner name, i.e., the name of the node to which this resource record pertains. . . . And I think that Stephane's new definition text is a good addition to the draft. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
On Thu, Sep 29, 2016 at 01:50:05AM -0400, Robert Edmonds wrote a message of 28 lines which said: > The QNAME is a domain name, but is it an owner name? There is no owned > record data in the question section (and the entries in the question > section are not RRs). You're rigt, of course. Here is the new version: "QNAME": it is defined in and in , section 4.1.2, but, because provides a different definition, we repeat the original one here: the QNAME is the domain name in the Question section. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
On Thu, Sep 29, 2016 at 1:50 AM, Robert Edmonds wrote: > Stephane Bortzmeyer wrote: > > On Mon, Sep 26, 2016 at 09:04:54AM -0400, > > Matt Larson wrote > > a message of 41 lines which said: > > > > > I'd venture that more people familiar with the subject matter would > > > define QNAME as the name in the question section of a DNS message. > > > (That's my sense of the definition, FWIW.) > > > > What about adding this text to the Terminology section of the draft? > > > >"QNAME": it is defined in and > >in , section 4.1.2, but, because >target="RFC2308"/> provides a different definition, we repeat the > >original one here: the QNAME is the owner name of the record in the > >Question section. > > The QNAME is a domain name, but is it an owner name? There is no owned > record data in the question section (and the entries in the question > section are not RRs). > Yes, I agree. I suggest "the QNAME is the domain name that appears in the Question section of a DNS message". -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
On Wed, Sep 28, 2016 at 09:26:38PM +, Stephane Bortzmeyer wrote: > On Mon, Sep 26, 2016 at 12:33:39PM +0100, > Ólafur Guðmundsson wrote > a message of 148 lines which said: > > > The RCODE applies to the RRSET pointed to by the last CNAME in answer > > section (or the missing one). > > This specific case was settled in RFC 6604 and I did not intend to > reopen it. My problem was with the definition of QNAME, not with the > proper rcode for a chain of CNAME. By the way, is it the case that CNAMEs in the answer section MUST appear in their natural chaining order: A. IN CNAME B. B. IN CNAME C. C. IN CNAME D. D. IN CNAME E. Which is to say can stub resolvers assume that this is always the case, or would it prudent to reassemble the list by finding the CNAME whose owner is the qname, and using the target alias to find the name CNAME, ... recursively without making assumptions about the order in which the records appear? I am writing some code in Haskell that process DNS responses, and made no assumptions about CNAME ordering in the response, because Haskell is recursive anyway and finding the starting point rather than using the first remaining response is easy enough. So this code is more robust in the face of unexpected CNAME ordering, irrelevant CNAME responses that are even part of the chain, ... What I'm wondering about is whether this is just quaint pedantry, encouraged by a language that makes it all too easy, or sensibly defensive programming... :-) Or put another way, does step "3 a" of Section 4.3.2 of RFC 1034 imply that responses MUST contain any CNAMEs in the typically expected order? And, if so, is it then the case that clients (wether stub or iterative) need make no effort to deal with responses that are not so ordered? Should clients take care to deal with CNAMEs in the answer section that don't form a linear chain (out of order, or not even possible to re-order as a linear chain). -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
Stephane Bortzmeyer wrote: > On Mon, Sep 26, 2016 at 09:04:54AM -0400, > Matt Larson wrote > a message of 41 lines which said: > > > I'd venture that more people familiar with the subject matter would > > define QNAME as the name in the question section of a DNS message. > > (That's my sense of the definition, FWIW.) > > What about adding this text to the Terminology section of the draft? > >"QNAME": it is defined in and >in , section 4.1.2, but, because target="RFC2308"/> provides a different definition, we repeat the >original one here: the QNAME is the owner name of the record in the >Question section. The QNAME is a domain name, but is it an owner name? There is no owned record data in the question section (and the entries in the question section are not RRs). -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
On Mon, Sep 26, 2016 at 12:33:39PM +0100, Ólafur Guðmundsson wrote a message of 148 lines which said: > The RCODE applies to the RRSET pointed to by the last CNAME in answer > section (or the missing one). This specific case was settled in RFC 6604 and I did not intend to reopen it. My problem was with the definition of QNAME, not with the proper rcode for a chain of CNAME. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
On Mon, Sep 26, 2016 at 09:04:54AM -0400, Matt Larson wrote a message of 41 lines which said: > I'd venture that more people familiar with the subject matter would > define QNAME as the name in the question section of a DNS message. > (That's my sense of the definition, FWIW.) What about adding this text to the Terminology section of the draft? "QNAME": it is defined in and in , section 4.1.2, but, because provides a different definition, we repeat the original one here: the QNAME is the owner name of the record in the Question section. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
Hi, Strong objections to this answer, or can we call it done? ISTM that the avoidance of ambiguity for implementers is the key thing here, so I’m especially interested in hearing from anyone who’s not sure how to code this as written. Thanks all for a good discussion, and the suggestion that defining QNAME might be suitable for draft-ietf-dnsop-terminology-bis. best, Suzanne > On Sep 23, 2016, at 4:22 AM, Stephane Bortzmeyer wrote: > > On Tue, Sep 20, 2016 at 06:13:50PM +0200, > Stephane Bortzmeyer wrote > a message of 68 lines which said: > >> This issue was spotted by Peter van Dijk. It is about >> draft-ietf-dnsop-nxdomain-cut-05, recently approved by IESG. The >> problem is the definition of "QNAME" when there is a CNAME chain. > > OK, after reading the discussion, my opinion, as an author (but I'll > of course defer the decision to the working group, the WG chairs, the > RFC editor and the flying spaghetti monster): > > The re-definition of QNAME by RFC 2308 is awkward and does not match > the general usage, or the previous definitions. Therefore, I prefer to > keep the "common sense" usage "QNAME is the owner name of the record > in the Question Section". Which means that, in my example, the QNAME > is "www.afnic.fr" and the current text of > draft-ietf-dnsop-nxdomain-cut-05 is correct. > > ___ > 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] Where in a CNAME chain is the QNAME?
Hello Paul, On 26 Sep 2016, at 16:32, Paul Hoffman wrote: On 26 Sep 2016, at 0:33, Peter van Dijk wrote: 2308 does not “redefine” QNAME. It clarifies that the usage in 1034 4.3.2 is the definition we use in RFCs. 1035 4.1(.2) does not conflict with this; the QNAME there is just the initial QNAME. This seems like a very limited view of RFC 1034. RFC 1034 actually defines QNAME in Section 3.7.1: 3.7.1. Standard queries A standard query specifies a target domain name (QNAME), query type (QTYPE), and query class (QCLASS) and asks for RRs which match. Further, the usage in Section 4.3.2 does not say that the QNAME is the last name in the chain, just that the algorithm itself repeats with a new value for QNAME: If the data at the node is a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, and go back to step 1. My reading of 3.7.1 + 4.3.2 is ‘the QNAME, at any time, means the name currently under consideration; initially this is the name from the query packet, but it gets updated on every CNAME follow’. To make QNAME work consistently between 1034, 2308 and several of the RFCs mentioned below, this is the only interpretation that makes sense to me. I don’t see any conflict between 1034 and 2308 given this reading. Many other RFCs need 2308: 2874, 4035, 4343, 4592, 4470, 4471, 5074, 5155, 6147, 6672 and most likely several others rely on the 2308 definition of QNAME. Without 2308, each of these RFCs would need extra text such as the text your draft has now. It is simply not necessary. I'm quite concerned about the assertion that RFC 4035 relies on RFC 2038's definition. QNAME is only mentioned in Section 4.5 and 4.7 there, and I don't see how those usages indicate that it is the last name in a chain. Can you clarify? I agree - on rereading that part of 4035 indeed it is talking about whole response packets. Must’ve confused it with denials, like in 5155. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
Paul Hoffman wrote:
> On 26 Sep 2016, at 0:33, Peter van Dijk wrote:
>
> > 2308 does not “redefine” QNAME. It clarifies that the usage in 1034
> > 4.3.2 is the definition we use in RFCs. 1035 4.1(.2) does not conflict
> > with this; the QNAME there is just the initial QNAME.
>
> This seems like a very limited view of RFC 1034. RFC 1034 actually defines
> QNAME in Section 3.7.1:
>
> 3.7.1. Standard queries
>
> A standard query specifies a target domain name (QNAME), query type
> (QTYPE), and query class (QCLASS) and asks for RRs which match.
>
> Further, the usage in Section 4.3.2 does not say that the QNAME is the last
> name in the chain, just that the algorithm itself repeats with a new value
> for QNAME:
>
> If the data at the node is a CNAME, and QTYPE doesn't
> match CNAME, copy the CNAME RR into the answer section
> of the response, change QNAME to the canonical name in
> the CNAME RR, and go back to step 1.
If STD 13 were to be typeset like a technical book, "QNAME" in 1034
§4.3.2 would be styled using the book's typographical convention for a
variable name.
The exact same formulation in §4.3 ("change … to the canonical name in
the CNAME RR") is used again in the resolver algorithm in §5.3:
The following resolver algorithm assumes that all functions have been
converted to a general lookup function, and uses the following data
structures to represent the state of a request in progress in the
resolver:
SNAME the domain name we are searching for.
STYPE the QTYPE of the search request.
SCLASS the QCLASS of the search request.
[…]
5.3.3. Algorithm
The top level algorithm has four steps:
[…]
4. Analyze the response, either:
[…]
c. if the response shows a CNAME and that is not the
answer itself, cache the CNAME, change the SNAME to the
canonical name in the CNAME RR and go to step 1.
[…]
Since "SNAME" doesn't conflict with a term from another part of the
document set, it's clear that SNAME is being used as a variable name. So
the parallel use in §4.3.2 ("change QNAME to the canonical name") must
also be as a variable name, not a terminological (re)definition.
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
On 26 Sep 2016, at 0:33, Peter van Dijk wrote: 2308 does not “redefine” QNAME. It clarifies that the usage in 1034 4.3.2 is the definition we use in RFCs. 1035 4.1(.2) does not conflict with this; the QNAME there is just the initial QNAME. This seems like a very limited view of RFC 1034. RFC 1034 actually defines QNAME in Section 3.7.1: 3.7.1. Standard queries A standard query specifies a target domain name (QNAME), query type (QTYPE), and query class (QCLASS) and asks for RRs which match. Further, the usage in Section 4.3.2 does not say that the QNAME is the last name in the chain, just that the algorithm itself repeats with a new value for QNAME: If the data at the node is a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, and go back to step 1. Many other RFCs need 2308: 2874, 4035, 4343, 4592, 4470, 4471, 5074, 5155, 6147, 6672 and most likely several others rely on the 2308 definition of QNAME. Without 2308, each of these RFCs would need extra text such as the text your draft has now. It is simply not necessary. I'm quite concerned about the assertion that RFC 4035 relies on RFC 2038's definition. QNAME is only mentioned in Section 4.5 and 4.7 there, and I don't see how those usages indicate that it is the last name in a chain. Can you clarify? --Paul Hoffman___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
> On Sep 23, 2016, at 4:22 AM, Stephane Bortzmeyer wrote: > > On Tue, Sep 20, 2016 at 06:13:50PM +0200, > Stephane Bortzmeyer wrote > a message of 68 lines which said: > >> This issue was spotted by Peter van Dijk. It is about >> draft-ietf-dnsop-nxdomain-cut-05, recently approved by IESG. The >> problem is the definition of "QNAME" when there is a CNAME chain. > > OK, after reading the discussion, my opinion, as an author (but I'll > of course defer the decision to the working group, the WG chairs, the > RFC editor and the flying spaghetti monster): > > The re-definition of QNAME by RFC 2308 is awkward and does not match > the general usage, or the previous definitions. Therefore, I prefer to > keep the "common sense" usage "QNAME is the owner name of the record > in the Question Section". Which means that, in my example, the QNAME > is "www.afnic.fr" and the current text of > draft-ietf-dnsop-nxdomain-cut-05 is correct. +1 to this interpretation. I think a good case can be made that QNAME is the last target in a chain of aliases based on the "variable substitution" use of QNAME in §4.3.2 of RFC 1035 and the definition of QNAME in RFC 2308. However, I think this definition violates the principal of least astonishment, as this thread shows: I'd venture that more people familiar with the subject matter would define QNAME as the name in the question section of a DNS message. (That's my sense of the definition, FWIW.) I like the current text in draft-ietf-dnsop-nxdomain-cut-05, which avoids confusion by explicitly calling out "denied name". Even if the consensus of this thread had been that the definition of QNAME was the "last alias target", I'd argue that we'd still want the "denied name" language to avoid any confusion because I don't think the "last alias target" of QNAME is the majority interpretation. Matt ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
On Mon, Sep 26, 2016 at 8:33 AM, Peter van Dijk wrote: > Hello, > > On 23 Sep 2016, at 10:22, Stephane Bortzmeyer wrote: > > On Tue, Sep 20, 2016 at 06:13:50PM +0200, >> Stephane Bortzmeyer wrote >> a message of 68 lines which said: >> >> This issue was spotted by Peter van Dijk. It is about >>> draft-ietf-dnsop-nxdomain-cut-05, recently approved by IESG. The >>> problem is the definition of "QNAME" when there is a CNAME chain. >>> >> >> OK, after reading the discussion, my opinion, as an author (but I'll >> of course defer the decision to the working group, the WG chairs, the >> RFC editor and the flying spaghetti monster): >> >> The re-definition of QNAME by RFC 2308 is awkward and does not match >> the general usage, or the previous definitions. Therefore, I prefer to >> keep the "common sense" usage "QNAME is the owner name of the record >> in the Question Section". Which means that, in my example, the QNAME >> is "www.afnic.fr" and the current text of >> draft-ietf-dnsop-nxdomain-cut-05 is correct. >> > > 2308 does not “redefine” QNAME. It clarifies that the usage in 1034 4.3.2 > is the definition we use in RFCs. 1035 4.1(.2) does not conflict with this; > the QNAME there is just the initial QNAME. > > Many other RFCs need 2308: 2874, 4035, 4343, 4592, 4470, 4471, 5074, 5155, > 6147, 6672 and most likely several others rely on the 2308 definition of > QNAME. Without 2308, each of these RFCs would need extra text such as the > text your draft has now. It is simply not necessary. > > > Peter, is right but the root cause is the role of "CNAME" and to lesser extent "DNAME". Both is what I have part of DNS Navigation records that act like "rewriters". 1034 was light on detail, 2308 might have uses a better notation but the effect would have been the same, The RCODE applies to the RRSET pointed to by the last CNAME in answer section (or the missing one). In hindsight the use of single RCODE with limited enumeration is the root cause. If one was designing this again one would allow multiple Questions in the header and each RRset would have a header that says what its ReturnCode is, but that is the advantage of hindsight. Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
Hello, On 23 Sep 2016, at 10:22, Stephane Bortzmeyer wrote: On Tue, Sep 20, 2016 at 06:13:50PM +0200, Stephane Bortzmeyer wrote a message of 68 lines which said: This issue was spotted by Peter van Dijk. It is about draft-ietf-dnsop-nxdomain-cut-05, recently approved by IESG. The problem is the definition of "QNAME" when there is a CNAME chain. OK, after reading the discussion, my opinion, as an author (but I'll of course defer the decision to the working group, the WG chairs, the RFC editor and the flying spaghetti monster): The re-definition of QNAME by RFC 2308 is awkward and does not match the general usage, or the previous definitions. Therefore, I prefer to keep the "common sense" usage "QNAME is the owner name of the record in the Question Section". Which means that, in my example, the QNAME is "www.afnic.fr" and the current text of draft-ietf-dnsop-nxdomain-cut-05 is correct. 2308 does not “redefine” QNAME. It clarifies that the usage in 1034 4.3.2 is the definition we use in RFCs. 1035 4.1(.2) does not conflict with this; the QNAME there is just the initial QNAME. Many other RFCs need 2308: 2874, 4035, 4343, 4592, 4470, 4471, 5074, 5155, 6147, 6672 and most likely several others rely on the 2308 definition of QNAME. Without 2308, each of these RFCs would need extra text such as the text your draft has now. It is simply not necessary. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
On Fri, Sep 23, 2016 at 07:57:26PM +, Viktor Dukhovni wrote a message of 73 lines which said: > This would I believe cause problems if one then concludes that the > subtree below the QNAME is absent. For the record, I agree with Robert Edmonds: this case is well covered in the current draft-ietf-dnsop-nxdomain-cut-05, with the concept of "denied name" (which is often, but not always, the QNAME). > So the NXDOMAIN for "truth" in the first query definitely does not > preclude a "stranger" subtree under "truth". It only attests to the > non-existence of "fiction". > > IIRC, reading a long-ago discussion on this topic, Paul Vixie, for > one, seemed to say that the first NXDOMAIN response is not only > acceptable, but is in fact the more correct choice. Yes, and it has been settled some time ago, with RFC 6604. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
Viktor Dukhovni wrote: > On Fri, Sep 23, 2016 at 10:22:32AM +0200, Stephane Bortzmeyer wrote: > > > On Tue, Sep 20, 2016 at 06:13:50PM +0200, > > Stephane Bortzmeyer wrote > > a message of 68 lines which said: > > > > > This issue was spotted by Peter van Dijk. It is about > > > draft-ietf-dnsop-nxdomain-cut-05, recently approved by IESG. The > > > problem is the definition of "QNAME" when there is a CNAME chain. > > > > OK, after reading the discussion, my opinion, as an author (but I'll > > of course defer the decision to the working group, the WG chairs, the > > RFC editor and the flying spaghetti monster): > > > > The re-definition of QNAME by RFC 2308 is awkward and does not match > > the general usage, or the previous definitions. Therefore, I prefer to > > keep the "common sense" usage "QNAME is the owner name of the record > > in the Question Section". Which means that, in my example, the QNAME > > is "www.afnic.fr" and the current text of > > draft-ietf-dnsop-nxdomain-cut-05 is correct. > > This would I believe cause problems if one then concludes that the > subtree below the QNAME is absent. How would one conclude that, when the document is careful to distinguish between the QNAME and the "denied name"? Abstract This document states clearly that when a DNS resolver receives a response with response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist. […] "Denied name": the domain name whose existence has been denied by a response of rcode NXDOMAIN. In most cases, it is the QNAME but, because of [RFC6604], it is not always the case. […] Warning: if there is a chain of CNAME (or DNAME), the name which does not exist is the last of the chain ([RFC6604]) and not the QNAME. The NXDOMAIN stored in the cache is for the denied name, not always for the QNAME. […] -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
On Fri, Sep 23, 2016 at 10:22:32AM +0200, Stephane Bortzmeyer wrote: > On Tue, Sep 20, 2016 at 06:13:50PM +0200, > Stephane Bortzmeyer wrote > a message of 68 lines which said: > > > This issue was spotted by Peter van Dijk. It is about > > draft-ietf-dnsop-nxdomain-cut-05, recently approved by IESG. The > > problem is the definition of "QNAME" when there is a CNAME chain. > > OK, after reading the discussion, my opinion, as an author (but I'll > of course defer the decision to the working group, the WG chairs, the > RFC editor and the flying spaghetti monster): > > The re-definition of QNAME by RFC 2308 is awkward and does not match > the general usage, or the previous definitions. Therefore, I prefer to > keep the "common sense" usage "QNAME is the owner name of the record > in the Question Section". Which means that, in my example, the QNAME > is "www.afnic.fr" and the current text of > draft-ietf-dnsop-nxdomain-cut-05 is correct. This would I believe cause problems if one then concludes that the subtree below the QNAME is absent. Below is a live example I just configured on a BIND 9.10.4-P2 authoritative server as reported by an "unbound" recursor (RRSIGs elided): ; <<>> DiG 9.10.4-P2 <<>> +dnssec +noall +comment +qu +ans +auth +nocl +nottl +cmd -t a truth.msmuxy.org ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39791 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1 ;truth.msmuxy.org. IN A truth.msmuxy.org. CNAME fiction.msmuxy.org. msmuxy.org. SOA ns.imrryr.org. postmaster.dukhovni.org. 631 3600 1200 604800 1200 U3H5CG8C4NE5NMCTRQ6BGRTB6LS3ROJQ.msmuxy.org. NSEC3 1 0 10 468B49CA72DA45F2 VM1M59BBPA704LUI11Q0T4CA3VA6KS77 NS SOA MX RRSIG DNSKEY NSEC3PARAM RP80TVU8HQVVE7P086NTPTN2SLRLU5OC.msmuxy.org. NSEC3 1 0 10 468B49CA72DA45F2 TM87BRIHMJM6HUF608JKLNOGTJQIAH0J While at the same time we also have: ; <<>> DiG 9.10.4-P2 <<>> +dnssec +noall +comment +qu +ans +auth +nocl +nottl +cmd -t a stranger.truth.msmuxy.org ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56877 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;stranger.truth.msmuxy.org. IN A stranger.truth.msmuxy.org. A192.0.2.1 So the NXDOMAIN for "truth" in the first query definitely does not preclude a "stranger" subtree under "truth". It only attests to the non-existence of "fiction". IIRC, reading a long-ago discussion on this topic, Paul Vixie, for one, seemed to say that the first NXDOMAIN response is not only acceptable, but is in fact the more correct choice. That compared with the alternative of returning just the CNAME (NOERROR) w/o a chained answer for the original RRTYPE and leaving the client to ask again with the target name only to discover that the target of the CNAME elicits NXDOMAIN. So it seems that "NXDOMAIN" + CNAME, attests only to the target, not the original QNAME and with DNSSEC comes along with a proof of non-existence for the target, and a proof existence for the CNAME itself. This could almost have imposed rather complex for DANE clients, had there been a possibility of useful TLSA records for a hostname that is an alias leading to a non-existent target. However, since it is not possible to connect to such a host (no A/ records), any TLSA records it might have are moot. -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
On Tue, Sep 20, 2016 at 06:13:50PM +0200, Stephane Bortzmeyer wrote a message of 68 lines which said: > This issue was spotted by Peter van Dijk. It is about > draft-ietf-dnsop-nxdomain-cut-05, recently approved by IESG. The > problem is the definition of "QNAME" when there is a CNAME chain. OK, after reading the discussion, my opinion, as an author (but I'll of course defer the decision to the working group, the WG chairs, the RFC editor and the flying spaghetti monster): The re-definition of QNAME by RFC 2308 is awkward and does not match the general usage, or the previous definitions. Therefore, I prefer to keep the "common sense" usage "QNAME is the owner name of the record in the Question Section". Which means that, in my example, the QNAME is "www.afnic.fr" and the current text of draft-ietf-dnsop-nxdomain-cut-05 is correct. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
Hello, On 20 Sep 2016, at 19:09, Warren Kumari wrote: I think the RFC2308 definition is only true in the negative caching context... or something... Which, of course, is the context in which draft-ietf-dnsop-nxdomain-cut uses QNAME. I’m not here to argue which definition of QNAME is correct, but I do think the text could use some clarification to avoid this confusion. Easiest might be to point at 2308 as that definition is functionally identical to the longer texts the draft has now. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
Hello,
On 20 Sep 2016, at 18:13, Stephane Bortzmeyer wrote:
Do you like long terminology discussions, backed by a dozen RFC, where
people disagree on what's written in these RFC? If so, read on.
When I told you about this confusion in your draft I wasn’t even
looking for a long terminology discussion. Be careful what you wish for,
I suppose ;)
RFC 7719 does not define QNAME (probably because it seemed obvious).
I checked 7719 today, was surprised QNAME was not in there. Probably a
good idea to fix for 7719bis?
Is the QNAME "www.afnic.fr" or "lb01-1.nic.fr" ("the data field of the
last CNAME")???
In my mind, lb01-1.nic.fr, but I understand the other position -
somewhat.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
On Tue, Sep 20, 2016 at 12:37 PM, Robert Edmonds wrote:
> Stephane Bortzmeyer wrote:
>> Do you like long terminology discussions, backed by a dozen RFC, where
>> people disagree on what's written in these RFC? If so, read on.
>
> Yes, please!
>
>> RFC 1034 had a different definition of QNAME but is not clear on the
>> specific case of CNAME chains:
>>
>> > A standard query specifies a target domain name (QNAME)
>
> RFC 1034 gives an "algorithm" (§4.3.2):
>
> […] Search the available zones for the zone which is the nearest
> ancestor to QNAME. […]
>
> […] If the whole of QNAME is matched, we have found the node.
>
> If the data at the node is a CNAME, and QTYPE doesn't match
> CNAME, copy the CNAME RR into the answer section of the
> response, change QNAME to the canonical name in the CNAME
> RR, and go back to step 1.
>
> […]
>
> It seems the use of QNAME for anything other than the question resource
> record name is due to this "variable reuse" in the §4.3.2 "algorithm".
>
> RFC 1035 gives a definition of QNAME in §4.1.
>
> All communications inside of the domain protocol are carried in a
> single format called a message. […]
>
> The names of the sections after the header are derived from their
> use in standard queries. The question section contains fields that
> describe a question to a name server. These fields are a query type
> (QTYPE), a query class (QCLASS), and a query domain name (QNAME).
> […]
>
> So, this implies that QNAME means the same thing regardless of whether
> the message is a query or response.
>
> Also see §4.1.2 which is even more graphic about where the QNAME is.
>
>> So, which is right? In this DNS query:
>>
>> % dig A www.afnic.fr
>>
>> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> A www.afnic.fr
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35551
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 1280
>> ;; QUESTION SECTION:
>> ;www.afnic.fr.IN A
>>
>> ;; ANSWER SECTION:
>> www.afnic.fr. 213 IN CNAME www.nic.fr.
>> www.nic.fr. 213 IN CNAME lb01-1.nic.fr.
>> lb01-1.nic.fr.213 IN A 192.134.5.24
>>
>> ;; Query time: 875 msec
>> ;; SERVER: 192.168.43.1#53(192.168.43.1)
>> ;; WHEN: Tue Sep 20 18:11:06 CEST 2016
>> ;; MSG SIZE rcvd: 100
>>
>> Is the QNAME "www.afnic.fr" or "lb01-1.nic.fr" ("the data field of the
>> last CNAME")???
>
> "www.afnic.fr", because that is the domain name in the question section.
+1.
The QNAME is (or, should be :-)) the name which is in the question.
Things get tricky when chasing CNAMEs because there can be multiple
questions, and so "the" QNAME changes. But, in your example above, I
believe it is www.afnic.fr.
I think the RFC2308 definition is only true in the negative caching
context... or something...
W
>
> --
> Robert Edmonds
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
The definition of QNAME in RFC 2308 feels like it is only relevant when discussing negative caching, not in general. All the other uses of the 1034/1035 definition of QNAME after 2308 feel consistent. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Where in a CNAME chain is the QNAME?
Stephane Bortzmeyer wrote:
> Do you like long terminology discussions, backed by a dozen RFC, where
> people disagree on what's written in these RFC? If so, read on.
Yes, please!
> RFC 1034 had a different definition of QNAME but is not clear on the
> specific case of CNAME chains:
>
> > A standard query specifies a target domain name (QNAME)
RFC 1034 gives an "algorithm" (§4.3.2):
[…] Search the available zones for the zone which is the nearest
ancestor to QNAME. […]
[…] If the whole of QNAME is matched, we have found the node.
If the data at the node is a CNAME, and QTYPE doesn't match
CNAME, copy the CNAME RR into the answer section of the
response, change QNAME to the canonical name in the CNAME
RR, and go back to step 1.
[…]
It seems the use of QNAME for anything other than the question resource
record name is due to this "variable reuse" in the §4.3.2 "algorithm".
RFC 1035 gives a definition of QNAME in §4.1.
All communications inside of the domain protocol are carried in a
single format called a message. […]
The names of the sections after the header are derived from their
use in standard queries. The question section contains fields that
describe a question to a name server. These fields are a query type
(QTYPE), a query class (QCLASS), and a query domain name (QNAME).
[…]
So, this implies that QNAME means the same thing regardless of whether
the message is a query or response.
Also see §4.1.2 which is even more graphic about where the QNAME is.
> So, which is right? In this DNS query:
>
> % dig A www.afnic.fr
>
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> A www.afnic.fr
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35551
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1280
> ;; QUESTION SECTION:
> ;www.afnic.fr.IN A
>
> ;; ANSWER SECTION:
> www.afnic.fr. 213 IN CNAME www.nic.fr.
> www.nic.fr. 213 IN CNAME lb01-1.nic.fr.
> lb01-1.nic.fr.213 IN A 192.134.5.24
>
> ;; Query time: 875 msec
> ;; SERVER: 192.168.43.1#53(192.168.43.1)
> ;; WHEN: Tue Sep 20 18:11:06 CEST 2016
> ;; MSG SIZE rcvd: 100
>
> Is the QNAME "www.afnic.fr" or "lb01-1.nic.fr" ("the data field of the
> last CNAME")???
"www.afnic.fr", because that is the domain name in the question section.
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Where in a CNAME chain is the QNAME?
Do you like long terminology discussions, backed by a dozen RFC, where
people disagree on what's written in these RFC? If so, read on.
This issue was spotted by Peter van Dijk. It is about
draft-ietf-dnsop-nxdomain-cut-05, recently approved by IESG. The
problem is the definition of "QNAME" when there is a CNAME chain.
Section 1.1 says:
> "Denied name": the domain name whose existence has been denied by a
> response of rcode NXDOMAIN. In most cases, it is the QNAME but,
> because of [RFC6604], it is not always the case.
And section 2:
> Warning: if there is a chain of CNAME (or DNAME), the name which
> does not exist is the last of the chain ([RFC6604]) and not the
> QNAME. The NXDOMAIN stored in the cache is for the denied name, not
> always for the QNAME.
This text in draft-ietf-dnsop-nxdomain-cut-05 assumes that the QNAME
is the owner name in the Question Section. But RFC 2308 thinks otherwise:
> "QNAME" - the name in the query section of an answer, or where this
> resolves to a CNAME, or CNAME chain, the data field of the last
> CNAME.
RFC 1034 had a different definition of QNAME but is not clear on the
specific case of CNAME chains:
> A standard query specifies a target domain name (QNAME)
RFC 7719 does not define QNAME (probably because it seemed obvious).
So, which is right? In this DNS query:
% dig A www.afnic.fr
; <<>> DiG 9.10.3-P4-Ubuntu <<>> A www.afnic.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35551
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;www.afnic.fr. IN A
;; ANSWER SECTION:
www.afnic.fr. 213 IN CNAME www.nic.fr.
www.nic.fr. 213 IN CNAME lb01-1.nic.fr.
lb01-1.nic.fr. 213 IN A 192.134.5.24
;; Query time: 875 msec
;; SERVER: 192.168.43.1#53(192.168.43.1)
;; WHEN: Tue Sep 20 18:11:06 CEST 2016
;; MSG SIZE rcvd: 100
Is the QNAME "www.afnic.fr" or "lb01-1.nic.fr" ("the data field of the
last CNAME")???
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
