Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

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.br@dmarc.ietf.org wrote:
>>
>> 
>>
>>> On 22 Jun 2022, at 00:07, John Levine <johnl@taugh.com <mailto:johnl@taugh.com>> wrote:
>>>
>>> It appears that  <rubensk@nic.br <mailto:rubensk@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 johnl@18.183.57.64.in-addr.arpa <mailto:johnl@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