> On 20 Feb 2020, at 03:36, Pirawat WATANAPONGSE <pirawa...@ku.th> wrote: > > Well, let’s look at the real netblock, shall we? (‘cause I have nothing to > hide) > You can see for yourself at https://dnsviz.net/d/108.158.in-addr.arpa/dnssec/ > > 1. There are old DS keys from .arpa to in-addr.arpa still dangling around.
Which, while messy, doesn’t cause operational problems to validators. > 2. 158.in-addr.arpa is still using ‘Algorithm 5’ > 3. Even though my 158.108.0.0/16 netblock was ROAed, APNIC did not link me to > the ‘reverse’ DNSsec chain: ROAs are orthogonal to DNSSEC. Nobody in the world had DNSSEC records changed because a ROA for address space was issued. > 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. > 3.2. If I want to hook into the ‘reverse’ DNSsec chain, who do I send my DS > key to? APNIC? ARIN? > 3.2.1. APNIC is not the SOA of 158.in-addr.arpa. > 3.2.2. I am no longer a ‘client’ of ARIN, the SOA of 158.in-addr.arpa. Who do you submit your NS records to update your delegation? The DS records go to EXACTLY the same entity. In this case it is APNIC. The RIR’s send blobs of RRsets to each other to handle cross region delegations like this. They can send DS records just as easily as they send NS records. > Shall we move on to another netblock? > > > Pirawat. > > > On Wed, Feb 19, 2020 at 10:25 PM Edward Lewis <edward.le...@icann.org> wrote: > I've been doing some examinations of ip6.arpa and in-addr.arpa as part of > other work and I'd say they are pretty darn clean as they are. So I (too) am > curious what would be needed as part of a "Flag Day" level clean up. > > > > I'm looking at the delegation information in the two zones and the > information at the zones they delegate. As far as delegations from those > zones to RIR run zones, I'd say they are perfect. For a while there were two > zones with misaligned NS sets, but they were "fixed" rather speedily last > week. (There's no glue in the zones.) > > > > What I mean by "delegations from those zones to RIR run zones" means that > there are a few delegations from ip6.arpa and in-addr.arpa that go to > non-RIRs or are "special" (like 10.in-addr.arpa). Of those, there are some > hiccups but that is something that is best handled by addressing the > individual situation. I don't see a "Flag Day" level concern - thus my > curiosity above. > > > > On 2/14/20, 2:24 PM, "dns-operations on behalf of Ondřej Surý" > <dns-operations-boun...@dns-oarc.net on behalf of ond...@sury.org> wrote: > > > > Hi, > > > > the DNS Flag Days initiative focus on protocol issues, and neither forward or > reverse zones are in the focus. > > > > If you have anything specific you could bring this up here. How is the .arpa > neglected? > > Ondrej > > -- > > Ondřej Surý <ond...@sury.org> > > > > > On 14 Feb 2020, at 18:22, Pirawat WATANAPONGSE <pirawa...@ku.th> wrote: > > > If you think my topic is irrelevant to DNS Flag Day 2020, or if someone has > already mentioned it, I do apologize. > > My reasoning is that the campaign is lopsided; we are focusing on the > ‘forward’ zones (because those are our children, bear our names, and we like > to brag), but the 2 huge ‘reverse’ zones are neglected (because they are the > bastard children). > > Anyone plans to clean up the ‘in-addr.arpa.’ and ‘ip6.arpa.’ this upcoming > Flag Day? Or it is not a priority (just yet) at this moment? > > By the way, do not confuse properly scaffolding the (reverse) zones from > populating them; from my point of view, they are separate issues. Even if you > are ever going to put just one PTR into it, a properly secured, hierarchized, > delegated (reverse) zone is still crucial. > > > My two cents’ worth, > > Pirawat. > > > > -- > > _/_/ _/_/ _/_/ _/_/ Assist.Prof. Pirawat WATANAPONGSE, > Ph.D. > > _/_/ _/_/ _/_/ _/_/ Department of Computer Engineering > > _/_/ _/_/ _/_/ _/_/ Kasetsart University, Bangkhen (Main) > Campus > > _/_/_/_/ _/_/ _/_/ Bangkok 10900, THAILAND > > _/_/_/_/ _/_/ _/_/ eMail: pirawa...@ku.th or > pirawa...@ku.ac.th > > _/_/ _/_/ _/_/ _/_/ Tel: +66 2 797 0999 extension 1417 > > _/_/ _/_/ _/_/_/_/_/_/ Fax: +66 2 579 6245 > > _/_/ _/_/ _/_/_/_/ http://www.cpe.ku.ac.th/~pw/ > > > > _______________________________________________ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > > > > -- > _/_/ _/_/ _/_/ _/_/ Assist.Prof. Pirawat WATANAPONGSE, > Ph.D. > _/_/ _/_/ _/_/ _/_/ Department of Computer Engineering > _/_/ _/_/ _/_/ _/_/ Kasetsart University, Bangkhen (Main) > Campus > _/_/_/_/ _/_/ _/_/ Bangkok 10900, THAILAND > _/_/_/_/ _/_/ _/_/ eMail: pirawa...@ku.th or > pirawa...@ku.ac.th > _/_/ _/_/ _/_/ _/_/ Tel: +66 2 797 0999 extension 1417 > _/_/ _/_/ _/_/_/_/_/_/ Fax: +66 2 579 6245 > _/_/ _/_/ _/_/_/_/ http://www.cpe.ku.ac.th/~pw/ > > _______________________________________________ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
