More exposition on motivation and use cases.#13
Conversation
|
|
||
| example.com. 86400 IN DELEG 0 config2.example.net. | ||
| example.com. 86400 IN NS ns1.example.net. | ||
| The Additional section would continue to serve glue records for the |
There was a problem hiding this comment.
This is intriguing but I don't quite believe it. DELEG is in the parent zone, and is only retrieved by an explicit query (QTYPE=DELEG). Sure, the parent should serve glue records alongside an NS record Answer, but why should it serve glue records alongside a DELEG Answer?
There's another wrinkle here though: SVCB recommends putting A+AAAA records for TargetName in the Additional section if they are in the same zone, to avoid a followup query. If we apply that to DELEG, it could mean adding A+AAAA records for "ns2.example.com" (in the above example). However, this would be redundant with the IP hints, and it would also be logically different: those A+AAAA records are locally available but they aren't part of this zone.
Bottom line: we should do IP glue or IP hints, but not both. Overall, my preference would be to stick with hints and get rid of the whole concept of glue.
There was a problem hiding this comment.
is only retrieved by an explicit query (QTYPE=DELEG)
That's not really a settled matter. I still think, pending testing to confirm that for the vast majority of the resolver base, that the real deployment win here is to serve NS, DS and DELEG together for any delegation and NOT require an explicit query for them. We're trying to make the whole business of finding modern auths more efficient, not add more queries.
And I really, really don't think we should be adding addresses for the DELEG names to the Additional section, because something that understands what DELEG is at all should be using the hints.
There was a problem hiding this comment.
It seems like this is not settled, and is also not relevant to the transport draft. Please remove it or move it to the other draft.
BTW, using QTYPE=DELEG doesn't add queries. It just replaces the "arbitrary" QTYPE in QNAME minimization with a meaningful one. Non-DELEG servers should treat it as an unknown QTYPE and return the NS (and glue) in a delegation response.
| All SvcParamKeys for the "dns" scheme from SVCB-DNS {{?RFC9461}} apply as specified. These are the "transport parameters", attributes describing how to reach an endpoint. | ||
|
|
||
| The "alpn" transport parameter is OPTIONAL to include (unlike in SVCB-DNS, where it is generally required). If the "alpn" SvcParamKey is omitted, the only available transport is presumed to be unencrypted DNS over UDP/TCP port 53. Endpoints can indicate that insecure transport is not available by specifying "mandatory=alpn". | ||
| The "alpn" transport parameter is OPTIONAL to include, unlike in SVCB-DNS, where it is generally required. If the "alpn" SvcParamKey is omitted, the only available transport is presumed to be unencrypted DNS over UDP/TCP port 53. Endpoints can indicate that insecure transport is not available by specifying "mandatory=alpn". [Why do we not require do53 to be explicit?] |
There was a problem hiding this comment.
Are you arguing that Do53 should be opt-in instead of opt-out? We can certainly structure it that way; the difference seems pretty superficial. I appreciate the current approach as an application of Occam's Razor, but it's possible that "mandatory=alpn" is too obscure or is stretching the "mandatory" semantics too far.
There was a problem hiding this comment.
Yes, I am arguing that if you are using a DELEG record, it should be explicit when you want do53 with it. I don't want really anything assumed.
It doesn't have to be in this draft initially though, since I can argue my case on the list.
(If all you wanted was Legacy DNS then just NS records.)
There was a problem hiding this comment.
| The "alpn" transport parameter is OPTIONAL to include, unlike in SVCB-DNS, where it is generally required. If the "alpn" SvcParamKey is omitted, the only available transport is presumed to be unencrypted DNS over UDP/TCP port 53. Endpoints can indicate that insecure transport is not available by specifying "mandatory=alpn". [Why do we not require do53 to be explicit?] | |
| The "alpn" transport parameter is OPTIONAL to include, unlike in SVCB-DNS, where it is generally required. If the "alpn" SvcParamKey is omitted, the only available transport is presumed to be unencrypted DNS over UDP/TCP port 53. Endpoints can indicate that insecure transport is not available by specifying "mandatory=alpn". [Should we change this to make do53 require a more explicit opt-in?] |
| [... how does this signal that it also offers do53? Is the though that it is | ||
| because only this draft specifies alpn and the core draft doesn't (currently) | ||
| have a method to explicitly signal do53? Maybe it should... ] |
There was a problem hiding this comment.
This server supports Do53 because it is not explicitly disclaimed by mandatory=alpn, as in the last example here.
There was a problem hiding this comment.
Okay, right, see above. I think we should require signalling do53 to be explicit.
There was a problem hiding this comment.
| [... how does this signal that it also offers do53? Is the though that it is | |
| because only this draft specifies alpn and the core draft doesn't (currently) | |
| have a method to explicitly signal do53? Maybe it should... ] | |
| [ If we move to requiring an explicit opt-in for do53 then these examples will have to change. ] |
| ## Resolution procedure | ||
|
|
||
| The DELEG and SVCB records intends to replace the NS record while also adding additional functionality in order to support additional transports for the DNS. Below are discussions of considerations for deployment. | ||
| As specified in {{?I-D.draft-dnsop-deleg}}, the ServiceMode DELEG records provide a weak signal from the operator about which transport mechanisms they would most prefer clients to use, but it is not mandatory that resolvers try the delegated servers in priority order. It might not even be possible for a resolver to do, such as if the highest priority record specifies an alpn that the resolver does not implement, but a lower priority record has an alpn that it can use. |
There was a problem hiding this comment.
I don't understand this line. Each ServiceMode record documents the supported transports for a particular endpoint, and the SvcPriority documents the recommended trial order. Incompatible endpoints are skipped. Of course clients are free to reorder them based on additional heuristics. This is all covered in RFC 9460.
There was a problem hiding this comment.
What don't you understand then? It's just making it clear in this document as well. Do you think this statement is inconsistent with that, or should just be shorter in drawing attention to it?
There was a problem hiding this comment.
OK. If this is just meant to be highlighting some relevant aspects of RFC 9460, then it should say so.
There was a problem hiding this comment.
Will do. I'll be working on some more editing tomorrow and will add the explicit reference.
| DELEG and SVCB records are intended to be the best method for modern resolvers to use delegation information for zones. | ||
|
|
||
| TODO: Fill this section out | ||
| Realistically, however, legacy resolvers will continue to exist on the Internet for a long time to come. If a zone operator removes all NS records, the availability of their zones will be impacted for the clients that are using non-supporting resolvers. In some cases, this may be a desired quality, but should be noted by zone owners and operators. |
There was a problem hiding this comment.
Why is this in the transport draft? This topic seems like it should go in the main DELEG draft.
There was a problem hiding this comment.
Agreed. It was here because it was the document I was working on first on the airplane, and I was addressing "fill this section out" with relevant thoughts.
There was a problem hiding this comment.
OK, please delete this section.
| # Privacy Considerations | ||
|
|
||
| TODO: Define how resolver selects which server connect to, especially when faced with selection of multiple transports. I's probably resolver's policy decision, but it should be said explicitly. | ||
| All of the information transmitted by this protocol is public information published in the DNS. |
There was a problem hiding this comment.
I don't think queries are meant to be "published" in the DNS.
There was a problem hiding this comment.
I also thought the sentence as a little awkward, but was working with some prior text. I agree regarding queries. This sentence could maybe be improved with "transmitted by authoritative servers", but the section needs work anyway.
There was a problem hiding this comment.
| All of the information transmitted by this protocol is public information published in the DNS. | |
| Negotiation of alternative transports with DELEG allows the use of authenticated encryption between resolvers and authoritative DNS servers. This improves privacy by concealing the QNAME and QTYPE from a network observer. This is especially beneficial when a resolver is only shared by a small number of users. |
| # Security Considerations | ||
|
|
||
| ### Connection Failures | ||
| No new security risks are introduced by this specification. [Too bold to say?] |
There was a problem hiding this comment.
Sure, maybe we aren't making anything worse (although I worry about DNS Water Torture-like attacks), but security and privacy considerations still need to cover how the protocol can fail to achieve the intended improvements. In this case, we need to talk about how TLS is authenticated, especially in unsigned zones. (Related: #5)
There was a problem hiding this comment.
Sounds good. I wasn't really pushing for that sentence so much as putting a starting point that would draw out the "you were wrong on the Internet, and let me tell you why ..." brainstorming.
works for me. as i recall i was just trying to clean up some prior wording. Co-authored-by: Benjamin M. Schwartz <ben@bemasc.net>
|
Could we maybe get this PR merged and edit from there? I'll break future edits into smaller PRs |
|
|
||
| example.com. 86400 IN DELEG 0 config2.example.net. | ||
| example.com. 86400 IN NS ns1.example.net. | ||
| The Additional section would continue to serve glue records for the |
There was a problem hiding this comment.
It seems like this is not settled, and is also not relevant to the transport draft. Please remove it or move it to the other draft.
BTW, using QTYPE=DELEG doesn't add queries. It just replaces the "arbitrary" QTYPE in QNAME minimization with a meaningful one. Non-DELEG servers should treat it as an unknown QTYPE and return the NS (and glue) in a delegation response.
| All SvcParamKeys for the "dns" scheme from SVCB-DNS {{?RFC9461}} apply as specified. These are the "transport parameters", attributes describing how to reach an endpoint. | ||
|
|
||
| The "alpn" transport parameter is OPTIONAL to include (unlike in SVCB-DNS, where it is generally required). If the "alpn" SvcParamKey is omitted, the only available transport is presumed to be unencrypted DNS over UDP/TCP port 53. Endpoints can indicate that insecure transport is not available by specifying "mandatory=alpn". | ||
| The "alpn" transport parameter is OPTIONAL to include, unlike in SVCB-DNS, where it is generally required. If the "alpn" SvcParamKey is omitted, the only available transport is presumed to be unencrypted DNS over UDP/TCP port 53. Endpoints can indicate that insecure transport is not available by specifying "mandatory=alpn". [Why do we not require do53 to be explicit?] |
There was a problem hiding this comment.
| The "alpn" transport parameter is OPTIONAL to include, unlike in SVCB-DNS, where it is generally required. If the "alpn" SvcParamKey is omitted, the only available transport is presumed to be unencrypted DNS over UDP/TCP port 53. Endpoints can indicate that insecure transport is not available by specifying "mandatory=alpn". [Why do we not require do53 to be explicit?] | |
| The "alpn" transport parameter is OPTIONAL to include, unlike in SVCB-DNS, where it is generally required. If the "alpn" SvcParamKey is omitted, the only available transport is presumed to be unencrypted DNS over UDP/TCP port 53. Endpoints can indicate that insecure transport is not available by specifying "mandatory=alpn". [Should we change this to make do53 require a more explicit opt-in?] |
| [... how does this signal that it also offers do53? Is the though that it is | ||
| because only this draft specifies alpn and the core draft doesn't (currently) | ||
| have a method to explicitly signal do53? Maybe it should... ] |
There was a problem hiding this comment.
| [... how does this signal that it also offers do53? Is the though that it is | |
| because only this draft specifies alpn and the core draft doesn't (currently) | |
| have a method to explicitly signal do53? Maybe it should... ] | |
| [ If we move to requiring an explicit opt-in for do53 then these examples will have to change. ] |
| DELEG and SVCB records are intended to be the best method for modern resolvers to use delegation information for zones. | ||
|
|
||
| TODO: Fill this section out | ||
| Realistically, however, legacy resolvers will continue to exist on the Internet for a long time to come. If a zone operator removes all NS records, the availability of their zones will be impacted for the clients that are using non-supporting resolvers. In some cases, this may be a desired quality, but should be noted by zone owners and operators. |
There was a problem hiding this comment.
OK, please delete this section.
| # Privacy Considerations | ||
|
|
||
| TODO: Define how resolver selects which server connect to, especially when faced with selection of multiple transports. I's probably resolver's policy decision, but it should be said explicitly. | ||
| All of the information transmitted by this protocol is public information published in the DNS. |
There was a problem hiding this comment.
| All of the information transmitted by this protocol is public information published in the DNS. | |
| Negotiation of alternative transports with DELEG allows the use of authenticated encryption between resolvers and authoritative DNS servers. This improves privacy by concealing the QNAME and QTYPE from a network observer. This is especially beneficial when a resolver is only shared by a small number of users. |
draft-dnsop-deleg.md
Outdated
| The proposed DELEG record type remedies this problem by providing extensible parameters to describe what attributes a resolver would like to know about the the delegated authority, for example that it should be contacted using a different transport mechanism than the default udp/53. | ||
|
|
||
| The record lives in harmony with the existing NS records and any DS records used to secure the delegation with DNSSEC, with all provided in the Authority section of DNS responses. Legacy DNS resolvers would continue to use the NS and DS records, while resolvers that understand DELEG and its associated parameters can efficiently switch. [This is our proposed best-case scenario, but still needs testing to confirm the assertion about legacy resolvers. We have several other backup plans about how it could be facilitated if the Authority method proves troublesome.] | ||
| The record lives in harmony with the existing NS records and any DS records used to secure the delegation with DNSSEC, with all three types provided in the Authority section of DNS responses. Legacy DNS resolvers will ignore the unknown DELEG type and continue to use the NS and DS records, per the testing described in Appendix A. Resolvers that understand DELEG and its associated parameters can efficiently switch to the new mechanism. |
There was a problem hiding this comment.
| The record lives in harmony with the existing NS records and any DS records used to secure the delegation with DNSSEC, with all three types provided in the Authority section of DNS responses. Legacy DNS resolvers will ignore the unknown DELEG type and continue to use the NS and DS records, per the testing described in Appendix A. Resolvers that understand DELEG and its associated parameters can efficiently switch to the new mechanism. | |
| The record lives in harmony with the existing NS records and any DS records used to secure the delegation with DNSSEC, with all three types provided in the Authority section of DNS responses. Legacy DNS resolvers will ignore the unknown DELEG type and continue to use the NS and DS records, per the testing described in {{Testing}}. Resolvers that understand DELEG and its associated parameters can efficiently switch to the new mechanism. |
|
A lot in the current draft has changed out from underneath this pull request. It might be better to close it and re-open it for just the bits that are still relevant. |
4 participants
Need to fill in some refs, but wanted to get in the edits I made during my flight