19 Jul
2019
19 Jul
'19
4:39 a.m.
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
19 Jul
19 Jul
5:54 a.m.
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
5:59 a.m.
Thanks Joe.MichaelSent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------From: Job Snijders <job(a)ntt.net> Date: 7/18/19
21:54 (GMT-08:00) To: AMPRNet working group <44net(a)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
6:02 a.m.
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.
--
Bryan Fields
727-409-1194 - Voice
http://bryanfields.net
6:27 a.m.
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
7:37 a.m.
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
7:42 a.m.
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(a)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
1:05 p.m.
I think this is resolved now.
On Fri, Jul 19, 2019 at 02:37 Job Snijders <job(a)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
1:48 p.m.
Thanks for sorting this out Job, much appreciated.
On Fri, Jul 19, 2019 at 1:07 PM Job Snijders <job(a)ntt.net> wrote:
I think this is resolved now.
On Fri, Jul 19, 2019 at 02:37 Job Snijders <job(a)ntt.net> wrote:
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
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
3:38 p.m.
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(a)ntt.net> wrote:
I think this is resolved now.
On Fri, Jul 19, 2019 at 02:37 Job Snijders <job(a)ntt.net> wrote:
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
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
1965
days inactive
1965
days old
9 comments
6 participants
participants (6)
-
Alistair Mackenzie -
Bryan Fields -
Job Snijders -
Michael Fox -
Michael Fox - N6MEF
-
Tom Hayward