Re: Questions about IRR best practices

[Adam Korab]

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 note to ipad...@centurylink.com - it works 
some of the time.

--Adam

Re: Questions about IRR best practices

[George Michaelson]

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
control the assets"

G

On Sat, 13 Nov 2021, 11:18 am Rubens Kuhl,  wrote:

>
>
> 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 old data, made under somebody else's
>> authority which you can't remove directly, even though it's probably stale.
>>
>> Something like a PKI tagged with your addresses and/or ASN.
>>
>>>
>>>
> That only helps with wrong origin IRR records. While this is the case at
> hand, a lot of proxy objects have correct origin attributes,  and are just
> managed by the wrong person.
>
> That said, TC IRR is currently using RPKI validation and the curious
> result is that most RPKI-triggered removals are objects sent by the own AS,
> but with a more specific prefix that what's published in RPKI.
>
> Rubens
>
>
>
>
>
>

Re: Questions about IRR best practices

[Rubens Kuhl]

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 old data, made under somebody else's
> authority which you can't remove directly, even though it's probably stale.
>
> Something like a PKI tagged with your addresses and/or ASN.
>
>>
>>
That only helps with wrong origin IRR records. While this is the case at
hand, a lot of proxy objects have correct origin attributes,  and are just
managed by the wrong person.

That said, TC IRR is currently using RPKI validation and the curious result
is that most RPKI-triggered removals are objects sent by the own AS, but
with a more specific prefix that what's published in RPKI.

Rubens

Re: Questions about IRR best practices

[George Michaelson]

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 directly, even though it's probably stale.

Something like a PKI tagged with your addresses and/or ASN.

G

On Sat, 13 Nov 2021, 10:41 am Jay Hennigan,  wrote:

> 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 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.
>
> --
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
>

Re: Questions about IRR best practices

[Jay Hennigan]

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 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.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: DNS hijack?

[Robert L Mathews]

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 policy:


https://www.icann.org/resources/pages/errp-2013-02-28-en

Particularly 2.2.4:

"In interrupting the DNS resolution path of the registration, if the 
registrar directs web traffic to the domain name to a web page while the 
registration is still renewable by the RAE, that web page must 
conspicuously indicate that the domain name registration is expired and 
provide renewal instructions."


If it didn't meet that requirement, you could complain to ICANN about it.

(You're also more generally right that what Network Solutions is doing 
here is horrible. Decent registrars don't redirect traffic: they simply 
set the domain name to clientHold so that it doesn't appear in the DNS 
at all, because otherwise they're breaking your stuff -- and what's 
worse, breaking it in a way that may take some time to recover from even 
after you renew the domain name, due to DNS caching.)


--
Robert L Mathews

Re: DNS hijack?

[William Herrin]

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 against a DNS provider going rogue, not your own 
> hired registrar.


DNSSEC would help DNS for the non-expired domain because the rogue
server would not have the key.

To my mind, though, Netsol's server should not be responding with
authoritative answers to random domains that aren't assigned to it.
That it does makes me think it's a good candidate for black-holing in
the routing system.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: DNS hijack?

[Rubens Kuhl]

>
>
>
>
> 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 hired registrar.


Rubens

Re: DNS hijack?

[Jim]

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 64.130.200.16 -
> which seems to give correct answers - or to 208.91.197.132 - which
> replies even for nonexisting domain names.
[..]

So yes, then.. A DNS Hijack by NetSol redirecting the hostname on an expired SLD
related to one of the individual nameserver hosts to a
faulty/non-compliant nameserver
of NetSol's that then publishes bogus RRs for domains that registrar
have no authority over.

That means instead of the 1 nameserver failing; the entire domain
breaks, even if there are multiple nameservers listed, and only 1 had
been accidentally allowed to expire.

DNSSEC would help here.   NetSol's rogue nameserver wouldn't be able to produce
the signed zone if validation were required.

-- 
-JH

Re: Validating multi-path in production?

[Jeff Tantsura]

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 keys 
monotonically changing, eventually you’d exercise every path available;
on itself would not help for end2end testing, usually integrated with a form of 
s/net flow to provide “proof of transit.
Inband telemetry (chose your poison) does provide basic device ID it has 
traversed as well as in some cases POT. 
Finally - there are public Microsoft presentations how we use IPinIP encap to 
traverse a particular path on wide radix ECMP fabrics.

Cheers,
Jeff

> On Nov 12, 2021, at 07:55, Adam Thompson  wrote:
> 
> 
> 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.)
> 
> Some of these issues were fairly obvious when they happened, but some were 
> really hard to pin down.
> 
> We've found that typical network monitoring tools (Observium & Smokeping, not 
> to mention plain old ping and traceroute) can't really detect a 
> hashing-related or multi-path-related problem: either the packets get through 
> or they don't.
> 
> Can anyone recommend either tools or techniques to validate that multi-path 
> forwarding either is, or isn't, working correctly in a production network?  
> I'm looking to add something to our test suite for when we make changes to 
> critical network gear.  Almost all the scenarios I want to test only involve 
> two paths, if that helps.
> 
> The best I've come up with so far is to have two test systems (typically VMs) 
> that use adjacent IP addresses and adjacent MAC addresses, and test both 
> inbound and outbound to/from those, blindly trusting/hoping that hashing 
> algorithms will probably exercise both paths.
> 
> Some of the problems we've seen show that merely looking at interface 
> counters is insufficient, so I'm trying to find an explicit proof, not 
> implicit.
> 
> Any suggestions?  Surely other vendors and/or admins have screwed this up in 
> subtle ways enough times that this knowledge exists?  (My Google-fu is 
> usually pretty good, but I'm striking out - maybe I'm using the wrong terms.)
> 
> -Adam
> 
> Adam Thompson
> Consultant, Infrastructure Services
> 
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athomp...@merlin.mb.ca
> www.merlin.mb.ca

Re: Questions about IRR best practices

[Adam Korab]

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
> ARIN, RIPE, etc), and then reference their AS-SET on your own AS-SET.
> IRR AS-SETs permit both referencing AS Numbers and AS-SETs as 'members:'.

This brings up a question I've been mulling over lately - if AS64500 has 
AS64500:AS-CUSTOMERS and has a customer AS64510, and AS64510 only ever
plans to originate routes themselves, with no downstreams, is there any
reason other than "future flexibility" for AS64510 to create an AS-SET,
e.g.:

as-set: AS64500-CUSTOMERS
|-> members: AS64510:AS-AS64510
 |-> members: AS64510

versus simply the following:

as-set: AS64500-CUSTOMERS
 |-> members: AS64510

It seems to me both are entirely functionally equivalent, aside that if
AS64510 ever wants to change things they would need to get AS64500 to
update their AS64500-CUSTOMERS members.

> The industry trend (very noticable the last 3 years) is that the ability
> to create proxy route object registrations is slowly fading away.
> 
> At at first glance proxy registrations seem better than 'no
> registration', the downside is that anyone can create proxy
> registrations for any prefix: proxies are not very safe!

I wonder what this means (eventually, anyway) for RADB, NTTCOM, LEVEL3,
etc.  Though LEVEL3 can hardly be considered on the bleeding edge of
IRR...

> The recommendation is that each and every IP resource holder creates IRR
> and/or RPKI objects themselves, or delegates the authority to do so to
> their service provider.

What is the mechanism for such a delegation?

It seems to me that with enough RPKI adoption, IRR will eventually go
away, but you mention "and/or" - is that just for current
interoperability?

Taking it a step futher, let's say I have valid ROAs for all my prefixes
today, because I do.  But I don't maintain my objects in ARIN's IRR.  Do
I need to migrate, and if so, assuming my upstreams still "reject RPKI
invalid but permit rpki unknown AND require an IRR AS-SET to build BGP
filters in the first place" it seems to me that maintaining IRR is
necessary because otherwise the upstream won't listen to the
announcements at all, much less verify RPKI.

> Technically this is likely to work, but the downside is that you end up
> with a hard dependency on another ISP's proxy registration. If for
> whatever reason that registration lapses (failure to pay bills, M, who
> knows) ... you might end up with a hard to troubleshoot situation where
> it is not immediately clear "it was working yesterday, but not today?!".

FWIW, Lee, I ran into this exact scenario this week.  Everything was
working, but the route was only being permitted by the customer's
upstream because of a stale object proxy registered by someone else.  My
two cents is that this is an exceedling common occurence.

> The best course of action is to ensure that objects are either managed
> by yourself, or by the customer, so the responsibilities and object
> ownership are clear to everyone involved.

And yet, there's probably double-digits of people that fully grok IRR,
despite the years and years of NOG presenations and tutorials and
everything else.

> A great tool to gain some insight into various IRR/BGP/RPKI data sources
> and what the registration status of various objecst might mean can be
> found at this awesome tool: https://irrexplorer.nlnog.net/

There's also a command-line irrtree that's pretty slick, and if you want
to verify AS-SET recursion and ultimately expansion into prefixes,
point your whois client toward filtergen.level3.net [1] and/or
filtergen.dan.me.uk [2]

--Adam

[1] But be careful because L3 filtergen doesn't recurse across
registries and will ignore data that's not source: LEVEL3 +unless* you
put 'remarks: Level3 members: RADB::AS-FOO' in the AS-SET.

[2] If you instead want to filtergen against RADB data (and objects
which RADB mirrors from others) see https://www.dan.me.uk/filtergen

Re: DNS hijack?

[Jeff Shultz]

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
> >
> >2dpnr.org. 300 IN A 208.91.197.132
>
> 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 64.130.200.16 -
> which seems to give correct answers - or to 208.91.197.132 - which
> replies even for nonexisting domain names.
>
> Lesson: don't use a name as an argument to dig's @
>


I think 208.91.197.132 (Network Solution's domain bucket) needs to go in
everyone's troubleshooting notebook as a sign there is an expired domain
somewhere affecting whatever you have going wrong.

-- 
Jeff Shultz

-- 
Like us on Social Media for News, Promotions, and other information!!

   
      
      
      














_ This message 
contains confidential information and is intended only for the individual 
named. If you are not the named addressee you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately by 
e-mail if you have received this e-mail by mistake and delete this e-mail 
from your system. E-mail transmission cannot be guaranteed to be secure or 
error-free as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses. The sender therefore does 
not accept liability for any errors or omissions in the contents of this 
message, which arise as a result of e-mail transmission. _

Re: DNS hijack?

[Stephane Bortzmeyer]

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 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 64.130.200.16 -
which seems to give correct answers - or to 208.91.197.132 - which
replies even for nonexisting domain names.

Lesson: don't use a name as an argument to dig's @

RE: Geolocation for Disney Plus

[Kevin McCormick]

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 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 
mailto:m...@geordish.org>> wrote:

Check out this link.
https://thebrotherswisp.com/index.php/geo-and-vpn/

On Fri, 12 Nov 2021 at 15:51, Drew Weaver 
mailto:drew.wea...@thenap.com>> 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 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 specifically which service D+ uses or is there a “list of 
usual suspects” that you guys check when these sorts of things arise?

I checked google, maxmind and a handful of others and those all know that we 
are in the US.

Thanks,
-Drew

Re: Geolocation for Disney Plus

[Jim Troutman]

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 had already done
what they could to escalate it.  We were also told that it would probably
not be fixed unless we had all of our customers call Disney directly and
complain.

It ultimately took several alternative contacts and some nice folks
reaching out to me directly after posting to this list.  And they had to
escalate internally.

Overall, pretty incompetent for the world’s largest media company.


On Fri, Nov 12, 2021 at 2:07 PM Norman Jester  wrote:

> 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  wrote:
>
> 
>
> 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 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 specifically which service D+ uses or is there a “list
>> of usual suspects” that you guys check when these sorts of things arise?
>>
>>
>>
>> I checked google, maxmind and a handful of others and those all know that
>> we are in the US.
>>
>>
>>
>> Thanks,
>>
>> -Drew
>>
> --
Jim Troutman,
jamesltrout...@gmail.com
Pronouns: he/him/his
207-514-5676 (cell)

Re: Geolocation for Disney Plus

[Norman Jester]

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  wrote:
> 
> 
> 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 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 specifically which service D+ uses or is there a “list of 
>> usual suspects” that you guys check when these sorts of things arise?
>> 
>>  
>> 
>> I checked google, maxmind and a handful of others and those all know that we 
>> are in the US.
>> 
>>  
>> 
>> Thanks,
>> 
>> -Drew

Weekly Global IPv4 Routing Table Report

[Routing Table Analysis Role Account]

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 bgp-st...@lists.apnic.net

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

If you have any comments please contact Philip Smith .

Global IPv4 Routing Table Report   04:00 +10GMT Sat 13 Nov, 2021

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

Analysis Summary


BGP routing table entries examined:  871023
Prefixes after maximum aggregation (per Origin AS):  329373
Deaggregation factor:  2.64
Unique aggregates announced (without unneeded subnets):  421022
Total ASes present in the Internet Routing Table: 72294
Prefixes per ASN: 12.05
Origin-only ASes present in the Internet Routing Table:   62097
Origin ASes announcing only one prefix:   25623
Transit ASes present in the Internet Routing Table:   10197
Transit-only ASes present in the Internet Routing Table:356
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  53
Max AS path prepend of ASN (265020)  50
Prefixes from unregistered ASNs in the Routing Table:   864
Number of instances of unregistered ASNs:   868
Number of 32-bit ASNs allocated by the RIRs:  37805
Number of 32-bit ASNs visible in the Routing Table:   31370
Prefixes from 32-bit ASNs in the Routing Table:  144615
Number of bogon 32-bit ASNs visible in the Routing Table:25
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:427
Number of addresses announced to Internet:   3071879936
Equivalent to 183 /8s, 25 /16s and 43 /24s
Percentage of available address space announced:   83.0
Percentage of allocated address space announced:   83.0
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  290647

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   230878
Total APNIC prefixes after maximum aggregation:   64823
APNIC Deaggregation factor:3.56
Prefixes being announced from the APNIC address blocks:  225931
Unique aggregates announced from the APNIC address blocks:92904
APNIC Region origin ASes present in the Internet Routing Table:   12105
APNIC Prefixes per ASN:   18.66
APNIC Region origin ASes announcing only one prefix:   3455
APNIC Region transit ASes present in the Internet Routing Table:   1696
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 27
Number of APNIC region 32-bit ASNs visible in the Routing Table:   7278
Number of APNIC addresses announced to Internet:  773269632
Equivalent to 46 /8s, 23 /16s and 40 /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-151865
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:255823
Total ARIN prefixes after maximum aggregation:   118120
ARIN Deaggregation factor: 2.17
Prefixes being announced from the ARIN address blocks:   255977
Unique aggregates announced from the ARIN address blocks:122546
ARIN Region origin ASes present in the Internet Routing Table:18948
ARIN Prefixes per ASN:13.51

Re: Geolocation for Disney Plus

[Dave Bell]

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 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 specifically which service D+ uses or is there a “list of
> usual suspects” that you guys check when these sorts of things arise?
>
>
>
> I checked google, maxmind and a handful of others and those all know that
> we are in the US.
>
>
>
> Thanks,
>
> -Drew
>

Re: DNS hijack?

[Richard]

> 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 that my domain was
> available for renew or purchase.
> 
> I hit my registrar, DirectNic, and found I'm good through 2023.
> They pulled up DNS checker and found that a bunch of DNS servers
> were showing 208.91.197.132 as the IP for the domain. It's actually
> in 64.130.197.x .

You have two nameservers listed:

  Domain Name: 2DPNR.ORG

  Name Server: GATEWAY.WVI.COM
  Name Server: VOYAGER.VISER.NET


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

The other one is returning the 64.nnn number.

So, the issue is somewhere in your dns.

Re: DNS hijack?

[Jeff Shultz]

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 again.
>
> queries for bar.com suddenly show up as "this domain is
> available" due to foo.com (which provides DNS for bar.com)
> having briefly gone into the expired state.  Users of bar.com
> are (rightly) confused, as bar.com was never in a jeopardy
> state.
>
> We'll see if Jeff confirms my suspicion of what happened
> in this case.   ^_^;
>
> Matt
>
>

That's exactly what happened, exacerbated by foo.com's domain registration
being held in the account of a now retired employee, so we got no
notifications on it (his email was... somewhat personalized over 20+ years
of managing it).

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.

-- 
Jeff Shultz

-- 
Like us on Social Media for News, Promotions, and other information!!

   
      
      
      














_ This message 
contains confidential information and is intended only for the individual 
named. If you are not the named addressee you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately by 
e-mail if you have received this e-mail by mistake and delete this e-mail 
from your system. E-mail transmission cannot be guaranteed to be secure or 
error-free as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses. The sender therefore does 
not accept liability for any errors or omissions in the contents of this 
message, which arise as a result of e-mail transmission. _

Validating multi-path in production?

[Adam Thompson]

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.)

Some of these issues were fairly obvious when they happened, but some were 
really hard to pin down.

We've found that typical network monitoring tools (Observium & Smokeping, not 
to mention plain old ping and traceroute) can't really detect a hashing-related 
or multi-path-related problem: either the packets get through or they don't.

Can anyone recommend either tools or techniques to validate that multi-path 
forwarding either is, or isn't, working correctly in a production network?  I'm 
looking to add something to our test suite for when we make changes to critical 
network gear.  Almost all the scenarios I want to test only involve two paths, 
if that helps.

The best I've come up with so far is to have two test systems (typically VMs) 
that use adjacent IP addresses and adjacent MAC addresses, and test both 
inbound and outbound to/from those, blindly trusting/hoping that hashing 
algorithms will probably exercise both paths.

Some of the problems we've seen show that merely looking at interface counters 
is insufficient, so I'm trying to find an explicit proof, not implicit.

Any suggestions?  Surely other vendors and/or admins have screwed this up in 
subtle ways enough times that this knowledge exists?  (My Google-fu is usually 
pretty good, but I'm striking out - maybe I'm using the wrong terms.)

-Adam

Adam Thompson
Consultant, Infrastructure Services
[1593169877849]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca
www.merlin.mb.ca

Geolocation for Disney Plus

[Drew Weaver]

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 specifically which service D+ uses or is there a "list of 
usual suspects" that you guys check when these sorts of things arise?

I checked google, maxmind and a handful of others and those all know that we 
are in the US.

Thanks,
-Drew

Re: DNS hijack?

[Matthew Petach]

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 that IP.
> > Even though those domains are perfectly legit and paid up. Or so it was
> explained to me and how it appeared.
>
> Hi Jeff,
>
> Do you mean that there's a delay between when you're recorded as
> having paid up and when everything is correct throughout the DNS
> system? Yes, there is. Your domain expired, you corrected the problem,
> but then there was an unexpected (by you) delay before the interloping
> name resolution was gone?
>
> If you meant something else, I'd like to hear a better description of
> the problem. If not... well of course: that's how the DNS works.
> There's propagation delay imposed by TTLs and refresh intervals before
> old data is discarded. There are a handful of scenarios (e.g.
> old-school browser pinning) where stale data can persist for months.
> Don't let the domain expire before you renew it. Really don't.
>

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 again.

queries for bar.com suddenly show up as "this domain is
available" due to foo.com (which provides DNS for bar.com)
having briefly gone into the expired state.  Users of bar.com
are (rightly) confused, as bar.com was never in a jeopardy
state.

We'll see if Jeff confirms my suspicion of what happened
in this case.   ^_^;

Matt

Re: DNS hijack?

[William Herrin]

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 paid up. Or so it was 
> explained to me and how it appeared.

Hi Jeff,

Do you mean that there's a delay between when you're recorded as
having paid up and when everything is correct throughout the DNS
system? Yes, there is. Your domain expired, you corrected the problem,
but then there was an unexpected (by you) delay before the interloping
name resolution was gone?

If you meant something else, I'd like to hear a better description of
the problem. If not... well of course: that's how the DNS works.
There's propagation delay imposed by TTLs and refresh intervals before
old data is discarded. There are a handful of scenarios (e.g.
old-school browser pinning) where stale data can persist for months.
Don't let the domain expire before you renew it. Really don't.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: DNS hijack?

[Stephane Bortzmeyer]

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 multi-year registration, and/or automatic
  renewal, so you no longer have to think of it,
* automatic entries in your agenda software is nice, too :-)
* automatic monitoring of expiration (through whois or, better, RDAP,
  later is an example of a Nagios/Icinga/whatever plugin using RDAP).

% /usr/local/lib/nagios/plugins/check_expire -H 2dpnr.org
2dpnr.org OK: expires in 497 days, 13:36:22.602780.