The main use case here is for major providers who want to get certificates for addresses before there is actually anything bootstrapped on the machine behind it yet. Then they are able to immediately stand something up that can be used instead of needing to go through the process of validation and issuance etc. This typically is not something that individuals who do not directly manage their own DNS servers will use.
> On Mar 12, 2018, at 5:37 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > > On 12 Mar 2018, at 8:58, Roland Bracewell Shoemaker wrote: > >> I’m working on a document in the ACME WG that concerns methods for >> validating control of IP addresses (draft-ietf-acme-ip) and wanted to see if >> anyone here could provide some input on a question I had regarding usage of >> the ip6.arpa and in-addr.arpa zones. >> >> In the original incarnation of this document one outlined method revolved >> around requesting that a user place a TXT record containing a random token >> in the relevant ip6.arpa or in-addr.arpa child zone for the address being >> validated and then verifying that this record was present. After reading RFC >> 3172 there was some concern that this would not be a ‘blessed’ usage of the >> zones and that they should only contain records that related to mapping >> protocol addresses to service names. Because of this we reworked the method >> to require placing the TXT record at the target of a PTR record in the >> relevant zone instead. >> >> After a number of discussions I’m interested in returning to the original >> concept as it simplifies a number of use cases that this document is >> intended to support but am still not sure whether or not this would be >> widely considered ‘ok’ by DNS folks. Obviously it’s entirely possible to do >> this as these child zones are delegated to users and they _can_ put whatever >> they want in them. Does this WG have strong opinions on whether we >> should/shouldn’t do this for technical reasons or we just being a bit too >> strict in our reading of 3172? > > If the use case here is to be able to issue certificates for TLS servers > based on the IP address instead of the domain name, creating something new in > the DNS may be overkill. That is, why even have Section 4.1 of > draft-ietf-acme-ip at all? What's wrong with only having direct HTTPS access? > > --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop