Folks,
I'm sure folks will want to express their outrage about the address sale for months.
In the meantime, let's focus on what we can control. How do we get reverse DNS working again for the part of 44/8 that wasn't sold?
Michael, N6MEF
Dear all,
On Thu, Jul 18, 2019 at 08:39:24PM -0700, Michael Fox - N6MEF wrote:
In the meantime, let's focus on what we can control. How do we get reverse DNS working again for the part of 44/8 that wasn't sold?
I've escalated this issue to contacts within Amazon and asked them to assist, they confirmed they have escalated with ARIN. I assume nobody intended for reverse DNS to become broken for the remaining /10 and /9.
I think the right people are now looking into it, and I hope this will be resolved shortly.
Kind regards,
Job
Thanks Joe.MichaelSent from my Verizon, Samsung Galaxy smartphone -------- Original message --------From: Job Snijders job@ntt.net Date: 7/18/19 21:54 (GMT-08:00) To: AMPRNet working group 44net@mailman.ampr.org Subject: Re: [44net] Reverse DNS broken Dear all,On Thu, Jul 18, 2019 at 08:39:24PM -0700, Michael Fox - N6MEF wrote:> In the meantime, let's focus on what we can control. How do we get> reverse DNS working again for the part of 44/8 that wasn't sold?I've escalated this issue to contacts within Amazon and asked them toassist, they confirmed they have escalated with ARIN. I assume nobodyintended for reverse DNS to become broken for the remaining /10 and /9.I think the right people are now looking into it, and I hope this willbe resolved shortly.Kind regards,Job_________________________________________44Net mailing list44Net@mailman.ampr.orghttps://mailman.ampr.org/mailman/listinfo/44net
On 7/19/19 12:54 AM, Job Snijders wrote:
I've escalated this issue to contacts within Amazon and asked them to assist, they confirmed they have escalated with ARIN. I assume nobody intended for reverse DNS to become broken for the remaining /10 and /9.
Well, on the plus side, we know about it now.
It needs to be fixed ASAP, but like many things (everything) at ARDC, it's a black hole how it works.
To help speed up the resolution process, it would be beneficial if someone provides me with data what exactly is broken, and what the values / parameters previously were.
was 44.in-addr.arpa. previously delegated to z.arin.net, x.arin.net, and r.arin.net? If not, where was it delegated? Where should it be delegated?
Any tangible data about what the state currently is, and what it should be; will help speed up recovery.
Kind regards,
Job
Some good debugging information was provided to me offlist , I've now been in touch with ARIN staff and some changes were made. It may take a few hours for the changes to be visible on the Internet, new zone file needs to be generated & pushed out.
My initial assessment is that the delegations for the remaining /10 and /9 towards AMPRnet DNS servers didnt exist. I don't know whose responsiblity it would've been to ensure that existed. I can't guess why they were missing, perhaps a coordination issue in the transfer process from the previous state to the current state.
The AMPRnet reverse DNS administators may want to verify that the authoritative dns servers are configured not for for 44.in-addr.arpa, but for the individual /16s within 44/8 that still are AMPRnet. I don't know who manages that so I hope this message finds them.
I'm running on fumes and only have 4 hours of sleep opportunity ahead of me - so signing off, I think things will probably restore in the next few hours.
Good luck!
Job
On Fri, Jul 19, 2019 at 05:27:27AM +0000, Job Snijders wrote:
To help speed up the resolution process, it would be beneficial if someone provides me with data what exactly is broken, and what the values / parameters previously were.
was 44.in-addr.arpa. previously delegated to z.arin.net, x.arin.net, and r.arin.net? If not, where was it delegated? Where should it be delegated?
Any tangible data about what the state currently is, and what it should be; will help speed up recovery.
Kind regards,
Job
quick follow-up, the reverse dns zone file generation will probably take place at 04:00 Eastern (in 1 hour and 20 min), or sooner. From that moment on it'll either work, or at least be within control of amprnet's reverse dns people.
On Fri, Jul 19, 2019 at 6:37 AM Job Snijders job@ntt.net wrote:
Some good debugging information was provided to me offlist , I've now been in touch with ARIN staff and some changes were made. It may take a few hours for the changes to be visible on the Internet, new zone file needs to be generated & pushed out.
My initial assessment is that the delegations for the remaining /10 and /9 towards AMPRnet DNS servers didnt exist. I don't know whose responsiblity it would've been to ensure that existed. I can't guess why they were missing, perhaps a coordination issue in the transfer process from the previous state to the current state.
The AMPRnet reverse DNS administators may want to verify that the authoritative dns servers are configured not for for 44.in-addr.arpa, but for the individual /16s within 44/8 that still are AMPRnet. I don't know who manages that so I hope this message finds them.
I'm running on fumes and only have 4 hours of sleep opportunity ahead of me - so signing off, I think things will probably restore in the next few hours.
Good luck!
Job
On Fri, Jul 19, 2019 at 05:27:27AM +0000, Job Snijders wrote:
To help speed up the resolution process, it would be beneficial if someone provides me with data what exactly is broken, and what the values / parameters previously were.
was 44.in-addr.arpa. previously delegated to z.arin.net, x.arin.net, and r.arin.net? If not, where was it delegated? Where should it be delegated?
Any tangible data about what the state currently is, and what it should be; will help speed up recovery.
Kind regards,
Job
I think this is resolved now.
On Fri, Jul 19, 2019 at 02:37 Job Snijders job@ntt.net wrote:
Some good debugging information was provided to me offlist , I've now been in touch with ARIN staff and some changes were made. It may take a few hours for the changes to be visible on the Internet, new zone file needs to be generated & pushed out.
My initial assessment is that the delegations for the remaining /10 and /9 towards AMPRnet DNS servers didnt exist. I don't know whose responsiblity it would've been to ensure that existed. I can't guess why they were missing, perhaps a coordination issue in the transfer process from the previous state to the current state.
The AMPRnet reverse DNS administators may want to verify that the authoritative dns servers are configured not for for 44.in-addr.arpa, but for the individual /16s within 44/8 that still are AMPRnet. I don't know who manages that so I hope this message finds them.
I'm running on fumes and only have 4 hours of sleep opportunity ahead of me - so signing off, I think things will probably restore in the next few hours.
Good luck!
Job
On Fri, Jul 19, 2019 at 05:27:27AM +0000, Job Snijders wrote:
To help speed up the resolution process, it would be beneficial if someone provides me with data what exactly is broken, and what the values / parameters previously were.
was 44.in-addr.arpa. previously delegated to z.arin.net, x.arin.net, and r.arin.net? If not, where was it delegated? Where should it be delegated?
Any tangible data about what the state currently is, and what it should be; will help speed up recovery.
Kind regards,
Job
Thanks for sorting this out Job, much appreciated.
On Fri, Jul 19, 2019 at 1:07 PM Job Snijders job@ntt.net wrote:
I think this is resolved now.
On Fri, Jul 19, 2019 at 02:37 Job Snijders job@ntt.net wrote:
Some good debugging information was provided to me offlist , I've now been in touch with ARIN staff and some changes were made. It may take a few hours for the changes to be visible on the Internet, new zone file needs to be generated & pushed out.
My initial assessment is that the delegations for the remaining /10 and /9 towards AMPRnet DNS servers didnt exist. I don't know whose responsiblity it would've been to ensure that existed. I can't guess why they were missing, perhaps a coordination issue in the transfer process from the previous state to the current state.
The AMPRnet reverse DNS administators may want to verify that the authoritative dns servers are configured not for for 44.in-addr.arpa, but for the individual /16s within 44/8 that still are AMPRnet. I don't know who manages that so I hope this message finds them.
I'm running on fumes and only have 4 hours of sleep opportunity ahead of me - so signing off, I think things will probably restore in the next few hours.
Good luck!
Job
On Fri, Jul 19, 2019 at 05:27:27AM +0000, Job Snijders wrote:
To help speed up the resolution process, it would be beneficial if someone provides me with data what exactly is broken, and what the values / parameters previously were.
was 44.in-addr.arpa. previously delegated to z.arin.net, x.arin.net,
and
r.arin.net? If not, where was it delegated? Where should it be delegated?
Any tangible data about what the state currently is, and what it should be; will help speed up recovery.
Kind regards,
Job
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Seems 44.25.0.0/16 is still broken. It was previously delegated to [abc]. ns.hamwan.net.
Tom KD7LXL
On Fri, Jul 19, 2019, 05:07 Job Snijders job@ntt.net wrote:
I think this is resolved now.
On Fri, Jul 19, 2019 at 02:37 Job Snijders job@ntt.net wrote:
Some good debugging information was provided to me offlist , I've now been in touch with ARIN staff and some changes were made. It may take a few hours for the changes to be visible on the Internet, new zone file needs to be generated & pushed out.
My initial assessment is that the delegations for the remaining /10 and /9 towards AMPRnet DNS servers didnt exist. I don't know whose responsiblity it would've been to ensure that existed. I can't guess why they were missing, perhaps a coordination issue in the transfer process from the previous state to the current state.
The AMPRnet reverse DNS administators may want to verify that the authoritative dns servers are configured not for for 44.in-addr.arpa, but for the individual /16s within 44/8 that still are AMPRnet. I don't know who manages that so I hope this message finds them.
I'm running on fumes and only have 4 hours of sleep opportunity ahead of me - so signing off, I think things will probably restore in the next few hours.
Good luck!
Job
On Fri, Jul 19, 2019 at 05:27:27AM +0000, Job Snijders wrote:
To help speed up the resolution process, it would be beneficial if someone provides me with data what exactly is broken, and what the values / parameters previously were.
was 44.in-addr.arpa. previously delegated to z.arin.net, x.arin.net,
and
r.arin.net? If not, where was it delegated? Where should it be delegated?
Any tangible data about what the state currently is, and what it should be; will help speed up recovery.
Kind regards,
Job
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
-
Alistair Mackenzie -
Bryan Fields -
Job Snijders -
Michael Fox -
Michael Fox - N6MEF
-
Tom Hayward