On 6/22/22 14:40, Paul Wouters wrote:
Unfortunately, the reverse zone is very often out of reach for those who use
the IP range and trying to do classless reverse delegation (RFC 2317) for those
who have less than a /24 is even harder to get.
That's exactly right, DNS operators will in many cases not control the reverse
zones of their NS IPs, especially when diversifying secondary operations across
edge providers.
What's more: reverse-based signaling introduces additional trusted parties --
namely, the zone administrators of the reverse zone's parents. That will
usually be some large-scale datacenter provider, the RIRs, up to the .arpa
operator.
These are the same parties who have a say in how traffic to those IP addresses gets
routed. If one of these actors mounted a DNSSEC spoofing attack on
_signal.<reverse-zone>.arpa, an accompanying routing compromise may not pose
much extra difficulty, but would allow for spoofing the child apex CDS/CDNSKEY
records. This would enable injecting fake records at the child and having them
fake-authenticated through the reverse zone.
In other words, reverse-based signaling introduces additional actors who are in
an (at least somewhat) privileged position, potentially enabling them to
undermine the whole protocol. This would change the trust model of the protocol
(which is certainly conceivable; but it would have to be made explicit).
In contrast, the draft currently has no such actors at all; the registrant can
choose all involved parties (including TLD registries). (Of course, there is
always the root operator, but that is not specific to bootstrapping.)
Best,
Peter
On Jun 21, 2022, at 23:30, rubensk=40nic...@dmarc.ietf.org wrote:
On 22 Jun 2022, at 00:07, John Levine <jo...@taugh.com
<mailto:jo...@taugh.com>> wrote:
It appears that <rube...@nic.br <mailto:rube...@nic.br>> said:
-=-=-=-=-=-
Hi.
During a meeting today of ROW (https://regiops.net <https://regiops.net>), the
I-D on CDS bootstrapping by using a DNSSEC-signed name at name server
zone (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/
<https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/>) was
discussed.
In that discussion, it was mentioned that the current draft only supports
out-of-bailiwick name servers; I replied that the
same principle could be applied to in-bailiwick name server by usage of the
reverse DNS zones for IPv4 and IPv6.
Urrgh. In principle, you can put anything you want in a reverse zone.
(Send mail to jo...@18.183.57.64.in-addr.arpa
<mailto:jo...@18.183.57.64.in-addr.arpa>. and it'll work.)
That's my recollection as well, but as the saying goes, code is law. Although
in this case only registry/registrar and DNS operator are required to
interoperate for the bootstrapping process.
In practice, I doubt that enough reverse zones are signed or that the
provisoning crudware that people use for reverse zones would work
often enough to be worth trying to do this. I did some surveys of
zones and found that in-bailiwick NS are quite uncommon, only a few
percent of the ones in large gTLDs.
I don't expect the IP space used for DNS servers to be managed thru an IPAM
system of sorts. But if one is used, it's unlikely they provision a zone-cut as
required in the draft.
The prevalence among the overall DNS system is indeed low, but I wonder what % this
represents within services that allow all of DNSSEC, CDS Bootstrapping and
in-bailiwick DNS servers, like Business and Enterprise plans in Cloudflare:
https://developers.cloudflare.com/dns/additional-options/custom-nameservers/
<https://developers.cloudflare.com/dns/additional-options/custom-nameservers/> .
Or if supporting this type of DNS servers can help the adoption of this draft
for the 99.9% use case of out-of-bailiwick servers. If not, we could be adding
a new piece to the DNS Camel...
Rubens
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
Like our community service? 💛
Please consider donating at
https://desec.io/
deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany
Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
