<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 19 Feb 2020 at 11:43, Pirawat WATANAPONGSE <<a href="mailto:pirawat.w@ku.th">pirawat.w@ku.th</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Well, let’s look at the real netblock, shall we? (‘cause I have nothing to hide)<br>You can see for yourself at <a href="https://dnsviz.net/d/108.158.in-addr.arpa/dnssec/" target="_blank">https://dnsviz.net/d/108.158.in-addr.arpa/dnssec/</a><br><br></div></div></blockquote><div><br></div><div>I don't really see any of these things as flag-day level problems.  The (so-called) DNS Flag Days are about fixing long standing interoperability issues that increase complexity of DNS server code, as it needs to work around those problems.  None of the issues below are interoperability issues, and none of them are long-standing issues either.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">1. There are old DS keys from .arpa to in-addr.arpa still dangling around.<br></div></div></blockquote><div><br></div><div>Why do you say there are old DS records (not keys) hanging around?  It looks to me like the DS records for key IDs 53696 and 63982 are likely to be pre-published for a key roll.  Although without very long term history of the zone contents it's hard to tell.  Perhaps one of them is outgoing and the other is incoming?  Either way, this is not a _problem_ for the zone or the DNS.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">2. 158.in-addr.arpa is still using ‘Algorithm 5’<br></div></div></blockquote><div><br></div><div>That could be improved, but again I don't see this as a flag-day level issue.  Algo 5 has only recently fallen out of favour, and we haven't even got around to deprecating it yet.  Presumably ARIN will get around to doing an algorithm roll in the coming months.  You might ask on arin-discuss[1] whether there are currently any plans, and what the schedule is.  It's entirely possible they've already published such a schedule... their operations team is usually pretty on top of things.  </div><div><br></div><div>The remainder of these are not DNS problems at all, they're registry operations and RIR policy issues.  For those I suggest you email the registration support contacts at RIPE and ARIN, and if that doesn't solve your issue, then I'd take it to their respective policy mailing lists.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">3. Even though my <a href="http://158.108.0.0/16" target="_blank">158.108.0.0/16</a> netblock was ROAed, APNIC did not link me to the ‘reverse’ DNSsec chain:<br>3.1. Why? Because it’s a ‘Historical’ netblock, transferred from ARIN to APNIC epochs ago. So, my ‘domain’ is with NIR (thank god), my ‘netblock’ Whois is now with APNIC, but my ‘reverse’ is still with ARIN.<br>3.2. If I want to hook into the ‘reverse’ DNSsec chain, who do I send my DS key to? APNIC? ARIN?<br>3.2.1. APNIC is not the SOA of 158.in-addr.arpa.<br>3.2.2. I am no longer a ‘client’ of ARIN, the SOA of 158.in-addr.arpa.</div></div></blockquote><div><br></div><div> [1]: <<a href="https://www.arin.net/participate/community/mailing_lists/">https://www.arin.net/participate/community/mailing_lists/</a>></div></div></div>