Jay Hennigan wrote:
> Long story short, we consolidated acquisitions into a single AS, returned
> the old AS to ARIN, and a 2006 RADB entry that looks to have been
> auto-generated by Level 3 with the old AS is still hanging around, causing
> other to question it.
If it's source: LEVEL3, drop a
Well, if you use a ROA as your only signed object, then yes. But really I
was hinting at RTA or RSC: use the mechanism to countersign an instruction
to RADB or any other IRR specifically about the RPSL you want to eject.
Not "because ROA do this" but "do this specific thing I command because I
On Fri, Nov 12, 2021 at 9:56 PM George Michaelson wrote:
> Wouldn't it be cool if we had a cryptographic mechanism to sign an
> authority to the IRR publisher to eject old data.
>
> Some way you could prove you have control of the asset, and the let the
> RADB people know you repudiated some
Wouldn't it be cool if we had a cryptographic mechanism to sign an
authority to the IRR publisher to eject old data.
Some way you could prove you have control of the asset, and the let the
RADB people know you repudiated some old data, made under somebody else's
authority which you can't remove
Tagging onto this thread as it's relevant to me.
Is there any mechanism for removing stale cruft that someone else has
added to IRR? Two of our subnets have some cruft from an automated
script that was accurate in 2006 when they were created, but are no
longer valid.
Long story short, we
On 11/12/21 8:33 AM, Jeff Shultz wrote:
I still think that this is not the correct way for NetSol to handle this
situation, particularly since the pages they put up look like phishbait
designed by Austin Powers.
I didn't see the page, but for what it's worth, this is governed by this
ICANN
On Fri, Nov 12, 2021 at 3:09 PM Rubens Kuhl wrote:
>> DNSSEC would help here. NetSol's rogue nameserver wouldn't be able to
>> produce
>> the signed zone if validation were required.
>
> Nope, they could just remove the DS since they are the registrar for that
> domain. DNSSEC only protects
>
>
>
>
> DNSSEC would help here. NetSol's rogue nameserver wouldn't be able to
> produce
> the signed zone if validation were required.
>
>
Nope, they could just remove the DS since they are the registrar for that
domain. DNSSEC only protects against a DNS provider going rogue, not your
own
On Fri, Nov 12, 2021 at 1:29 PM Stephane Bortzmeyer wrote:
> On Thu, Nov 11, 2021 at 09:44:04PM +, [..]
> It depends on where you are (from my resolver, I get
> 64.130.197.11). This is because the name voyager.viser.net is not
> stable yet. Depending on your resolver, it points to
LAG - Micro BFD (RFC7130) provides per constituent livability. MLAG is much
more complicated (there’s a proposal in IETF but not progressing), so LACP is
pretty much the only option.
ECMP could use old/good single hop BFD per pair.
Practically - if you introduce enough flows with one of the hash
Job Snijders via NANOG wrote:
> Dear Lee,
Hi Job,
> *ring ring* - "IRR/RPKI helpdesk how may I help you today?" :-)
What a fantastic helpdesk it is, too! ;-)
> Another way to satisfy this request is to ask the organization's
> provider to create an AS-SET (preferably RIR-operatored IRR such as
On Fri, Nov 12, 2021 at 11:30 AM Stephane Bortzmeyer
wrote:
> On Thu, Nov 11, 2021 at 09:44:04PM +,
> Richard wrote
> a message of 37 lines which said:
>
> > The second of these is returning the 208.nnn IPnumber for your
> > a-record:
> >
> >dig @VOYAGER.VISER.NET 2dpnr.org
> >
> >
On Thu, Nov 11, 2021 at 09:44:04PM +,
Richard wrote
a message of 37 lines which said:
> The second of these is returning the 208.nnn IPnumber for your
> a-record:
>
>dig @VOYAGER.VISER.NET 2dpnr.org
>
>2dpnr.org. 300 IN A 208.91.197.132
It depends on where you are (from my
I the past I have found that Disney+ and HBO MAX both use Digital Envoy/Digital
Element.
Thank you,
Kevin McCormick
From: NANOG On Behalf Of Norman
Jester
Sent: Friday, November 12, 2021 12:05 PM
To: Dave Bell
Cc: nanog@nanog.org
Subject: Re: Geolocation for Disney Plus
The contacts on
It took me several months to get a Disney+ geolocation issue resolved
recently.
I sent emails to the known contacts. Got one response saying the issue
would be investigated. Later, no response to additional follow-ups over
several weeks.
Phone calls to their consumer hell desk told me that they
The contacts on that brotherwisp page for Disney+ do not respond. I have had
success only with peeringdb contacts.
As recently as two days ago they resolved a similar issue for me as peeringdb
listed contacts.
Norman Jester
619-319-7055 (whatsapp ok!)
> On Nov 12, 2021, at 9:39 AM, Dave Bell
This is an automated weekly mailing describing the state of the Internet
Global IPv4 Routing Table as seen from APNIC's router in Japan.
The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.
Daily listings are sent to
Check out this link.
https://thebrotherswisp.com/index.php/geo-and-vpn/
On Fri, 12 Nov 2021 at 15:51, Drew Weaver wrote:
> We’ve had a few complaints that users are getting redirected to the EN-GB
> version of Disney+ whenever they try to visit the site.
>
>
>
> I have tried very hard to figure
> Date: Thursday, November 11, 2021 13:28:07 -0800
> From: Jeff Shultz
>
> Okay, so this is anecdotal, but since the domain belongs to me it's
> more than a little annoying.
>
> I got some calls that one of my domains, 2dpnr.org was going to a
> page that said it was Network Solutions and
On Fri, Nov 12, 2021 at 7:07 AM Matthew Petach
wrote:
>
> I suspect it's more a case of
>
> domain foo.com provides DNS service for several other domains,
> including bar.com.
>
> bar.com is fully paid up.
>
> foo.com doesn't get paid up on time; expires, but is quickly
> re-claimed and paid up
Hello all.
Over time, we've run into occurrences of both bugs and human error, both in our
own gear and in our partner networks' gear, specifically affecting multi-path
forwarding, at pretty much all layers: Multi-chassis LAG, ECMP, and BGP MP.
(Yes, I am a corner-case magnet. Lucky me.)
We've had a few complaints that users are getting redirected to the EN-GB
version of Disney+ whenever they try to visit the site.
I have tried very hard to figure out which geolocation service they are using
to come to that conclusion but have yet to be able to figure it out.
Does anyone know
On Fri, Nov 12, 2021 at 5:55 AM William Herrin wrote:
> On Thu, Nov 11, 2021 at 6:36 PM Jeff Shultz
> wrote:
> >
> >
> > Yeah, apparently when a domain expires, a lot of DNS queries to domains
> in that domain's DNS server... get redirected to a Network Solutions "this
> is expired" website at
On Thu, Nov 11, 2021 at 6:36 PM Jeff Shultz wrote:
>
>
> Yeah, apparently when a domain expires, a lot of DNS queries to domains in
> that domain's DNS server... get redirected to a Network Solutions "this is
> expired" website at that IP.
> Even though those domains are perfectly legit and
On Thu, Nov 11, 2021 at 01:36:58PM -0800,
Jeff Shultz wrote
a message of 122 lines which said:
> Never mind, looks like an expired domain issue. Someone didn't remind
> someone else.
To avoid such a problem:
* some registries allow for multi-year registration,
* some registrars allow for
25 matches
Mail list logo
