Looking to work through GeoIP issue with Square
My google-fu is failing me - I'm looking to find out which GeoIP service Square uses, or a path to work through a GeoIP issue with them. A client of ours uses Square and unfortunately one of the blocks (23.247.204.0/22) we received at ARIN was at one time associated with France. As you can imagine, they've geo-fenced some of their financial services. The GeoIP issue was fixed on MaxMind many months ago, and another client worked through this issue with AWS, but apparently Square uses yet another data source. If someone can help me on or pm me off-list, that would be great. Thanks, Frank AS53347 AS18883
CHI-NOG11 - Agenda - May 11th
We are pleased to announce that the Chicago Network Operators Group will host their 11th annual conference (CHI-NOG 11) on May 11th, 2023 in Chicago, IL. Stop by and see our great agenda. Presentations - Design and Implementation of the Illinois Express Quantum Metropolitan Area Network by Joaquin Chung (University of Chicago) - Seeing the Light: How Optical Transceiver Analytics Can Illuminate Your Data by Javier Antich (Selector AI) - gRIBI – an open interface for programming your RIB by Steve Ulrich (Arista) - Stand Up for Your Routes! Using the Resource Public Key Infrastructure (RPKI) by Brad Gorman (ARIN) - Blockchain in Networking by Mike McBride (Futurewei) - Peering Automation Then and Now by Matt Griswold (FullCtl) - A Small Data Approach to Flow Analysis by Shannon Weyrick (Netbox Labs) - Documentation, Automation, Verification, Oh my! by Dan Kelcher (IP Fabric) - WISP Network Practices and Technologies by Justin Wilson (J2 Consulting) - Simplifying Network Observability Device Onboarding with Nautobot by Nate Gotz (Network to Code) Detailed agenda can be found at https://chinog.org/chi-nog-11/agenda-11/ Registration is still open, but ending soon. For more details please see https://chinog.org/chi-nog-11/registration/ Thank you Tom Kacprzynski
Re: Reverse DNS for eyeballs?
On Fri, 21 Apr 2023 at 20:44, Jason Healy via NANOG wrote: > This is not intended as snark: what do people recommend for IPv6? I try to > maintain forward/reverse for all my server/infrastructure equipment. But > clients? They're making up temporary addresses all day long. So far, I've > given up on trying to keep track of those addresses, even though it's a > network under my direct control. Stateless generation at query time - https://github.com/cmouse/pdns-v6-autorev/blob/master/rev.pl I wrote some POCs quite bit long ago http://p.ip.fi/L5PK - base36 http://p.ip.fi/CAtB - rfc2289 -- ++ytti
Re: Reverse DNS for eyeballs?
We actually manually list our customer ranges in pbl, or at least used to. Probably something else that I need to check on. On Fri, Apr 21, 2023, 8:04 AM Lukas Tribus wrote: > Hello, > > > without PTRs you will probably get your prefixes listed in things like > Spamhouse PBL. So adding the correct PTR for a mailserver may not be > enough, as services like that love to classify entire IP blocks. Of > course Spamhaus provides the tools to fix this issue. But what if > there are 4 - 5 other services like that? Do you want to go down that > rabbit hole, everytime you turn up a mailserver in your prefix? > > I also think reverse DNS records are useful when you have discussions > with content providers for all sorts of reasons like geolocation > issues or "VPN" classifications. > > Of course whois/irr records are the proper tools for this. But if I > have to discuss my IP ranges with some first level support desk at a > large content provider, everything that stands out negatively will > impact my chances of actually getting it done and how fast it will get > done. > > > Considering how subjective IP classifications are, I will not return > NXDOMAIN for v4 addresses if there is even a small chance that it will > make my life harder at some point in the future. > > > Lukas >
Weekly Global IPv4 Routing Table Report
This is an automated weekly mailing describing the state of the 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 https://thyme.apnic.net. If you have any comments please contact Philip Smith . IPv4 Routing Table Report 04:00 +10GMT Sat 22 Apr, 2023 BGP Table (Global) as seen in Japan. Report Website: https://thyme.apnic.net Detailed Analysis: https://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 918940 Prefixes after maximum aggregation (per Origin AS): 348842 Deaggregation factor: 2.63 Unique aggregates announced (without unneeded subnets): 448780 Total ASes present in the Internet Routing Table: 74349 Prefixes per ASN: 12.36 Origin-only ASes present in the Internet Routing Table: 63776 Origin ASes announcing only one prefix: 26197 Transit ASes present in the Internet Routing Table: 10573 Transit-only ASes present in the Internet Routing Table:439 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 55 Max AS path prepend of ASN (265020) 50 Prefixes from unregistered ASNs in the Routing Table: 1361 Number of instances of unregistered ASNs: 1361 Number of 32-bit ASNs allocated by the RIRs: 41703 Number of 32-bit ASNs visible in the Routing Table: 34496 Prefixes from 32-bit ASNs in the Routing Table: 170505 Number of bogon 32-bit ASNs visible in the Routing Table:13 Special use prefixes present in the Routing Table:1 Prefixes being announced from unallocated address space:857 Number of addresses announced to Internet: 3061027072 Equivalent to 182 /8s, 115 /16s and 145 /24s Percentage of available address space announced: 82.7 Percentage of allocated address space announced: 82.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.6 Total number of prefixes smaller than registry allocations: 307074 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 242581 Total APNIC prefixes after maximum aggregation: 69276 APNIC Deaggregation factor:3.50 Prefixes being announced from the APNIC address blocks: 236874 Unique aggregates announced from the APNIC address blocks:97897 APNIC Region origin ASes present in the Internet Routing Table: 13392 APNIC Prefixes per ASN: 17.69 APNIC Region origin ASes announcing only one prefix: 3937 APNIC Region transit ASes present in the Internet Routing Table: 1801 Average APNIC Region AS path length visible:4.5 Max APNIC Region AS path length visible: 32 Number of APNIC region 32-bit ASNs visible in the Routing Table: 8693 Number of APNIC addresses announced to Internet: 773697152 Equivalent to 46 /8s, 29 /16s and 174 /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:268810 Total ARIN prefixes after maximum aggregation: 122340 ARIN Deaggregation factor: 2.20 Prefixes being announced from the ARIN address blocks: 271345 Unique aggregates announced from the ARIN address blocks:130919 ARIN Region origin ASes present in the Internet Routing Table:19084 ARIN Prefixes per ASN:
Re: Reverse DNS for eyeballs?
Once upon a time, heasley said: > I view complete DNS coverage to be a basic function. All used addresses > should have forward and matching reverse records. But why? It's not like anybody can trust what's in a reverse DNS string, even if it has matching forward. If I'm looking for "ownership", I'm going to registries, not DNS. Since it can't be guaranteed (or even flagged as) maintained, you can't trust any information in that string. -- Chris Adams
Re: Reverse DNS for eyeballs?
> I view complete DNS coverage to be a basic function. All used addresses > should have forward and matching reverse records. This is not intended as snark: what do people recommend for IPv6? I try to maintain forward/reverse for all my server/infrastructure equipment. But clients? They're making up temporary addresses all day long. So far, I've given up on trying to keep track of those addresses, even though it's a network under my direct control. Thanks, Jason
Re: Reverse DNS for eyeballs?
Fri, Apr 21, 2023 at 07:37:49AM -0500, Chris Adams: > Once upon a time, Forrest Christian (List Account) > said: > > I have a feeling that I might be stepping into a can of worms by asking > > this, but.. > > > > What's the current thinking around reverse DNS on IPs used by typical > > residential/ small business customers. > > I don't see any benefit to programmatically-generated reverse DNS. I > stopped setting it up a long time ago now. Really, reverse DNS these > days is mostly only useful for: > > - mail servers (where it shows a modicum of control and clue) > - infrastructure/router IPs (so mtr/traceroute can show useful info) I view complete DNS coverage to be a basic function. All used addresses should have forward and matching reverse records. This is not difficult stuff. Bonus points for including a clli code or similar indicating the general location of use for uses like network device interfaces, commodity end-users, etc; also not difficult stuff. You are tracking your allocations, right? Programmatically generating your device configurations? So, generate DNS from that same database(s).
Re: Reverse DNS for eyeballs?
Hello, without PTRs you will probably get your prefixes listed in things like Spamhouse PBL. So adding the correct PTR for a mailserver may not be enough, as services like that love to classify entire IP blocks. Of course Spamhaus provides the tools to fix this issue. But what if there are 4 - 5 other services like that? Do you want to go down that rabbit hole, everytime you turn up a mailserver in your prefix? I also think reverse DNS records are useful when you have discussions with content providers for all sorts of reasons like geolocation issues or "VPN" classifications. Of course whois/irr records are the proper tools for this. But if I have to discuss my IP ranges with some first level support desk at a large content provider, everything that stands out negatively will impact my chances of actually getting it done and how fast it will get done. Considering how subjective IP classifications are, I will not return NXDOMAIN for v4 addresses if there is even a small chance that it will make my life harder at some point in the future. Lukas
Re: Reverse DNS for eyeballs?
On 4/21/23 14:37, Chris Adams wrote: I don't see any benefit to programmatically-generated reverse DNS. I stopped setting it up a long time ago now. Really, reverse DNS these days is mostly only useful for: - mail servers (where it shows a modicum of control and clue) - infrastructure/router IPs (so mtr/traceroute can show useful info) Agreed. Mark.
Re: Reverse DNS for eyeballs?
On 4/21/23 15:02, Frank Habicht wrote: I would say the absence of reverse DNS tells useful info to receiving MTAs - to preferably not accept. As does a randomly-generated one... Mark.
Re: Reverse DNS for eyeballs?
On Fri, Apr 21, 2023 at 5:40 AM Chris Adams wrote: > Once upon a time, Forrest Christian (List Account) > said: > > I have a feeling that I might be stepping into a can of worms by asking > > this, but.. > > > > What's the current thinking around reverse DNS on IPs used by typical > > residential/ small business customers. > > I don't see any benefit to programmatically-generated reverse DNS. I > stopped setting it up a long time ago now. Really, reverse DNS these > days is mostly only useful for: > > - mail servers (where it shows a modicum of control and clue) > - infrastructure/router IPs (so mtr/traceroute can show useful info) > Same > -- > Chris Adams >
Re: Reverse DNS for eyeballs?
On 21/04/2023 15:37, Chris Adams wrote: I don't see any benefit to programmatically-generated reverse DNS. I stopped setting it up a long time ago now. Really, reverse DNS these days is mostly only useful for: - mail servers (where it shows a modicum of control and clue) - infrastructure/router IPs (so mtr/traceroute can show useful info) I would say the absence of reverse DNS tells useful info to receiving MTAs - to preferably not accept. Frank
Re: Reverse DNS for eyeballs?
Once upon a time, Forrest Christian (List Account) said: > I have a feeling that I might be stepping into a can of worms by asking > this, but.. > > What's the current thinking around reverse DNS on IPs used by typical > residential/ small business customers. I don't see any benefit to programmatically-generated reverse DNS. I stopped setting it up a long time ago now. Really, reverse DNS these days is mostly only useful for: - mail servers (where it shows a modicum of control and clue) - infrastructure/router IPs (so mtr/traceroute can show useful info) -- Chris Adams
Re: Reverse DNS for eyeballs?
> On Apr 21, 2023, at 11:38 AM, Forrest Christian (List Account) > wrote: > What's the current thinking around reverse DNS on IPs used by typical > residential/ small business customers? > I'm not talking about reverse dns for infrastructure/router IPs here, as I > still feel those need to be kept up to date. This is just for the individual > end user IPs. I think it’s really useful… but as IPv4 becomes a thing of the past, it probably needs to be supplied dynamically by a plug-in to your nameserver, rather than in giant static tables. -Bill
Reverse DNS for eyeballs?
I have a feeling that I might be stepping into a can of worms by asking this, but.. What's the current thinking around reverse DNS on IPs used by typical residential/ small business customers. Way way back in the day I used to generate "filler" reverse dns for all of these ranges .. that is, records like "45.100.51.198.in-addr.arpa IN PTR 198-51-100‐45.dialup.example.com", and then add a forward A record to match. We had a procedure to override this generic domain upon customer request when a static IP was assigned, such as for a mail server. As time has marched on, and other people were responsible for the reverse dns zones, cruft from old customers no longer with us has accumulated in the reverse DNS override file and I recently discovered that many newer ranges are either nonexistent or not updated. As I'm in the process of cleaning up several other related messes, I'm feeling I should clean this one up too. I've kinda felt for a while now that reverse dns isn't really needed for the customer IPs but before I dump the whole thing overboard and switch to returning NXDOMAIN unless the customer really needs a reverse dns record I figured I'd ask what the current thinking is for these among the internet community. I'm not talking about reverse dns for infrastructure/router IPs here, as I still feel those need to be kept up to date. This is just for the individual end user IPs.
