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
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
