RE: difference with caching when connected to telia internet

[Aaron Gould]

Thank you all for your advice and input. I wanted to circle back with you
all on this.

Turns out it was my fault.  Doesn't seem that this was a Telia problem at
all.

What happened was, when I turned up my new 10 gig Telia Internet connection
a few days ago, I needed to balance out my (4) 10 gig internet connections
so I chopped up a /17 into (4) /19's.  When I did this, I was still
advertising the /17 to my local caches, but I was advertising the (4) /19's
, one on each of my (4) 10 gig internet connections.  So the caches out on
the public internet were learning more specific prefixes (longer masks) then
my local caches were learning... so the caches on the internet were being
used instead of my local caches.  Once google and Netflix tech support
helped to make me aware of this, I correctly sent the additional (4) /19's
to my caches and now all is well. 

- Aaron

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[William Herrin]

On Fri, Mar 17, 2017 at 2:31 PM, John Curran  wrote:

> Glad to help (and apologies for the information coming out in pieces –
> we’ve opted to go with updates as we learn more rather than some for
> comprehensive but less timely report.)
>

Also very much appreciated.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

RE: difference with caching when connected to telia internet

[Aaron Gould]

Dang why would they "silently" do that !?  wouldn't that shot holes in my
caching purpose , also I just got off the phone with a Telia net eng in D.C.
, he said he doesn't know anything about why this is happening.

Thanks, I'm advertising more specific prefixes to local Netflix now... but
as I said in another email post.. suddenly one nf cache isn't reachable to
the nf engineer... and both ggc nodes bgp sessions are bouncing.  :|

- Aaron

RE: difference with caching when connected to telia internet

[Aaron Gould]

Yes I did... 

Netflix said, they are rcv'ing same prefixes with lower cost in DFW !!  I
have no idea why.  Netflix told me to advertise shorter prefixes to my local
cluster... I'm doing it now.  And strangely now the Netflix guy lost control
plane to one of my (2) nodes.  Someone is running out to put hands on it

Ggc said, they are rcv'ing more specific routes at other locations!  I have
no idea why this suddenly happened.  Then suddenly BOTH of my ggc node
cluster bgp sessions are bouncing !

I don't touch these caches, hardly ever... suddenly all this :|

-Aaron

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[John Curran]

On 17 Mar 2017, at 2:17 PM, William Herrin  wrote:
> 
> On Fri, Mar 17, 2017 at 2:14 PM, John Curran  wrote:
> 
>> See previous reply.  The data was both correctly formatted and signed,
>> so the agreed integrity checks passed.
>> 
> 
> Ah, okay. So it wasn't bad counts as originally reported but no data with
> counts that confirmed no data. Thanks for the clarification!

Bill - 

Glad to help (and apologies for the information coming out in pieces –
we’ve opted to go with updates as we learn more rather than some for 
comprehensive but less timely report.) 

Thanks!
/John

John Curran
President and CEO
ARIN

Re: difference with caching when connected to telia internet

[Denys Fedoryshchenko]

On 2017-03-17 18:04, Aaron Gould wrote:
Thanks, but James, you would not believe how rapidly the traffic to my 
local
caches drop off, *and* on the same day I brought up my new Telia 
internet
connection.  ...and furthermore, my internet inbound traffic went 
*through

the roof*

-Aaron
Most probably they silently readvertise BGP announces of customers to 
their caches.
Maybe just announce less specific prefixes to Telia, and more specific 
to caches?

Also at least GGC has BGP communities for priorities.

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[William Herrin]

On Fri, Mar 17, 2017 at 2:14 PM, John Curran  wrote:

> See previous reply.  The data was both correctly formatted and signed,
> so the agreed integrity checks passed.
>

Ah, okay. So it wasn't bad counts as originally reported but no data with
counts that confirmed no data. Thanks for the clarification!

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[John Curran]

On 17 Mar 2017, at 2:08 PM, William Herrin  wrote:
> 
> On Fri, Mar 17, 2017 at 1:42 PM, Mark Kosters  wrote:
>> On 3/17/17, 12:26 PM, "NANOG on behalf of William Herrin" <
> nanog-boun...@nanog.org on behalf of b...@herrin.us> wrote:
>>>Hmm. That sounds like an ARIN-side bug too. ARIN's code responded to
>>>corrupted data by zeroing out the data instead of using the last
> known good
>> 
>> there were no bugs in ARIN’s software in regards to this issue. We
> followed exactly what RIPE told us to do.
> 
> Hi Mark,
> 
> That shot my eyebrow up. You misspoke here, right? There's no bug -solely
> because- you did what the design said to do? The design calls for some
> self-check information and it's not a critical design bug to zero-out the
> publish if the self-check fails?

Bill - 

See previous reply.  The data was both correctly formatted and signed, 
so the agreed integrity checks passed. 

Thanks,
/John

John Curran
President and CEO
ARIN

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[John Curran]

On 17 Mar 2017, at 12:26 PM, William Herrin 
mailto:b...@herrin.us>> wrote:

On Fri, Mar 17, 2017 at 7:52 AM, Romeo Zwart 
mailto:rz%2b...@zwart.com>> wrote:
> RIPE NCC have issued a statement about the issue here:
>
>  https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html
>
> Our apologies for the inconvenience caused.

Hmm. That sounds like an ARIN-side bug too. ARIN's code responded to corrupted 
data by zeroing out the data instead of using the last known good data. That's 
awfully brittle for such a critical service.

Agreed in principle - receiving incorrect data (improperly formatted, 
corrupted, or not properly signed)
should result in appropriate notice and no change to the running system.  This 
is actually the case with
ARIN’s systems.

However, we received a properly formatted and signed zonelet file, albeit one 
which contained zero
records.   APNIC also received similar correctly formatted/signed zonelet files 
as a record of the RIPE
bug, and the three RIRs have been working closely together to get the correct 
RIPE data loaded back
into our authoritative DNS systems.

Thanks!
/John

John Curran
President and CEO
ARIN

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[Mark Kosters]

On 3/17/17, 12:26 PM, "NANOG on behalf of William Herrin" 
 wrote:

On Fri, Mar 17, 2017 at 7:52 AM, Romeo Zwart  wrote:
> RIPE NCC have issued a statement about the issue here:
>
>  https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html
>
> Our apologies for the inconvenience caused.

Hmm. That sounds like an ARIN-side bug too. ARIN's code responded to
corrupted data by zeroing out the data instead of using the last known good
data. That's awfully brittle for such a critical service.

Regards,
Bill Herrin
  

Hi Bill,

The analysis was not yet complete when the notice went out from RIPE. After 
doing a post-mortum, there were no bugs in ARIN’s software in regards to this 
issue. We followed exactly what RIPE told us to do. When we noticed an issue 
with RIPE’s updates yesterday, we notified them as well.

Two zones managed by APNIC that received delegations from RIPE were also 
affected by RIPE’s bug – it was more than just a RIPE/ARIN thing.

The three impacted RIR’s have been working closely together to get RIPE’s DNS 
entries correctly added into our respective authoritative DNS systems.

Thanks,
Mark
ARIN CTO
 

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[William Herrin]

On Fri, Mar 17, 2017 at 1:42 PM, Mark Kosters  wrote:
> On 3/17/17, 12:26 PM, "NANOG on behalf of William Herrin" <
nanog-boun...@nanog.org on behalf of b...@herrin.us> wrote:
>> Hmm. That sounds like an ARIN-side bug too. ARIN's code responded to
>> corrupted data by zeroing out the data instead of using the last
known good
>
> there were no bugs in ARIN’s software in regards to this issue. We
followed exactly what RIPE told us to do.

Hi Mark,

That shot my eyebrow up. You misspoke here, right? There's no bug -solely
because- you did what the design said to do? The design calls for some
self-check information and it's not a critical design bug to zero-out the
publish if the self-check fails?

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG,
MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 18 Mar, 2017

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  638006
Prefixes after maximum aggregation (per Origin AS):  249297
Deaggregation factor:  2.56
Unique aggregates announced (without unneeded subnets):  308468
Total ASes present in the Internet Routing Table: 56540
Prefixes per ASN: 11.28
Origin-only ASes present in the Internet Routing Table:   48937
Origin ASes announcing only one prefix:   21715
Transit ASes present in the Internet Routing Table:7603
Transit-only ASes present in the Internet Routing Table:215
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  41
Max AS path prepend of ASN ( 55644)  36
Prefixes from unregistered ASNs in the Routing Table:72
Numnber of instances of unregistered ASNs:   73
Number of 32-bit ASNs allocated by the RIRs:  17731
Number of 32-bit ASNs visible in the Routing Table:   13780
Prefixes from 32-bit ASNs in the Routing Table:   55776
Number of bogon 32-bit ASNs visible in the Routing Table:46
Special use prefixes present in the Routing Table:2
Prefixes being announced from unallocated address space:411
Number of addresses announced to Internet:   2837968708
Equivalent to 169 /8s, 39 /16s and 247 /24s
Percentage of available address space announced:   76.7
Percentage of allocated address space announced:   76.7
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.5
Total number of prefixes smaller than registry allocations:  211466

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   175063
Total APNIC prefixes after maximum aggregation:   50204
APNIC Deaggregation factor:3.49
Prefixes being announced from the APNIC address blocks:  174394
Unique aggregates announced from the APNIC address blocks:71975
APNIC Region origin ASes present in the Internet Routing Table:7931
APNIC Prefixes per ASN:   21.99
APNIC Region origin ASes announcing only one prefix:   2219
APNIC Region transit ASes present in the Internet Routing Table:   1134
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 41
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2770
Number of APNIC addresses announced to Internet:  761082244
Equivalent to 45 /8s, 93 /16s and 49 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-137529
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:194687
Total ARIN prefixes after maximum aggregation:93337
ARIN Deaggregation factor: 2.09
Prefixes being announced from the ARIN address blocks:   197063
Unique aggregates announced from the ARIN address blocks: 90389
ARIN Region origin ASes present in the Internet Routing Table:17842
ARIN Prefixes per ASN:11.04
ARIN Region or

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[George William Herbert]

> On Mar 17, 2017, at 10:28 AM, valdis.kletni...@vt.edu wrote:
> 
> On Fri, 17 Mar 2017 17:42:11 +0100, Bjørn Mork said:
>> Well, it was a nice smoke test of the "RDNS required" anti-feature.  All
>> of a sudden we couldn't even send email to ourselves, having smarthosts
>> in one of the affected zones. Nice.
> 
> If you don't have a chaos monkey, the Internet will provide one free of 
> charge.

Or to a service partner or underlying infrastructure you rely on.

Isn't complexity grand...


-george

Sent from my iPhone

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[valdis . kletnieks]

On Fri, 17 Mar 2017 17:42:11 +0100, Bjørn Mork said:
> Well, it was a nice smoke test of the "RDNS required" anti-feature.  All
> of a sudden we couldn't even send email to ourselves, having smarthosts
> in one of the affected zones. Nice.

If you don't have a chaos monkey, the Internet will provide one free of charge.



pgpQlswegClVA.pgp
Description: PGP signature

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[Jared Mauch]

On Fri, Mar 17, 2017 at 05:42:11PM +0100, Bjørn Mork wrote:
> William Herrin  writes:
> > On Fri, Mar 17, 2017 at 7:52 AM, Romeo Zwart  wrote:
> >> RIPE NCC have issued a statement about the issue here:
> >>
> >>  https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html
> >>
> >> Our apologies for the inconvenience caused.
> >
> > Hmm. That sounds like an ARIN-side bug too. ARIN's code responded to
> > corrupted data by zeroing out the data instead of using the last known good
> > data. That's awfully brittle for such a critical service.
> 
> Well, it was a nice smoke test of the "RDNS required" anti-feature.  All
> of a sudden we couldn't even send email to ourselves, having smarthosts
> in one of the affected zones. Nice.
> 
> Maybe time to re-evaluate the usefulness of that config...

or proper whitelisting of your own infrastructure :-)

- Jared

-- 
Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[Bjørn Mork]

William Herrin  writes:
> On Fri, Mar 17, 2017 at 7:52 AM, Romeo Zwart  wrote:
>> RIPE NCC have issued a statement about the issue here:
>>
>>  https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html
>>
>> Our apologies for the inconvenience caused.
>
> Hmm. That sounds like an ARIN-side bug too. ARIN's code responded to
> corrupted data by zeroing out the data instead of using the last known good
> data. That's awfully brittle for such a critical service.

Well, it was a nice smoke test of the "RDNS required" anti-feature.  All
of a sudden we couldn't even send email to ourselves, having smarthosts
in one of the affected zones. Nice.

Maybe time to re-evaluate the usefulness of that config...



Bjørn

Re: any issue with Centurylink yesterday

[Ken Matlock]

Yeah, it sounds like it. ICMP echo/echo reply was working end-to-end, but
it's possible they were blocking the Type 4 messages somewhere (I didn't
resort to packet captures to get THAT in-depth).

Ken

On Fri, Mar 17, 2017 at 10:15 AM, William Herrin  wrote:

> On Fri, Mar 17, 2017 at 11:39 AM, Ken Matlock 
> wrote:
>
>> I know most of the day yesterday my Centurylink DSL (Denver, CO) I was
>> having odd... issues, but only to some sites, and intermittent. I'd
>> have issues getting content from a URL (but pinging the host would be
>> fine,
>> and manual telnet to TCP/443 would work).
>
>
> Hi Ken,
>
> When I hear those symptoms my brain jumps to path MTU discovery.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Dirtside Systems . Web: 
>

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[William Herrin]

On Fri, Mar 17, 2017 at 7:52 AM, Romeo Zwart  wrote:
> RIPE NCC have issued a statement about the issue here:
>
>  https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html
>
> Our apologies for the inconvenience caused.

Hmm. That sounds like an ARIN-side bug too. ARIN's code responded to
corrupted data by zeroing out the data instead of using the last known good
data. That's awfully brittle for such a critical service.

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: difference with caching when connected to telia internet

[Mike Hammett]

The cache box does need to fill. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Aaron Gould"  
To: "James Breeden" , "NANOG"  
Sent: Friday, March 17, 2017 11:04:48 AM 
Subject: RE: difference with caching when connected to telia internet 

Thanks, but James, you would not believe how rapidly the traffic to my local 
caches drop off, *and* on the same day I brought up my new Telia internet 
connection. ...and furthermore, my internet inbound traffic went *through 
the roof* 

-Aaron 

Re: any issue with Centurylink yesterday

[William Herrin]

On Fri, Mar 17, 2017 at 11:39 AM, Ken Matlock  wrote:

> I know most of the day yesterday my Centurylink DSL (Denver, CO) I was
> having odd... issues, but only to some sites, and intermittent. I'd
> have issues getting content from a URL (but pinging the host would be fine,
> and manual telnet to TCP/443 would work).


Hi Ken,

When I hear those symptoms my brain jumps to path MTU discovery.

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: difference with caching when connected to telia internet

[Niels Bakker]

* aar...@gvtc.com (Aaron Gould) [Fri 17 Mar 2017, 17:05 CET]:
Thanks, but James, you would not believe how rapidly the traffic to 
my local caches drop off, *and* on the same day I brought up my new 
Telia internet connection.  ...and furthermore, my internet inbound 
traffic went *through the roof*


Did you talk to Netflix and to Google's GGC team to confirm that they 
were still directing your customer towards your on-net caches?



-- Niels.

RE: difference with caching when connected to telia internet

[Aaron Gould]

Thanks, but James, you would not believe how rapidly the traffic to my local
caches drop off, *and* on the same day I brought up my new Telia internet
connection.  ...and furthermore, my internet inbound traffic went *through
the roof*

-Aaron

Re: any issue with Centurylink yesterday

[Ken Matlock]

Yeah, not sure that was related, as my issues started earlier in the day
(about 8am-9am Mountain time).

Either way it all seems fine today, no hiccups, no issues. so whatever it
was got resolved.

Ken


On Fri, Mar 17, 2017 at 9:02 AM, Pennington, Scott <
scott.penning...@cinbell.com> wrote:

> There may have been other events, but we were notified of a fiber cut in
> the Nashville area that impacted a few ckts for us around 6:30PM easter.
>
> -Scott
> 
> From: NANOG [nanog-boun...@nanog.org] on behalf of T Kawasaki via NANOG [
> nanog@nanog.org]
> Sent: Friday, March 17, 2017 8:35 AM
> To: NANOG
> Subject: any issue with Centurylink yesterday
>
> Guys,
> Is there any issues with centurylink yesterday? Through out day, peering
> from major iSPs to Centurylink had higher latency yesterday. I looked out
> now, it seems to settle down for now.
>
> Tatsuya
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you receive
> this in error, please contact the sender and destroy any copies of this
> document.
>

Re: any issue with Centurylink yesterday

[Ken Matlock]

I know most of the day yesterday my Centurylink DSL (Denver, CO) I was
having odd... issues, but only to some sites, and intermittent. I'd
have issues getting content from a URL (but pinging the host would be fine,
and manual telnet to TCP/443 would work). Latencies were *slightly* higher
than normal (36ms to a site vs 18ms normal), but I just chalked it up to
'Centurylink' and figured eventually it'd resolve itself.

This morning it all seems well again, so no idea WTF the problem was
(honestly I didn't look at it too much, as I was more motivated to go out
and enjoy the gorgeous weather instead).

Ken


On Fri, Mar 17, 2017 at 6:35 AM, T Kawasaki via NANOG 
wrote:

> Guys,
> Is there any issues with centurylink yesterday? Through out day, peering
> from major iSPs to Centurylink had higher latency yesterday. I looked out
> now, it seems to settle down for now.
>
> Tatsuya
>

RE: any issue with Centurylink yesterday

[Pennington, Scott]

There may have been other events, but we were notified of a fiber cut in the 
Nashville area that impacted a few ckts for us around 6:30PM easter.

-Scott

From: NANOG [nanog-boun...@nanog.org] on behalf of T Kawasaki via NANOG 
[nanog@nanog.org]
Sent: Friday, March 17, 2017 8:35 AM
To: NANOG
Subject: any issue with Centurylink yesterday

Guys,
Is there any issues with centurylink yesterday? Through out day, peering from 
major iSPs to Centurylink had higher latency yesterday. I looked out now, it 
seems to settle down for now.

Tatsuya
The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential and/or privileged material. Any 
review, retransmission, dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you receive this in error, please contact 
the sender and destroy any copies of this document.

RE: difference with caching when connected to telia internet

[James Breeden]

Shouldn't be. It could just be that the content on the cache locally is not 
what the user is requesting. 

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Aaron Gould
Sent: Friday, March 17, 2017 9:59 AM
To: 'NANOG' 
Subject: difference with caching when connected to telia internet

Regarding, caching services like Netflix OCA and Google GGC, does anyone know 
if there is something strange that occurs when connected to Telia BGP
AS1299 ?  .meaning, if I have local Netflix/google caches, and then later I 
establish a BGP session for Internet with Telia/BGP 1299, would there be 
something that would make netflix and google caches reachable via Telia look 
better than my local ones ?!

 

-Aaron

 

difference with caching when connected to telia internet

[Aaron Gould]

Regarding, caching services like Netflix OCA and Google GGC, does anyone
know if there is something strange that occurs when connected to Telia BGP
AS1299 ?  .meaning, if I have local Netflix/google caches, and then later I
establish a BGP session for Internet with Telia/BGP 1299, would there be
something that would make netflix and google caches reachable via Telia look
better than my local ones ?!

 

-Aaron

 

any issue with Centurylink yesterday

[T Kawasaki via NANOG]

Guys, 
Is there any issues with centurylink yesterday? Through out day, peering from 
major iSPs to Centurylink had higher latency yesterday. I looked out now, it 
seems to settle down for now.

Tatsuya

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[Romeo Zwart]

Dear all,

RIPE NCC have issued a statement about the issue here:

 https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html

Our apologies for the inconvenience caused.

Kind regards,
Romeo Zwart
RIPE NCC

On 17/03/17 12:31 , John Curran wrote:
> Eygene - 
> 
>   We are aware there’s an issue and working on it presently with RIPE. 
>   Expect additional updates shortly.
> 
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
>> On 17 Mar 2017, at 11:04 AM, Eygene Ryabinkin  wrote:
>>
>> Job, good day.
>>
>> Fri, Mar 17, 2017 at 09:55:56AM +, Job Snijders wrote:
>>> 171 also seems affected.
>>
>> Not the whole one, it seems:
>> {{{
>> $ dig +trace -t soa 1.171.in-addr.arpa
>>
>> ; <<>> DiG 9.10.4-P6 <<>> +trace -t soa 1.171.in-addr.arpa
>> ;; global options: +cmd
>> .202634  IN  NS  m.root-servers.net.
>> .202634  IN  NS  i.root-servers.net.
>> .202634  IN  NS  k.root-servers.net.
>> .202634  IN  NS  c.root-servers.net.
>> .202634  IN  NS  a.root-servers.net.
>> .202634  IN  NS  d.root-servers.net.
>> .202634  IN  NS  l.root-servers.net.
>> .202634  IN  NS  e.root-servers.net.
>> .202634  IN  NS  g.root-servers.net.
>> .202634  IN  NS  b.root-servers.net.
>> .202634  IN  NS  j.root-servers.net.
>> .202634  IN  NS  h.root-servers.net.
>> .202634  IN  NS  f.root-servers.net.
>> .511016  IN  RRSIG   NS 8 0 518400 2017032917 
>> 2017031616 61045 . 
>> OjsjoA6WCcThV3BqhAyMaXI3bU1m228Gl8nvaR074qBtem/RjaFJh1Oe 
>> r7LPI6W15jgbRGuCY7/GUNgDex4ZM43yvx2iY+2GpSk9b2/pKGbDaDIp 
>> X1Hd8418206eow1P/SgPqtT+2LzjM+lz/HKUvCyPoN4uX5/7GDExn8ir 
>> 2Q/vw81Za2nJ4Ji6oeGAmE8g6V3RJfTI0El/CP9Vl2/r0jWDZZ+wtYRA 
>> uwqvQYj+7VZc5+UJDJ3/Gne1LBnzXKnZRwnfJtZenhfZ7X20D9PiXvfJ 
>> M2s1ryqZvg8K5RqYt/r8pIiq1Udd1KWQBgdN7Q629+jNSngZQtH19R9H fM7h1w==
>> ;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
>>
>> in-addr.arpa.172800  IN  NS  a.in-addr-servers.arpa.
>> in-addr.arpa.172800  IN  NS  b.in-addr-servers.arpa.
>> in-addr.arpa.172800  IN  NS  c.in-addr-servers.arpa.
>> in-addr.arpa.172800  IN  NS  d.in-addr-servers.arpa.
>> in-addr.arpa.172800  IN  NS  e.in-addr-servers.arpa.
>> in-addr.arpa.172800  IN  NS  f.in-addr-servers.arpa.
>> in-addr.arpa.86400   IN  DS  47054 8 2 
>> 5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
>> in-addr.arpa.86400   IN  DS  53696 8 2 
>> 13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
>> in-addr.arpa.86400   IN  DS  63982 8 2 
>> AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
>> in-addr.arpa.86400   IN  RRSIG   DS 8 2 86400 
>> 2017033000 2017031623 33786 arpa. 
>> gqNN6MmLVxFtSG0oxdyoYVSXZlp6vY9yxpnJW89TYCHfTkv+ZmklM76O 
>> IHdTznEhLHXbyr4BaxjFCshsC3WacdH/YZYa/SZynJ9Q1N6/bogrIUTn 
>> qs61Y/YD4Sk5lI7YvUxVnPrF3lk1pY8dpoTkprTLZngoeQEsm552inqG ypU=
>> ;; Received 731 bytes from 193.0.14.129#53(k.root-servers.net) in 41 ms
>>
>> 171.in-addr.arpa.86400   IN  NS  ns1.apnic.net.
>> 171.in-addr.arpa.86400   IN  NS  ns2.lacnic.net.
>> 171.in-addr.arpa.86400   IN  NS  ns3.apnic.net.
>> 171.in-addr.arpa.86400   IN  NS  ns4.apnic.net.
>> 171.in-addr.arpa.86400   IN  NS  apnic.authdns.ripe.net.
>> 171.in-addr.arpa.86400   IN  NS  apnic1.dnsnode.net.
>> 171.in-addr.arpa.86400   IN  NS  tinnie.arin.net.
>> 171.in-addr.arpa.86400   IN  DS  49699 5 1 
>> 0240801C96480900CC6D93130AF45CFE86EDE940
>> 171.in-addr.arpa.86400   IN  DS  49699 5 2 
>> 6E0BA96F05B4D39C1668979731E040213BB6130DE33E86E063B5F7F7 5C465C88
>> 171.in-addr.arpa.86400   IN  RRSIG   DS 8 3 86400 20170330042932 
>> 20170309125911 4341 in-addr.arpa. 
>> RKcPZJdG1MBrwpfa1mIK7ikIU585i1Jv+UkEBHxuM3BxxAbD+ht0W04C 
>> ljboyXJfYK8ly/YTDqNUkWKZLwDHlkq/rgNwTG63sPT8iK8qya+2qUVB 
>> iTXVsD2HaV1V/KwgJjlWHRNnlwkK0YZ5Q7tevXaq4yyLT2Q2mu5dkhFC evNQOyI=
>> ;; Received 482 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 69 
>> ms
>>
>> 171.in-addr.arpa.0   IN  SOA ns1.apnic.net. 
>> read-txt-record-of-zone-first-dns-admin.apnic.net. 5276 7200 1800 604800 
>> 172800
>> 171.in-addr.arpa.0   IN  RRSIG   SOA 5 3 172800 20170416100102 
>> 20170317090102 7858 171.in-addr.arpa. 
>> dH+uuGq9pgMc9TEMkTwrf9NGMj5zFnbZt3kjlNSF0kPzGk3WUr5g84jv 
>> 0SN88Y26eP/Op4Vv8JewyVu2IT1POnmiNpDYELkJxrTWnPPc6CJ2wugR 
>> TrFLOq6eIsqtrCcWbatQ7XSXXj1

Re: ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[Alberto Delgado]

I just receive an answer from RIPE and now its working again:



Dear Alberto,

Our apologies for this. There was a bug in our DNS provisioning system, 
and it temporarily caused some delegations (where the parent zone is 
operated by ARIN) to be removed. The bug has been fixed, and the correct 
data is now being published on the RIPE NCC FTP server. We expect ARIN's 
DNS provisioning system to pick it up shortly, and the delegations will 
be restored.


Regards,
Anand Buddhdev
RIPE NCC



El 2017-03-17 11:49, Alberto Delgado escribió:

Me too.

 We have a 164.138.208.0/22 and we have issues with dns reverse too

 We sent an email to ripe support, but no answer yet


 El 2017-03-17 10:53, Stephane Bortzmeyer escribió:

On Fri, Mar 17, 2017 at 12:03:58PM +0300,
 Eygene Ryabinkin  wrote
 a message of 71 lines which said:


Seems like the other /16 from 144.in-addr.arpa are affected too
(at least).


Also in 164.in-addr.arpa, it seems?

Re: ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[Alberto Delgado]

 Me too.

 We have a 164.138.208.0/22 and we have issues with dns reverse too

 We sent an email to ripe support, but no answer yet


 El 2017-03-17 10:53, Stephane Bortzmeyer escribió:

On Fri, Mar 17, 2017 at 12:03:58PM +0300,
 Eygene Ryabinkin  wrote
 a message of 71 lines which said:


Seems like the other /16 from 144.in-addr.arpa are affected too
(at least).


Also in 164.in-addr.arpa, it seems?

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[John Curran]

Folks -

RIPE NCC has backed out the change at issue, and we are again processing
zonelet files received from them.   They’ve posted more details here -


FYI,
/John

John Curran
President and CEO
ARIN

On 17 Mar 2017, at 12:31 PM, John Curran 
mailto:jcur...@istaff.org>> wrote:

Eygene -

 We are aware there’s an issue and working on it presently with RIPE.
 Expect additional updates shortly.

/John

John Curran
President and CEO
ARIN

On 17 Mar 2017, at 11:04 AM, Eygene Ryabinkin 
mailto:rea+na...@grid.kiae.ru>> wrote:

Job, good day.

Fri, Mar 17, 2017 at 09:55:56AM +, Job Snijders wrote:
171 also seems affected.

Not the whole one, it seems:
{{{
$ dig +trace -t soa 1.171.in-addr.arpa

; <<>> DiG 9.10.4-P6 <<>> +trace -t soa 1.171.in-addr.arpa
;; global options: +cmd
. 202634 IN NS m.root-servers.net.
. 202634 IN NS i.root-servers.net.
. 202634 IN NS k.root-servers.net.
. 202634 IN NS c.root-servers.net.
. 202634 IN NS a.root-servers.net.
. 202634 IN NS d.root-servers.net.
. 202634 IN NS l.root-servers.net.
. 202634 IN NS e.root-servers.net.
. 202634 IN NS g.root-servers.net.
. 202634 IN NS b.root-servers.net.
. 202634 IN NS j.root-servers.net.
. 202634 IN NS h.root-servers.net.
. 202634 IN NS f.root-servers.net.
. 511016 IN RRSIG NS 8 0 518400 2017032917 2017031616 61045 . 
OjsjoA6WCcThV3BqhAyMaXI3bU1m228Gl8nvaR074qBtem/RjaFJh1Oe 
r7LPI6W15jgbRGuCY7/GUNgDex4ZM43yvx2iY+2GpSk9b2/pKGbDaDIp 
X1Hd8418206eow1P/SgPqtT+2LzjM+lz/HKUvCyPoN4uX5/7GDExn8ir 
2Q/vw81Za2nJ4Ji6oeGAmE8g6V3RJfTI0El/CP9Vl2/r0jWDZZ+wtYRA 
uwqvQYj+7VZc5+UJDJ3/Gne1LBnzXKnZRwnfJtZenhfZ7X20D9PiXvfJ 
M2s1ryqZvg8K5RqYt/r8pIiq1Udd1KWQBgdN7Q629+jNSngZQtH19R9H fM7h1w==
;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa.
in-addr.arpa. 86400 IN DS 47054 8 2 
5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
in-addr.arpa. 86400 IN DS 53696 8 2 
13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
in-addr.arpa. 86400 IN DS 63982 8 2 
AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
in-addr.arpa. 86400 IN RRSIG DS 8 2 86400 2017033000 2017031623 33786 
arpa. gqNN6MmLVxFtSG0oxdyoYVSXZlp6vY9yxpnJW89TYCHfTkv+ZmklM76O 
IHdTznEhLHXbyr4BaxjFCshsC3WacdH/YZYa/SZynJ9Q1N6/bogrIUTn 
qs61Y/YD4Sk5lI7YvUxVnPrF3lk1pY8dpoTkprTLZngoeQEsm552inqG ypU=
;; Received 731 bytes from 
193.0.14.129#53(k.root-servers.net) in 41 ms

171.in-addr.arpa. 86400 IN NS ns1.apnic.net.
171.in-addr.arpa. 86400 IN NS ns2.lacnic.net.
171.in-addr.arpa. 86400 IN NS ns3.apnic.net.
171.in-addr.arpa. 86400 IN NS ns4.apnic.net.
171.in-addr.arpa. 86400 IN NS 
apnic.authdns.ripe.net.
171.in-addr.arpa. 86400 IN NS apnic1.dnsnode.net.
171.in-addr.arpa. 86400 IN NS tinnie.arin.net.
171.in-addr.arpa. 86400 IN DS 49699 5 1 0240801C96480900CC6D93130AF45CFE86EDE940
171.in-addr.arpa. 86400 IN DS 49699 5 2 
6E0BA96F05B4D39C1668979731E040213BB6130DE33E86E063B5F7F7 5C465C88
171.in-addr.arpa. 86400 IN RRSIG DS 8 3 86400 20170330042932 20170309125911 
4341 in-addr.arpa. RKcPZJdG1MBrwpfa1mIK7ikIU585i1Jv+UkEBHxuM3BxxAbD+ht0W04C 
ljboyXJfYK8ly/YTDqNUkWKZLwDHlkq/rgNwTG63sPT8iK8qya+2qUVB 
iTXVsD2HaV1V/KwgJjlWHRNnlwkK0YZ5Q7tevXaq4yyLT2Q2mu5dkhFC evNQOyI=
;; Received 482 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 69 ms

171.in-addr.arpa. 0 IN SOA ns1.apnic.net. 
read-txt-record-of-zone-first-dns-admin.apnic.net.
 5276 7200 1800 604800 172800
171.in-addr.arpa. 0 IN RRSIG SOA 5 3 172800 20170416100102 20170317090102 7858 
171.in-addr.arpa. dH+uuGq9pgMc9TEMkTwrf9NGMj5zFnbZt3kjlNSF0kPzGk3WUr5g84jv 
0SN88Y26eP/Op4Vv8JewyVu2IT1POnmiNpDYELkJxrTWnPPc6CJ2wugR 
TrFLOq6eIsqtrCcWbatQ7XSXXj1UglqVVydlX1ExoIh9MdP+1eBneD1I 4OU=
171.in-addr.arpa. 172800 IN NSEC 10.171.in-addr.arpa. NS SOA TXT RRSIG NSEC 
DNSKEY
171.in-addr.arpa. 172800 IN RRSIG NSEC 5 3 172800 20170416100102 20170317090102 
7858 171.in-addr.arpa. QieHZ0W7jx3QCgLuvqtKtFoLPYkxn5R9nRO1oMbSSXkdF+S4iQQkVlX7 
DyQvoL69hKA+S9idfernf6DwNTQgeWFfCdjUyOjMCa3Ag/S8ARZs7K4F 
N9DxB/cBCZm7KTzwAzXFe3cJ/d1Wo45Tx9jf

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[Eygene Ryabinkin]

John, Alex, Romeo,

Fri, Mar 17, 2017 at 12:31:06PM +0100, John Curran wrote:
>   We are aware there’s an issue and working on it presently with RIPE. 
>   Expect additional updates shortly.

Fri, Mar 17, 2017 at 12:50:48PM +0100, Alex Band wrote:
> You can find a detailed announcement from the RIPE NCC here:
> https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html 
> 

Fri, Mar 17, 2017 at 12:52:10PM +0100, Romeo Zwart wrote:
> RIPE NCC have issued a statement about the issue here:
> 
>  https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html
> 
> Our apologies for the inconvenience caused.

Thanks for your work: the issue seem to be fixed.  I am trying to
verify if everything works as expected, there are some neats,
{{{
206.144.in-addr.arpa.   172800  IN  NS  ns1.rrcki.ru.
206.144.in-addr.arpa.   172800  IN  NS  ns.kiae.ru.
206.144.in-addr.arpa.   172800  IN  NS  ns3.rrcki.ru.
206.144.in-addr.arpa.   172800  IN  NS  ns2.grid.kiae.ru.
206.144.in-addr.arpa.   172800  IN  NS  ns.grid.kiae.ru.
206.144.in-addr.arpa.   10800   IN  NSEC207.144.in-addr.arpa. NS RRSIG 
NSEC
206.144.in-addr.arpa.   10800   IN  RRSIG   NSEC 5 4 10800 20170331110430 
20170317100430 33345 144.in-addr.arpa. vbFwaKdRa7Jd70aAbJ
5mC37BsTzMg3nWVI5gqQLLOqSaCZfH0XUez+Uk 
MbTNvepziCRzH+HgSLabuvRSo4nIUP1SjOd2WX0wySSdb/blqhfmjw3l 
n8laqOxy/lj8TDiIuxOdw2JhM1v5x/DH4aDnwdGFfUEOdgzCU5k8LdAT oyA=   

  ;; Received 373 bytes from 199.180.180.63#53(r.arin.net) in 198 ms

;; Question section mismatch: got 206.144.0.0.in-addr.arpa/PTR/IN
;; Question section mismatch: got 206.144.0.0.in-addr.arpa/PTR/IN
206.144.in-addr.arpa.   3600IN  SOA ns.kiae.ru. noc.rrcki.ru. 
2017020803 10800 3600 180 3600
;; Received 105 bytes from 144.206.239.1#53(ns.grid.kiae.ru) in 0 ms
}}}
about question mismatch, though my guts feel that this is the local
issue at rrcki.ru.

Thanks again!  And for a nicely-written summary -- too.
-- 
Eygene Ryabinkin, National Research Centre "Kurchatov Institute"

Always code as if the guy who ends up maintaining your code will be
a violent psychopath who knows where you live.

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[Alex Band]

You can find a detailed announcement from the RIPE NCC here:
https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html 


-Alex Band

> On 17 Mar 2017, at 12:31, John Curran  wrote:
> 
> Eygene - 
> 
>  We are aware there’s an issue and working on it presently with RIPE. 
>  Expect additional updates shortly.
> 
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
>> On 17 Mar 2017, at 11:04 AM, Eygene Ryabinkin  wrote:
>> 
>> Job, good day.
>> 
>> Fri, Mar 17, 2017 at 09:55:56AM +, Job Snijders wrote:
>>> 171 also seems affected.
>> 
>> Not the whole one, it seems:
>> {{{
>> $ dig +trace -t soa 1.171.in-addr.arpa
>> 
>> ; <<>> DiG 9.10.4-P6 <<>> +trace -t soa 1.171.in-addr.arpa
>> ;; global options: +cmd
>> .202634  IN  NS  m.root-servers.net.
>> .202634  IN  NS  i.root-servers.net.
>> .202634  IN  NS  k.root-servers.net.
>> .202634  IN  NS  c.root-servers.net.
>> .202634  IN  NS  a.root-servers.net.
>> .202634  IN  NS  d.root-servers.net.
>> .202634  IN  NS  l.root-servers.net.
>> .202634  IN  NS  e.root-servers.net.
>> .202634  IN  NS  g.root-servers.net.
>> .202634  IN  NS  b.root-servers.net.
>> .202634  IN  NS  j.root-servers.net.
>> .202634  IN  NS  h.root-servers.net.
>> .202634  IN  NS  f.root-servers.net.
>> .511016  IN  RRSIG   NS 8 0 518400 2017032917 
>> 2017031616 61045 . 
>> OjsjoA6WCcThV3BqhAyMaXI3bU1m228Gl8nvaR074qBtem/RjaFJh1Oe 
>> r7LPI6W15jgbRGuCY7/GUNgDex4ZM43yvx2iY+2GpSk9b2/pKGbDaDIp 
>> X1Hd8418206eow1P/SgPqtT+2LzjM+lz/HKUvCyPoN4uX5/7GDExn8ir 
>> 2Q/vw81Za2nJ4Ji6oeGAmE8g6V3RJfTI0El/CP9Vl2/r0jWDZZ+wtYRA 
>> uwqvQYj+7VZc5+UJDJ3/Gne1LBnzXKnZRwnfJtZenhfZ7X20D9PiXvfJ 
>> M2s1ryqZvg8K5RqYt/r8pIiq1Udd1KWQBgdN7Q629+jNSngZQtH19R9H fM7h1w==
>> ;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
>> 
>> in-addr.arpa.172800  IN  NS  a.in-addr-servers.arpa.
>> in-addr.arpa.172800  IN  NS  b.in-addr-servers.arpa.
>> in-addr.arpa.172800  IN  NS  c.in-addr-servers.arpa.
>> in-addr.arpa.172800  IN  NS  d.in-addr-servers.arpa.
>> in-addr.arpa.172800  IN  NS  e.in-addr-servers.arpa.
>> in-addr.arpa.172800  IN  NS  f.in-addr-servers.arpa.
>> in-addr.arpa.86400   IN  DS  47054 8 2 
>> 5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
>> in-addr.arpa.86400   IN  DS  53696 8 2 
>> 13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
>> in-addr.arpa.86400   IN  DS  63982 8 2 
>> AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
>> in-addr.arpa.86400   IN  RRSIG   DS 8 2 86400 
>> 2017033000 2017031623 33786 arpa. 
>> gqNN6MmLVxFtSG0oxdyoYVSXZlp6vY9yxpnJW89TYCHfTkv+ZmklM76O 
>> IHdTznEhLHXbyr4BaxjFCshsC3WacdH/YZYa/SZynJ9Q1N6/bogrIUTn 
>> qs61Y/YD4Sk5lI7YvUxVnPrF3lk1pY8dpoTkprTLZngoeQEsm552inqG ypU=
>> ;; Received 731 bytes from 193.0.14.129#53(k.root-servers.net) in 41 ms
>> 
>> 171.in-addr.arpa.86400   IN  NS  ns1.apnic.net.
>> 171.in-addr.arpa.86400   IN  NS  ns2.lacnic.net.
>> 171.in-addr.arpa.86400   IN  NS  ns3.apnic.net.
>> 171.in-addr.arpa.86400   IN  NS  ns4.apnic.net.
>> 171.in-addr.arpa.86400   IN  NS  apnic.authdns.ripe.net.
>> 171.in-addr.arpa.86400   IN  NS  apnic1.dnsnode.net.
>> 171.in-addr.arpa.86400   IN  NS  tinnie.arin.net.
>> 171.in-addr.arpa.86400   IN  DS  49699 5 1 
>> 0240801C96480900CC6D93130AF45CFE86EDE940
>> 171.in-addr.arpa.86400   IN  DS  49699 5 2 
>> 6E0BA96F05B4D39C1668979731E040213BB6130DE33E86E063B5F7F7 5C465C88
>> 171.in-addr.arpa.86400   IN  RRSIG   DS 8 3 86400 20170330042932 
>> 20170309125911 4341 in-addr.arpa. 
>> RKcPZJdG1MBrwpfa1mIK7ikIU585i1Jv+UkEBHxuM3BxxAbD+ht0W04C 
>> ljboyXJfYK8ly/YTDqNUkWKZLwDHlkq/rgNwTG63sPT8iK8qya+2qUVB 
>> iTXVsD2HaV1V/KwgJjlWHRNnlwkK0YZ5Q7tevXaq4yyLT2Q2mu5dkhFC evNQOyI=
>> ;; Received 482 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 69 
>> ms
>> 
>> 171.in-addr.arpa.0   IN  SOA ns1.apnic.net. 
>> read-txt-record-of-zone-first-dns-admin.apnic.net. 5276 7200 1800 604800 
>> 172800
>> 171.in-addr.arpa.0   IN  RRSIG   SOA 5 3 172800 20170416100102 
>> 20170317090102 7858 171.in-addr.arpa. 
>> dH+uuGq9pgMc9TEMkTwrf9NGMj5zFnbZt3kjlNSF0kPzGk3WUr5g84jv 
>> 0SN88Y26eP/Op4Vv8JewyVu2IT1POnmiNpDYELkJxrTWnPPc6CJ2wugR 
>> TrFLOq6eIsqtr

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[John Curran]

Eygene - 

  We are aware there’s an issue and working on it presently with RIPE. 
  Expect additional updates shortly.

/John

John Curran
President and CEO
ARIN

> On 17 Mar 2017, at 11:04 AM, Eygene Ryabinkin  wrote:
> 
> Job, good day.
> 
> Fri, Mar 17, 2017 at 09:55:56AM +, Job Snijders wrote:
>> 171 also seems affected.
> 
> Not the whole one, it seems:
> {{{
> $ dig +trace -t soa 1.171.in-addr.arpa
> 
> ; <<>> DiG 9.10.4-P6 <<>> +trace -t soa 1.171.in-addr.arpa
> ;; global options: +cmd
> . 202634  IN  NS  m.root-servers.net.
> . 202634  IN  NS  i.root-servers.net.
> . 202634  IN  NS  k.root-servers.net.
> . 202634  IN  NS  c.root-servers.net.
> . 202634  IN  NS  a.root-servers.net.
> . 202634  IN  NS  d.root-servers.net.
> . 202634  IN  NS  l.root-servers.net.
> . 202634  IN  NS  e.root-servers.net.
> . 202634  IN  NS  g.root-servers.net.
> . 202634  IN  NS  b.root-servers.net.
> . 202634  IN  NS  j.root-servers.net.
> . 202634  IN  NS  h.root-servers.net.
> . 202634  IN  NS  f.root-servers.net.
> . 511016  IN  RRSIG   NS 8 0 518400 2017032917 
> 2017031616 61045 . 
> OjsjoA6WCcThV3BqhAyMaXI3bU1m228Gl8nvaR074qBtem/RjaFJh1Oe 
> r7LPI6W15jgbRGuCY7/GUNgDex4ZM43yvx2iY+2GpSk9b2/pKGbDaDIp 
> X1Hd8418206eow1P/SgPqtT+2LzjM+lz/HKUvCyPoN4uX5/7GDExn8ir 
> 2Q/vw81Za2nJ4Ji6oeGAmE8g6V3RJfTI0El/CP9Vl2/r0jWDZZ+wtYRA 
> uwqvQYj+7VZc5+UJDJ3/Gne1LBnzXKnZRwnfJtZenhfZ7X20D9PiXvfJ 
> M2s1ryqZvg8K5RqYt/r8pIiq1Udd1KWQBgdN7Q629+jNSngZQtH19R9H fM7h1w==
> ;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
> 
> in-addr.arpa. 172800  IN  NS  a.in-addr-servers.arpa.
> in-addr.arpa. 172800  IN  NS  b.in-addr-servers.arpa.
> in-addr.arpa. 172800  IN  NS  c.in-addr-servers.arpa.
> in-addr.arpa. 172800  IN  NS  d.in-addr-servers.arpa.
> in-addr.arpa. 172800  IN  NS  e.in-addr-servers.arpa.
> in-addr.arpa. 172800  IN  NS  f.in-addr-servers.arpa.
> in-addr.arpa. 86400   IN  DS  47054 8 2 
> 5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
> in-addr.arpa. 86400   IN  DS  53696 8 2 
> 13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
> in-addr.arpa. 86400   IN  DS  63982 8 2 
> AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
> in-addr.arpa. 86400   IN  RRSIG   DS 8 2 86400 2017033000 
> 2017031623 33786 arpa. 
> gqNN6MmLVxFtSG0oxdyoYVSXZlp6vY9yxpnJW89TYCHfTkv+ZmklM76O 
> IHdTznEhLHXbyr4BaxjFCshsC3WacdH/YZYa/SZynJ9Q1N6/bogrIUTn 
> qs61Y/YD4Sk5lI7YvUxVnPrF3lk1pY8dpoTkprTLZngoeQEsm552inqG ypU=
> ;; Received 731 bytes from 193.0.14.129#53(k.root-servers.net) in 41 ms
> 
> 171.in-addr.arpa. 86400   IN  NS  ns1.apnic.net.
> 171.in-addr.arpa. 86400   IN  NS  ns2.lacnic.net.
> 171.in-addr.arpa. 86400   IN  NS  ns3.apnic.net.
> 171.in-addr.arpa. 86400   IN  NS  ns4.apnic.net.
> 171.in-addr.arpa. 86400   IN  NS  apnic.authdns.ripe.net.
> 171.in-addr.arpa. 86400   IN  NS  apnic1.dnsnode.net.
> 171.in-addr.arpa. 86400   IN  NS  tinnie.arin.net.
> 171.in-addr.arpa. 86400   IN  DS  49699 5 1 
> 0240801C96480900CC6D93130AF45CFE86EDE940
> 171.in-addr.arpa. 86400   IN  DS  49699 5 2 
> 6E0BA96F05B4D39C1668979731E040213BB6130DE33E86E063B5F7F7 5C465C88
> 171.in-addr.arpa. 86400   IN  RRSIG   DS 8 3 86400 20170330042932 
> 20170309125911 4341 in-addr.arpa. 
> RKcPZJdG1MBrwpfa1mIK7ikIU585i1Jv+UkEBHxuM3BxxAbD+ht0W04C 
> ljboyXJfYK8ly/YTDqNUkWKZLwDHlkq/rgNwTG63sPT8iK8qya+2qUVB 
> iTXVsD2HaV1V/KwgJjlWHRNnlwkK0YZ5Q7tevXaq4yyLT2Q2mu5dkhFC evNQOyI=
> ;; Received 482 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 69 ms
> 
> 171.in-addr.arpa. 0   IN  SOA ns1.apnic.net. 
> read-txt-record-of-zone-first-dns-admin.apnic.net. 5276 7200 1800 604800 
> 172800
> 171.in-addr.arpa. 0   IN  RRSIG   SOA 5 3 172800 20170416100102 
> 20170317090102 7858 171.in-addr.arpa. 
> dH+uuGq9pgMc9TEMkTwrf9NGMj5zFnbZt3kjlNSF0kPzGk3WUr5g84jv 
> 0SN88Y26eP/Op4Vv8JewyVu2IT1POnmiNpDYELkJxrTWnPPc6CJ2wugR 
> TrFLOq6eIsqtrCcWbatQ7XSXXj1UglqVVydlX1ExoIh9MdP+1eBneD1I 4OU=
> 171.in-addr.arpa. 172800  IN  NSEC10.171.in-addr.arpa. NS SOA TXT 
> RRSIG NSEC DNSKEY
> 171.in-addr.arpa. 172800  IN  RRSIG   NSEC 5 3 172800 20170416100102 
> 20170317090102 7858 171.in-addr.arpa. 
> QieHZ0W7jx3QCgLuvqtKtFoLPYkxn5R9nRO1oMbSSXkdF+S4iQQkVlX7 
> DyQvoL69hKA+S9idfernf6DwNTQgeWFfCdjUyOjMCa3Ag/S8ARZs7K4F 
> N9DxB/cBCZm7KTzwAzXFe3cJ

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[Eygene Ryabinkin]

Job, good day.

Fri, Mar 17, 2017 at 09:55:56AM +, Job Snijders wrote:
> 171 also seems affected.

Not the whole one, it seems:
{{{
$ dig +trace -t soa 1.171.in-addr.arpa

; <<>> DiG 9.10.4-P6 <<>> +trace -t soa 1.171.in-addr.arpa
;; global options: +cmd
.   202634  IN  NS  m.root-servers.net.
.   202634  IN  NS  i.root-servers.net.
.   202634  IN  NS  k.root-servers.net.
.   202634  IN  NS  c.root-servers.net.
.   202634  IN  NS  a.root-servers.net.
.   202634  IN  NS  d.root-servers.net.
.   202634  IN  NS  l.root-servers.net.
.   202634  IN  NS  e.root-servers.net.
.   202634  IN  NS  g.root-servers.net.
.   202634  IN  NS  b.root-servers.net.
.   202634  IN  NS  j.root-servers.net.
.   202634  IN  NS  h.root-servers.net.
.   202634  IN  NS  f.root-servers.net.
.   511016  IN  RRSIG   NS 8 0 518400 2017032917 
2017031616 61045 . OjsjoA6WCcThV3BqhAyMaXI3bU1m228Gl8nvaR074qBtem/RjaFJh1Oe 
r7LPI6W15jgbRGuCY7/GUNgDex4ZM43yvx2iY+2GpSk9b2/pKGbDaDIp 
X1Hd8418206eow1P/SgPqtT+2LzjM+lz/HKUvCyPoN4uX5/7GDExn8ir 
2Q/vw81Za2nJ4Ji6oeGAmE8g6V3RJfTI0El/CP9Vl2/r0jWDZZ+wtYRA 
uwqvQYj+7VZc5+UJDJ3/Gne1LBnzXKnZRwnfJtZenhfZ7X20D9PiXvfJ 
M2s1ryqZvg8K5RqYt/r8pIiq1Udd1KWQBgdN7Q629+jNSngZQtH19R9H fM7h1w==
;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

in-addr.arpa.   172800  IN  NS  a.in-addr-servers.arpa.
in-addr.arpa.   172800  IN  NS  b.in-addr-servers.arpa.
in-addr.arpa.   172800  IN  NS  c.in-addr-servers.arpa.
in-addr.arpa.   172800  IN  NS  d.in-addr-servers.arpa.
in-addr.arpa.   172800  IN  NS  e.in-addr-servers.arpa.
in-addr.arpa.   172800  IN  NS  f.in-addr-servers.arpa.
in-addr.arpa.   86400   IN  DS  47054 8 2 
5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
in-addr.arpa.   86400   IN  DS  53696 8 2 
13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
in-addr.arpa.   86400   IN  DS  63982 8 2 
AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
in-addr.arpa.   86400   IN  RRSIG   DS 8 2 86400 2017033000 
2017031623 33786 arpa. 
gqNN6MmLVxFtSG0oxdyoYVSXZlp6vY9yxpnJW89TYCHfTkv+ZmklM76O 
IHdTznEhLHXbyr4BaxjFCshsC3WacdH/YZYa/SZynJ9Q1N6/bogrIUTn 
qs61Y/YD4Sk5lI7YvUxVnPrF3lk1pY8dpoTkprTLZngoeQEsm552inqG ypU=
;; Received 731 bytes from 193.0.14.129#53(k.root-servers.net) in 41 ms

171.in-addr.arpa.   86400   IN  NS  ns1.apnic.net.
171.in-addr.arpa.   86400   IN  NS  ns2.lacnic.net.
171.in-addr.arpa.   86400   IN  NS  ns3.apnic.net.
171.in-addr.arpa.   86400   IN  NS  ns4.apnic.net.
171.in-addr.arpa.   86400   IN  NS  apnic.authdns.ripe.net.
171.in-addr.arpa.   86400   IN  NS  apnic1.dnsnode.net.
171.in-addr.arpa.   86400   IN  NS  tinnie.arin.net.
171.in-addr.arpa.   86400   IN  DS  49699 5 1 
0240801C96480900CC6D93130AF45CFE86EDE940
171.in-addr.arpa.   86400   IN  DS  49699 5 2 
6E0BA96F05B4D39C1668979731E040213BB6130DE33E86E063B5F7F7 5C465C88
171.in-addr.arpa.   86400   IN  RRSIG   DS 8 3 86400 20170330042932 
20170309125911 4341 in-addr.arpa. 
RKcPZJdG1MBrwpfa1mIK7ikIU585i1Jv+UkEBHxuM3BxxAbD+ht0W04C 
ljboyXJfYK8ly/YTDqNUkWKZLwDHlkq/rgNwTG63sPT8iK8qya+2qUVB 
iTXVsD2HaV1V/KwgJjlWHRNnlwkK0YZ5Q7tevXaq4yyLT2Q2mu5dkhFC evNQOyI=
;; Received 482 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 69 ms

171.in-addr.arpa.   0   IN  SOA ns1.apnic.net. 
read-txt-record-of-zone-first-dns-admin.apnic.net. 5276 7200 1800 604800 172800
171.in-addr.arpa.   0   IN  RRSIG   SOA 5 3 172800 20170416100102 
20170317090102 7858 171.in-addr.arpa. 
dH+uuGq9pgMc9TEMkTwrf9NGMj5zFnbZt3kjlNSF0kPzGk3WUr5g84jv 
0SN88Y26eP/Op4Vv8JewyVu2IT1POnmiNpDYELkJxrTWnPPc6CJ2wugR 
TrFLOq6eIsqtrCcWbatQ7XSXXj1UglqVVydlX1ExoIh9MdP+1eBneD1I 4OU=
171.in-addr.arpa.   172800  IN  NSEC10.171.in-addr.arpa. NS SOA TXT 
RRSIG NSEC DNSKEY
171.in-addr.arpa.   172800  IN  RRSIG   NSEC 5 3 172800 20170416100102 
20170317090102 7858 171.in-addr.arpa. 
QieHZ0W7jx3QCgLuvqtKtFoLPYkxn5R9nRO1oMbSSXkdF+S4iQQkVlX7 
DyQvoL69hKA+S9idfernf6DwNTQgeWFfCdjUyOjMCa3Ag/S8ARZs7K4F 
N9DxB/cBCZm7KTzwAzXFe3cJ/d1Wo45Tx9jf6Drx551oqOw1gmDIL4y6 +k4=
;; Received 530 bytes from 202.12.31.140#53(ns4.apnic.net) in 347 ms
}}}
since it is APNIC who respond to queries about it.  Any more specific
reverse records that are cross ARIN and die there from 171.x.y.z?
-- 
Eygene Ryabinkin, National Research Centre "Kurchatov Institute"

Alw

Re: ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[Stephane Bortzmeyer]

On Fri, Mar 17, 2017 at 12:03:58PM +0300,
 Eygene Ryabinkin  wrote 
 a message of 71 lines which said:

> We (at Kurchatov Insitute) still use 144.206.0.0/16, the legacy
> block, and seeing the breakage rooted at ARIN since this night,
> {{{
> $ dig +trace -t soa 206.144.in-addr.arpa

According to DNSDB, it arrived yesterday, around 1630 UTC.

Re: ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[Job Snijders]

171 also seems affected.

Job

On Fri, 17 Mar 2017 at 10:54, Stephane Bortzmeyer  wrote:

> On Fri, Mar 17, 2017 at 12:03:58PM +0300,
>  Eygene Ryabinkin  wrote
>  a message of 71 lines which said:
>
> > Seems like the other /16 from 144.in-addr.arpa are affected too
> > (at least).
>
> Also in 164.in-addr.arpa, it seems?
>

Re: ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[Stephane Bortzmeyer]

On Fri, Mar 17, 2017 at 12:03:58PM +0300,
 Eygene Ryabinkin  wrote 
 a message of 71 lines which said:

> Seems like the other /16 from 144.in-addr.arpa are affected too
> (at least).

Also in 164.in-addr.arpa, it seems?

ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[Eygene Ryabinkin]

We (at Kurchatov Insitute) still use 144.206.0.0/16, the legacy
block, and seeing the breakage rooted at ARIN since this night,
{{{
$ dig +trace -t soa 206.144.in-addr.arpa

; <<>> DiG 9.10.4-P6 <<>> +trace -t soa 206.144.in-addr.arpa
;; global options: +cmd
.   206351  IN  NS  a.root-servers.net.
.   206351  IN  NS  c.root-servers.net.
.   206351  IN  NS  d.root-servers.net.
.   206351  IN  NS  e.root-servers.net.
.   206351  IN  NS  l.root-servers.net.
.   206351  IN  NS  f.root-servers.net.
.   206351  IN  NS  g.root-servers.net.
.   206351  IN  NS  h.root-servers.net.
.   206351  IN  NS  j.root-servers.net.
.   206351  IN  NS  m.root-servers.net.
.   206351  IN  NS  k.root-servers.net.
.   206351  IN  NS  i.root-servers.net.
.   206351  IN  NS  b.root-servers.net.
.   514733  IN  RRSIG   NS 8 0 518400 2017032917 
2017031616 61045 . OjsjoA6WCcThV3BqhAyMaXI3bU1m228Gl8nvaR074qBtem/RjaFJh1Oe 
r7LPI6W15jgbRGuCY7/GUNgDex4ZM43yvx2iY+2GpSk9b2/pKGbDaDIp 
X1Hd8418206eow1P/SgPqtT+2LzjM+lz/HKUvCyPoN4uX5/7GDExn8ir 
2Q/vw81Za2nJ4Ji6oeGAmE8g6V3RJfTI0El/CP9Vl2/r0jWDZZ+wtYRA 
uwqvQYj+7VZc5+UJDJ3/Gne1LBnzXKnZRwnfJtZenhfZ7X20D9PiXvfJ 
M2s1ryqZvg8K5RqYt/r8pIiq1Udd1KWQBgdN7Q629+jNSngZQtH19R9H fM7h1w==
;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

in-addr.arpa.   172800  IN  NS  e.in-addr-servers.arpa.
in-addr.arpa.   172800  IN  NS  f.in-addr-servers.arpa.
in-addr.arpa.   172800  IN  NS  d.in-addr-servers.arpa.
in-addr.arpa.   172800  IN  NS  c.in-addr-servers.arpa.
in-addr.arpa.   172800  IN  NS  b.in-addr-servers.arpa.
in-addr.arpa.   172800  IN  NS  a.in-addr-servers.arpa.
in-addr.arpa.   86400   IN  DS  53696 8 2 
13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
in-addr.arpa.   86400   IN  DS  63982 8 2 
AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
in-addr.arpa.   86400   IN  DS  47054 8 2 
5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
in-addr.arpa.   86400   IN  RRSIG   DS 8 2 86400 2017033000 
2017031623 33786 arpa. 
gqNN6MmLVxFtSG0oxdyoYVSXZlp6vY9yxpnJW89TYCHfTkv+ZmklM76O 
IHdTznEhLHXbyr4BaxjFCshsC3WacdH/YZYa/SZynJ9Q1N6/bogrIUTn 
qs61Y/YD4Sk5lI7YvUxVnPrF3lk1pY8dpoTkprTLZngoeQEsm552inqG ypU=
;; Received 733 bytes from 198.41.0.4#53(a.root-servers.net) in 64 ms

144.in-addr.arpa.   86400   IN  NS  r.arin.net.
144.in-addr.arpa.   86400   IN  NS  u.arin.net.
144.in-addr.arpa.   86400   IN  NS  x.arin.net.
144.in-addr.arpa.   86400   IN  NS  y.arin.net.
144.in-addr.arpa.   86400   IN  NS  z.arin.net.
144.in-addr.arpa.   86400   IN  NS  arin.authdns.ripe.net.
144.in-addr.arpa.   86400   IN  DS  62856 5 1 
484154736CF9D4DC4F1C2B807BDC06E5B1645AFF
144.in-addr.arpa.   86400   IN  RRSIG   DS 8 3 86400 20170328085556 
20170307105911 4341 in-addr.arpa. 
X3nPKgjQbRef6BxK3msEXi/IcfpG1rylY2xeWwfNO6fJB5x/QT38ZCA5 
XMs6CBeXb59tpQFbgjwZX+prqSpjGFtZ+phFuzsaGmuPOF0FFypMHj7F 
swykEFvaPY5z4d8mo9FKFJetF2gZfzYthwJWW0x2oo2H2BG0lEedVUCb 1aGs/HE=
;; Received 380 bytes from 193.0.9.1#53(f.in-addr-servers.arpa) in 48 ms

144.in-addr.arpa.   0   IN  SOA z.arin.net. dns-ops.arin.net. 
2017022432 1800 900 691200 10800
144.in-addr.arpa.   0   IN  RRSIG   SOA 5 3 86400 20170331083220 
20170317073220 33345 144.in-addr.arpa. 
k2sZXuQQR3MyyRiB9Wd7fw45yZTbNokjQtFFNY+aCEa/85AnSyuomLlZ 
jZs4A0bO376/Z1v+bTHoeFqsyHr/xuWHX74r0QC/TCeP0amc+w8RqCvw 
Yox1TfoJxwhblGNRCgyLw52WszMYyr49EfWPfpHAKFU+G94gdilf3C6x GOM=
144.in-addr.arpa.   10800   IN  NSEC0.144.in-addr.arpa. NS SOA 
RRSIG NSEC DNSKEY
144.in-addr.arpa.   10800   IN  RRSIG   NSEC 5 3 10800 20170331083220 
20170317073220 33345 144.in-addr.arpa. 
opvG8SC7+UjHSTtBBtekWNkhLFMIxFxOdejJ7sM7t8lyGNzM6sOABeSI 
ADXfo8q3p4YFBHgBU5fRCAhBdiQ/AiZC0dLMnHb4WdKEv5bDsBbq5Pt6 
vabJaIv7Gizw7kBy1JZ/ZrC4Jmp4EX0HiYA+Ak+aQggD7gdI/6tFDNpl N7M=
205.144.in-addr.arpa.   10800   IN  NSEC207.144.in-addr.arpa. NS RRSIG 
NSEC
205.144.in-addr.arpa.   10800   IN  RRSIG   NSEC 5 4 10800 20170331083220 
20170317073220 33345 144.in-addr.arpa. 
F1e5mA7C3Mx10YSaNtshzfzfER8pudDOQkUoe+jeDhHeDZeR8FM1FoqW 
dqrNh5X6JVNlTdWGio6evnSkxnaoJFYyeYJtc+tJ8dTd5APJxJCSOfhH 
VfRNy7VHs2PdElRo1rRwMw+5Zncc0u8uPdmFDv2ZG8Vv3zj5C6l7rMla 3SA=
;; Received 718 bytes from 199.212.0.63#53(z.arin.net) in 128 ms
}}}

Seems like the other /16 from 144.in-addr.arpa are affected too
(at least).

ARIN ticke

Re: Government agency renting or selling IP space

[John Curran]

On 17 Mar 2017, at 6:07 AM, Mel Beckman  wrote:
> 
> John,
> 
> It's a California State government agency. Does that make a difference?

Yes - very much so. (US Government has interesting procedures stemming 
from the US Constitution for handling the release of any rights or interest, 
but the same does not apply to state governments.)

Mr. Herrin’s remarks are correct - normal ARIN transfer procedures apply.

Thanks,
/John

John Curran
President and CEO
ARIN