Re: [DNSOP] I-D Action: draft-yao-dnsop-accompanying-questions-04.txt
Dear Richard Gibson, Thanks a lot for your kind review and questions. some comments are below inline. Jiankang Yao From: Richard Gibson Date: 2017-09-19 10:48 To: dnsop Subject: Re: [DNSOP] I-D Action: draft-yao-dnsop-accompanying-questions-04.txt I have some questions about this draft. How should responders populate the COUNT fields when one record answers multiple accompanying questions? For example, assume example.com has an MX record but no A or (the latter two thus being covered by an authority section SOA): QUESTION example.com. IN MX AQ example.com. IN A AQ example.com. IN ANSWER example.com. 3600 IN MX 10 mail.example.net. AUTHORITY example.com. 3600 IN SOA … example.com. 3600 IN SOA … ADDITIONAL . 0 CLASS4096 OPT ??? In a more general sense, how are responders to generate—and how are initiators to interpret—responses in which it is not clear which question any given response record corresponds to? [Jiankang Yao] The responders will put the query result of main question first, then Accompanying Question 1, Accompanying Question 2 in the answer, authority or additional section. It means that the responders will put the results for main question first, then Accompanying Question 1, Accompanying Question 2, one by one in order. The initiators will also interpret the result in the answer, authority or additional section, one question by one question in order, main question first, then Accompanying Question 1, Accompanying Question 2. The interpretation will base on the value of ANCOUNT, ARCOUNT, NSCOUNT, and AQ-ANCOUNT, AQ-ARCOUNT, AQ-NSCOUNT. In your example above, ANCOUNT=1, ARCOUNT=1, NSCOUNT=0; AQ1-ANCOUNT=0, AQ1-ARCOUNT=0, AQ1-NSCOUNT=1; AQ2-ANCOUNT=0, AQ2-ARCOUNT=0, AQ1-NSCOUNT=1 so the initiators will know: the result for main question is: ANSWER example.com. 3600 IN MX 10 mail.example.net. AUTHORITY ADDITIONAL . 0 CLASS4096 OPT ??? the result for accompanying question 1 is: ANSWER AUTHORITY example.com. 3600 IN SOA … ADDITIONAL the result for accompanying question 2 is: ANSWER AUTHORITY example.com. 3600 IN SOA … ADDITIONAL Section 3 defines the prefix field of an accompanying question as "a domain name with the form of a dot or a sequence of labels ending with a pointer"... could you clarify that "the form of a dot" refers to the root domain name (i.e., a single null label with wire format 0x00)? [Jiankang Yao] sorry for confusion words. it means a single null label . In section 4, what is meant by "the responder assembles the prefix with the main domain name"? Wire-format domain names are necessarily fully-qualified, whether or not they end with compression pointers. Is the operation to be interpreted as something like "if the prefix is the DNS root domain, treat it as the QNAME"? If so, I think such special processing is unnecessary, because it's already possible to reference the QNAME directly with a compression pointer. [Jiankang Yao] thanks, You are right. I will clarify the words. Why require accompanying question names to match or be subdomains of the QNAME? It precludes potentially useful queries like QNAME=www.example.com. accompanied by prefix=static.example.com., and prohibiting them doesn't prevent out-of-bailiwick queries anyway. [Jiankang Yao] currently the use cases for accompanying questions are the same domain names with different typs (A and AAA) or different sub domain names (TLSA record: _443._tcp.www.example.com ). If we can find some strong use cases for queries like QNAME=www.example.com. accompanied by prefix=static.example.com, we may consider to adjust the design. Section 5 references a "not been implemented, too many accompanying-questions." response... what would that response look like? [Jiankang Yao] Here, I think that it need a new rcode value for it. Best Regards. Jiankang Yao On Sun, Sep 17, 2017 at 11:19 PM, 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 : A DNS Query including A Main Question with Accompanying Questions Authors : Jiankang Yao Paul Vixie Ning Kong Xiaodong Li Filename: draft-yao-dnsop-accompanying-questions-04.txt Pages : 11 Date: 2017-09-17 Abstract: This document enables DNS initiators to send a main question accompanying with several related questions in a single DNS query, and enables DNS responders to put the answers into a single DNS response. This extension enables a range of initiators to look up "X, or failing that, Y" in a better way than both current alternat
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
From: Tim Wicinski Date: 2018-07-30 10:11 To: John Levine CC: Evan Hunt; dnsop Subject: Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest > > I had spent some time looking the draft over and realizing it was marked > standards track, and I think it would be easier to adopt for the the > specific use case if > it wasn't standards track. > > And, why not combine zone-digest with 7706bis? > It seems to be a good try. Jiankang Yao___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fw: New Version Notification for draft-arnt-yao-dnsop-root-data-caching-00.txt
Hello, A new draft about root data caching is proposed, which aims to solve the similar problem presented in RFC7706 and gives the DNS administrator one more option. Thanks. Jiankang Yao -原始邮件- 发件人: internet-dra...@ietf.org 发送时间: 2019-02-14 08:13:44 (星期四) 收件人: "Jiankang Yao" , "Arnt Gulbrandsen" 抄送: 主题: New Version Notification for draft-arnt-yao-dnsop-root-data-caching-00.txt A new version of I-D, draft-arnt-yao-dnsop-root-data-caching-00.txt has been successfully submitted by Jiankang Yao and posted to the IETF repository. Name: draft-arnt-yao-dnsop-root-data-caching Revision: 00 Title: Decreasing Fetch time of Root Data by Additional Caching Rules Document date: 2019-02-12 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-arnt-yao-dnsop-root-data-caching-00.txt Status: https://datatracker.ietf.org/doc/draft-arnt-yao-dnsop-root-data-caching/ Htmlized: https://tools.ietf.org/html/draft-arnt-yao-dnsop-root-data-caching-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-arnt-yao-dnsop-root-data-caching Abstract: Some DNS recursive resolvers have long round trip times to the nearest DSN root server, which has been an obstacle to DNS query performance. In order to decrease root record fetch time without introducing a new source of errors, this document proposes a root- specific modification to the caching rules. 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. The IETF Secretariat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fw: New Version Notification for draft-yao-dnsop-root-cache-00.txt
Dear all, I submit a draft about Decreasing Fetch time of DNS Root Data. Many DNS recursive resolvers have long round trip times to the DNS root server. It has been an obstacle to increse the performance of DNS query. In order to decrease fetch time of DNS root data, this document proposes a new mechanism by improving the mechanism of root data cacheing. Pls kindly help to review it and give the comments. I would also like to apply 10 minutes slot to introduce this idea in the next IETF meeting thanks a lot. Jiankang Yao From: internet-drafts Date: 2015-09-29 12:20 To: XiaoDong Lee; Jiankang Yao; Xiaodong Li; Jiankang Yao; Ning Kong; Ning Kong Subject: New Version Notification for draft-yao-dnsop-root-cache-00.txt A new version of I-D, draft-yao-dnsop-root-cache-00.txt has been successfully submitted by Jiankang Yao and posted to the IETF repository. Name: draft-yao-dnsop-root-cache Revision: 00 Title: Decreasing Fetch time of Root Data by Improving the Mechanism of Root Data Cacheing Document date: 2015-09-28 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-yao-dnsop-root-cache-00.txt Status: https://datatracker.ietf.org/doc/draft-yao-dnsop-root-cache/ Htmlized: https://tools.ietf.org/html/draft-yao-dnsop-root-cache-00 Abstract: Many DNS recursive resolvers have long round trip times to the DNS root server. It has been an obstacle to increse the performance of DNS query. In order to decrease fetch time of DNS root data, this document proposes a new mechanism by improving the mechanism of root data cacheing. 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. The IETF Secretariat___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-yao-dnsop-root-cache-00.txt
From: Joe Abley Date: 2015-09-29 23:00 To: yaojk CC: dnsop Subject: Re: [DNSOP] New Version Notification for draft-yao-dnsop-root-cache-00.txt >Hi Jiankang, >What reason do you have to think that response latency from root servers >has any measurable impact on end-user experience? > I think that there are some papers which explain it. One observation: due to the complexity of the network environment, the current quality of access to root service is uneven globally. For example, CNNIC finds through comprehensive monitoring and analysis that in China the time delay of access to the 13 root servers varies greatly from province to province, showing a difference of up to 200ms for most root servers, and in a number of provinces nearly 60% queries fail to hit the root mirrors deployed in China. BTW, this draft is trying to solve the same problem speicified in draft-ietf-dnsop-root-loopback. I think that the authors of draft-ietf-dnsop-root-loopback will have a better explaination than me. > >Queries to root servers from individual clients are sent very >infrequently, in my experience; the TTLs are not short. The probability >that any client of a real-world resolver gets a delayed response because >of latency between the resolver and a root server seems vanishingly >small. > We use the root data's feature of "the TTLs are not short, the data is not likely to be changed" to initiate our design. This design in the draft will reduce the load to the root server. Most traffic that might lead to the root server will be lead to the root data cache. Best Regards Jiankang Yao > >Joe On 29 Sep 2015, at 0:28, Jiankang Yao wrote: > Dear all, > >I submit a draft about Decreasing Fetch time of DNS Root Data. > > Many DNS recursive resolvers have long round trip times to the DNS > root server. It has been an obstacle to increse the performance of > DNS query. In order to decrease fetch time of DNS root data, this > document proposes a new mechanism by improving the mechanism of root > data cacheing. > > Pls kindly help to review it and give the comments. > >I would also like to apply 10 minutes slot to introduce this idea > in the next IETF meeting > > thanks a lot. > > > > > Jiankang Yao > > From: internet-drafts > Date: 2015-09-29 12:20 > To: XiaoDong Lee; Jiankang Yao; Xiaodong Li; Jiankang Yao; Ning Kong; > Ning Kong > Subject: New Version Notification for > draft-yao-dnsop-root-cache-00.txt > > A new version of I-D, draft-yao-dnsop-root-cache-00.txt > has been successfully submitted by Jiankang Yao and posted to the > IETF repository. > > Name: draft-yao-dnsop-root-cache > Revision: 00 > Title: Decreasing Fetch time of Root Data by Improving the Mechanism > of Root Data Cacheing > Document date: 2015-09-28 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/internet-drafts/draft-yao-dnsop-root-cache-00.txt > Status: > https://datatracker.ietf.org/doc/draft-yao-dnsop-root-cache/ > Htmlized: > https://tools.ietf.org/html/draft-yao-dnsop-root-cache-00 > > > Abstract: > Many DNS recursive resolvers have long round trip times to the DNS > root server. It has been an obstacle to increse the performance of > DNS query. In order to decrease fetch time of DNS root data, this > document proposes a new mechanism by improving the mechanism of root > data cacheing. > > > > > 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. > > The IETF Secretariat___ > 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] Decreasing Access Time to Root Servers
Hello, It is good to know that draft-ietf-dnsop-root-loopback will be soon be published as RFC. Thanks for authors' and WG's effort. For the rfc-to-be (draft-ietf-dnsop-root-loopback-05.txt), there are following working group summary " This document came out of several different proposals involving improving the redundancy of the DNS Root Zone. The document was the one which the Working Group was able to gather consensus. The discussion behind this was engaging as several felt the trade off of local copies for speed increased operational fragility. This document was not written to become a Best Practice or an Internet Standard, but as an Informational document to explain how operators currently manage such tasks." draft-yao-dnsop-root-cache helps to provide another or alternative choices to improve the redundancy of the DNS Root Zone. Different dns operators may choose different methods: draft-ietf-dnsop-root-loopback or draft-yao-dnsop-root-cache. draft-yao-dnsop-root-cache improves on draft-ietf-dnsop-root-loopback in the following ways: 1. The resolver which supports draft-yao-dnsop-root-cache is still a resolver which still needs to get the root data information from 13 dns root servers. The resolver which supports draft-ietf-dnsop-root-loopback does not need to get the root data information from 13 dns root servers. In the other words, if all resolvers were upgraded to support draft-ietf-dnsop-root-loopback, there would have millions of "root servers". It is hard to imagine how to manage so many "root servers". The root-cache-enabled resolver has not such problems. 2. Root-loopback server Operation of the Root Zone must be run on the Loopback Address while the root-cache-enabled resolver can be run on any address. 3. The resolver which supports draft-yao-dnsop-root-cache will cache and improve the recent query result (which is also most likely to be queried again) via the new mechanism, improving the dns query efficiency. 4. Due to the possible "operational fragility", the root-loopback enabled software will be released without the default configuration of support of draft-ietf-dnsop-root-loopback. The root-loopback enabled software is suitable for the experienced DNS operators and big dns resolving service providers. The root-cache enabled software can be released with the default configuration of support of draft-yao-dnsop-root-cache. The root-cache enabled software is suitable for most DNS operators and dns resolving service providers. To help to decrease the access time to root servers, one method might be not enough to satisfy all kinds of DNS operators. It is better that the WG provides another choice for dns operators. Thanks. Jiankang Yao From: The IESG Date: 2015-10-06 07:03 To: IETF-Announce CC: dnsop mailing list; dnsop chair; RFC Editor Subject: [DNSOP] Document Action: 'Decreasing Access Time to Root Servers by Running One on Loopback' to Informational RFC (draft-ietf-dnsop-root-loopback-05.txt) The IESG has approved the following document: - 'Decreasing Access Time to Root Servers by Running One on Loopback' (draft-ietf-dnsop-root-loopback-05.txt) as Informational RFC This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-root-loopback/ Technical Summary Some DNS recursive resolvers have longer-than-desired round trip times to the closest DNS root server. Some DNS recursive resolver operators want to prevent snooping of requests sent to DNS root servers by third parties. Such resolvers can greatly decrease the round trip time and prevent observation of requests by running a copy of the full root zone on a loopback address (such as 127.0.0.1). This document shows how to start and maintain such a copy of the root zone that does not pose a threat to other users of the DNS, at the cost of adding some operational fragility for the operator. Working Group Summary This document came out of several different proposals involving improving the redundancy of the DNS Root Zone. The document was the one which the Working Group was able to gather consensus. The discussion behind this was engaging as several felt the trade off of local copies for speed increased operational fragility. This document was not written to become a Best Practice or an Internet Standard, but as an Informational document to explain how operators currently manage such tasks. Document Quality Note, There is an IPR disclosure related to this document. The Authors have already been aware of this IPR disclosure, and no of no other IPR disclosure related to this document. The opinion of the working group is that the IPR party implies a willingness to commit to not requiring any li
[DNSOP] New Non-WG Mailing List: Bundled-domain-names -- Discussion of"bundled domain names"
Dear all, There is a New Non-WG Mailing List: Bundled-domain-names -- Discussion of"bundled domain names". Welcome to join this list for a discussion. To subscribe: https://www.ietf.org/mailman/listinfo/bundled-domain-names Thanks. Jiankang Yao 发件人: "IETF Secretariat";; 发送时间: 2016年2月4日(星期四) 下午3:03 收件人: "IETF Announcement List"; 抄送: "yaojk"; "bundled-domain-names"; 主题: New Non-WG Mailing List: Bundled-domain-names -- Discussion of"bundled domain names" A new IETF non-working group email list has been created. List address: bundled-domain-na...@ietf.org. Archive: https://mailarchive.ietf.org/arch/search/?email_list=bundled-domain-names To subscribe: https://www.ietf.org/mailman/listinfo/bundled-domain-names Purpose: This list is for discussion of DNS identical resolution for mapping one name entirely to another name (bundled names). CNAME maps one name to another name. DNAME maps its descendants to another domain name. If a domain wants to map itself *and* its descendants to another domain name, what should we do? This list will discuss solutions to this problem. See the problem statement here: https://tools.ietf.org/html/draft-yao-dnsext-identical-resolution For additional information, please contact the list administrators. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-00.txt
Dear all, We submit a draft about "A DNS Query including A Main Question with Accompanying Questions". Any comments are welcome. Thanks. Jiankang Yao From: internet-drafts Date: 2016-04-28 15:50 To: XiaoDong Lee; Paul A. Vixie; Jiankang Yao; Paul Vixie; Xiaodong Li; Ning Kong Subject: New Version Notification for draft-yao-dnsop-accompanying-questions-00.txt A new version of I-D, draft-yao-dnsop-accompanying-questions-00.txt has been successfully submitted by Jiankang Yao and posted to the IETF repository. Name: draft-yao-dnsop-accompanying-questions Revision: 00 Title: A DNS Query including A Main Question with Accompanying Questions Document date: 2016-04-28 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-yao-dnsop-accompanying-questions-00.txt Status: https://datatracker.ietf.org/doc/draft-yao-dnsop-accompanying-questions/ Htmlized: https://tools.ietf.org/html/draft-yao-dnsop-accompanying-questions-00 Abstract: This document enables DNS initiators to send a main question accompanying with several related questions in a single DNS query, and enables DNS responders to put the answers into a single DNS response. This mechanism can reduce the number of DNS round-trips per application work-unit. 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. The IETF Secretariat___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-00.txt
From: Ray Bellis Date: 2016-04-29 17:38 To: draft-yao-dnsop-accompanying-questions CC: dnsop Subject: Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-00.txt > I am unconvinced that the ability to specify multiple QNAMEs offers any > benefits and can't think of any good use cases where the client knows a > priori what the other QNAMEs might be. [ I don't consider looking up > example.com and www.example.com at the same time to be 'good' ]. > when receiving an email from a...@example.com, I often would like to visit the website of www.example.com too when I reply the email. another examples are : 1, when querying DNSSEC records for www.example.com, it normally needs querying example.com too for DNSSEC verification. 2, DKIM exmaple in Appendix A of rfc5617 Appendix A. Lookup Examples aaa.example A 192.0.2.1(1) _adsp._domainkey.aaa.example TXT "dkim=all" (2) bbb.example MX 10 mail.bbb.example (3) mail.bbb.example A 192.0.2.2(4) 3, DMARC example when you query for example.com, you might look up for _dmarc.example.com > The examples given all appear to show a recursor -> authority query, but > I see no hint in the draft about whether it's only for that path or also > for stub -> recursor. > I think that it works for both. The hint is the name "responder", "initiator" section 4. Responder Processing . . . . . . . . . . . . . . . . . . . . 5 section 5. Initiator Processing . . . . . . . . . . . . . . . . . . . . 6 Inititator can be stub or recursor Responder can be authority server or recursor Best regards. Jiankang Yao > Ray > > p.s. I noticed a dangling reference to RFC1321 (MD5) ? > typos. will remove it. thanks for catching it.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-00.txt
From: Paul Wouters Date: 2016-05-03 23:36 To: Ray Bellis CC: yaojk; dnsop Subject: Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-00.txt >It would be nice if you do a qtype=mx lookup that you could get the >related records. > this is one possible solution. but you have to design different rfcs for different similar use cases. for examples: for dmarc, you need to design one for tlsa or ipseckey, you design another one. in future, when similar use cases appear again, you have to produce another another rfc. for example, https://tools.ietf.org/html/draft-ietf-uta-smtp-tlsrpt-00 UTA is also a possible customer for draft-yao-dnsop-accompanying-questions-00.txt >Whether it is dmarc or tlsa or ipseckey. But what >happened is that we moved those type of records to a different location >from the qname. So that made this proposed feature a lot less >interesting. > our current suggested solution's benefit is that draft-yao-dnsop-accompanying-questions-00.txt can work for most current use cases mentioned such as dmarc, tlsa or ipseckey. it will also work for future use cases https://tools.ietf.org/html/draft-ietf-uta-smtp-tlsrpt-00. If there is a solution which can kill two birds with one stone, why refuse to use it? Best Regards Jiankang Yao ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] bname draft and its related bar bof
Dear all, this draft was discussed in dnsext a few years ago. It has been updated to a new version. It redesigns the method of how to compatible with DNSSEC. If the resolver sends no signaling of bname support but with DNSSEC, the server does the following thing: 1). the server issues cname and its signature when querying the same owner name with BNAME 2). the server issues dname and its signature when querying the children of the same owner name of BNAME PS： the server prepares the siganture of CNAME and DNAME beforehand. If you have already with the key idea of this draft, you can focus on section 5 and 6. Could you kindly help to review it? any comments are welcome. BTW, We would like to hold a bar bof in the Berlin IETF meeting, discussing the issues related to bundled domain names' DNS resolution and its possible solution. if you are interested in it, pls kindly let me know it or subscribe it via https://www.ietf.org/mailman/listinfo/bundled-domain-names thanks a lot. Jiankang Yao From: internet-drafts Date: 2016-05-23 14:30 To: Xiaodong LEE; Paul A. Vixie; Jiankang Yao; Jiankang YAO; XiaoDong Lee; Paul Vixie Subject: New Version Notification for draft-yao-dnsext-bname-06.txt A new version of I-D, draft-yao-dnsext-bname-06.txt has been successfully submitted by Jiankang YAO and posted to the IETF repository. Name: draft-yao-dnsext-bname Revision: 06 Title: Bundled DNS Name Redirection Document date: 2016-05-23 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-yao-dnsext-bname-06.txt Status: https://datatracker.ietf.org/doc/draft-yao-dnsext-bname/ Htmlized: https://tools.ietf.org/html/draft-yao-dnsext-bname-06 Diff: https://www.ietf.org/rfcdiff?url2=draft-yao-dnsext-bname-06 Abstract: This document defines a new DNS Resource Record called "BNAME", which provides the capability to map itself and its subtree of the DNS name space to another domain. It differs from the CNAME record which only maps a single node of the DNS name space, from the DNAME which only maps the subtree of the DNS name space to another domain. 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. The IETF Secretariat___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption"
From: fujiwara Date: 2016-07-06 17:09 To: dnsop Subject: Re: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption" >* My idea > I prefer multiple query sections (with some restrictions) > and merged answers. > multiple query examples may be >NAME A + NAME + MX >NAME A + NAME + _443._tcp.NAME TLSA >NAME A + NAME + _sip._udp.NAME SRV + _sips._tcp.NAME SRV + ... > Dear Fujiwara-san, Your points/scenarios fall in the Draft https://www.ietf.org/internet-drafts/draft-yao-dnsop-accompanying-questions-00.txt pls help to take a look. thanks. Jiankang Yao___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-01.txt
Hello, We have updated it to the new version, simplying the mechanism. pls kindly help to review it. any comments are welcome. If Seoul DNSOP meeting has some time slot for it, I will appreciate it. thanks a lot. Jiankang Yao -原始邮件- 发件人: internet-dra...@ietf.org 抄送: 主题: New Version Notification for draft-yao-dnsop-accompanying-questions-01.txt A new version of I-D, draft-yao-dnsop-accompanying-questions-01.txt has been successfully submitted by Jiankang Yao and posted to the IETF repository. Name: draft-yao-dnsop-accompanying-questions Revision: 01 Title: A DNS Query including A Main Question with Accompanying Questions Document date: 2016-10-24 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-yao-dnsop-accompanying-questions-01.txt Status: https://datatracker.ietf.org/doc/draft-yao-dnsop-accompanying-questions/ Htmlized: https://tools.ietf.org/html/draft-yao-dnsop-accompanying-questions-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-yao-dnsop-accompanying-questions-01 Abstract: This document enables DNS initiators to send a main question accompanying with several related questions in a single DNS query, and enables DNS responders to put the answers into a single DNS response. This mechanism can reduce the number of DNS round-trips per application work-unit. 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. The IETF Secretariat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-01.txt
From: Bob Harold Date: 2016-10-25 00:25 To: Jiankang Yao; IETF DNSOP WG Subject: Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-01.txt > I like the concept. > thanks. > The AQ bit and count are probably unnecessary, the option length will > determine the end of the options. > will consider to remove it in the next version. > But I don't understand how the length of each prefix is determined. Can you > explain? > It is same to normal domain names. it is terminated by a label with zero length.We will clarify it in the next version. > Some minor spelling corrections: > thanks. Jiankang Yao ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-01.txt
Dear JINMEI-san,
Thanks a lot for your kind review. All your comments/questions are very
helpful to improve the document.
More comments are followed below.
thanks a lot.
Jiankang Yao
From: 神明達哉
Date: 2016-10-25 02:47
To: Jiankang Yao
CC: dnsop; Paul Vixie
Subject: Re: [DNSOP] Fw: New Version Notification for
draft-yao-dnsop-accompanying-questions-01.txt
> A few comments on a quick read:
>
> - Does it assume to be used for exchanges between stub and recursive
> resolvers?
>
yes.
Intended for Both " between stub and recursive resolvers", and "between
recursive and authoritative"
>If it's also intended to be used between recursive and
> authoritative, how does it handle a delegation answer?
>
Most RRs needed to parallel query are normally located in the same zone.
In case of that some sub-domain names are delegated, the Delegation information
will be returned to the recursive server.
the recursive server then check the sub-domain based on the Delegation
information and get the answer.
> - Should we assume SOA('s) in the authority section for negative
> answers?
>
yes.
> - What if AQ-TYPE is ANY? I suspect the answer can be ambiguous in
> that case (even though it may not be a big issue in practice). For
> example, if the first AQ-TYPE is ANY and the second is , and the
> answer section only contains one (in addition to the answer to
> the main question), it's ambiguous for which AQ the answer is.
>
For each accompanying question, I suggest to remove AQ and Count/Seq bits,
and add AQ-ANCOUNT, AQ-NSCOUNT and AQ-ARCOUNT bits
AQ-ANCOUNT an unsigned 16 bit integer specifying the number of
resource records in the answer section.
AQ-NSCOUNT an unsigned 16 bit integer specifying the number of name
server resource records in the authority records
section.
AQ-ARCOUNT an unsigned 16 bit integer specifying the number of
resource records in the additional records section.
> - Likewise, what if the result is a CNAME chain? For example, if the
> answer to the first AQ is a CNAME and the name for the second AQ is
> the CNAME's target, it can be ambiguous for which AQ the subsequent
> answer (that follows the CNAME answer) is.
>
the proposed AQ-ANCOUNT, AQ-NSCOUNT and AQ-ARCOUNT bits can make it clear
> - I wonder whether there are other cases where the results can be
> ambiguous and whether some of them can be more troublesome than the
> above examples.
>
pls see above.
>
> - Regarding the definition of "Prefix" in Section 3:
>
>o Prefix field is a substring between the main domain name of the
> main quesiton and the accompanying domain name of the accompanying
> question.
>
> what "substring" means is vague to me. It's not even clear whether
> this is an ascii string or it's a complete wire-format domain name.
> Likewise, the notation of "S-S1" is quite informal. Since this is
> part of a formal definition, I'd suggest making it more formal and
> precise, eliminating any ambiguity depending on the interpretation.
>
If we describe the Prefix field as the domain name which uses the message
compression specified in section 4.1.4. of rfc1035, that may be easily
understood.
We will update this part of text.
> - This part of Section 4 seems to assume a responder implementation
> generally echos back unrecognized EDNS options:
>
>[...] An AQ
>unaware responder is expected to ignore the AQ OPT of the query, and
>may echo the received OPT back into additional section of the
>response message.
>
> and the following part of Section 5 seems to rely on that
> assumption:
>
>If the initial value of the AQ-RCODE is unchanged in the response, it
>indicates that the responder is AQ unaware.
>
yes.
> But, as far as I know actual implementations tend to NOT echo back
> unrecognized options.
>
In this case, the Initiator receiving no AQ OPT will assume that the Responder
does not support AQ.
We will clarify it in the new vesion. Thanks for catching it.
> - Section 6: there's a missing period after 'example.com':
>
>Answer |example.com IN A 192.168.0.1 |
>
will update it.
thanks.
Jiankang Yao
> --
> JINMEI, Tatuya___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] (version 2)Re: Re: draft-yao-dnsop-accompanying-questions
Dear Jinmei-san,
We have updated it to a new version.
https://www.ietf.org/internet-drafts/draft-yao-dnsop-accompanying-questions-02.txt
We hope that the new version has addressed all your concerns.
Thanks a lot for your kind comments to help to improve this document.
Best Regards,
Jiankang Yao
> -原始邮件-
> 发件人: "神明達哉"
> 发送时间: 2016-10-28 00:46:17 (星期五)
> 收件人: yaojk
> 抄送: dnsop , vixie
> 主题: Re: [DNSOP] Fw: New Version Notification for
> draft-yao-dnsop-accompanying-questions-01.txt
>
> At Wed, 26 Oct 2016 14:55:49 +0800,
> "Jiankang Yao" wrote:
>
> > >If it's also intended to be used between recursive and
> > > authoritative, how does it handle a delegation answer?
> >
> > Most RRs needed to parallel query are normally located in the same zone.
>
> That's probably true, but since this proposal is quite generic we
> can't simply assume that in the description of the protocol.
>
> > In case of that some sub-domain names are delegated, the Delegation
> > information will be returned to the recursive server.
> > the recursive server then check the sub-domain based on the Delegation
> > information and get the answer.
>
> I don't disagree with that as a high level observation. But my point
> in the question was that if it's supposed to work for delegation, it
> should describe how it should work more clearly (specifically what
> will be answered in the response from the authoritative server, and
> specifically how the recursive server should react to it, etc).
>
> > > - Should we assume SOA('s) in the authority section for negative
> > > answers?
> >
> > yes.
>
> IMO things like this should also be explicitly included in the doc.
>
> --
> JINMEI, Tatuya
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
NS mismatch between parent zone and child zone is an issue. I think that this draft is a very good start. Jiankang Yao From: fujiwara Date: 2016-11-02 14:10 To: dnsop Subject: [DNSOP] draft-fujiwara-dnsop-resolver-update-00 Hello, I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to improve resolver algorithm. Please read it and comment. I also made a presentation of the same topic at previous DNS-OARC workshop. https://indico.dns-oarc.net/event/25/session/6/contribution/19/material/slides/2.pdf Regards, -- Kazunori Fujiwara, JPRS > From: internet-dra...@ietf.org > > A new version of I-D, draft-fujiwara-dnsop-resolver-update-00.txt > has been successfully submitted by Kazunori Fujiwara and posted to the > IETF repository. > > Name: draft-fujiwara-dnsop-resolver-update > Revision: 00 > Title: Updating Resolver Algorithm > Document date: 2016-11-01 > Group: Individual Submission > Pages: 9 > URL: > https://www.ietf.org/internet-drafts/draft-fujiwara-dnsop-resolver-update-00.txt > Status: > https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-resolver-update/ > Htmlized: > https://tools.ietf.org/html/draft-fujiwara-dnsop-resolver-update-00 > > > Abstract: >Parent side NS RRSet and glue records are all information to access >servers for child zone. However, they may be overwritten by child >zone data (zone apex NS RRSet and other A/ RRSets). The >overwrite makes name resolution unstable and induces vulnerabilities. >RFC 2181 section 5.4.1 specifies trustworthiness of DNS data. And it >is deemed that that all cached data (authoritative data, non- >authoritative data, referrals and glue records) are merged into one. >Resolvers may answer non-authoritative data, referrals and glue >records that should not be returned. This document proposes updating >resolver algorithm that separates the cache to "authoritative data >cache" and "delegation cache". The former is used to answer stub >resolvers, and the latter is used to iterate zones. > > > > > > 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. > > The IETF Secretariat > ___ 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] Dname and its synthesized cname
Dear Mark, thanks for your kind reply. in RFC 2672, "The synthesized CNAME RR, if provided, MUST have The same CLASS as the QCLASS of the query, TTL equal to zero," In RFC6672 "A CNAME RR with Time to Live (TTL) equal to the corresponding DNAME RR is synthesized and included in the answer section when the DNAME is employed as a substitution instruction." " Resolvers MUST be able to handle a synthesized CNAME TTL of zero or a value equal to the TTL of the corresponding DNAME record (as some older, authoritative server implementations set the TTL of synthesized CNAMEs to zero). A TTL of zero means that the CNAME can be discarded immediately after processing the answer. " So in RFC 6672, DNAME resolver seem to have been updated to cache the synthesized cname. thanks. Jiankang Yao From: Mark Andrews Date: 2016-11-20 10:30 To: yao jk CC: dnsop@ietf.org Subject: Re: [DNSOP] Dname and its synthesized cname In message , yao jk writes: > Hello, > > Assume the resolver cache has 3 records: > A.com IN dname b.com 100 > A.com IN rrsig dname 100 > A.a.com IN cname a.b.com 2000 > > > When TTL expires after 100s but not after 2000s, what will resolver do when t > he query for a.a.com with dnssec DO bit enabled? DNAME aware clients cache the DNAME, not the CNAME. The CNAME is only there for clients that don't understand DNAME. > Thanks > > Jiankang > > >From my phone > ___ > 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___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-03.txt
hello, Based on Seoul IETF's discussion, I refine the introduction of this document to explain the motivation and compare with other mechanisms. the key text is here: - 1. Introduction Sometimes, when DNS lookup of X, an application will lookup Y if X fails. For examples, the initiator may fall back to A record if the lookup of MX record fails. Some initiators do it in sequence, X and after a few seconds, then Y. Although it is simple, this leads to unpleasant waiting whenever X times out or answers negatively. Some initiators use concurrent X/Y lookups and a state machine to decide whether to use X or Y. If an answer to Y arrives but none to X, the initiator needs to wait a little or else fall back to Y inappropriately. Concurrent lookup is faster if the X lookup takes time and falling back to Y is appropriate, but rather complex, with four states to test, and the initiator needs to wait for an answer to X or a timeout before it can use Y. This document enables a quicker, more easily tested failover. There is no need to test different answer sequences, there's no need for a state machine, there's no need for timeouts beyond receiving the reply. This document describes a method by which DNS initiators can send a main question accompanying with several related questions in a single DNS query, and enables DNS responders place all related answers into a single DNS response. This mechanism can reduce the number of DNS round-trips per application work-unit, by carrying several related queries in a single query transaction. It has the following advantages compared to other solutions. o Compared to sequential lookups: It's roughly as simple, but much faster in case a fallback to Y is necessary. o Compared to the concurrent mechanism: It is slightly faster (if the initiator needs to wait for an X timeout) and/or prevents inappropriate fallback (if the answer to X arrives too late), and it has a simpler state machine. This mechanism can also be used in the scenarios when the application needs more records of the same domain name or its sub-domain name. For examples, when asking about a QTYPE=A RRset, a QTYPE= RRset may also be of use [RFC 5321]; When asking for some RRset of www.example.com about A and , records of a sub-domain name such as _443._tcp.www.example.com for TLSA may be of interest[RFC 6698]. -------- Jiankang Yao From: internet-drafts Date: 2017-06-23 15:41 To: XiaoDong Lee; Ning Kong; Paul Vixie; Jiankang Yao; Xiaodong Li Subject: New Version Notification for draft-yao-dnsop-accompanying-questions-03.txt A new version of I-D, draft-yao-dnsop-accompanying-questions-03.txt has been successfully submitted by Jiankang Yao and posted to the IETF repository. Name: draft-yao-dnsop-accompanying-questions Revision: 03 Title: A DNS Query including A Main Question with Accompanying Questions Document date: 2017-06-23 Group: dnsop Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-yao-dnsop-accompanying-questions-03.txt Status: https://datatracker.ietf.org/doc/draft-yao-dnsop-accompanying-questions/ Htmlized: https://tools.ietf.org/html/draft-yao-dnsop-accompanying-questions-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-yao-dnsop-accompanying-questions-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-yao-dnsop-accompanying-questions-03 Abstract: This document enables DNS initiators to send a main question accompanying with several related questions in a single DNS query, and enables DNS responders to put the answers into a single DNS response. This extension enables a range of initiators to look up "X, or failing that, Y" in a better way than both current alternatives. This mechanism can reduce the number of DNS round- trips per application work-unit. 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. The IETF Secretariat___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] resolverkey-01 draft
Dear all, there is a draft about resolver key, which trys to attack the dnssec last mile problem solution. the idea is similar to DKIM, which identify the domain sending the email. here we use the similar mechanism to identify the response from the resolver to the stub resolver. any comments are welcome. thanks a lot. Jiankang Yao - Original Message - From: To: Sent: Friday, September 10, 2010 10:30 AM Subject: I-D Action:draft-yao-dnsop-resolverkey-01.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Resolver Key Identified DNS Query > Author(s) : J. Yao > Filename: draft-yao-dnsop-resolverkey-01.txt > Pages : 8 > Date: 2010-09-09 > > DNSSEC hardens the DNS between the root server and the recursive > resolver. It does not secure the communications between the stub > resolver and the recursive resolver. This document specifies the > mechanism which deals with securing the communications between them. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yao-dnsop-resolverkey-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ___ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >Content-Type: text/plain Content-ID: <2010-09-09192208@ietf.org> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IPR Disclosure: VeriSign, Inc.'s Statement about IPR related to draft-ietf-dnsop-rfc4641bis-13 and draft-koch-dnsop-dnssec-operator-change-04
- Original Message - From: "SM" To: ; Cc: ; ; ; ; ; ; ; Sent: Friday, December 07, 2012 3:13 AM Subject: Re: [DNSOP] IPR Disclosure: VeriSign, Inc.'s Statement about IPR related to draft-ietf-dnsop-rfc4641bis-13 and draft-koch-dnsop-dnssec-operator-change-04 > The IPR disclosure at https://datatracker.ietf.org/ipr/1924/ does not > mention RFC 4641. As draft-ietf-dnsop-rfc4641bis-13 is based on RFC > 4641, does the submitter believe that an IPR disclosure is required > for RFC 4641? > I am interested in this question too since rfc4641bis and rfc4641 share a lot of points. Jiankang Yao > Regards, > -sm > > ___ > 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] Changes to Charter
From: Warren Kumari Date: 2014-03-21 19:38 To: Tim Wicinski CC: joel jaeggli; dnsop Subject: Re: [DNSOP] Changes to Charter On Wed, Mar 19, 2014 at 3:42 PM, Tim Wicinski wrote: > > Hello > > This is a conversation I've scheduled a few times and I did poor time > mangement. After some discussion we're proposing adding two items to the > DNSOP charter: > > --- > > 5. Address possible minor changes or extensions to the DNS Protocol, > initially with a focus on the operational impacts of these changes. Act as > clearinghouse or providing advice to ADs and other WGs on EDNS0 options, new > RRTYPEs, record synthesis, or other mechanics of extending DNS to support > other applications. > Since DNSEXT closed down, this wording can help to solve the small issues related to extensions to the DNS Protocol if the issue is not big enough to create a new WG. Jiankang Yao___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
Section 3.1.1. Responses Tailored to the Originator in the draft-iab-dns-applications-07 has some related discussion to this topic. From the IAB draft, it seems that IAB does not prefer to tailor dns response based on the originator. Jiankang Yao From: Joe Abley Date: 2014-05-07 01:18 To: DNSOP WG Subject: [DNSOP] call to work on edns-client-subnet Hi all, I'm seeing increasing discussion about edns-client-subnet (most recently documented, I think, in the expired document draft-vandergaast-edns-client-subnet-02), both in commercial and open source venues (there's an active thread on the unbound-users mailing list right now, for example). Google DNS supports edns-client-subnet, which by recent GIH+GGM count means 10%+ of all client queries now trigger queries to authority servers with that option included. On the authority side, support for this option has a potential impact on query load. On the recursive side, support for this option has a potential impact on cache size. With multiple implementations, there are interop issues. If I recall the history of draft-vandergaast-edns-client-subnet-02, it stalled because various persuasive people in IETF working groups reacted to the vomity taste it left in their mouths (by which I refer to the concept, not the quality of the documentation). I may well have been one of them. However, I now feel that regardless of any vomity taste, what we are looking at is a proposal that has been implemented in multiple code bases (and hence must interoperate), has seen significant deployment and the use of which has operational consequences. Both the protocol changes and the impact on operations should be documented. I think dnsop should pick up some or all of this work. I think not picking up this work will result in implementation and operational problems. (I am reminded of the consequences of not standardising NAT, for example.) I would be happy to contribute reviews and/or text. Thoughts? Joe ___ 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] call to work on edns-client-subnet
One view about this issue based on the previous discussion years ago is that the dns implementors may choose to tailor the dns response in their own way, but ietf is unlikely to standardize it. Jiankang Yao From: Colm MacCárthaigh Date: 2014-05-07 09:14 To: yaojk CC: Joe Abley; dnsop Subject: Re: [DNSOP] call to work on edns-client-subnet On Tue, May 6, 2014 at 6:04 PM, Jiankang Yao wrote: Section 3.1.1. Responses Tailored to the Originator in the draft-iab-dns-applications-07 has some related discussion to this topic. From the IAB draft, it seems that IAB does not prefer to tailor dns response based on the originator. 3.1.1 reads pretty neutral to me, even saying that it "introduces little harm" (for web portals) and that it has broad adoption in the field. It just notes that it doesn't have much support in the community. But it clearly has broad support on the internet. At this point a majority of DNS responses are likely based on the originator (that's my guess based on local data, but it'd be interesting to see real data). -- Colm ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00
The draft says " Once the resolver has transferred and validated the zone, it MUST act as though it is a copy of the root zone." If the idea in this document is implemented, does it mean that the "root servers" will be everywhere in the internet? Jiankang Yao ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00
From: Tim Wicinski Date: 2014-06-24 22:12 To: dnsop Subject: Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00 > >Speaking as co-chair, Mr. Hoffman is absolutely correct on this point - >we are more than OK with half-baked ideas being hand-waved and a solid >discussion happening on the list. >That's fine: it is supposed to be a consensus document and we aren't >there yet. My hope is that DNSOP doesn't become too DNSEXT-like where if >the -00 for a proposal isn't universally loved, it is destroyed instead >of worked on. > +1 Even it looks to be not a good idea at the first stage, it may become a good idea after a detailed discussion and some adjustment. Jiankang Yao___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback
Are the functions of this kind of recursive resolvers similar to the slave server of the root? The root slave server gets the latest info from root master server, serving many recursive server. This kind of "root slave server " gets the latest info from root servers, serving only local recursive server. Can we understand this concept from this kind of view? Jiankang Yao From: Tim Wicinski Date: 2014-11-17 05:45 To: dnsop Subject: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback This starts a Call for Adoption for draft-wkumari-dnsop-root-loopback The draft is available here: https://datatracker.ietf.org/doc/draft-wkumari-dnsop-root-loopback/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. We will take all adoption support from Warren's email. This official call for adoption ends Sunday, November 30th, 2014. Thanks, tim wicinski DNSOP co-chair ___ 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] New Version Notification for draft-wkumari-dnsop-root-loopback-02.txt
From: Joe Abley Date: 2014-11-27 06:29 To: Paul Hoffman CC: dnsop Subject: Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-root-loopback-02.txt > >I think the document is well-written and clear, but that it needs the risks >(non-zero) and benefits (near->zero) to be clearly discussed, and to avoid any >unwarranted suggestion that doing this is sensible in the general case. > Agree. adding one section about the pros and cons will be better. Jiankang Yao___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
It is a great job. It lists many terms. In order to have some words be understood by newbie of DNS, I think that adding the example for every term in the appendix will be another bonus. For example,for the term of "zone cut" Zone cut -- The delimitation point between two zones where the origin of one of the zones is the child of the other zone. If there are some examples which show what the zone cuts are, that will be great. Jiankang Yao From: Paul Hoffman Date: 2015-01-20 06:16 To: IETF DNSOP WG Subject: [DNSOP] New version of the DNS terminology draft Greetings again. Andrew, Kazunori, and I have done a massive revision on the DNS terminology draft based on the input we got on the -00. We're sure we have further to go, but we wanted people to look over the new version and give feedback. Thanks! Name: draft-hoffman-dns-terminology Revision: 01 Title: DNS Terminology Document date: 2015-01-19 Group: Individual Submission Pages: 14 URL: http://www.ietf.org/internet-drafts/draft-hoffman-dns-terminology-01.txt Status: https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology/ Htmlized: http://tools.ietf.org/html/draft-hoffman-dns-terminology-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-hoffman-dns-terminology-01 ___ 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] IPR disclosure related to draft-ietf-dnsop-root-loopback
From: Paul Vixie Date: 2015-02-28 01:18 To: Niall O'Reilly CC: dnsop Subject: Re: [DNSOP] IPR disclosure related to draft-ietf-dnsop-root-loopback > thank you alison. but until verisign chooses a license regime for this > patent, we won't know how to respond. it is this working group's cultural > bias to avoid IPR, which means that if verisign doesn't self-declare the > "royalty-free" option, IETF will have t > engage lawyers and experts to determine whether this draft will have to be modified to avoid verisign's asserted rights. having verisign make the first move would save us all a lot of time and money. so this statement: > > agree it here. IETF is unwilling to standardardize some technology which has to be paid by the user. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
