Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue
Viktor Dukhovni wrote: > The draft states that in rare cases sibling glue could be useful, as a > result of cyclic dependency loops. Interesting. Such dependency existed between two TLDs (IIRC "edu" and "org") 20 or 30 years ago and I thought and still think there are redundancy issues. That is, the example in the draft is insufficient and, at least, the following should be an additional example: bar.test. 86400 IN NS ns1.foo.test. bar.test. 86400 IN NS ns2.foo.test. foo.test. 86400 IN NS ns1.foo.test. foo.test. 86400 IN NS ns1.bar.test. foo.test. 86400 IN NS ns2.bar.test. in which case, without sibling glue, if ns1.foo.test goes down, name resolutions of both zones become impossible, which should not satisfy minimum required redundancy of DNS. If zones have local redundancy policy to allow two or more (N) name servers simuntaneously go down, which should be the cases with zones having (N+1) name servers, more examples can be constructed. For example: bar.test. 86400 IN NS ns1.foo.test. bar.test. 86400 IN NS ns2.foo.test. bar.test. 86400 IN NS ns1.bar.test. foo.test. 86400 IN NS ns1.foo.test. foo.test. 86400 IN NS ns1.bar.test. foo.test. 86400 IN NS ns2.bar.test. suffers, if two in-zone name servers go down. In late 2021 the authors analyzed zone file data available from ICANN's Centralized Zone Data Service [CZDS] and found 222 out of approximately 209,000,000 total delegations that had only sibling domain NS RRs in a cyclic dependency as above. "only sibling domain NS RRs"? If my examples above are considered, there should be more cases. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
To be clear, I am not saying that RFC1034/1035 say that you /can/ use QDCOUNT > 1. I am saying that they do /not/ say that you /can not/ use QDCOUNT > 1. On Thu, Feb 16, 2023 at 5:53 PM Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > Dick Franks wrote: > > >> So, there is no specification to mention queries with > >> QDCOUNT>1, either informatively, optionaly or normatively. > > >> Then, 3425 titled "Obsoleting IQUERY" updated 1035. > > >> As such, after 3425, QDCOUNT nomatively must always be 1. > > > The last statement is informatively and normatively mistaken. > > The counterexample is to be found in RFC8490(5.4): > > Not up to date. OK. Thanks. But, my statements are enough to deny > the original statement by Ted as if 1034 had admitted standard > queries with QDCOUNT>1 and another statement by Joe: > > > But we know that those are old documents that lack normative > > clarity. > > w.r.t. normative status of standard queries. > > As Mark and I stated: > > >> It does not prohibit extended query forms be they a different > >> QDCOUNT for QUERY, a new opcode which supports multiple queries. > Nor > does it prohibit protocol extentions to allow standard > > queries have QDCOUNT>1, > > modifying 1034/5 is fine but possibility/existence of such > modifications can not be a supporting fact for a false > statement that 1034 had admitted standard queries with > QDCOUNT>1. > > Masataka Ohta > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue
On Thu, Feb 16, 2023 at 09:15:35PM -0500, Viktor Dukhovni wrote: > Perhaps we'll find that we can't distinguish sibling glue from still > required "orphan glue" (mention of which I see got removed from > draft-02), and need the sibling glue as a last resort when the forward > lookup of the out-of-bailiwick name fails. That would I guess be > unforunate, because I'd much rather see all "unnatural" glue disappear > from DNS delegation zones. Actually, orphan glue is of course not a problem and not needed as sibling glue, since as part of the parent domain's authoritative data it is in fact easily resolved via an explicit query. -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
Dick Franks wrote: >> So, there is no specification to mention queries with >> QDCOUNT>1, either informatively, optionaly or normatively. >> Then, 3425 titled "Obsoleting IQUERY" updated 1035. >> As such, after 3425, QDCOUNT nomatively must always be 1. The last statement is informatively and normatively mistaken. The counterexample is to be found in RFC8490(5.4): Not up to date. OK. Thanks. But, my statements are enough to deny the original statement by Ted as if 1034 had admitted standard queries with QDCOUNT>1 and another statement by Joe: > But we know that those are old documents that lack normative > clarity. w.r.t. normative status of standard queries. As Mark and I stated: It does not prohibit extended query forms be they a different QDCOUNT for QUERY, a new opcode which supports multiple queries. > Nor does it prohibit protocol extentions to allow standard > queries have QDCOUNT>1, modifying 1034/5 is fine but possibility/existence of such modifications can not be a supporting fact for a false statement that 1034 had admitted standard queries with QDCOUNT>1. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-01.txt
Did you really intend to make the message hard to read? Really "font-size:small”? Really grey instead of black "color:#33”? Please fix your MUA settings or choose a different MUA that actually has sane settings. Hi folks, we (finally) pu= blished a new version of the domain verification techniques draft, now as i= ntended-BCP. Weve had some feedback from providers but would love for = folks=C2=A0to review, especially people who would actually use it.On = Thu, 16 Feb 2023 at 11:15, mailto:internet-dra...@ietf.org;>= internet-dra...@ietf.org wrote: > On 17 Feb 2023, at 06:20, Shivan Kaul Sahib wrote: > > Hi folks, we (finally) published a new version of the domain verification > techniques draft, now as intended-BCP. We've had some feedback from providers > but would love for folks to review, especially people who would actually use > it. > > On Thu, 16 Feb 2023 at 11:15, wrote: > > 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 : Domain Verification Techniques using DNS > Authors : Shivan Sahib > Shumon Huque > Paul Wouters > Filename: draft-ietf-dnsop-domain-verification-techniques-01.txt > Pages : 11 > Date: 2023-02-16 > > Abstract: >Many services on the Internet need to verify ownership or control of >a domain in the Domain Name System (DNS). This verification is often >done by requesting a specific DNS record to be visible in the domain. >There are a variety of techniques in use today, with different pros >and cons. This document proposes some practices to avoid known >problems. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-verification-techniques-01.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-domain-verification-techniques-01 > > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > ___ > 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 -- 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] I-D Action: draft-ietf-dnsop-domain-verification-techniques-01.txt
It appears that Shivan Kaul Sahib said: >-=-=-=-=-=- > >Hi folks, we (finally) published a new version of the domain verification >techniques draft, now as intended-BCP. We've had some feedback from >providers but would love for folks to review, especially people who would >actually use it. While I think it would be good to publish some best practices in this area, this draft still seems scattered and makes some assertions that seem to me to be somewhere between unsupported and mistaken. I think we agree that the goal is there are two parties, call them owner and verifier, and the verifier gives the owner a random token that the owner puts in its DNS to show it owns the domain. There are a bunch of different aspects that one can look at independently. One is where the token goes, in the name or contents of the owner's record. I think we agree that putting the token at the owner's host name is a bad idea, but either of these can work, with a1b2c3 being the random token: _a1b2c3.example.com IN ... "whatever" _crudco.example.com IN ... "a1b2c3" If you use a fixed prefix, _crudco in this case, you should register it in the RFC8552 attrleaf registry. Another is what record type to use. I find the arguments against CNAME unpersuasive, basically saying that if you do something dumb, it won't work, which is true, but it's always true. I realize that RFC1034 says not to chain CNAMEs, but we all know that people chain CNAMEs and it works, e.g. www.microsoft.com goes through three CNAMEs and it works fine. If you use a _name in the attrleaf registry or a _random prefix I would think the changes of a CNAME colliding with something else are low, and a verifier presumably controls its own DNS and can keep CNAME chains short. So any of these could work: _a1b2c3.example.com IN TXT "crudco" _a1b2c3.example.com IN CNAME verify.crudco.wtf. _crudco.example.com IN TXT "a1b2c3" _crudco.example.com IN CNAME _a1b2c3.crudco.wtf. As you sort of note in one of the appendices, you can have different tokens in the name and the content if for some reason that is useful. For the length of time the token is valid, there seem to be only two: five minutes for a one-off verification like for ACME, or forever for someone who is doing continuing analysis of something in your domain, typically web analytics. While I can see aesthetic reasons to get rid of expired one-off tokens, I don't see the point of putting an expiration time in them, nor any particular harm in leaving them there if they are at _name and not the main host name. You might also say something about TTLs, e.g., not to have a 12 hour TTL for a token you plan to remove in a few minutes. There are some other minor points. You say to generate 128 random bits, but then to hash them to 256 which I don't understand. (As RFC 4086 sec 6.2 notes, strong random bits often are already hash output.) If 128 bits is enough, use 128 bits, if you need 256, generate 256. Either way I'd do base32 rather than base64 encoding to make the result more robust against helpful software that does you a favor by case folding. Overall, I'd lay out the options, and point out the advantages or disadvantages of each rather than just saying "do this" without a strong basis not to do it the other ways that work fine in practice. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for "Domain Verification Techniques using DNS"
All I was not being passive aggressive about the authors publishing their update, I was reading the datatracker incorrectly from my phone. However, since they now have published their update, let us do this WGLC. Much has changed, mostly after feedback from previous IETF meetings that this is changed to a BCP. As an operator, the chairs would love to hear feedback pro or con on their views on this. The WGLC will still end on March 2nd, 2023 On Thu, Feb 16, 2023 at 12:06 PM Tim Wicinski wrote: > > > OH Apologies. > > I had felt the authors published their new version, but I sent the wrong > draft message out. > > Please ignore this and I'll stop trying to be useful today > > tim > > > On Thu, Feb 16, 2023 at 12:04 PM Tim Wicinski wrote: > >> >> All >> >> The authors and the chairs feel this document has reached the stage where >> it's ready for Working Group Last Call. >> >> >> This starts a Working Group Last Call for: >> draft-ietf-dnsop-domain-verification-techniques >> >> Current versions of the draft is available here: >> >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/ >> >> The Current Intended Status of this document is: Best Current Practice. >> Initially this docucment started out as Informational and more about a >> survey, but feedback from the working group moved towards BCP. If this >> feels wrong in any way, please speak up! >> >> Please review the draft and offer relevant comments. >> If this does not seem appropriate please speak out. >> If someone feels the document is *not* ready for publication, >> please speak out with your reasons. >> >> This starts a two week Working Group Last Call process, and ends on: >> March 2nd 2023 >> >> thanks >> tim >> > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-01.txt
Hi folks, we (finally) published a new version of the domain verification techniques draft, now as intended-BCP. We've had some feedback from providers but would love for folks to review, especially people who would actually use it. On Thu, 16 Feb 2023 at 11:15, wrote: > > 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 : Domain Verification Techniques using DNS > Authors : Shivan Sahib > Shumon Huque > Paul Wouters > Filename: draft-ietf-dnsop-domain-verification-techniques-01.txt > Pages : 11 > Date: 2023-02-16 > > Abstract: >Many services on the Internet need to verify ownership or control of >a domain in the Domain Name System (DNS). This verification is often >done by requesting a specific DNS record to be visible in the domain. >There are a variety of techniques in use today, with different pros >and cons. This document proposes some practices to avoid known >problems. > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/ > > There is also an HTML version available at: > > https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-verification-techniques-01.html > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-domain-verification-techniques-01 > > > Internet-Drafts are also available by rsync at rsync.ietf.org: > :internet-drafts > > > ___ > 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
[DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-01.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 : Domain Verification Techniques using DNS Authors : Shivan Sahib Shumon Huque Paul Wouters Filename: draft-ietf-dnsop-domain-verification-techniques-01.txt Pages : 11 Date: 2023-02-16 Abstract: Many services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). This verification is often done by requesting a specific DNS record to be visible in the domain. There are a variety of techniques in use today, with different pros and cons. This document proposes some practices to avoid known problems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-verification-techniques-01.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-domain-verification-techniques-01 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
If we're looking for more counterexamples, there's also RFC7873#5.4 For servers with DNS Cookies enabled, the QUERY opcode behavior is extended to support queries with an empty Question Section (a QDCOUNT of zero (0)), provided that an OPT record is present with a COOKIE option. Such servers will send a reply that has an empty Answer Section and has a COOKIE option containing the Client Cookie and a valid Server Cookie. I can see why that was added, but I really wish it hadn't been... Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
On 16/02/2023 12:52, Dick Franks wrote: The last statement is informatively and normatively mistaken. The counterexample is to be found in RFC8490(5.4): A DSO message begins with the standard twelve-byte DNS message header [RFC1035] with the OPCODE field set to the DSO OPCODE (6). However, unlike standard DNS messages, the question section, answer section, authority records section, and additional records sections are not present. The corresponding count fields (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) MUST be set to zero on transmission. Good spot, Dick, and one I admit I'd forgotten about, which as a co-author of RFC 8490 is slightly embarrassing! However for OPCODE 0 (QUERY) the assertion still remains valid. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
On 16Feb23, Dick Franks allegedly wrote: > The last statement is informatively and normatively mistaken. > The counterexample is to be found in RFC8490(5.4): > > A DSO message begins with the standard twelve-byte DNS message header > [RFC1035] with the OPCODE field set to the DSO OPCODE (6). However, > unlike standard DNS messages, the question section, answer section, > authority records section, and additional records sections are not > present. The corresponding count fields (QDCOUNT, ANCOUNT, NSCOUNT, > ARCOUNT) MUST be set to zero on transmission. If we're looking for more counterexamples, there's also RFC7873#5.4 For servers with DNS Cookies enabled, the QUERY opcode behavior is extended to support queries with an empty Question Section (a QDCOUNT of zero (0)), provided that an OPT record is present with a COOKIE option. Such servers will send a reply that has an empty Answer Section and has a COOKIE option containing the Client Cookie and a valid Server Cookie. Mark. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
On Thu, 16 Feb 2023 at 01:14, Masataka Ohta wrote: >8 > > So, there is no specification to mention queries with QDCOUNT>1, > either informatively, optionaly or normatively. > > Then, 3425 titled "Obsoleting IQUERY" updated 1035. > > As such, after 3425, QDCOUNT nomatively must always be 1. > The last statement is informatively and normatively mistaken. The counterexample is to be found in RFC8490(5.4): A DSO message begins with the standard twelve-byte DNS message header [RFC1035] with the OPCODE field set to the DSO OPCODE (6). However, unlike standard DNS messages, the question section, answer section, authority records section, and additional records sections are not present. The corresponding count fields (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) MUST be set to zero on transmission. Dick Franks ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for "Domain Verification Techniques using DNS"
OH Apologies. I had felt the authors published their new version, but I sent the wrong draft message out. Please ignore this and I'll stop trying to be useful today tim On Thu, Feb 16, 2023 at 12:04 PM Tim Wicinski wrote: > > All > > The authors and the chairs feel this document has reached the stage where > it's ready for Working Group Last Call. > > > This starts a Working Group Last Call for: > draft-ietf-dnsop-domain-verification-techniques > > Current versions of the draft is available here: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/ > > The Current Intended Status of this document is: Best Current Practice. > Initially this docucment started out as Informational and more about a > survey, but feedback from the working group moved towards BCP. If this > feels wrong in any way, please speak up! > > Please review the draft and offer relevant comments. > If this does not seem appropriate please speak out. > If someone feels the document is *not* ready for publication, > please speak out with your reasons. > > This starts a two week Working Group Last Call process, and ends on: March > 2nd 2023 > > thanks > tim > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Working Group Last Call for "Domain Verification Techniques using DNS"
All The authors and the chairs feel this document has reached the stage where it's ready for Working Group Last Call. This starts a Working Group Last Call for: draft-ietf-dnsop-domain-verification-techniques Current versions of the draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/ The Current Intended Status of this document is: Best Current Practice. Initially this docucment started out as Informational and more about a survey, but feedback from the working group moved towards BCP. If this feels wrong in any way, please speak up! Please review the draft and offer relevant comments. If this does not seem appropriate please speak out. If someone feels the document is *not* ready for publication, please speak out with your reasons. This starts a two week Working Group Last Call process, and ends on: March 2nd 2023 thanks tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-bellis-dnsext-multi-qtypes-07.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 : DNS Multiple QTYPEs Author : Ray Bellis Filename: draft-bellis-dnsext-multi-qtypes-07.txt Pages : 7 Date: 2023-02-16 Abstract: This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS query. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-bellis-dnsext-multi-qtypes-07.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-bellis-dnsext-multi-qtypes-07 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
Benno Overeinder wrote: We would like to point out that discussions should be respectful which is about the people and the most common and annoying disrespectful behaviour in IETF is to make meaningless comments without reading strongly related rfcs, IDs or mails which is why we have been saying "Read the draft" against people lacking proper respect to others. Without such respect, discussions can not be technical. In this case, people not reading 1034/5, even after I quote releavant parts of them, totally lack respect for pioneering contributers (I'm not) to DNS in early days. > Note that the DNSOP WG Chairs ensure that the IETF Guidelines for > Conduct, RFC 7154, are adhered to. With proper interpretation of "respect", yes. Note that meaning of "respect" was discussed in main IETF list several months ago. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
All, We would like to point out that discussions should be respectful and about technical issues and not about the person. Note that the DNSOP WG Chairs ensure that the IETF Guidelines for Conduct, RFC 7154, are adhered to. Thanks, Benno, Suzanne and Tim co-chairs DNSOP WG On 16/02/2023 06:01, Masataka Ohta wrote: Mark Andrews wrote: It advises against a new QTYPE that returns multiples types and gives the reasoning behind the decision. That is not the same as prohibiting QDCOUNT > 1. That's in my first mail. But, we are in subthread on my second mail. All of you should learn to read the rfcs and, then, mails you are responding, before writing huge amount of abstract nonsenses. Masataka Ohta ___ 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
