Subject: [Acme] acme-ip reverse-dns discussion

From: Roland Bracewell Shoemaker <[email-masked]>
Date: Wed, 21 Mar 2018 20:55:59 +0000

Hey all,

Following on from the meeting today I wanted to start a discussion on what to do moving forward with regard to the reverse-dns method defined in draft-ietf-acme-ip. There were arguments on both sides about whether the method should be retained or removed with I’ll quickly paraphrase (if you feel I’ve misrepresented either please correct me).

The argument for removing this was that there are no technical issues with the method as-is but that the reverse DNS zones are historically badly managed and that using them for validation will cause problems down the line (presumably misissuance by a person who controls the zone but doesn’t actually control the IPs the zone represents). The argument for keeping it is that the IETF (or more specifically the ACME WG) should not be where CA or browser policy is dictated and that given these methods are currently allowed under the CABF BRs and browser root programs it would actually be useful to have a technically defined method for validation that can at least be used as a tool for further research on the topic.

As stated at the meeting I’m of the opinion that we should move forward with the method in the document and if individual browsers or CABF feel strongly that these methods are not secure they should disallow their usage in their root programs or the BRs respectively which would prevent any CA from actually using the method. That said there was obviously a contingent of people who disagree with me on this.

I guess one thing to ask is do we have anyone who would actually _want_ to use this? My understanding is the main use case, much like for the dns-01 challenge, is to get certs for IP identifiers before actually having to stand anything up on a machine so that it can instantly start doing its job which seems valuable.

Thanks,
Roland

---

From: Alan Doherty <[email-masked]>
Date: Thu, 22 Mar 2018 03:16:19 +0000

I'm pro moving forward
(i personally want my SANs to include the machines ips so anyone connecting via ip doesn't have to click through a security warning before being redirected to the correct name, yes 0 - minimal legitimate users would try the ip, but same for many of the names in my SAN id just like to see them show in log like other unintended for https names (to find out where they come from more than anything else) they don't show if they stop at cert warning

but im an edge case (most don't care about the unexpected traffic/load)

At 20:55 21/03/2018  Wednesday, Roland Bracewell Shoemaker wrote:
>Hey all, Following on from the meeting today I wanted to start a discussion on what to do moving forward with regard to the reverse-dns method defined in draft-ietf-acme-ip. There were arguments on both sides about whether the method should be retained or removed with I’ll quickly paraphrase (if you feel I’ve misrepresented either please correct me). The argument for removing this was that there are no technical issues with the method as-is but that the reverse DNS zones are historically badly managed and that using them for validation will cause problems down the line (presumably misissuance by a person who controls the zone but doesn’t actually control the IPs the zone represents). The argument for keeping it is that the IETF (or more specifically the ACME WG) should not be where CA or browser policy is dictated and that given these methods are currently allowed under the CABF BRs and browser root programs it would actually be useful to have a technically defined method f
or validation that can at least be used as a tool for further research on the topic. As stated at the meeting I’m of the opinion that we should move forward with the method in the document and if individual browsers or CABF feel strongly that these methods are not secure they should disallow their usage in their root programs or the BRs respectively which would prevent any CA from actually using the method. That said there was obviously a contingent of people who disagree with me on this. I guess one thing to ask is do we have anyone who would actually _want_ to use this? My understanding is the main use case, much like for the dns-01 challenge, is to get certs for IP identifiers before actually having to stand anything up on a machine so that it can instantly start doing its job which seems valuable. Thanks, Roland _______________________________________________ Acme mailing list [email-masked] https://www.ietf.org/mailman/listinfo/acme

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Mar 2018 18:15:02 -0700

On Wed, Mar 21, 2018 at 1:55 PM, Roland Bracewell Shoemaker <
[email-masked]> wrote:
>
> The argument for removing this was that there are no technical issues with
> the method as-is but that the reverse DNS zones are historically badly
> managed and that using them for validation will cause problems down the
> line (presumably misissuance by a person who controls the zone but doesn’t
> actually control the IPs the zone represents).

I'm not sure why you don't think this is a technical issue.

In any case, this is part of the argument, but not the only part. The
reason that the forward DNS lookup check is reasonable (to the extent to
which it is) is that forward DNS resolution is an integral part of going to
the site, and therefore control of the DNS substantively *is* control of
the site (i.e., there is fate sharing). By contrast, reverse resolution
forms no part of addressing the site, and therefore control of this region
of the DNS proves nothing about your control of the site. This is, of
course, why the reverse tree is in such bad shape.

> The argument for keeping it is that the IETF (or more specifically the
> ACME WG) should not be where CA or browser policy is dictated and that
> given these methods are currently allowed under the CABF BRs and browser
> root programs it would actually be useful to have a technically defined
> method for validation that can at least be used as a tool for further
> research on the topic.
>

It's not a matter of dictating CA or browser policy, but of not
standardizing a method of validation which we know to be severely flawed.
In no way does this preclude other people from deploying this
authentication mechanism; the standard for registering an identifier in
this space is "Specification Required" and the standard the expert is
supposed to evaluate is quite low (
https://tools.ietf.org/html/draft-ietf-acme-acme-11#section-9.7.8).

   When evaluating a request for an assignment in this registry, the
   designated expert should ensure that the method being registered has
   a clear, interoperable definition and does not overlap with existing
   validation methods.  That is, it should not be possible for a client
   and server to follow the same set of actions to fulfill two different
   validation methods.

If CAs wish to experiment with -- or even use -- this technique, they need
only publish a specification. The difference is that the IETF would not be
endorsing it.

-Ekr

---

From: Roland Bracewell Shoemaker <[email-masked]>
Date: Wed, 28 Mar 2018 14:16:22 +0200

> On Mar 28, 2018, at 3:15 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Wed, Mar 21, 2018 at 1:55 PM, Roland Bracewell Shoemaker <[email-masked]> wrote:
> The argument for removing this was that there are no technical issues with the method as-is but that the reverse DNS zones are historically badly managed and that using them for validation will cause problems down the line (presumably misissuance by a person who controls the zone but doesn’t actually control the IPs the zone represents).
> 

I don’t think this is a technical issue because technically it is essential exactly the same as the existing DNS validation method. The only difference being instead of needing to trust the root and TLD zones you need to trust the reverse zones. I think the DNS method is technically sound but if it were managed in the way you and others are suggesting then it would be equally broken. To me the issue is not technical but operational. If for whatever reason the management of the reverse zone was brought into line with the defined expectations of how it is meant to be managed this method would seemingly not be an issue for everyone.

> In any case, this is part of the argument, but not the only part. The reason that the forward DNS lookup check is reasonable (to the extent to which it is) is that forward DNS resolution is an integral part of going to the site, and therefore control of the DNS substantively *is* control of the site (i.e., there is fate sharing). By contrast, reverse resolution forms no part of addressing the site, and therefore control of this region of the DNS proves nothing about your control of the site. This is, of course, why the reverse tree is in such bad shape.
> 

Again I think this is an operational issue, as defined in RFC 1034, 1912, 3172, 5855, etc etc the reverse zones are meant to be a reliable inverse mapping from address to host name, which if believed should allow us to use them as a viable method for validating control of addresses. While I agree this is a weaker guarantee of control than forward DNS I don’t think it is so substantively worse that it sould not be used (again as defined, I take no issue with the arguments that it is badly managed).

>  
> The argument for keeping it is that the IETF (or more specifically the ACME WG) should not be where CA or browser policy is dictated and that given these methods are currently allowed under the CABF BRs and browser root programs it would actually be useful to have a technically defined method for validation that can at least be used as a tool for further research on the topic.
> 
> It's not a matter of dictating CA or browser policy, but of not standardizing a method of validation which we know to be severely flawed. In no way does this preclude other people from deploying this authentication mechanism; the standard for registering an identifier in this space is "Specification Required" and the standard the expert is supposed to evaluate is quite low (https://tools.ietf.org/html/draft-ietf-acme-acme-11#section-9.7.8).
> 
> If CAs wish to experiment with -- or even use -- this technique, they need only publish a specification. The difference is that the IETF would not be endorsing it.
> 
> -Ekr
>  
> 

I personally think it would be nice to standardize a method of doing this type of validation, given it is something currently being used in the wild be CAs, but since there seems to be staunch oppopsition to doing so and at least the one user we had whom was interested in doing this have found another way of doing what they want I think at this point it makes sense to just scrap it. Unless someone else pops out of the woodwork with strong opinions I’ll remove the method and publish a new version of the draft after I return from vacation.

---

From: Alan Doherty <[email-masked]>
Date: Wed, 28 Mar 2018 13:59:27 +0100

how about a dual/combined solution

ie ptr lookup (returns list of names)
validation lookup of txt record (as per current spec) for one of those names, 
proves longevity of control
+
http-get for http://ip-address/.well-known/acme-challenge/etc
to prove current control of the ip 

(same challenge token in both)

it wouldn't help all use cases but would satisfy all the 'control of ip today doesn't prove control tomorrow' and 'control of ptr doesn't prove control of the ip' naysayers 

and allow those of us that have competent/reasonable ip suppliers who have setup ptr's as requested to add our ips to our https servers SAN lists 
(and possibly add pressure to the other ip suppliers to fixup ptr delegations/zones/etc)

At 02:15 28/03/2018  Wednesday, Eric Rescorla wrote:

>On Wed, Mar 21, 2018 at 1:55 PM, Roland Bracewell Shoemaker <<mailto:[email-masked]>[email-masked]> wrote:
>The argument for removing this was that there are no technical issues with the method as-is but that the reverse DNS zones are historically badly managed and that using them for validation will cause problems down the line (presumably misissuance by a person who controls the zone but doesnâ€™t actually control the IPs the zone represents). 
>
>
>Â 
>It's not a matter of dictating CA or browser policy, but of not standardizing a method of validation which we know to be severely flawed. In no way does this preclude other people from deploying this authentication mechanism; the standard for registering an identifier in this space is "Specification Required" and the standard the expert is supposed to evaluate is quite low (<https://tools.ietf.org/html/draft-ietf-acme-acme-11#section-9.7.8>https://tools.ietf.org/html/draft-ietf-acme-acme-11#section-9.7.8).
>
>Â  Â When evaluating a request for an assignment in this registry, the
>Â  Â designated expert should ensure that the method being registered has
>Â  Â a clear, interoperable definition and does not overlap with existing
>Â  Â validation methods.Â  That is, it should not be possible for a client
>Â  Â and server to follow the same set of actions to fulfill two different
>Â  Â validation methods.
>
>Â 
>_______________________________________________
>Acme mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/acme

---

From: Michael Casadevall <[email-masked]>
Date: Wed, 28 Mar 2018 09:54:12 -0400

On 3/27/2018 9:15 PM, Eric Rescorla wrote:
>
>
> On Wed, Mar 21, 2018 at 1:55 PM, Roland Bracewell Shoemaker 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     The argument for removing this was that there are no technical
>     issues with the method as-is but that the reverse DNS zones are
>     historically badly managed and that using them for validation will
>     cause problems down the line (presumably misissuance by a person
>     who controls the zone but doesn’t actually control the IPs the
>     zone represents). 
>
>
> reason that the forward DNS lookup check is reasonable (to the extent 
> to which it is) is that forward DNS resolution is an integral part of 
> going to the site, and therefore control of the DNS substantively *is* 
> control of the site (i.e., there is fate sharing). By contrast, 
> reverse resolution forms no part of addressing the site, and therefore 
> control of this region of the DNS proves nothing about your control of 
> the site. This is, of course, why the reverse tree is in such bad shape.
>

There's actually a larger problem here that's been overlooked as far as 
I can tell. Specifically, an operator of a site may not have 
authoritative control of the reverse DNS zone unless they are the owner 
of of the internet routable block (/24 or larger with IPv6, /64+ IPv6). 
When a block is subdivided for something like Amazon EC2, or Linode, 
reverse DNS updates are published through an provider specific method 
which then the block owner can publish into their zones.

ARIN: https://www.arin.net/resources/request/reversedns.html
RIPE: 
https://www.ripe.net/manage-ips-and-asns/db/support/configuring-reverse-dns

This opens a rather ugly can of worms: the designated owner of the block 
can publish whatever records and thus create certificates for *any* IP 
address by simply adding a second PTR record to any existing ones, 
complete the challenge, and then delete the PTR leaving anyone unaware 
short of checking CT logs for their IP address. As previously brought 
up, reverse DNS isn't typically used to getting to a website so this 
could be essentially invisible attack.

Alan somewhat beat me to this point, I think PTR validation may be 
useful for proving "long term" control of an IP address from a provider, 
but in and of itself, I think it's a security issue waiting to happen. 
If it was combined with a second challenge however which direct control 
of the machine on that IP+proof of intent to have a certificate issued, 
it would be usable.

> standardizing a method of validation which we know to be severely 
> flawed. In no way does this preclude other people from deploying this 
> authentication mechanism; the standard for registering an identifier 
> in this space is "Specification Required" and the standard the expert 
> is supposed to evaluate is quite low 
> (https://tools.ietf.org/html/draft-ietf-acme-acme-11#section-9.7.8).
>

What concerns me is that if we don't have a method of validation for IP 
addresses that are reasonably secure, people might just take this I-D 
and implement it anyway without realizing why. I personally think being 
able to have certs issued for IPs is reasonably useful to an extent so 
if we can fix the specification, it's a worthwhile thing to do.
Michael

---

From: "Matthew D. Hardeman" <[email-masked]>
Date: Wed, 28 Mar 2018 12:46:59 -0500

> 
> There's actually a larger problem here that's been overlooked as far as I can tell. Specifically, an operator of a site may not have authoritative control of the reverse DNS zone unless they are the owner of of the internet routable block (/24 or larger with IPv6, /64+ IPv6). When a block is subdivided for something like Amazon EC2, or Linode, reverse DNS updates are published through an provider specific method which then the block owner can publish into their zones.
> 
> ARIN: https://www.arin.net/resources/request/reversedns.html <https://www.arin.net/resources/request/reversedns.html>
> RIPE: https://www.ripe.net/manage-ips-and-asns/db/support/configuring-reverse-dns <https://www.ripe.net/manage-ips-and-asns/db/support/configuring-reverse-dns>
> 
> This opens a rather ugly can of worms: the designated owner of the block can publish whatever records and thus create certificates for *any* IP address by simply adding a second PTR record to any existing ones, complete the challenge, and then delete the PTR leaving anyone unaware short of checking CT logs for their IP address. As previously brought up, reverse DNS isn't typically used to getting to a website so this could be essentially invisible attack.
> 
> Alan somewhat beat me to this point, I think PTR validation may be useful for proving "long term" control of an IP address from a provider, but in and of itself, I think it's a security issue waiting to happen. If it was combined with a second challenge however which direct control of the machine on that IP+proof of intent to have a certificate issued, it would be usable.

I have a significant amount of IP space registered at ARIN and can speak to the reverse-DNS delegation configuration.

For IPv4, ARIN allows for the record holder for the IP space to delegate the lookup zone to name-servers of the resource holder’s choice at the /24 level.  Having said that, if I as an ISP provide a full /24 to an end-user customer, I can configure the /24 at ARIN with as being SWIP’ed to the customer entity and update the NS delegation for that /24’s reverse zone to my customer’s name servers.  I could also override that at any time and send it to a name-server in the middle.

To be clear, the ONLY record that the ARIN resource holder can directly influence at ARIN is a set of NS records indicating what name servers to delegate the zone to. 

Does this mean that the network provider for the IP space in question can hijack the validation process?  Yes.  But this is not materially different from a registrar being able to similarly hijack the NS delegations for a domain that’s been registered with them.

If we think of an IP address as a strongly named resource like, say, a particular domain label, we can see that in both cases it is entirely possible for the trusted parties in the closer-to-the-root hierarchies to subvert validation processes by asserting the control inherent in their position as the “earlier asked party” vs the delegations down the line.

As an aside, for smaller than /24 delegation, an ISP can literally further delegate reverse lookup to a zone of a single IP address, allowing smaller customers direct access to update the reverse DNS for those IPs within their own name servers, if desired.  This configuration is rare, but exists.

---

From: Michael Casadevall <[email-masked]>
Date: Wed, 28 Mar 2018 19:16:28 -0400

I went back and forth and re-read several RFCs, the baseline 
requirements, and the draft, and ended three or four drafts of this 
email before replying so just some broad thoughts.

On 3/28/2018 1:46 PM, Matthew D. Hardeman wrote:
>
> I have a significant amount of IP space registered at ARIN and can 
> speak to the reverse-DNS delegation configuration.
>
> For IPv4, ARIN allows for the record holder for the IP space to 
> delegate the lookup zone to name-servers of the resource holder’s 
> choice at the /24 level.  Having said that, if I as an ISP provide a 
> full /24 to an end-user customer, I can configure the /24 at ARIN with 
> as being SWIP’ed to the customer entity and update the NS delegation 
> for that /24’s reverse zone to my customer’s name servers.  I could 
> also override that at any time and send it to a name-server in the middle.
>
> To be clear, the ONLY record that the ARIN resource holder can 
> directly influence at ARIN is a set of NS records indicating what name 
> servers to delegate the zone to.
>
> Does this mean that the network provider for the IP space in question 
> can hijack the validation process?  Yes.  But this is not materially 
> different from a registrar being able to similarly hijack the NS 
> delegations for a domain that’s been registered with them.
>

You bring up a good point, and while I'm not sure I 100% agree with 
this, mootness comes into play as after checking the literal text of 
CA/B BR, and it says under 3.2.2.5.

"3. Performing a reverse-IP address lookup and then verifying control 
over the resulting Domain Name under Section 3.2.2.4 [Validation of 
Domain Authorization or Control]"

Which at looking at the specification, and the CA/B rules side by side, 
it *does* meet 3.2.2.5. I know per RFC 1034, there's only supposed to be 
one PTR per domain, but in practice people have published multiple ones. 
What happens in that case?

As far as I understand it, it's protocol legal to send multiple PTRs, 
although I'm not sure how the resolver handles that, or if it's even 
easily detectable in Boulder.

Furthermore, I do have one remaining niggle I spotted on the third or 
fourth re-reading. Specifically, nowhere in the DNS token generation do 
we actually put the IP address we want to validate; the token is 
generated from the hash of the host. I doubt this is a security concern, 
but wanted to make sure this wasn't a mistake.

> If we think of an IP address as a strongly named resource like, say, a 
> particular domain label, we can see that in both cases it is entirely 
> possible for the trusted parties in the closer-to-the-root hierarchies 
> to subvert validation processes by asserting the control inherent in 
> their position as the “earlier asked party” vs the delegations down 
> the line.
>

 From a reverse-DNS perspective, that's true since the PTR (in theory) 
is supposed to point to the most authoritative name a server may have. 
That being said, I have issues thinking of IPs as a strongly named 
resource in general fairly transitory compared to the domain names 
they're attached to, and useless in and of them selves due to 
multitenant/virtual hosting.

Hope this isn't too rambling, and thanks Matt for the insight and 
patience on the ARIN reverse DNS zone. I do have concerns on actually 
using the reverse zone for any sort of validation, but as CA/B has 
approved it so I won't comment on those grounds due to out-of-scopiness.
Michael

---

From: Alan Doherty <[email-masked]>
Date: Thu, 29 Mar 2018 02:01:02 +0100

At 14:54 28/03/2018  Wednesday, Michael Casadevall wrote:
>Content-Type: multipart/alternative;
> boundary="------------834EF402DF7BD9A4D3D7E1FB"
>Content-Language: en-US
>
>
>

not really an issue as authorisation keys are mounted in the forward zone
(indicated by ptr only)
thus as long as the ip supplier(owner) has placed the ptr records the customer(ip leaser) requested once the job is done

>ARIN: <https://www.arin.net/resources/request/reversedns.html>https://www.arin.net/resources/request/reversedns.html
>RIPE: <https://www.ripe.net/manage-ips-and-asns/db/support/configuring-reverse-dns>https://www.ripe.net/manage-ips-and-asns/db/support/configuring-reverse-dns
>

if your being attacked by your own ip supplier this is the least of your worries as they could as easily route your websites ip to another host momentarily(or just for LE outbounds) to complete the cert validation for any/all other name(s)
(and then at will intercept some/all of your visitors undetectably without cert pining, but no methods can defend you from your own isp/ip/connectivity provider, thats why some level of trust is implied in choosing them)

ptr really is only an issue where you have an unresponsive ip supplier with stale ptr records
and thus the old/previous lease-owner can easily get a cert for your ip (though limited in use to them, except when they can mitm some subset of your visitors) 

>What concerns me is that if we don't have a method of validation for IP addresses that are reasonably secure, people might just take this I-D and implement it anyway without realizing why. I personally think being able to have certs issued for IPs is reasonably useful to an extent so if we can fix the specification, it's a worthwhile thing to do.
>Michael
>

---

From: Alan Doherty <[email-masked]>
Date: Thu, 29 Mar 2018 02:09:23 +0100

>As an aside, for smaller than /24 delegation, an ISP can literally further delegate reverse lookup to a zone of a single IP address, allowing smaller customers direct access to update the reverse DN…

with all our sub-24 ranges we just have the owner setup

uuu.xx.yy.zz.in-addr.arpa cname uuu.xx.yy.zz.r-ptrs.orionnetworks.ie.

then we setup and manage the ptrs within our own sub-zone, it works well for us

---

From: Alan Doherty <[email-masked]>
Date: Thu, 29 Mar 2018 02:13:14 +0100

i did mail the author with the textual changes needed to explicitly handle multiple ptrs but no response

-------------------------------------------------------------
apologies for direct contact as im not aware of protocol

but wanted to suggest amendments to
https://datatracker.ietf.org/doc/draft-ietf-acme-ip/?include_text=1

not alterations just clarifying detail as some ips have multiple PTR records

4.1.

instead of

The client constructs the validation domain name by prepending the
   label "_acme-challenge" to the domain name referenced in the PTR
   resource record for the IN-ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596]
   reverse mapping of the IP address.  The client then provisions a TXT
   record with the digest for this name.

(altered additions 'one of' and '(s)' )

The client constructs the validation domain name by prepending the
   label "_acme-challenge" to one of the domain name(s) referenced in the PTR
   resource record for the IN-ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596]
   reverse mapping of the IP address.  The client then provisions a TXT
   record with the digest for this name.

instead of

On receiving a response, the server MUST verify that the key
   authorization in the response matches the "token" value in the
   challenge and the client's ACME account key.  If they do not match,
   then the server MUST return an HTTP error in response to the POST
   request in which the client sent the challenge.

   To validate a DNS challenge, the server performs the following steps:

   1.  Compute the SHA-256 digest of the key authorization

   2.  Query for a PTR record for the IP identifier's relevant reverse
       mapping based on its version

   3.  Query for TXT records for the computed validation domain name

   4.  Verify that the contents of one of the TXT records matches the
       digest value

altered  r/a/all and added (s) twice

On receiving a response, the server MUST verify that the key
   authorization in the response matches the "token" value in the
   challenge and the client's ACME account key.  If they do not match,
   then the server MUST return an HTTP error in response to the POST
   request in which the client sent the challenge.

   To validate a DNS challenge, the server performs the following steps:

   1.  Compute the SHA-256 digest of the key authorization

   2.  Query for all the PTR record(s) for the IP identifier's relevant reverse
       mapping based on its version

   3.  Query for TXT records for the computed validation domain name(s)

   4.  Verify that the contents of one of the TXT records matches the
       digest value

At 00:16 29/03/2018  Thursday, Michael Casadevall wrote:
>I went back and forth and re-read several RFCs, the baseline requirements, and the draft, and ended three or four drafts of this email before replying so just some broad thoughts. On 3/28/2018 1:46 PM, Matthew D. Hardeman wrote: > > I have a significant amount of IP space registered at ARIN and can > speak to the reverse-DNS delegation configuration. > > For IPv4, ARIN allows for the record holder for the IP space to > delegate the lookup zone to name-servers of the resource holderâ€™s > choice at the /24 level. Â Having said that, if I as an ISP provide a > full /24 to an end-user customer, I can configure the /24 at ARIN with > as being SWIPâ€™ed to the customer entity and update the NS delegation > for that /24â€™s reverse zone to my customerâ€™s name servers. Â I could > also override that at any time and send it to a name-server in the middle. > > To be clear, the ONLY record that the ARIN resource holder can > directly influence at ARIN is a set of NS records indicating wha
t name > servers to delegate the zone to. > > Does this mean that the network provider for the IP space in question > can hijack the validation process? Â Yes. Â But this is not materially > different from a registrar being able to similarly hijack the NS > delegations for a domain thatâ€™s been registered with them. > You bring up a good point, and while I'm not sure I 100% agree with this, mootness comes into play as after checking the literal text of CA/B BR, and it says under 3.2.2.5. "3. Performing a reverse-IP address lookup and then verifying control over the resulting Domain Name under Section 3.2.2.4 [Validation of Domain Authorization or Control]" Which at looking at the specification, and the CA/B rules side by side, it *does* meet 3.2.2.5. I know per RFC 1034, there's only supposed to be one PTR per domain, but in practice people have published multiple ones. What happens in that case? As far as I understand it, it's protocol legal to send multiple PTRs, although I'm n
ot sure how the resolver handles that, or if it's even easily detectable in Boulder. Furthermore, I do have one remaining niggle I spotted on the third or fourth re-reading. Specifically, nowhere in the DNS token generation do we actually put the IP address we want to validate; the token is generated from the hash of the host. I doubt this is a security concern, but wanted to make sure this wasn't a mistake. > If we think of an IP address as a strongly named resource like, say, a > particular domain label, we can see that in both cases it is entirely > possible for the trusted parties in the closer-to-the-root hierarchies > to subvert validation processes by asserting the control inherent in > their position as the â€œearlier asked partyâ€ vs the delegations down > the line. > From a reverse-DNS perspective, that's true since the PTR (in theory) is supposed to point to the most authoritative name a server may have. That being said, I have issues thinking of IPs as a strongly name
d resource in general fairly transitory compared to the domain names they're attached to, and useless in and of them selves due to multitenant/virtual hosting. Hope this isn't too rambling, and thanks Matt for the insight and patience on the ARIN reverse DNS zone. I do have concerns on actually using the reverse zone for any sort of validation, but as CA/B has approved it so I won't comment on those grounds due to out-of-scopiness. Michael _______________________________________________ Acme mailing list [email-masked] https://www.ietf.org/mailman/listinfo/acme </x-flowed>

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 29 Mar 2018 09:17:19 -0500

On 2018-03-28 12:46 -0500, Matthew D. Hardeman wrote:
> As an aside, for smaller than /24 delegation, an ISP can literally
> further delegate reverse lookup to a zone of a single IP address,
> allowing smaller customers direct access to update the reverse DNS for
> those IPs within their own name servers, if desired.  This configuration
> is rare, but exists.

This is documented in RFC 2317 - Classless IN-ADDR.ARPA delegation
aka BCP 20

   This document describes a way to do IN-ADDR.ARPA delegation on non-
   octet boundaries for address spaces covering fewer than 256
   addresses.  The proposed method should thus remove one of the
   objections to subnet on non-octet boundaries but perhaps more
   significantly, make it possible to assign IP address space in smaller
   chunks than 24-bit prefixes, without losing the ability to delegate
   authority for the corresponding IN-ADDR.ARPA mappings.  The proposed
   method is fully compatible with the original DNS lookup mechanisms
   specified in [1], i.e. there is no need to modify the lookup
   algorithm used, and there should be no need to modify any software
   which does DNS lookups.

-- 
Patrick Mevzek

---

From: James Cloos <[email-masked]>
Date: Thu, 29 Mar 2018 11:04:51 -0400

>>>>> "AD" == Alan Doherty <[email-masked]> writes:

AD> with all our sub-24 ranges we just have the owner setup

AD> uuu.xx.yy.zz.in-addr.arpa cname uuu.xx.yy.zz.r-ptrs.orionnetworks.ie.

AD> then we setup and manage the ptrs within our own sub-zone, it works well for us

Alternatively, some providers set up NS records for each ip in the
range, allowing the end user to have a zone for each PTR on their
own dns infrastucture.

More data, and marginally slower, but it works.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Alan Doherty <[email-masked]>
Date: Thu, 29 Mar 2018 17:54:22 +0100

>More data, and marginally slower, but it works.

downside is another person to contact if ye change nameservers
(why we prefer the indirect referal)