Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
Hi Paul, Please see inline On Wed, 17 Jul 2019 at 21:47, Paul Hoffman wrote: > On Jul 17, 2019, at 7:36 AM, tirumal reddy wrote: > >> One example is that the stub or browser may want to change DoH servers, > such as if it has discovered one that has a better security policy. > >> > > Attackers can also host DoH servers and claim they have better security > policy, How will the stub resolver know the server is not lying ? > > The same way that they will authenticate any policy information. This is > no different than any other policy choice, is it? > No, I am not aware of any standard techniques used by endpoints and IoT devices to authenticate the policy information provided by the network ? If you are aware of such techniques, Please share. > > > > 2) DHCP clients typically have no secure and trusted relationships to > DHCP servers, how will the client know it is communicating with the > recursive resolver hosted in the attached network ? > > > >> It will not. This has always been the problem with DHCP, and efforts to > make DHCP authenticated have not borne fruit. > >> > > Yes, but how will the client know it is communicating with an attacker's > DoH server or not ? > > In other words, if the client does not securely learn the IP address or > domain name of the resolver, the client could end-up retrieving the > attacker's resolver information. > > Are you saying that the only way for a client to learn policy information > is from secure DHCP or secure RA? It seems like others here disagree with > that, and want network administrators to be able to leverage the resolvers > under their control to issue policy statements. > I am not proposing to use Secure DHCP or secure RA. Consider a scenario where an attacker also hosts a resolver and issues policy statements to claim better security and privacy than the one provided the network administrator. How will the client know the policy statement is issued by the resolver deployed by the network administrators or by an attacker ? > Discussing these future configuration options without solving the secure > bootstrapping problem is of little use to implementations and deployments. > > Others seem to disagree with that statement. > Sure, but I don't see any discussion in the draft explaining how the client determines the future configuration options is coming from a trusted source. If the source cannot be trusted, endpoint can be configured to use a malicious resolver server compromising the endpoint security and privacy, and the future configuration options is not helpful. > > > > 4) Any specific reason for picking I-JSON ? > > > >> Absolutely. I-JSON is more likely to be interoperable than plain JSON: > that's why it exists. Given that the developers of the clients for this > protocol will be different than the developers of the servers, greater > interoperability should be an emphasis. > >> > > JSON also provides interoperability, please see > https://tools.ietf.org/wg/jose/charters. > > I-JSON was partially motivated by problems discovered in JOSE. > Okay. > > > My other question is why JSON and not CBOR ? > > CBOR has no advantages in this use case, and JSON is easy to put into > master files. > CBOR has smaller message size compared to JSON and is faster to process than JSON. Cheers, -Tiru > > --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
On Jul 17, 2019, at 7:36 AM, tirumal reddy wrote: >> One example is that the stub or browser may want to change DoH servers, such >> as if it has discovered one that has a better security policy. >> > Attackers can also host DoH servers and claim they have better security > policy, How will the stub resolver know the server is not lying ? The same way that they will authenticate any policy information. This is no different than any other policy choice, is it? > > 2) DHCP clients typically have no secure and trusted relationships to DHCP > > servers, how will the client know it is communicating with the recursive > > resolver hosted in the attached network ? > >> It will not. This has always been the problem with DHCP, and efforts to make >> DHCP authenticated have not borne fruit. >> > Yes, but how will the client know it is communicating with an attacker's DoH > server or not ? > In other words, if the client does not securely learn the IP address or > domain name of the resolver, the client could end-up retrieving the > attacker's resolver information. Are you saying that the only way for a client to learn policy information is from secure DHCP or secure RA? It seems like others here disagree with that, and want network administrators to be able to leverage the resolvers under their control to issue policy statements. > Discussing these future configuration options without solving the secure > bootstrapping problem is of little use to implementations and deployments. Others seem to disagree with that statement. > > 4) Any specific reason for picking I-JSON ? > >> Absolutely. I-JSON is more likely to be interoperable than plain JSON: >> that's why it exists. Given that the developers of the clients for this >> protocol will be different than the developers of the servers, greater >> interoperability should be an emphasis. >> > JSON also provides interoperability, please see > https://tools.ietf.org/wg/jose/charters. I-JSON was partially motivated by problems discovered in JOSE. > My other question is why JSON and not CBOR ? CBOR has no advantages in this use case, and JSON is easy to put into master files. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
Hi Paul,
Please see inline
On Thu, 11 Jul 2019 at 05:55, Paul Hoffman wrote:
> On Jul 9, 2019, at 3:46 AM, tirumal reddy wrote:
> > My comments below:
> >
> > 1) Unless a DNS request for .{in-addr,ip6}.arpa/IN/RESINFO,
> >or a subdomain, as described in Section 2 is sent over DNS-over-TLS
> >(DoT) [RFC7858] or DNS-over-HTTPS (DoH) [RFC8484], or unless the
> >.{in-addr,ip6}.arpa zone is signed with DNSSEC, the
> >response is susceptible to forgery.
> >
> > Comment> If the stub resolver is already using DoH with the recursive
> resolver, why does it have to determine the URI template of the DoH server?
>
> One example is that the stub or browser may want to change DoH servers,
> such as if it has discovered one that has a better security policy.
>
Attackers can also host DoH servers and claim they have better security
policy, How will the stub resolver know the server is not lying ?
>
> > 2) DHCP clients typically have no secure and trusted relationships to
> DHCP servers, how will the client know it is communicating with the
> recursive resolver hosted in the attached network ?
>
> It will not. This has always been the problem with DHCP, and efforts to
> make DHCP authenticated have not borne fruti.
>
Yes, but how will the client know it is communicating with an attacker's
DoH server or not ?
In other words, if the client does not securely learn the IP address or
domain name of the resolver, the client could end-up retrieving the
attacker's resolver information.
> > 3)
> >In the future, DHCP and/or DCHPv6 and/or RA may have options that
> >allow the configuration to contain the domain name of a resolver. If
> >so, this can be used for matching the domain name in the TLS
> >certificate.
> >
> > Comment> Same comment as above, Please see
> https://tools.ietf.org/html/rfc8310#section-7.3.1 [tools.ietf.org]
>
> That document does not preclude future configuration options. I don't see
> any reason for this spec to do so.
>
Discussing these future configuration options without solving the secure
bootstrapping problem is of little use to implementations and deployments.
> > 4) Any specific reason for picking I-JSON ?
>
> Absolutely. I-JSON is more likely to be interoperable than plain JSON:
> that's why it exists. Given that the developers of the clients for this
> protocol will be different than the developers of the servers, greater
> interoperability should be an emphasis.
>
JSON also provides interoperability, please see
https://tools.ietf.org/wg/jose/charters. My other question is why JSON and
not CBOR ?
Cheers,
-Tiru
>
> > 5) The resolver information can also be provided in the server
> certificate itself, for example see
> https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-04#section-10.1
> [tools.ietf.org]. The pros and cons of both approaches need to be
> discussed in the WG.
>
> Agree. If that document progresses, it will certainly have an effect on
> the protocol proposed here.
>
> --Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
On Fri, 12 Jul 2019, Paul Wouters wrote: > > I find the term "security policy", a bit unnerving here. A DNS server > is either secure (and tells the truth), or it is not secure (and tells > lies). There is no "better". Some people say lying is more "secure for the > user", but that can really only come from a pre-existing configuration, > not a random DNS server offered by your random local network. > > I think the better term here is "privacy policy". We kind of assume > all DoH severs are "secure" (at least for their transport, see above) > but we feel we can trust some DoH servers more than others for privacy. No, it is really about security, but in a broader sense. Some resolvers will lie to you when you try to access a known malicious destination, e.g. a website which hosts malware or phishing, or, if "you" are a bot, your command and control server. This would be "insecure" by your definition above, but in reality it makes the whole Internet access experience more secure. In this scenario, a "better" security policy by a resolver is one using a list of filtered destinations that is more precise, more timely updated, more localized, more tailored to your own needs (including the fact that some resolvers allow each individual user of the local network to choose a different filtering policy, or none at all). So the user might indeed want to use a resolver that employs a better security policy, or even the resolver with which they have a contract to provide a specific security policy, which, in the case of ISPs, will usually be the one advertised by the local network. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
On Thu, 11 Jul 2019, Paul Hoffman wrote: Comment> If the stub resolver is already using DoH with the recursive resolver, why does it have to determine the URI template of the DoH server? One example is that the stub or browser may want to change DoH servers, such as if it has discovered one that has a better security policy. I find the term "security policy", a bit unnerving here. A DNS server is either secure (and tells the truth), or it is not secure (and tells lies). There is no "better". Some people say lying is more "secure for the user", but that can really only come from a pre-existing configuration, not a random DNS server offered by your random local network. I think the better term here is "privacy policy". We kind of assume all DoH severs are "secure" (at least for their transport, see above) but we feel we can trust some DoH servers more than others for privacy. 2) DHCP clients typically have no secure and trusted relationships to DHCP servers, how will the client know it is communicating with the recursive resolver hosted in the attached network ? It will not. This has always been the problem with DHCP, and efforts to make DHCP authenticated have not borne fruti. And since the prime advantage of DoH is privacy, and you cannot have privacy without an authenticated encrypted channel, using a randomly announced third party DoH server gains you little (and surely unmeasurable) privacy. Unless you already trust the DoH server announced, but than you hardly need the DHCP announcement. Just setting up the connection to the DoH servers you trust (and have certs/CA for) until one works. If those fail, you might as well use UDP 53 to whatever DHCP gave you. In the future, DHCP and/or DCHPv6 and/or RA may have options that allow the configuration to contain the domain name of a resolver. If so, this can be used for matching the domain name in the TLS certificate. As stated above, I see only very little use in this. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
On Jul 9, 2019, at 3:46 AM, tirumal reddy wrote:
> My comments below:
>
> 1) Unless a DNS request for .{in-addr,ip6}.arpa/IN/RESINFO,
>or a subdomain, as described in Section 2 is sent over DNS-over-TLS
>(DoT) [RFC7858] or DNS-over-HTTPS (DoH) [RFC8484], or unless the
>.{in-addr,ip6}.arpa zone is signed with DNSSEC, the
>response is susceptible to forgery.
>
> Comment> If the stub resolver is already using DoH with the recursive
> resolver, why does it have to determine the URI template of the DoH server?
One example is that the stub or browser may want to change DoH servers, such as
if it has discovered one that has a better security policy.
> 2) DHCP clients typically have no secure and trusted relationships to DHCP
> servers, how will the client know it is communicating with the recursive
> resolver hosted in the attached network ?
It will not. This has always been the problem with DHCP, and efforts to make
DHCP authenticated have not borne fruti.
> 3)
>In the future, DHCP and/or DCHPv6 and/or RA may have options that
>allow the configuration to contain the domain name of a resolver. If
>so, this can be used for matching the domain name in the TLS
>certificate.
>
> Comment> Same comment as above, Please see
> https://tools.ietf.org/html/rfc8310#section-7.3.1 [tools.ietf.org]
That document does not preclude future configuration options. I don't see any
reason for this spec to do so.
> 4) Any specific reason for picking I-JSON ?
Absolutely. I-JSON is more likely to be interoperable than plain JSON: that's
why it exists. Given that the developers of the clients for this protocol will
be different than the developers of the servers, greater interoperability
should be an emphasis.
> 5) The resolver information can also be provided in the server certificate
> itself, for example see
> https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-04#section-10.1
> [tools.ietf.org]. The pros and cons of both approaches need to be discussed
> in the WG.
Agree. If that document progresses, it will certainly have an effect on the
protocol proposed here.
--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
On Thu, 4 Jul 2019, Paul Hoffman wrote: Can you say more about what you mean? Is it a prediction, or a measurement, or a mixture, or something else? A prediction based on current measurements. Seriously, I'd love to be shown to be wrong in the future. We needed this for the freeswan project 25 years ago and it hasn't happened. Additionally, classless reverse delegation is even harder to get from ISPs if you don't have a full a /24, and I'm not even talking about signing your classless reverse delegation. Solution for endusers that need a DNSSEC signed reverse will not see deployment. I'd be happ to be wrong and that this will cause it to happen more than for our freeswan project, but I wouldn't bet on it. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
On Jul 3, 2019, at 7:13 PM, Joe Abley wrote: > On Jul 3, 2019, at 20:40, Paul Hoffman wrote: > >> If we want DNSSEC signing, we have to use the DNS reverse tree for the >> names, even though only a tiny percent of that tree will be signed. > > Aside from those parts of the in-addr.arpa and ip6.arpa domains that > correspond to special-use and unassigned addresses, I don't believe > there's any operational or protocol reasons that both domains couldn't > be completely signed today. Fully agree. > I'm aware that is not the case, but you > sound oddly definitive in your statement above. I guess I left off the "unfortunately, I predict" part. > Can you say more about what you mean? Is it a prediction, or a > measurement, or a mixture, or something else? A prediction based on current measurements. Seriously, I'd love to be shown to be wrong in the future. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
Moin! On 4 Jul 2019, at 2:40, Paul Hoffman wrote: I don't see the parallel with RFC 8484. We cannot force resolver vendors to care enough about announcing information about themselves to use either protocol. And we certainly cannot tell applications how to search for information. We can, however, offer options that either can use. Of course we can. If we define a discovery protocol for secure DNS we can define what a discovery client has to do. If we don’t do this it will cause problems. Say if from the draft resolver vendor N implements section 2 and browser vendor M implements section 3, both have implemented the protocol still it won’t work together. Current DHCP only offers information on resolvers by IP address, but that doesn't mean that no future version of resolver discover would not, particularly in situations where an OS or application already has one resolver and wants to get to a different one. That is, there is no reason not to add this as a potential for the future. Hmm a name as entry point for a name resolution protocol - ok maybe some future engineers come up with something but until we should say that current protocols don’t support it explicit and not implicit as it will confuse people. If a resolver of any type can't be configured to give the information here, it just won't. Again the problem are the consequences when it doesn’t. Which might happen because even though the ISP resolver has configured the RESINFO record it simply might not get the query if it is ignored by the proxy on the CPE the customer has bought, because of type. Are there words we could add to make this clearer? I ask because I still don't see how your concern can be dealt with in the protocol. The fallback to TXT or some other way to get to the resolver IP to ask. Should there be a fallback (TXT)? I'm not sure how that would help if it can't be configured due to address issues. DNS proxies can forward stuff and you could put wildcard answers on the link local/RFC1918 addresses. So you could actually make it work. But the likelihood of being able to forward TXT are bigger then the likelihood of being able to forward RESINFO, thus my question for fallback. This surprises me. There are forwarders that only forward requests and responses based on the RRtype? Well I saw this in the early days of DNSSEC deployment where a proxy (which is a forwarder, but dumber) did forward A, , MX, TXT, NS, etc. but not DNSKEY or any query type he did know nothing about. As we are defining a new query type this problem might surface again, thus the proposed fallback to txt or some other mechanism to work around the CPE at the customer site. I liked the idea of the earlier draft where there was a special name to get to the IP of the resolver. Understood, but people objected earlier to our use of a special-use domain name that could not have DNSSEC signing. If we want DNSSEC signing, we have to use the DNS reverse tree for the names, even though only a tiny percent of that tree will be signed. Well DNSSEC signing might work with the proper resolver signing reverse for RFC1918 which is a very common case will not work. SO long -Ralf —-- Ralf Weber ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
Hi Paul, On Jul 3, 2019, at 20:40, Paul Hoffman wrote: > If we want DNSSEC signing, we have to use the DNS reverse tree for the names, > even though only a tiny percent of that tree will be signed. Aside from those parts of the in-addr.arpa and ip6.arpa domains that correspond to special-use and unassigned addresses, I don't believe there's any operational or protocol reasons that both domains couldn't be completely signed today. I'm aware that is not the case, but you sound oddly definitive in your statement above. Can you say more about what you mean? Is it a prediction, or a measurement, or a mixture, or something else? Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
On Jul 1, 2019, at 4:11 PM, 神明達哉 wrote: > > At Sat, 29 Jun 2019 22:55:07 +, > Paul Hoffman wrote: > > > > - I think the RESINFO RDATA specification (at least its wire format, > > > and preferably also the presentation format) should be more clearly > > > specified. At least to me it was not very clear, and I'm afraid > > > this can lead to interoperability problems. > > > > It is a JSON object. What beyond that description would help? > > For example, if it can be a part of a standard zone file, what's the > expected presentation format? Is it a la TXT character string (but > there's no length limitation) or something special? How do we handle > non-ascii characters? Ah, I had not considered the presentation format. We'll add something about that in the next draft. > Also, how do we compare RESINFO RDATAs? Should they be compared as > opaque binary, or should two semantically identical JSON objects > considered equal as RESINFO RDATA too (even if, for example, they are > different regarding white spaces)? As opaque binary, definitely. JSON has so many ways of doing character escaping, it would be unlikely to make a completely correct JSON text comparator. We'll add that in the next draft as well. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
On Jun 30, 2019, at 1:08 AM, Ralf Weber wrote: > On 30 Jun 2019, at 1:01, Paul Hoffman wrote: >>> - The draft offers two methods of retrieving the object but says nothing >>> about which is mandatory (Me being a lazy DNS geek will certainly not put a >>> web server on my DNS server so won’t implement 3). Will it still work? Why? >> >> Neither is mandatory: both are optional. That is, we cannot force a resolver >> to give information about itself, nor can we force it to do something >> abnormal for a resolver (be authoritative for a new type of query or run a >> web server). > Sure you can not, but as we have seen with RFC8484 deplopyment where browser > vendors can say, oh if you don’t speak this (our language) we will just go > around you and talk to someone else. I want to avoid that situation in > discovery. So we have to give the client of such a protocol clear guidance on > what to do. IMHO try both ways and only if none work go back to your fallback > scenario. That is missing in the draft. I don't see the parallel with RFC 8484. We cannot force resolver vendors to care enough about announcing information about themselves to use either protocol. And we certainly cannot tell applications how to search for information. We can, however, offer options that either can use. >> The name doesn't need to be in the config of the DNS part of the resolver: >> it would only appear in the TLS part, just as it does in every web server >> that supports TLS. > That does make no sense. Where does a client of discovery get the name from? > All stub resolvers I know only have the IP configured and not a name. Can you > explain where the name for such a call would come from? Current DHCP only offers information on resolvers by IP address, but that doesn't mean that no future version of resolver discover would not, particularly in situations where an OS or application already has one resolver and wants to get to a different one. That is, there is no reason not to add this as a potential for the future. >>> - The biggest issue IMHO are RFC1918 and IPv6 link local addresses as these >>> are mostly used in homes for DNS resolver addresses. This means that the >>> CPE - who usually is a DNS Forwarder has to answer (and understand) this >>> query and either forward or answer by himself. DNS Proxies might not >>> implement RFC3597. >> >> If a resolver of any type can't be configured to give the information here, >> it just won't. > Again the problem are the consequences when it doesn’t. Which might happen > because even though the ISP resolver has configured the RESINFO record it > simply might not get the query if it is ignored by the proxy on the CPE the > customer has bought, because of type. Are there words we could add to make this clearer? I ask because I still don't see how your concern can be dealt with in the protocol. >>> Should there be a fallback (TXT)? >> >> I'm not sure how that would help if it can't be configured due to address >> issues. > DNS proxies can forward stuff and you could put wildcard answers on the link > local/RFC1918 addresses. So you could actually make it work. But the > likelihood of being able to forward TXT are bigger then the likelihood of > being able to forward RESINFO, thus my question for fallback. This surprises me. There are forwarders that only forward requests and responses based on the RRtype? > In general I don’t like the idea of traversing the reverse tree for that as > we can not validate it in a lot of use cases anyway and the information we > want is rather static and does not necessarily appear in the global DNS as it > is first line resolver specific. Understood, but people objected earlier to our use of a special-use domain name that could not have DNSSEC signing. If we want DNSSEC signing, we have to use the DNS reverse tree for the names, even though only a tiny percent of that tree will be signed. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
At Sat, 29 Jun 2019 22:55:07 +,
Paul Hoffman wrote:
> > - I think the RESINFO RDATA specification (at least its wire format,
> > and preferably also the presentation format) should be more clearly
> > specified. At least to me it was not very clear, and I'm afraid
> > this can lead to interoperability problems.
>
> It is a JSON object. What beyond that description would help?
For example, if it can be a part of a standard zone file, what's the
expected presentation format? Is it a la TXT character string (but
there's no length limitation) or something special? How do we handle
non-ascii characters?
Also, how do we compare RESINFO RDATAs? Should they be compared as
opaque binary, or should two semantically identical JSON objects
considered equal as RESINFO RDATA too (even if, for example, they are
different regarding white spaces)?
> > - The last sentence of Section 2 doesn't make sense to me:
> >
> >they only need code to handle the RESINFO RRtype that is not in
> >.{in-addr,ip6}.arpa/IN or a subdomain of >ip>.{in-addr,ip6}.arpa/IN .
> >
> > Should it actually be "that is in" instead of "that is not in"? If
> > it's really "not in", I don't know how to interpret this in this
> > context...
>
> The whole sentence is confusing, and we can remove it. Thus, that whole
paragraph can go away.
It may depend on the original intent of the NODATA/NXDOMAIN
restriction, but I'm personally fine with that.
--
JINMEI, Tatuya
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
Moin! On 30 Jun 2019, at 1:01, Paul Hoffman wrote: - The draft offers two methods of retrieving the object but says nothing about which is mandatory (Me being a lazy DNS geek will certainly not put a web server on my DNS server so won’t implement 3). Will it still work? Why? Neither is mandatory: both are optional. That is, we cannot force a resolver to give information about itself, nor can we force it to do something abnormal for a resolver (be authoritative for a new type of query or run a web server). Sure you can not, but as we have seen with RFC8484 deplopyment where browser vendors can say, oh if you don’t speak this (our language) we will just go around you and talk to someone else. I want to avoid that situation in discovery. So we have to give the client of such a protocol clear guidance on what to do. IMHO try both ways and only if none work go back to your fallback scenario. That is missing in the draft. The name doesn't need to be in the config of the DNS part of the resolver: it would only appear in the TLS part, just as it does in every web server that supports TLS. That does make no sense. Where does a client of discovery get the name from? All stub resolvers I know only have the IP configured and not a name. Can you explain where the name for such a call would come from? - The biggest issue IMHO are RFC1918 and IPv6 link local addresses as these are mostly used in homes for DNS resolver addresses. This means that the CPE - who usually is a DNS Forwarder has to answer (and understand) this query and either forward or answer by himself. DNS Proxies might not implement RFC3597. If a resolver of any type can't be configured to give the information here, it just won't. Again the problem are the consequences when it doesn’t. Which might happen because even though the ISP resolver has configured the RESINFO record it simply might not get the query if it is ignored by the proxy on the CPE the customer has bought, because of type. Should there be a fallback (TXT)? I'm not sure how that would help if it can't be configured due to address issues. DNS proxies can forward stuff and you could put wildcard answers on the link local/RFC1918 addresses. So you could actually make it work. But the likelihood of being able to forward TXT are bigger then the likelihood of being able to forward RESINFO, thus my question for fallback. In general I don’t like the idea of traversing the reverse tree for that as we can not validate it in a lot of use cases anyway and the information we want is rather static and does not necessarily appear in the global DNS as it is first line resolver specific. So long -Ralf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
On Jun 29, 2019, at 2:22 PM, Ralf Weber wrote: > > Couple of questions/remarks that may have been asked/answered (but are not > discussed in the draft thus I’m asking). > > - The draft offers two methods of retrieving the object but says nothing > about which is mandatory (Me being a lazy DNS geek will certainly not put a > web server on my DNS server so won’t implement 3). Will it still work? Why? Neither is mandatory: both are optional. That is, we cannot force a resolver to give information about itself, nor can we force it to do something abnormal for a resolver (be authoritative for a new type of query or run a web server). > - In section 3 there is the mention of the DOMAINNAMEOFRESOLVER. I have no > idea how any API/Interface for DNS resolvers offers the ability to enter a > name. So where does it come from? If there is no such thing should we not > remove it from the draft. The name doesn't need to be in the config of the DNS part of the resolver: it would only appear in the TLS part, just as it does in every web server that supports TLS. > - The biggest issue IMHO are RFC1918 and IPv6 link local addresses as these > are mostly used in homes for DNS resolver addresses. This means that the CPE > - who usually is a DNS Forwarder has to answer (and understand) this query > and either forward or answer by himself. DNS Proxies might not implement > RFC3597. If a resolver of any type can't be configured to give the information here, it just won't. > Should there be a fallback (TXT)? I'm not sure how that would help if it can't be configured due to address issues. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
Thanks for the review!
On Jun 28, 2019, at 1:06 PM, 神明達哉 wrote:
> I don't have a strong opinion on the adoption, but I'm willing to
> review it. My comments on 02 follow:
>
> - I think the RESINFO RDATA specification (at least its wire format,
> and preferably also the presentation format) should be more clearly
> specified. At least to me it was not very clear, and I'm afraid
> this can lead to interoperability problems.
It is a JSON object. What beyond that description would help?
> - It was not clear to me how the RESINFO is supported or not supported
> by authoritative servers.
>
> Section 1 states:
>[...] Authoritative
>servers MUST NOT answer queries that are defined in this protocol.
>
> But Section 2 states:
>
>[...] if the resolver can be configured to
>also be authoritative for some zones, it can use that configuration
>to actually be authoritative for the addresses on which it responds.
>
> This sounds like an "authoritative server" may answer those queries
> (perhaps Section 1 means "real" authoritative servers, and
> authoritative only servers in particular, while Section 2 intends to
> mean "local zone" features often available in recursive server
> implementations. But that's not really clear from the text.)
>
> And Section 6 states:
>
>[...] or unless the
>.{in-addr,ip6}.arpa zone is signed with DNSSEC, the
>response is susceptible to forgery.
>
> This seems to implicate that RESINFO under a
> .{in-addr,ip6}.arpa zone could be signed and answered by
> its authoritative server.
>
> I think the draft needs to clarify the expected role or limitation
> of authoritative servers regarding the proposed protocol.
Good catch! We will make this clearer in the next draft by sahing that, even if
the server is also an authoritative server, the responses only pertain to the
recursive side.
> - (Somewhat related to the previous point) Section 2 states
>
>Any query for the RESINFO RRtype that is not in .{in-
>addr,ip6}.arpa/IN or a subdomain of .{in-addr,ip6}.arpa/
>IN is meaningless and MUST result in a NODATA or NXDOMAIN response.
>Resolvers would not need any special code to meet this requirement;
>[...]
>
> How can we enforce (with a MUST) the result of NODATA or NXDOMAIN,
> especially if the resolver doesn't do anything special for such a
> case? If it means the resolver could just try to resolve it with
> authoritative servers and we require authoritative servers return
> NODATA or NXDOMAIN, can we always assume that? What if the zone's
> administrator configure a zone including the RESINFO? (And in any
> case, wouldn't it contradict the MUST NOT in Section 1?)
Hrm, this is a good point. A recursive resolver might have cached a RESINFO
response from some other server that it queried. We will remove the restriction.
>
> - The last sentence of Section 2 doesn't make sense to me:
>
>they only need code to handle the RESINFO RRtype that is not in
>.{in-addr,ip6}.arpa/IN or a subdomain of ip>.{in-addr,ip6}.arpa/IN .
>
> Should it actually be "that is in" instead of "that is not in"? If
> it's really "not in", I don't know how to interpret this in this
> context...
The whole sentence is confusing, and we can remove it. Thus, that whole
paragraph can go away.
--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
