Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-08.txt
On 31. 08. 19 1:27, Wes Hardaker wrote: > Shane Kerr writes: > >> While I thought the RCODE linkage was a bit clunky, the idea of having >> some structure to the response codes was actually kind of nice, for >> the same reason that the 1xx, 2xx, 3xx, 4xx, 5xx status codes were >> nice. I think the draft is better without using RCODE, but maybe we >> can pick numbers for EDE that are grouped in a similar way? > > So, assuming we *can't* easily group them by rcode. Well, we can, but > the results may not match given discussions with implementers. > > If you want to take a whack at suggesting appropriate ranges I'd love to > see what you come up with. As with all loaves of bread, do you slice > them cross-wise, length-wise or diagonally? Main question is not "what categories we need" but "what is the purpose/who is consumer of the information"? Once we have answer to this it will be easier to establish a categorization. IMHO the most useful information is dichotomy: a) the problem is local (= call network admin/ISP/telco) b) the problem is remote (= call your bank because their internetbanking broke and _do not your bother ISP_). Such simple distinction would allow client apps way more informative message than "We’re having trouble finding that site" + would make life easier for support people. This distinction is especially important for DNSSEC validation failures - e.g. if RRSIGs are expired your ISP/resolver operator _should not_ take any action so it is desirable to "assign blame" to web site owner. Shane, what do you think about proposal at the end of message https://mailarchive.ietf.org/arch/msg/dnsop/JHYQunp0L7C_vUcBb9fOi22QfpI - specifically Near and Far bits? Also we need to ask stub resolver developers what would be useful for them. Bernardo, what information would make life easier for stub/app developers? -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-08.txt
Petr Špaček wrote: > > IMHO the most useful information is dichotomy: > > a) the problem is local (= call network admin/ISP/telco) > > b) the problem is remote (= call your bank because their internetbanking > broke and _do not your bother ISP_). I think that's helpful. There's an interesting case wrt blocking / censorship, e.g. "near block" => ISP is responsible; "far block" => required by force of law. Tony. -- f.anthony.n.finchhttp://dotat.at/ Portland, Plymouth, Biscay: West or southwest 5 to 7, occasionally gale 8 later except in Biscay. Moderate or rough, becoming rough or very rough, occasionally high later in northwest Plymouth. Rain or thundery showers. Good, occasionally poor.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
Following discussions around the "HTTPSSVC" record proposal in Montreal with the DNSOP, HTTP and TLS WGs, we've updated what was previously "draft-nygren-httpbis-httpssvc-03". The new version is "draft-nygren-dnsop-svcb-httpssvc-00". This incorporates much of the feedback from the WG discussions, as well as feedback from discussions with the TLS WG (as we'd like to see this replace the need for a separate ESNI record). In particular, it generalizes the record into a new "SVCB" record which doesn't have any protocol-specific semantics. It also defines an "HTTPSSVC" record that is compatible with SVCB (sharing a wire-format and parameter registry) and which defines the HTTP(S)-specific semantics such as bindings to Alt-Svc. Other protocols can either define bindings directly to SVCB or can define their own RR Type (which should only ever be needed if there is a need to use the record at a zone apex). We'd like to see this adopted by the DNSOP WG. Until then, issues and PRs can go against: https://github.com/MikeBishop/dns-alt-svc Major changes from "draft-nygren-httpbis-httpssvc-03" include: * Separation into the SVCB and HTTPSSVC RR Types (and separated all of the HTTPS-specific functionality and text to its own portion of the document). * Elimination of the SvcRecordType field (and making the SvcRecordType implicit) * Changing the wire format of parameters from being in Alt-Svc text format to a more general binary key/value pair format (with a mapping to Alt-Svc for HTTPSSVC). * Adding optional "ipv4hint" and "ipv6hint" parameters. * Quite a few cleanups and clarifications based on input (and we undoubtedly have more left to go) This retains support for all of the use-cases that the previous HTTPSSVC record had (such as for covering the ANAME / CNAME-at-the-zone-apex use-case). Feedback is most welcome. If the TLS WG is going to use this instead of a separate ESNI record, there is a desire to make progress on this fairy quickly. Erik -- Forwarded message - From: Date: Mon, Sep 23, 2019 at 7:01 PM Subject: New Version Notification for draft-nygren-dnsop-svcb-httpssvc-00.txt To: Mike Bishop , Erik Nygren , Benjamin Schwartz A new version of I-D, draft-nygren-dnsop-svcb-httpssvc-00.txt has been successfully submitted by Benjamin Schwartz and posted to the IETF repository. Name: draft-nygren-dnsop-svcb-httpssvc Revision: 00 Title: Service binding and parameter specification via the DNS (DNS SVCB and HTTPSSVC) Document date: 2019-09-22 Group: Individual Submission Pages: 33 URL: https://www.ietf.org/internet-drafts/draft-nygren-dnsop-svcb-httpssvc-00.txt Status: https://datatracker.ietf.org/doc/draft-nygren-dnsop-svcb-httpssvc/ Htmlized: https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-nygren-dnsop-svcb-httpssvc Abstract: This document specifies the "SVCB" and "HTTPSSVC" DNS resource record types to facilitate the lookup of information needed to make connections for origin resources, such as for HTTPS URLs. SVCB records allow an origin to be served from multiple network locations, each with associated parameters (such as transport protocol configuration and keying material for encrypting TLS SNI). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPSSVC DNS RR is a variation of SVCB for HTTPS and HTTP origins. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TO BE REMOVED: This proposal is inspired by and based on recent DNS usage proposals such as ALTSVC, ANAME, and ESNIKEYS (as well as long standing desires to have SRV or a functional equivalent implemented for HTTP). These proposals each provide an important function but are potentially incompatible with each other, such as when an origin is load-balanced across multiple hosting providers (multi-CDN). Furthermore, these each add potential cases for adding additional record lookups in-addition to /A lookups. This design attempts to provide a unified framework that encompasses the key functionality of these proposals, as well as providing some extensibility for addressing similar future challenges. TO BE REMOVED: The specific name for this RR type is an open topic for discussion. "SVCB" and "HTTPSSVC" are meant as placeholders as they are easy to replace. Other names might include "B", "SRV2", "SVCHTTPS", "HTTPS", and "ALTSVC". 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] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
On Tue, Sep 24, 2019 at 9:18 AM Erik Nygren wrote: > Following discussions around the "HTTPSSVC" record proposal in Montreal > with the DNSOP, HTTP and TLS WGs, we've updated what was previously > "draft-nygren-httpbis-httpssvc-03". The new version is > "draft-nygren-dnsop-svcb-httpssvc-00". This incorporates much of the > feedback from the WG discussions, as well as feedback from discussions with > the TLS WG (as we'd like to see this replace the need for a separate ESNI > record). > > In particular, it generalizes the record into a new "SVCB" record which > doesn't have any protocol-specific semantics. It also defines an > "HTTPSSVC" record that is compatible with SVCB (sharing a wire-format and > parameter registry) and which defines the HTTP(S)-specific semantics such > as bindings to Alt-Svc. Other protocols can either define bindings > directly to SVCB or can define their own RR Type (which should only ever be > needed if there is a need to use the record at a zone apex). > > We'd like to see this adopted by the DNSOP WG. Until then, issues and PRs > can go against: https://github.com/MikeBishop/dns-alt-svc > > Major changes from "draft-nygren-httpbis-httpssvc-03" include: > > * Separation into the SVCB and HTTPSSVC RR Types (and separated all of > the HTTPS-specific functionality and text to its own portion of the > document). > * Elimination of the SvcRecordType field (and making the SvcRecordType > implicit) > * Changing the wire format of parameters from being in Alt-Svc text format > to a more general binary key/value pair format (with a mapping to Alt-Svc > for HTTPSSVC). > * Adding optional "ipv4hint" and "ipv6hint" parameters. > * Quite a few cleanups and clarifications based on input (and we > undoubtedly have more left to go) > > This retains support for all of the use-cases that the previous HTTPSSVC > record had (such as for covering the ANAME / CNAME-at-the-zone-apex > use-case). > > Feedback is most welcome. If the TLS WG is going to use this instead of a > separate ESNI record, there is a desire to make progress on this fairy > quickly. > >Erik > > -- Forwarded message - > From: > Date: Mon, Sep 23, 2019 at 7:01 PM > Subject: New Version Notification for > draft-nygren-dnsop-svcb-httpssvc-00.txt > To: Mike Bishop , Erik Nygren , > Benjamin Schwartz > > > > A new version of I-D, draft-nygren-dnsop-svcb-httpssvc-00.txt > has been successfully submitted by Benjamin Schwartz and posted to the > IETF repository. > > Name: draft-nygren-dnsop-svcb-httpssvc > Revision: 00 > Title: Service binding and parameter specification via the DNS > (DNS SVCB and HTTPSSVC) > Document date: 2019-09-22 > Group: Individual Submission > Pages: 33 > URL: > https://www.ietf.org/internet-drafts/draft-nygren-dnsop-svcb-httpssvc-00.txt > Status: > https://datatracker.ietf.org/doc/draft-nygren-dnsop-svcb-httpssvc/ > Htmlized: > https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-nygren-dnsop-svcb-httpssvc > > > Abstract: >This document specifies the "SVCB" and "HTTPSSVC" DNS resource record >types to facilitate the lookup of information needed to make >connections for origin resources, such as for HTTPS URLs. SVCB >records allow an origin to be served from multiple network locations, >each with associated parameters (such as transport protocol >configuration and keying material for encrypting TLS SNI). They also >enable aliasing of apex domains, which is not possible with CNAME. >The HTTPSSVC DNS RR is a variation of SVCB for HTTPS and HTTP >origins. By providing more information to the client before it >attempts to establish a connection, these records offer potential >benefits to both performance and privacy. > >TO BE REMOVED: This proposal is inspired by and based on recent DNS >usage proposals such as ALTSVC, ANAME, and ESNIKEYS (as well as long >standing desires to have SRV or a functional equivalent implemented >for HTTP). These proposals each provide an important function but >are potentially incompatible with each other, such as when an origin >is load-balanced across multiple hosting providers (multi-CDN).. >Furthermore, these each add potential cases for adding additional >record lookups in-addition to /A lookups. This design attempts >to provide a unified framework that encompasses the key functionality >of these proposals, as well as providing some extensibility for >addressing similar future challenges. > >TO BE REMOVED: The specific name for this RR type is an open topic >for discussion. "SVCB" and "HTTPSSVC" are meant as placeholders as >they are easy to replace. Other names might include "B", "SRV2", >"SVCHTTPS", "HTTPS", and "ALTSVC". > Looks good to me, hope it gets used! Several places have text like: 4. DNS Server Behavior 2. "If a
Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-08.txt
On 9/24/19 12:36 PM, Tony Finch wrote: > Petr Špaček wrote: >> IMHO the most useful information is dichotomy: >> >> a) the problem is local (= call network admin/ISP/telco) >> >> b) the problem is remote (= call your bank because their internetbanking >> broke and _do not your bother ISP_). > I think that's helpful. > > There's an interesting case wrt blocking / censorship, e.g. "near block" > => ISP is responsible; "far block" => required by force of law. And when *forwarder* returns that the domain was blocked (via this RFC)? If we go this near/far way (and I would like that), I'd suggest that we additionally try to polish the semantics for forwarding and caching, i.e. how the errors might best bubble through these layers. When a resolver only talks to other resolvers, it currently can't often determine whether the problem is in them or in authoritative servers - it gets the same SERVFAIL, but perhaps if all layers support extended codes and we design them well, it might be possible to "reliably" assign blame to authoritative side in more cases. Example: the authoritative servers don't reply at all (to the forwarder), so possibly after trying a second forwarder with the same result, we probably want to assign blame to the authoritative servers and not to the forwarder. Well, I'm a little sorry for suggesting such a scope creep, but still... --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
