Re: more spaces in PTRs, this time totisp.net
on Fri, Oct 22, 2021 at 04:05:44AM +, Steven Champeon wrote: > > Anyone? FWIW, I took a look at my scans data and there's a lot of this around. Of the 5477 PTRs with spaces, in approximately ~490 domains*, those with more than twenty hosts with PTRs containing spaces are the following: 2178 bbox.fr (still) 961 misc (basically, domains that don't exist, garbage rdns, etc.) 255 yorku.ca 203 hostforweb.com 157 teknotel.com 156 uncg.edu 129 lacoe.edu 55 is.co.mz 52 uni-bonn.de 41 ncsu.edu 41 bell.ca** 40 fuse.net 36 dartmouth.edu 27 gatech.edu 26 uni-goettingen.de 25 isu.edu 25 csub.edu 21 qut.edu.au Anyone from these orgs that cares can contact me offlist for more info, or as someone who saw the bbox.fr post did, forward to the relevant people and ask them to do the same. FWIW, some involve leading, some involve trailing, but most contain spaces in the labels themselves. * FSVO "domain" ** I had a contact at bell.ca but she has since retired and they have apparently kept introducing more bad rDNS. TIA, Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ Internet security and antispam hostname intelligence: http://enemieslist.com/
Re: Network visibility
Seth Breidbart has the last word on this point, I think: The Internet is "the largest equivalence class in the reflexive, transitive, symmetric closure of the relationship 'can be reached by an IP packet from'." The associated press can bite me. Nice! Miles -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. In our lab, theory and practice are combined: nothing works and no one knows why. ... unknown
Re: Network visibility
> But I will capitalize Internet in all relevant uses. > > This is an *engineering definition*, it matters that you name the right > object, and I am one of the people who will, in fact, die on this hill. You are not alone. > The associated press can bite me. While I respect and appreciate the AP (ap?) in general, in this particular instance, I am with you. -- TTFN, patrick > On Oct 22, 2021, at 01:21, Jay R. Ashworth wrote: > - Original Message - >> From: "Miles Fidelman" > >> Guys, >> >> You guys were in grade school, some of us were there at the beginning >> (well, in my case, 2 years after the beginning). I can assure you that >> folks made a big deal about what was and wasn't the Internet, and the >> distinction between "an internet" and "the (capital I) Internet." >> Opinions varied then, and opinions vary now. >> >> But... by and large, as I understand the general zeitgeist: >> >> - you're either on the Internet, or you're not - the key question is >> whether you can send & receive IP packets from the public address space >> (i.e., the classified segments are internets, but not part of THE >> Internet). There are also disagreements on where the Internet ends - at >> the demarc, or at the IP stack in your machine (I argue the latter, but >> that's debatable) > > Seth Breidbart has the last word on this point, I think: > > The Internet is "the largest equivalence class in the reflexive, transitive, > symmetric closure of the relationship 'can be reached by an IP packet from'." > > The associated press has, in the last year or two, disparaged the > capitalization > of the word Internet, proving they do not understand there's a difference. > > If they won't capitalize "my" name, I won't capitalize theirs. > > But I will capitalize Internet in all relevant uses. > > This is an *engineering definition*, it matters that you name the right > object, and I am one of the people who will, in fact, die on this hill. > > The associated press can bite me. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > j...@baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Weekly Global IPv4 Routing Table Report
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.rand.apnic.net. If you have any comments please contact Philip Smith . Global IPv4 Routing Table Report 04:00 +10GMT Sat 23 Oct, 2021 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 867554 Prefixes after maximum aggregation (per Origin AS): 329940 Deaggregation factor: 2.63 Unique aggregates announced (without unneeded subnets): 419703 Total ASes present in the Internet Routing Table: 72150 Prefixes per ASN: 12.02 Origin-only ASes present in the Internet Routing Table: 61971 Origin ASes announcing only one prefix: 25553 Transit ASes present in the Internet Routing Table: 10179 Transit-only ASes present in the Internet Routing Table:348 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 53 Max AS path prepend of ASN (265020) 50 Prefixes from unregistered ASNs in the Routing Table: 920 Number of instances of unregistered ASNs: 924 Number of 32-bit ASNs allocated by the RIRs: 37600 Number of 32-bit ASNs visible in the Routing Table: 31219 Prefixes from 32-bit ASNs in the Routing Table: 145632 Number of bogon 32-bit ASNs visible in the Routing Table:22 Special use prefixes present in the Routing Table:1 Prefixes being announced from unallocated address space:417 Number of addresses announced to Internet: 3071270144 Equivalent to 183 /8s, 15 /16s and 221 /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: 288266 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 231716 Total APNIC prefixes after maximum aggregation: 66510 APNIC Deaggregation factor:3.48 Prefixes being announced from the APNIC address blocks: 227141 Unique aggregates announced from the APNIC address blocks:92521 APNIC Region origin ASes present in the Internet Routing Table: 12039 APNIC Prefixes per ASN: 18.87 APNIC Region origin ASes announcing only one prefix: 3422 APNIC Region transit ASes present in the Internet Routing Table: 1700 Average APNIC Region AS path length visible:4.6 Max APNIC Region AS path length visible: 37 Number of APNIC region 32-bit ASNs visible in the Routing Table: 7211 Number of APNIC addresses announced to Internet: 773052288 Equivalent to 46 /8s, 19 /16s and 215 /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:254633 Total ARIN prefixes after maximum aggregation: 117512 ARIN Deaggregation factor: 2.17 Prefixes being announced from the ARIN address blocks: 254543 Unique aggregates announced from the ARIN address blocks:122065 ARIN Region origin ASes present in the Internet Routing Table:18927 ARIN Prefixes per ASN:
Anybody out there from Suddenlink AS19108?
Ping me off-list if so. Please and thank you. --Adam
Re: IPv6 and CDN's
On 10/22/21 18:08, t...@pelican.org wrote: I don't think it'll ever make money, but I think it will reduce costs. CGNAT boxes cost money, operating them costs money, dealing with the support fallout from them costs money. Especially in the residential space, where essentially if the customer calls you, ever, you just blew years' worth of margin. The problem is accurately modelling cost reduction using native IPv6 in lieu of CG-NAT is hard when the folk that need convincing are the CFO's. They are more used to "spend 1 to get 2". Convincing them to "save 2 by spending 1" - not as easy as one may think. Mark.
Re: IPv6 and CDN's
On 10/22/21 17:45, Bryan Fields wrote: Until IPv6 becomes provides a way to make money for the ISP, I don't see it being offered outside of the datacenter. It is being offered, it's just not being adopted. We deliver an IPv6 /126 p2p and /56 or /48 onward assignment to all our DIA customers. No interest. We deliver an IPv6 /125 p2p and eBGP session to all our IP Transit customers. 5/10 are interested. You can only do what you can only do. Mark.
Re: IPv6 and CDN's
Hi again, Op 22-10-21 om 17:13 schreef Job Snijders: Tl;DR Not at all. This was a very interesting read! Thank you. While pondering over it, I noticed that the ns[1234].fastly.net servers are nicely anycasted throughout the globe. If anyone could turn on IPv6 on their authoritatives without therisk of loosing too much performance, I reckon it would be them... our Cloudflare. But they already did it. ;-). > work in progress! I have good hopes. Rumour has it that Fastly employs some very smart people. I'm sure we'll see nice things happening when the time is right. -- Marco
Re: IPv6 and CDN's
On Friday, 22 October, 2021 16:45, "Bryan Fields" said: > Until IPv6 becomes provides a way to make money for the ISP, I don't see it > being offered outside of the datacenter. I don't think it'll ever make money, but I think it will reduce costs. CGNAT boxes cost money, operating them costs money, dealing with the support fallout from them costs money. Especially in the residential space, where essentially if the customer calls you, ever, you just blew years' worth of margin. My residential ISP here in the UK routes me (and every other subscriber) a /56 without being asked. (Their supplied CPE router just puts the first /64 on the LAN and refuses to process PD requests to hand out any of the other /64s, but baby steps...) Cheers, Tim.
Re: IPv6 and CDN's
On 10/22/21 11:13 AM, Job Snijders via NANOG wrote: > Another aspect that flabbergasts me anno 2021 is how there *still* are > BGP peering disputes between (more than two) major global internet service > providers in which IPv6 is 'held hostage' as part of slow commercial > negotiations. Surely end-to-end IPv6 connectivity should be a priority? Even the DNS root servers are not 100% reachable via IPv6. I would think IANA would have some standard about reachability for root operators. FWIW, I just was able to change my home office internet (I reside in the most densely populated county of Florida). The new provider sold me a dual stack connection, however when they came to deliver it, there was no IPv6 as promised. After spending almost a week playing phone tag, I finally got some one with clue. I was told they have no support if IPv6 and no plans to ever support IPv6 as there is no way to monetize it. This leaves me in the same position as my prior circuit via the local cable co. (no plans to offer IPv6) but at least it's faster than the 2 meg up cable service. Until IPv6 becomes provides a way to make money for the ISP, I don't see it being offered outside of the datacenter. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: IPv6 and CDN's
Hi everyone, goedenmiddag Marco! On Fri, Oct 22, 2021 at 01:40:42PM +0200, Marco Davids via NANOG wrote: > We currently live in times where is actually fun to go IPv6-only. In my > case, as in: running a FreeBSD kernel compiled without the IPv4-stack. Indeed, this is fun experimentation. Shaking the (source code) trees through excercises like these is a valuable way to identify gaps. > It turns out that there underlying CDN's with domain names such as > ‘l-msedge.net’ and ‘trafficmanager.net’ (Microsoft) or 'fastly.net', that > reside on authoritative name servers that *only* have an IPv4 address. As some observant readers noticed (hint: https://ip6.nl/#!deb.debian.org), Fastly is working hard with select customers and friends to support IPv6 for everyone. > I guess my question is simple: Why? > > Are there good architectural reason for this? Or is it just something > that is overlooked and forgotten about? The universal deployment of IPv6 appears to be a multi-decennial multigenerational project. Allow me to shed some light on various aspects. One of the challenges faced by those wishing to deploy IPv6 (compared to IPv4) is how from a BGP Default-Free Zone perspective, IPv4 and IPv6 are not alike at all! The Internet's IPv6 routing topology is vastly different from the IPv4 topology. The above phenomenon is perfectly understandable following from the fact that IPv4 predates IPv6 - and IP networks grow as they grow. In a perfect world the IPv6 network would grow perfectly congruent alongside the global IPv4 network. In this perfect world indeed IPv6 can "just be enabled", and used whenever available! Unfortunately the reality of the situation is far more chaotic! For example if you look at PeeringDB's 'netixlan' table, large discrepancies between the number of absent IPv4 entries and absent IPv6 entries are visible: $ curl -s https://peeringdb.com/api/netixlan | jq '.' | fgrep -c '"ipaddr4": null' 1286 $ curl -s https://peeringdb.com/api/netixlan | jq '.' | fgrep -c '"ipaddr6": null' 8160 >From the above it's implied that the density of the 'IPv4 mesh' is much higher than the density and diversity of the 'IPv6 mesh', simply because more operators present more IPv4 traffic-exchange opportunities to other operators - compared to IPv6. This has performance implications. Another aspect that flabbergasts me anno 2021 is how there *still* are BGP peering disputes between (more than two) major global internet service providers in which IPv6 is 'held hostage' as part of slow commercial negotiations. Surely end-to-end IPv6 connectivity should be a priority? Anyway, back to your question: content delivery networks who leverage all possible technical knobs and buttons to increase performance (such as BGP traffic engineering) might be reluctant to offer IPv6 services "as if they are the same as IPv4". More study is required. Tl;DR - work in progress! :-) Kind regards, Job ps. Have you tried running an IPv6-only RPKI validator? About 1.4% of RPKI VRPs appears to be 'missing' in IPv6-only environments :-/
Re: IPv6 and CDN's
On Fri, 22 Oct 2021, 13:03 Jens Link, wrote: > I ran into this some time ago with deb.debian.org on an IPv6 only Debian > VM with a locally installed resolver. I opened a ticket which was closed > in record time: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961296 > > After some ranting and shouting it now works > I'm going to post the relevant message here: > Sometimes I wonder why I report bugs.. > > But your answer was the answer I was expecting. Thanks for noting. > > So I can summarize this as "The Debian Project doesn't care if IPv6 is working"? Jens, you went into that ticket looking for a fight, in a place staffed by largely unpaid volunteers, choosing to belittle their efforts and then attempting to shame them into action. You even chose to mark the bug severity higher than the default, despite you having chosen that mirror for your install. https://www.debian.org/Bugs/Developer#severities Marco explained to you that the mirror network has plenty of selections to make, but you choose to make a fuss about one supported option not working to a standard the rest of the community pretty much agrees is nowhere near attainable at this time. Using netselect https://packages.debian.org/stable/net/netselect to choose a reachable mirror with the lowest latency would have easily mitigated this issue for you. DNS64 and NAT64 are going to be with us for a very long time, and if you refuse to support IPv4 even through a translation layer then it is clear you are acting against the interests of further IPv6 adoption by associating IPv6 issues with zealotry. The apathy sometimes associated with IPv6 support today is because of this perceived high effort low reward nature of confrontation. I would strongly advise you apologise to Marco for your grandstanding, and adopt a more constructive way of furthering your ideology. The NANOG code of conduct clearly states: https://www.nanog.org/about/code-conduct/ > In the spirit of mutual respect and collaboration, NANOG does not tolerate any unwelcome behavior, including but not limited to: > * Aggressively pushing your own services, products, or causes. > [...] Please join the rest of us in advocating for IPv6 adoption, rather than the current bullying tactics you seem to be choosing that wins the battle and loses the war. We are all friends* here. You can be a great asset in this effort we should all seek. M *FSVO friends, obvs.
Re: DOJ files suit to enforce FCC penalty for robocalls
We have telco's registered in the US, Cyprus and Israel. Lately I'm Europe we have been getting emails from people using protonmail. The conversation dies one we ask for business registration documents. On Thu, Oct 21, 2021, 16:14 Aaron C. de Bruyn via NANOG wrote: > My normal test for this is to register a new domain name and leave my > whois info public. > > Over the span of 1-2 weeks I will usually get 50-100 calls from people > with a certain accent asking for a mispronunciation of my name and if I > need a website developed. Then I forward them over to my spam recording > line. > > I registered a handful of new domains this week, and I've had less than 5 > calls so far. > > -A > > > On Thu, Oct 21, 2021 at 12:13 PM Michael Thomas wrote: > >> >> On 10/21/21 10:57 AM, Sean Donelan wrote: >> > >> > The multi-million dollar fines announced with great fanfaire by the >> > Federal Communication Commission are almost never collected. The FCC >> > doesn't have enforcement authority to collect fines. The FCC usually >> > withholds license renewals until penalties are paid. If the violator >> > doesn't have any FCC licenses (or doesn't care), the FCC is powerless. >> > >> > The FCC refers uncollected penalties to the Department of Justice. In >> > the past, DOJ didn't prioritize uncollected penalties and most fines >> > were never enforced. >> > >> > >> > The Department of Justice Files Suit to Recover $9.9 Million >> > Forfeiture Penalty for Nearly 5,000 Illegally Spoofed Robocalls >> > >> > >> https://www.justice.gov/opa/pr/department-justice-files-suit-recover-forfeiture-penalty-nearly-5000-illegally-spoofed >> > >> >> So has any of the STIR/SHAKEN stuff that was mandated made any >> difference on the ground yet? I assume this is different than what you >> posted about though. >> >> Mike >> >>
Re: Questions about IRR best practices
> 2. On the ARIN side, when ARIN-NONAUTH goes away next year, does that do away > with our ability to do proxy route objects? Do we need to require all of our > BGP customers to set up their own IRRs? Not only ARIN. LACNIC and TC (the two IRRs covering the LAC region, TC for Brazil, LACNIC for Mexico and other Latin American countries) have strict non-proxy policies, and there is no -NONAUTH scape route. > 3. On the RADb side, if we're turning up a new customer that doesn't have an > IRR, and another ISP already has a proxy registration for that customer, is > it sufficient for us to add that customer's AS to our customer AS-SET? The problem with that is all of sudden the covering object could disappear. Rubens
Re: Questions about IRR best practices
Dear Lee, *ring ring* - "IRR/RPKI helpdesk how may I help you today?" :-) On Fri, Oct 22, 2021 at 08:25:10AM -0500, Lee Fawkes wrote: > I have a couple of questions about best practices for Internet Routing > Registries. I'm able to find lots of documentation about *how* to do > things, but not a lot of documentation about when I *should* do things. I > work for a medium-sized ISP in the US, and we are currently using both RADb > and the ARIN IRR. We peer all over the place, but my main concern is how > Cogent and Hurricane Electric build prefix filters from our IRRs. > > 1. Netflix is asking us to add the AS of a downstream customer of one of > our customers to our customer AS-SET. We have a direct relationship with > this organization's provider, but not with this organization itself. Is > this appropriate? 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:'. > 2. On the ARIN side, when ARIN-NONAUTH goes away next year, does that > do away with our ability to do proxy route objects? Do we need to > require all of our BGP customers to set up their own IRRs? 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! 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. These days everyone wants to see firm cryptographic proof! > 3. On the RADb side, if we're turning up a new customer that doesn't have > an IRR, and another ISP already has a proxy registration for that customer, > is it sufficient for us to add that customer's AS to our customer AS-SET? 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?!". 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. > I've been getting around the fact that RADb doesn't allow multiple > proxy registrations by registering proxy route objects in > ARIN-NONAUTH, but that won't be an option much longer, and I can't > really experiment with our customers' route objects to see what works. 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/ Follow up questions welcome! Kind regards, Job
Questions about IRR best practices
Good morning Operators; I have a couple of questions about best practices for Internet Routing Registries. I'm able to find lots of documentation about *how* to do things, but not a lot of documentation about when I *should* do things. I work for a medium-sized ISP in the US, and we are currently using both RADb and the ARIN IRR. We peer all over the place, but my main concern is how Cogent and Hurricane Electric build prefix filters from our IRRs. 1. Netflix is asking us to add the AS of a downstream customer of one of our customers to our customer AS-SET. We have a direct relationship with this organization's provider, but not with this organization itself. Is this appropriate? 2. On the ARIN side, when ARIN-NONAUTH goes away next year, does that do away with our ability to do proxy route objects? Do we need to require all of our BGP customers to set up their own IRRs? 3. On the RADb side, if we're turning up a new customer that doesn't have an IRR, and another ISP already has a proxy registration for that customer, is it sufficient for us to add that customer's AS to our customer AS-SET? I've been getting around the fact that RADb doesn't allow multiple proxy registrations by registering proxy route objects in ARIN-NONAUTH, but that won't be an option much longer, and I can't really experiment with our customers' route objects to see what works. Thanks! -Lee Fawkes
Re: Providing IPv4 Services in an IPv6 Backbone
On 10/22/21 15:19, Jason Iannone wrote: Thanks for sharing. Maybe I have blinders on, but LDPv6 and the v6 SR flavors don't have much use if v4 CE sites aren't supported. Indeed. If your goal is an IPv6-only network with IPv6-only services, then Nokia may have an answer for you. But if you want IPv4-as-a-Service over an IPv6-only network (4PE or 4VPE), then I'd recommend beating up the vendors. I'd start with Nokia, since by all accounts, they seem to be leading the charge at this point. Mark.
Re: Providing IPv4 Services in an IPv6 Backbone
Thanks for sharing. Maybe I have blinders on, but LDPv6 and the v6 SR flavors don't have much use if v4 CE sites aren't supported. Jason On Fri, Oct 22, 2021 at 12:56 AM Mark Tinka wrote: > > > On 10/21/21 21:18, Jason Iannone wrote: > > > > > Hi all, > > > > Have there been any gap closures on RFC7439? I am particularly > > interested in 4PE, 4VPE, and other MPLS enabled services like L3VPN, > > NG-MVPN, E-Line, E-LAN, and EVPN. Does Juniper have an > > "ipv4-tunneling" mpls keyword? > > I posted this here earlier this month: > > https://mailman.nanog.org/pipermail/nanog/2021-October/215609.html > > Unaware of any other vendor who claims to have solved this problem. > > Mark. >
Re: IPv6 and CDN's
Hello, client side IPv6-only is one thing, but IPv6-only recursive DNS resolution is probably so niche that content providers and CDN's do not particularly care at this point in time. On the other hand, there is probably no good reason to run authoritative DNS servers without IPv6 connectivity. Lukas
Re: IPv6 and CDN's
On second thoughts... I seem to have been confused by the 'no records for fastly.net' (as a DNS-purist: that should have said "ns[1234].fastly.net" instead, to make it relevant). ;-) I ran into this some time ago with deb.debian.org Right. So please ignore: Just for the record; your issue is slightly different: You wrote: "deb.debian.org is a CNAME for debian.map.fastly.net. There are no records for fastly.net so any DNS querys from an IPv6 only resolver will not work." -- Marco
Re: IPv6 and CDN's
On 10/22/21 14:03, Jens Link wrote: I don't think it was overlooked or forgotten. More along "We have always done it this way", "We had problems enabling IPv6 (ages ago)" or something else you can find on https://ipv6excuses.com/. I think it's a combination of both... they tried back in the day, it broke, and they "parked" it for later. When Marketing and The World were happy to see that www.insert-favorite-content-url-here.com had and IPv6 PTR records, who cared whether boring, little-known FQDN's were remembered or not. And then, all the engineers moved on to some other gig, where they did better because, why not? Mark.
Re: IPv6 and CDN's
Hi Jens, Op 22-10-21 om 14:03 schreef Jens Link: I ran into this some time ago with deb.debian.org on an IPv6 only Debian VM with a locally installed resolver. I opened a ticket which was closed in record time: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961296 Just for the record; your issue is slightly different: You wrote: "deb.debian.org is a CNAME for debian.map.fastly.net. There are no records for fastly.net so any DNS querys from an IPv6 only resolver will not work." At the moment debian.map.fastly.net has an -record though. The thing is; the authoritative name servers of fastly.net are only willing to hand out that -record via IPv4. So it still doesn't work with the (locally installed) IPv6-only resolver ;-) Cheers, -- Marco
Re: IPv6 and CDN's
Marco Davids via NANOG writes: > It turns out that there underlying CDN's with domain names such as > ‘l-msedge.net’ and ‘trafficmanager.net’ (Microsoft) or 'fastly.net', > that reside on authoritative name servers that *only* have an IPv4 > address. Fastly does have IPv6 enabled authoritative DNS server but it looks like it's not the default. I ran into this some time ago with deb.debian.org on an IPv6 only Debian VM with a locally installed resolver. I opened a ticket which was closed in record time: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961296 After some ranting and shouting it now works but a couple of days ago I ran in the same problem while trying to install something via pip. fles.pythonhosted.org is also using fastly. > I guess my question is simple: Why? I'm asking myself the same question. > Are there good architectural reason for this? Or is it just something > that is overlooked and forgotten about? I don't think it was overlooked or forgotten. More along "We have always done it this way", "We had problems enabling IPv6 (ages ago)" or something else you can find on https://ipv6excuses.com/. Jens -- | Delbrueckstr. 41| 12051 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jensl...@quux.de| --- |
IPv6 and CDN's
Hi! We currently live in times where is actually fun to go IPv6-only. In my case, as in: running a FreeBSD kernel compiled without the IPv4-stack. A few years back doing such thing was mostly disappointing, but nowadays is actually quite doable and entertaining. So, the other day I decided to take this experiment to the next level by disconnecting my local resolver from IPv4 as well. Then things started to break. LinkedIn, Bing, Openstreetmap... Although they all work great on IPv6-only, now they no longer did. It turns out that there underlying CDN's with domain names such as ‘l-msedge.net’ and ‘trafficmanager.net’ (Microsoft) or 'fastly.net', that reside on authoritative name servers that *only* have an IPv4 address. I guess my question is simple: Why? Are there good architectural reason for this? Or is it just something that is overlooked and forgotten about? I would love to find out! Thank you. -- Marco This is also fun by the way. Look at that nice banner on https://clintonwhitehouse2.archives.gov/ :-)
Re: more spaces in PTRs, this time totisp.net
\032 is space. Go read STD13 aka RFC 1034 and RFC 1035. -- Mark Andrews > On 22 Oct 2021, at 16:40, Owen DeLong via NANOG wrote: > > \032 is not a space. > > Decimal 32 (0x20, \040) is a space. > \032 is a Ctrl-Z (26 decimal, 0x1a) > > Owen > > >> On Oct 21, 2021, at 22:14 , Mel Beckman wrote: >> >> Typo I’d say. DB-drive DNS servers, which don’t keep their entries in >> traditional PTR-record text format, can fall victim to this. Rather than >> parse the text every times, they just spit out whatever is in the table >> column, even if it has embedded spaces. I’ve seen this happen in SnitchDNS. >> >> -mel via cell >> On Oct 21, 2021, at 9:08 PM, Steven Champeon wrote: >>> >>> >>> Anyone? >>> >>> 1.179.154.11:1-179-180.11.cisp.totisp.\\ net >>> >>> dig -x 1.179.154.11 >>> >>> 11.154.179.1.in-addr.arpa. 7200INPTR >>> 1-179-180.11.cisp.totisp.\032net. >>> >>> -- >>> hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: >>> http://hesketh.com/ >>> Internet security and antispam hostname intelligence: >>> http://enemieslist.com/ >
Re: more spaces in PTRs, this time totisp.net
On 22/10/2021 06:39, Owen DeLong via NANOG wrote: > \032 is not a space. > > Decimal 32 (0x20, \040) is a space. > \032 is a Ctrl-Z (26 decimal, 0x1a) In DNS zone files (and dig's presentation format) backslashed numbers are in decimal, not octal - RFC 1035, §5.1. Ray
Re: more spaces in PTRs, this time totisp.net
On Friday, 22 October, 2021 06:39, "Owen DeLong via NANOG" said: > \032 is not a space. > > Decimal 32 (0x20, \040) is a space. > \032 is a Ctrl-Z (26 decimal, 0x1a) So, someone trying to "undo" in a GUI editor, or a failed attempt to exit 'vi'? Cheers, Tim.
Fort - Now Available as a FreeBSD Port
For those who run FreeBSD, the Fort RPKI validator is now available in the ports tree: https://www.freshports.org/net/fort/ Many thanks to Toni Kalombo for submitting and maintaining the port, and to Philip Paeps to committing it. I've also sent a note to the Fort developers to update the installation information for FreeBSD. Mark.
Re: more spaces in PTRs, this time totisp.net
Owen, Ah, so a cross-base typo! :) -mel via cell > On Oct 21, 2021, at 10:40 PM, Owen DeLong wrote: > > \032 is not a space. > > Decimal 32 (0x20, \040) is a space. > \032 is a Ctrl-Z (26 decimal, 0x1a) > > Owen > > >> On Oct 21, 2021, at 22:14 , Mel Beckman wrote: >> >> Typo I’d say. DB-drive DNS servers, which don’t keep their entries in >> traditional PTR-record text format, can fall victim to this. Rather than >> parse the text every times, they just spit out whatever is in the table >> column, even if it has embedded spaces. I’ve seen this happen in SnitchDNS. >> >> -mel via cell >> On Oct 21, 2021, at 9:08 PM, Steven Champeon wrote: >>> >>> >>> Anyone? >>> >>> 1.179.154.11:1-179-180.11.cisp.totisp.\\ net >>> >>> dig -x 1.179.154.11 >>> >>> 11.154.179.1.in-addr.arpa. 7200INPTR >>> 1-179-180.11.cisp.totisp.\032net. >>> >>> -- >>> hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: >>> http://hesketh.com/ >>> Internet security and antispam hostname intelligence: >>> http://enemieslist.com/ >
