[dns-operations] [Ext] Re: Is this DNS Flag Day 2020 including 'in-addr.arpa.' and 'ip6.arpa.' clean-up?

[Mark Andrews]

> On 20 Feb 2020, at 03:36, Pirawat WATANAPONGSE <pirawat.w at 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.lewis at 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-bounces at dns-oarc.net on behalf of ondrej at 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ý <ondrej at sury.org>
> 
> 
> 
> 
> On 14 Feb 2020, at 18:22, Pirawat WATANAPONGSE <pirawat.w at 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: Pirawat.W at ku.th or Pirawat.W at 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 at 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: Pirawat.W at ku.th or Pirawat.W at 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 at 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: marka at isc.org