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
[DNSOP] More on Special Use Domain Registry
I have gotten the sense of a belief that IANA (the IANA functions office) runs many registries for the IETF and they are not controversial and because of this, the issues surrounding the Special Use Domain Name registry are all fluff and no substance. But the Special Use Domain Name registry is a special case, it is not a run-of-the-mill IANA registry. The registry is special because the items registered are not bound in a narrow scope. The registered items (names) are used in many different contexts. This is opposed to protocol parameter registries, where the registered item has a very narrow meaning. E.g., "MX" as a mnemonic for the numeric value of 15 in the registry for resource records is not treated as a conflict with "MX" as the two-letter code for Mexico (not an IANA registry). (Ignoring well known use problems with dig.) There are registries run by IANA like the Special Use Domain Name registry when it comes to scope. To name two the IPv4 and IPv6 address registries. Addresses and other number parameters (AS numbers) are used in narrow contexts but are also seen in other places. The point is that these registries are supported by well-developed policies for entering items into registries, the Regional Internet Registries have agreed to pan-RIR, global policies on these registries. This writing is in reaction to a rather limited set of participants in the discussions on the topic. Maybe that is appropriate, maybe that is a reflection that the DNSOP WG is not the best place to cover this topic. That is not an insult because there's a significant difference between the function of registration (of anything) and the function of the DNS system. Those two topics are often confused and I think that is happening again. If it seems that there is limited discussion during this two-week period and the consensus is that this is not a topic for the WG, I think that it is understandable. Although many in DNSOP WG have expertise for this, the roster of other work represents "time better spent" means that this work could be pushed off the table. However, the discussion ought to be resumed somewhere else. I think that the Special Use Domain Name registry is needed but as it is currently defined, inadequate. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] More on Special Use Domain Registry
>This writing is in reaction to a rather limited set of participants in the disc >ussions on the topic. Maybe that is appropriate, maybe that is a reflection th >at the DNSOP WG is not the best place to cover this topic. That is not an insu >lt because there's a significant difference between the function of registratio >n (of anything) and the function of the DNS system. Those two topics are often > confused and I think that is happening again. > >If it seems that there is limited discussion during this two-week period and th >e consensus is that this is not a topic for the WG, I think that it is understa >ndable. Although many in DNSOP WG have expertise for this, the roster of other > work represents "time better spent" means that this work could be pushed off t >he table. However, the discussion ought to be resumed somewhere else. I think > that the Special Use Domain Name registry is needed but as it is currently def >ined, inadequate. I think draft-tldr-sutld-ps describes only the tip of an iceberg: o There is strong resistance within the IETF to assigning names to things outside of the DNS, for a variety of reasons: * Requires a mechanism for identifying which of a set of resolution processes is required in order to resolve a particular name. [...] * The semantics of alternative resolution protocols may differ from the DNS protocol; DNS has the concept of RRtypes; other protocols may not support RRtypes, or may support some entirely different data structuring mechanism. We have no architecture how to deal with radically different naming systems that share a single name space. Certainly .onion uses completely different concepts than are used in DNS. This is a technical question that in my opinion the IETF should address. One extreme is to have no technical requirements. Anything that can benefit from a piece of the global name space can apply. The other extreme would be to require that such a system is on the outside similar to DNS, i.e. support the equivalent of , MX, etc. lookups. For example, is .onion as described in RFC 7686 from a technical point of view what we want or not. If the outcome of such a discussion would be to have no technical requirements on alternative naming systems, then it makes more sense to have the name community create a policy for such registrations and limit IETF activity to specifications that are strongly interconnected with internet standards, such as .ipv4only.arpa ___ 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?
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] More on Special Use Domain Registry
> On Sep 23, 2016, at 8:15 AM, Edward Lewis wrote: > > If it seems that there is limited discussion during this two-week period and > the consensus is that this is not a topic for the WG, I think that it is > understandable. Although many in DNSOP WG have expertise for this, the > roster of other work represents "time better spent" means that this work > could be pushed off the table. However, the discussion ought to be resumed > somewhere else. I think that the Special Use Domain Name registry is needed > but as it is currently defined, inadequate. I tend to agree with you. Let’s see what conclusion the chairs will draw from these 2 weeks of discussion… Alain. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] More on Special Use Domain Registry
This is really well put, Ed. Thanks. I'm a little tempted to plagiarize you. On Fri, Sep 23, 2016 at 8:15 AM, Edward Lewis wrote: > I have gotten the sense of a belief that IANA (the IANA functions office) > runs many registries for the IETF and they are not controversial and > because of this, the issues surrounding the Special Use Domain Name > registry are all fluff and no substance. But the Special Use Domain Name > registry is a special case, it is not a run-of-the-mill IANA registry. > > The registry is special because the items registered are not bound in a > narrow scope. The registered items (names) are used in many different > contexts. This is opposed to protocol parameter registries, where the > registered item has a very narrow meaning. E.g., "MX" as a mnemonic for > the numeric value of 15 in the registry for resource records is not treated > as a conflict with "MX" as the two-letter code for Mexico (not an IANA > registry). (Ignoring well known use problems with dig.) > > There are registries run by IANA like the Special Use Domain Name registry > when it comes to scope. To name two the IPv4 and IPv6 address registries. > Addresses and other number parameters (AS numbers) are used in narrow > contexts but are also seen in other places. The point is that these > registries are supported by well-developed policies for entering items into > registries, the Regional Internet Registries have agreed to pan-RIR, global > policies on these registries. > > This writing is in reaction to a rather limited set of participants in the > discussions on the topic. Maybe that is appropriate, maybe that is a > reflection that the DNSOP WG is not the best place to cover this topic. > That is not an insult because there's a significant difference between the > function of registration (of anything) and the function of the DNS system. > Those two topics are often confused and I think that is happening again. > > If it seems that there is limited discussion during this two-week period > and the consensus is that this is not a topic for the WG, I think that it > is understandable. Although many in DNSOP WG have expertise for this, the > roster of other work represents "time better spent" means that this work > could be pushed off the table. However, the discussion ought to be resumed > somewhere else. I think that the Special Use Domain Name registry is > needed but as it is currently defined, inadequate. > > > ___ > 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
