Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
On Mon, Jul 11, 2016 at 10:39 PM, John R Levinewrote: >> for a web to DNS proxy to decide to send a reply back, it would need to >> consider it complete? >> >> Or are you proposing that the http server would start streaming back the >> payload as it received the (possibly out of order) replies? > > > I was thinking that the proxy would get all the queries from the DNS > request, deal with them however it wants, maybe stuff them to a nearby DNS > cache with TCP if it pipelines properly, or split them up into separate > requests if it doesn't, then collect the responses and send them back when > it has them, which I guess would constitute streaming. RFC 7766 says that > out-of-order is fine. Without HTTP/2 each request, clients would need to start a separate connection to get parallel processing, which means TCP handshake and potentially a TLS and more bookkeeping code. So client makes requests to proxy over HTTP/2 to mitigate the costs (here 7766 doesn't apply). Then proxy translates incoming HTTP/2 multiplexed requests into either DNS/TCP queries to origins (here 7766 helps) or plain old DNS (additional costs and bookkeeping). Server sends back DNS responses to proxy, which in turn translates them to DNS/HTTP answers. So both DNS/TCP out-of-order processing and DNS/HTTP out-of-order processing is desirable here. > I suppose with http/2 we get two-way streaming more or less for free. > > R's, > John Yep, the proxy can also push DNS answers to client ahead of time, which is interesting and something DNS servers can't do right now. On another note - this proposal kind of competes with DNS over HTTP encoded in JSON. While that one doesn't transport exact byte-by-byte DNS messages, it's much more consumer-friendly and elegant than piggybacking binary data. I wonder why that one is not getting more attention. Marek > > ___ > 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 for Adoption: draft-song-dns-wireformat-http
RFC 7766 is about DNS/TCP not about DNS/HTTP, the order of processing has to be determined by the wrapping protocol. You would get it for free if this draft was about TCP over HTTP or HTTP over DNS/TCP, but it's not. Marek On Mon, Jul 11, 2016 at 10:32 PM, John R Levinewrote: >>> Don't you get this automatically if it's treated as a TCP DNS >>> connection? You stuff a bunch of requests down the pipe, and you get >>> back a bunch of responses. >>> See RFC 7766. > > >> You get queueing for free, but not pipelining and out-of-order >> responses, that has to be defined. > > > RFC 7766 says you should get pipelining and out-of-order responses on TCP > DNS. Take a look. > > Even if the underlying DNS server that the proxy is using can't do it, any > newly written proxy should provide TCP DNS the way 7766 says it should. > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
for a web to DNS proxy to decide to send a reply back, it would need to consider it complete? Or are you proposing that the http server would start streaming back the payload as it received the (possibly out of order) replies? I was thinking that the proxy would get all the queries from the DNS request, deal with them however it wants, maybe stuff them to a nearby DNS cache with TCP if it pipelines properly, or split them up into separate requests if it doesn't, then collect the responses and send them back when it has them, which I guess would constitute streaming. RFC 7766 says that out-of-order is fine. I suppose with http/2 we get two-way streaming more or less for free. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
for a web to DNS proxy to decide to send a reply back, it would need to consider it complete? Or are you proposing that the http server would start streaming back the payload as it received the (possibly out of order) replies? Maybe instead should use WebSockets -- Original Message -- From: "John R Levine"To: "Marek Vavruša" Cc: "dnsop" Sent: 12/07/2016 3:32:51 p.m. Subject: Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http Don't you get this automatically if it's treated as a TCP DNS connection? You stuff a bunch of requests down the pipe, and you get back a bunch of responses. See RFC 7766. You get queueing for free, but not pipelining and out-of-order responses, that has to be defined. RFC 7766 says you should get pipelining and out-of-order responses on TCP DNS. Take a look. Even if the underlying DNS server that the proxy is using can't do it, any newly written proxy should provide TCP DNS the way 7766 says it should. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ 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 for Adoption: draft-song-dns-wireformat-http
I guess presuming that the back end will use TCP for DNS you could do this, but I would imagine that's not always the case? If it doesn't, there's a lot of queries that will fail, particularly with DNSSEC included. See RFC 7766. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
Don't you get this automatically if it's treated as a TCP DNS connection? You stuff a bunch of requests down the pipe, and you get back a bunch of responses. See RFC 7766. You get queueing for free, but not pipelining and out-of-order responses, that has to be defined. RFC 7766 says you should get pipelining and out-of-order responses on TCP DNS. Take a look. Even if the underlying DNS server that the proxy is using can't do it, any newly written proxy should provide TCP DNS the way 7766 says it should. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
On Mon, Jul 11, 2016 at 10:06 PM, John Levinewrote: >>So I suggest some thought should be given to reducing round-trips by >>allowing for multiple DNS request payloads in a single HTTP request >>message, and multiple DNS response payloads in an HTTP response message. > > Don't you get this automatically if it's treated as a TCP DNS > connection? You stuff a bunch of requests down the pipe, and you get > back a bunch of responses. > > See RFC 7766. > > R's > John You get queueing for free, but not pipelining and out-of-order responses, that has to be defined. The draft mentions this, but I think at this point it should just depend on HTTP/2, as it's the only way to get decent performance from resolvers but high variance in response time, and request semantics in both is different and needs to be defined, i.e. what happens when client cancels in-flight query, what happens when server resolver pushes response. Marek > ___ > 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 for Adoption: draft-song-dns-wireformat-http
>So I suggest some thought should be given to reducing round-trips by >allowing for multiple DNS request payloads in a single HTTP request >message, and multiple DNS response payloads in an HTTP response message. Don't you get this automatically if it's treated as a TCP DNS connection? You stuff a bunch of requests down the pipe, and you get back a bunch of responses. See RFC 7766. R's John ___ 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"
IETF Secretariat wrote: > The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state > Candidate for WG Adoption (entered by Tim Wicinski) > > The document is available at > https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/ Hi, I've read the -03 version of this draft and previous mailing list discussion about prior versions of the draft and I don't support its adoption. There doesn't seem to be a strong (preferably data-driven) reasoning to justify the mechanism described in the draft, and in previous discussion [0] it's described as being, essentially, just an interesting optimization. [0] https://mailarchive.ietf.org/arch/msg/dnsop/NruMO-whi7UW7gzXF-gu9OrYTMg For keeping popular records in cache, pre-fetching (e.g. draft-wkumari-dnsop-hammer) would seem like a less disruptive technique since it can be implemented entirely by the recursive name server, and it can also be applied to unsigned records, of which there are still quite a few. Pre-fetching probably doesn't help unpopular records as much (if at all), but unpopular records (by definition) don't have as many users as popular records. About the draft itself: I wondered why signalling is necessary. • RFC 1034 §4.3.2 “Algorithm”, step 6: 6. Using local data only, attempt to add other RRs which may be useful to the additional section of the query. Exit. This would seem to let an authoritative nameserver add any records deemed “useful” to the additional section of a response. (The RFC says “query” instead of “response” here, but that is almost certainly an erratum.) • RFC 2181 §5.4.1 “Ranking data”: Unauthenticated RRs received and cached from the least trustworthy of those groupings, that is data from the additional data section, and data from the authority section of a non-authoritative answer, should not be cached in such a way that they would ever be returned as answers to a received query. They may be returned as additional information where appropriate. Ignoring this would allow the trustworthiness of relatively untrustworthy data to be increased without cause or excuse. When DNS security [RFC2065] is in use, and an authenticated reply has been received and verified, the data thus authenticated shall be considered more trustworthy than unauthenticated data of the same type. […] This is the prohibition on promoting additional section RRs to answer section RRs in the responses returned to clients. But the prohibition only applies to unauthenticated RRs. It actually sub-divides the “Additional information from an authoritative answer” rank into two sub-ranks based on DNSSEC status. Is there anywhere else in the DNS/DNSSEC specs that would prohibit that promotion, where the additional record is DNSSEC secure? Otherwise I would think that nameservers could populate the additional section with whatever they want, and security-aware recursive name servers could pick up secure RRs from the additional section, and cache them such that they would be returned in the answer section to clients, all without any signalling. So the EXTRA bit could be eliminated? • Section 8 “Use of Additional information” from the draft: When receiving additional records in the additional section, a resolver follows certain rules: 1. Additional records MUST be validated before being used. 2. Additional records SHOULD be annotated in the cache as having been received as Additional records. 3. Additional records SHOULD have lower priority in the cache than answers received because they were requested. This is to help evict Additional records from the cache first (to help prevent cache filling attacks). 4. Recursive resolvers MAY choose to ignore Additional records for any reason, including CPU or cache space concerns, phase of the moon, etc. It may choose to accept all, some or none of the Additional records. is very confusing to me. I think it doesn't apply to additional records that are the normal result of additional section processing? I think it is actually talking about “extra” records that are undergoing an upgrade. Basically, this whole idea seems to me like something that can already be implemented today, without any specification work other than the format of the EXTRA RR. But the EXTRA RR is just configuration information and you don't strictly need it until you want to distribute it interoperably. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
One thing I think has always been bugging me about DNS over HTTP is the appalling performance we will likely see in a lot of cases. Even small latencies in normal DNS lookups cause major impact on page load times on complex pages with resources from many servers, and adding HTTP overhead to this will slow things further. So I suggest some thought should be given to reducing round-trips by allowing for multiple DNS request payloads in a single HTTP request message, and multiple DNS response payloads in an HTTP response message. E.g. sending requests as base64 encoded blob values in key-value pairs as post data, so that a response can be linked back to the request. At this stage of the game this should be quite easy, but will become more and more difficult as time goes by if the single request/response model is rolled out. Regards Adrien -- Original Message -- From: "Tim Wicinski"To: "dnsop" Sent: 12/07/2016 10:33:14 a.m. Subject: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http This starts an official Call for Adoption for draft-song-dns-wireformat-http The draft is available here: https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/ 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 wanted this Call to coincide with the Berlin meeting so if there is opinions that needed to be voiced, they can do so. This call for adoption ends: 25 July 2016 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] Call for Adoption: draft-song-dns-wireformat-http
>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. Yes, we should adopt it. It needs some work, but what draft doesn't. >Please also indicate if you are willing to contribute text, review, etc. Yes. My main suggestion is to lose the Proxy-DNS-Transport header and always have the request and response in TCP format. If the server doing the http-to-DNS proxy wants to microoptimize and try the query as UDP and see if it works, that's fine, but I'm guessing that the proxy will usually be close to the cache it's using so the penalty for TCP will be low. I'd also want to change some of the motivation text. To me, by far the most likely scenario here is javascript applications that want to do DNS queries, e.g. for SRV, but can't because javascript doesn't let you do that. Now the server that provided the javascript blob can also be the DNS proxy. The javascript can't query random other DNS proxies due to cross-site scripting rules. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] The DNSOP WG has placed draft-bellis-dnsop-session-signal in state "Candidate for WG Adoption"
The DNSOP WG has placed draft-bellis-dnsop-session-signal in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-bellis-dnsop-session-signal/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Call for Adoption: draft-song-dns-wireformat-http
This starts an official Call for Adoption for draft-song-dns-wireformat-http The draft is available here: https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/ 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 wanted this Call to coincide with the Berlin meeting so if there is opinions that needed to be voiced, they can do so. This call for adoption ends: 25 July 2016 Thanks, tim wicinski DNSOP co-chair ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 答复: Fw: New Version Notification for draft-shane-dns-manifesto-00.txt
UDP+cookies could work for you? -G On Mon, Jul 11, 2016 at 10:19 PM, Ray Belliswrote: > > > On 11/07/2016 07:13, George Michaelson wrote: > >> Things like client capability signalling, I suspect are in a harder >> bucket. I won't say intractably hard, but last time I floated >> capability flagging, I got pretty strong pushback. > > I think capability flagging is difficult in a stateless protocol like > UDP - there's no guarantee that the next endpoint that you send a packet > to is the same one that just told you what capabilities it has. > > It could be done over TCP, and perhaps in other protocols that add a > pseudo-session on top of UDP (e.g. DNS-o-DTLS?) but even then the > signaling should only really apply to the current connection / session. > > As it happens, the Session Signaling draft I submitted last week > originally had an option for exchanging the end-points' EDNS0 option > support, but some of my co-authors didn't like it so I removed it... > > Ray > > ___ > 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] draft-wkumari-dnsop-multiple-responses-03
On Mon, Jul 11, 2016 at 10:01 AM, John Dickinsonwrote: > Hi, > > A couple of nits > > EXTRA is spelt in at least 3 different ways. Yup. English is an evolving language -- it was just evolving faster in this doc than elsewhere :-) Fixed in Github version (to be posted once the draft cutoff opens): https://github.com/wkumari/draft-wkumari-dnsop-multiple-responses > The example in 5.1 introduces the AAA RR type without definition :) > Gah, I thought I could slide that though, and not have to write a whole new draft. Fixed... > Section 2 paragraph 1: I think that more recent examples of the background > regarding trust of additional records could be found. Yes, so would I / we -- however, we spent some time looking (specifically on the "why not to trust additional") and were not able to find any. Any pointers much appreciated. > IMHO section 8 item 2 should be removed as it is tending towards saying how > item 3 should be implemented. Fair 'nuff. Done, and updated in Github. Thank you for your comments. See you in Berlin? W > > regards > John > > > John Dickinson > > http://sinodun.com > > Sinodun Internet Technologies Ltd. > Magdalen Centre > Oxford Science Park > Robert Robinson Avenue > Oxford OX4 4GA > U.K. > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption"
On Mon, Jul 11, 2016 at 3:33 PM, Tony Finchwrote: > > Warren Kumari wrote: >> >> Hmmm... I think that this sounds reasonable, possibly with a minor tweak. >> Initially the EXTRA RR was never intended to be something that could >> be queried - the EXTRA (nee ADDitional) record only existed to allow >> copying from the master to the slave (they were instructions to the >> nameservers, not actual RR). Now that we allow querying directly, the >> RR type needs more discussion. > > One thing I vaguely wondered about is how this interacts with RFC 2181 > trustworthiness ranking. > > If you have a validating resolver then it can accept the additional records > OK. That isn't safe if you aren't validating or if the zone is unsigned. Yup -- the document says that you may only do this if you DNSSEC validate. "4. Returning multiple answers [snip ] In order to include additional records in a response, these conditions need to be met: 1. Additional records MUST only be included when the Name Server is authoritative for the zone, and the records to be returned are DNSSEC signed. ..." and "8. Use of Additional information When receiving additional records in the additional section, a resolver follows certain rules: 1. Additional records MUST be validated before being used." > > But maybe the contents of the EXTRA RRset are safe? The resolver can go and > get the real answers asynchronously. (Probably needs a quota to avoid > amplification.) Yup - it could be used to instruct a (non-validating) resolver to please go off and start fetching this list of other records... but, seeing as everyone already validates (right?!) we don't suggest this. > However I don't know how an authority would decide whether > to fill in the additional data or the EXTRA RRs... > Hmm. It seems that we have done a poor job of wording this bit. We meant to say that this information is always placed in the additional section (assuming that support is signalled). The only exception to this is if someone queries for the EXTRA record explicitly. But, Wes, Yan and I (and anyone else interested. Tony?) will discuss the best way to encode this in the zone file in Berlin, and also better explain the "always stuff this in additional (because, well, it is additional), but people can ask if they really want to..." bit W >> Wes and I will chat more in Berlin, but I'd like to be able to have a >> way to insert a preference into the RR as well (if there are N extra >> records, but only space for M, I'd like to be able to indicate which >> are the M to include). >> How would: >> EXTRA pref type name >> work for you? (pref would likely be an octet). > > That seems like a useful refinement :-) > > Tony. > -- > f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption"
Warren Kumariwrote: > > Hmmm... I think that this sounds reasonable, possibly with a > minor tweak. > Initially the EXTRA RR was never intended to be something that could > be queried - the EXTRA (nee ADDitional) record only existed to allow > copying from the master to the slave (they were instructions to the > nameservers, not actual RR). Now that we allow querying directly, the > RR type needs more discussion. One thing I vaguely wondered about is how this interacts with RFC 2181 trustworthiness ranking. If you have a validating resolver then it can accept the additional records OK. That isn't safe if you aren't validating or if the zone is unsigned. But maybe the contents of the EXTRA RRset are safe? The resolver can go and get the real answers asynchronously. (Probably needs a quota to avoid amplification.) However I don't know how an authority would decide whether to fill in the additional data or the EXTRA RRs... > Wes and I will chat more in Berlin, but I'd like to be able to have a > way to insert a preference into the RR as well (if there are N extra > records, but only space for M, I'd like to be able to indicate which > are the M to include). > How would: > EXTRA pref type name > work for you? (pref would likely be an octet). That seems like a useful refinement :-) Tony. -- f.anthony.n.finch http://dotat.at/ - I xn-- zr8h punycode ___ 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"
On Thu, Jul 7, 2016 at 5:32 AM, Tony Finchwrote: > Regarding the format of EXTRA RRs, it's better to use a list of RRs rather > than a list embedded in one RR. And a single label isn't enough, e.g. > TLSA. > > So I suggest the presentation format should be like > > EXTRA typename. > > and the wire format should be a 16 bit type followed by an uncompressed name. Hmmm... I think that this sounds reasonable, possibly with a minor tweak. Initially the EXTRA RR was never intended to be something that could be queried - the EXTRA (nee ADDitional) record only existed to allow copying from the master to the slave (they were instructions to the nameservers, not actual RR). Now that we allow querying directly, the RR type needs more discussion. Wes and I will chat more in Berlin, but I'd like to be able to have a way to insert a preference into the RR as well (if there are N extra records, but only space for M, I'd like to be able to indicate which are the M to include). How would: EXTRA pref type name work for you? (pref would likely be an octet). W > > Tony. > -- > f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode > South Utsire: Variable 3 or 4, becoming southwesterly 4 or 5. Slight or > moderate. Rain at first. Good, occasionally moderate at first. -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-01.txt
On Fri, Jul 8, 2016 at 5:20 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 of the IETF. > > Title : DNS Terminology > Authors : Paul Hoffman > Andrew Sullivan > Kazunori Fujiwara > Filename: draft-ietf-dnsop-terminology-bis-01.txt > Pages : 30 > Date: 2016-07-08 > > Abstract: >The DNS is defined in literally dozens of different RFCs. The >terminology used by implementers and developers of DNS protocols, and >by operators of DNS systems, has sometimes changed in the decades >since the DNS was first defined. This document gives current >definitions for many of the terms used in the DNS in a single >document. > >This document will be the successor to RFC 7719. It will update many >of the original RFCs. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-01 > > Source of Synthesis ">asterisk label<.>closest encloser<." should be ".." Page 21 "The oginal defintion of SEPs was in [RFC3757]." should be "The original definition of SEPs was in [RFC3757]." (spelling correction of "original definition") -- Bob Harold ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-key-tag-02.txt
On Fri, Jul 8, 2016 at 6:36 PM, Paul Hoffmanwrote: > Greetings again; I'm the new co-author on this draft. Based on the WG > discussion where a bunch of us wanted to use EDNS0 and a bunch of us wanted > to use queries, the authors tentatively decided that the best way to go > forwards is to put both methods in the draft. After all, a motivated > observer of the signals will not have much problem watching both types of > signals, and end systems can decide which of the two they want to use. > > We understand that "specify more than one" is often an unpopular choice in > the IETF, about as unpopular as "don't get consensus on one". This is a WG > document so we need consensus even to go with two ways. We look forward to > hearing from you about this choice and how we can move forwards. > > --Paul Hoffman > > > > On 8 Jul 2016, at 15:30, internet-dra...@ietf.org 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 of the >> IETF. >> >> Title : Signaling Trust Anchor Knowledge in DNS >> Security Extensions (DNSSEC) >> Authors : Duane Wessels >> Warren Kumari >> Paul Hoffman >> Filename: draft-ietf-dnsop-edns-key-tag-02.txt >> Pages : 13 >> Date: 2016-07-08 >> >> Abstract: >>The DNS Security Extensions (DNSSEC) were developed to provide origin >>authentication and integrity protection for DNS data by using digital >>signatures. These digital signatures can be verified by building a >>chain-of-trust starting from a trust anchor and proceeding down to a >>particular node in the DNS. This document specifies two different >>ways for validating resolvers to signal to a server which keys are >>referenced in their chain-of-trust. The data from such signaling >>allow zone administrators to monitor the progress of rollovers in a >>DNSSEC-signed zone. >> >>This document describes two independent methods for validating >>resolvers to publish their referenced keys: an EDNS option and a >>differnt DNS query. The reason there are two methods instead of one >>is some people see significant problems with each method. Having two >>methods is clearly worse than having just one, but it is probably >>better for the Internet than having no way to gain the information >>from the resolvers. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-dnsop-edns-key-tag-02 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-key-tag-02 >> >> Abstract, second paragraph "differnt" -> "different" 5.1. Query Format What if the key tag is less than 0x1000 hex or 4096 decimal - Should the resulting hex have leading zeros (always 4 characters?) or not? For example, would 4095 decimal be _ta-0fff or _ta-fff ? (I prefer always 4 characters hex, but it is your doc.) 5.3.1. Interaction With Aggressive Negative Caching I would prefer that the tags always be sorted. No big deal for two tags, but if there was a compromise or mistake during a rollover, there might be three keys and the savings in records might be significant. If you decide to specify sorting, I think it would go in section 5.1 and not in 5.3.1. -- Bob Harold ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-wkumari-dnsop-multiple-responses-03
Hi, A couple of nits EXTRA is spelt in at least 3 different ways. The example in 5.1 introduces the AAA RR type without definition :) Section 2 paragraph 1: I think that more recent examples of the background regarding trust of additional records could be found. IMHO section 8 item 2 should be removed as it is tending towards saying how item 3 should be implemented. regards John John Dickinson http://sinodun.com Sinodun Internet Technologies Ltd. Magdalen Centre Oxford Science Park Robert Robinson Avenue Oxford OX4 4GA U.K. signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 答复: Fw: New Version Notification for draft-shane-dns-manifesto-00.txt
On 11/07/2016 07:13, George Michaelson wrote: > Things like client capability signalling, I suspect are in a harder > bucket. I won't say intractably hard, but last time I floated > capability flagging, I got pretty strong pushback. I think capability flagging is difficult in a stateless protocol like UDP - there's no guarantee that the next endpoint that you send a packet to is the same one that just told you what capabilities it has. It could be done over TCP, and perhaps in other protocols that add a pseudo-session on top of UDP (e.g. DNS-o-DTLS?) but even then the signaling should only really apply to the current connection / session. As it happens, the Session Signaling draft I submitted last week originally had an option for exchanging the end-points' EDNS0 option support, but some of my co-authors didn't like it so I removed it... Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 答复: Fw: New Version Notification for draft-shane-dns-manifesto-00.txt
Thats good to know Mark. I took a dark view of change in DNS, but I do recall believing that for some problems, with tractable volumes of change-effectors, you can move on them. So, thanks for pushing: it helps. Things like client capability signalling, I suspect are in a harder bucket. I won't say intractably hard, but last time I floated capability flagging, I got pretty strong pushback. -G On Mon, Jul 11, 2016 at 3:58 PM, Mark Andrewswrote: > > In message >