<div dir="ltr"><div>I am probably saying this badly, and I regret any implied teaching-your-granny-to-suck-eggs. Thats not my goal.</div><div><br></div>I understand Reverse-DNS as a namespace which contains assertions made by the entity which controls the next-highest do-separated tlabel delegation point, or the hunt backwards to the root. That doesn't have to BE the immediate rightmost dot if you are a /24, the /16 might not be delegated. Likewise there may only be a /24 and the intermediate /16 may not exist as a delegation point: the /24 may reside directly in an RIR /8 delegation zone file.<div>
<br></div><div>So, in that respect, it represents an assertion of PTR made by a 'parent' entity over the addressblock in question.</div><div><br></div><div>Because it is forced to align to the dot boundary of the mapping of an IPv4 or IPv6 address, which do not align cleanly with the CIDR boundary of routing, It has a more limited applicability to statements over routing.</div>
<div><br></div><div>There are people who believe there are ways round that but its work-in-progress. (which btw, I am not involved with and I make no claims as to its viability or otherwise. I do personally think a clean CIDR/prefix respecting namespace in DNS would be interesting and useful)</div>
<div><br>So noting that it has limited applicability in the wide to the exact-match of routing, It does at least have relationship to the management of the address space and respects a top-down delegation/hierarchy model of management. Again, I am not trying to say what should/should-not be regarding that, just that it does follow a hierarchy, which can be useful, because trust stems from the root TA out of band, so a signed DNS reverse space represents a series of encompassing hierarchical trust statements from the root down.</div>
<div><br></div><div>Parent assertions can be useful. Signed parent assertions can be useful. They can include information which materially says "for more information go <here>" so in principle, they can empower address holders, under a suitable framework, to make trustable assertions about an IP address.</div>
<div><br></div><div>Can anyone think of reasons why they might want to do that?</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 13, 2014 at 8:03 AM, Mark Boolootian <span dir="ltr"><<a href="mailto:booloo@ucsc.edu" target="_blank">booloo@ucsc.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Randy,<br>
<div class=""><br>
>> I'm interested in knowing if it is standard practice amongst folks to<br>
>> sign .arpa zones.  Is there a compelling use case for signing reverse<br>
>> zones?<br>
><br>
</div><div class="">> standard practice?  you some kinda control freak?<br>
<br>
</div>Learned at the feet of the masters (and thank you :-)<br>
<div class=""><br>
> first there is the arguments about whether reverse zones are useful and<br>
> should be populated.  i happen to use reverse lookup daily, so i try to<br>
> maintain them well for all the address space for which i am responsible.<br>
<br>
</div>We do likewise.<br>
<div class=""><br>
> so, given that i am gonna maintain the zone, why would i not want to<br>
> also sign the data?  the amount of work is trivial, and it's just one<br>
> more step in trying to paint security on the horribly insecure internet.<br>
<br>
</div>I was anticipating more of a beating for my question, but apparently<br>
there is an overabundance of politeness here :-)    All points taken.<br>
<span class="HOEnZb"><font color="#888888"><br>
mark<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations<br>
dns-jobs</a> mailing list<br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-jobs" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-jobs</a><br>
</div></div></blockquote></div><br></div>