NTAC Peering Working Group

[Michael H Lambert <>]

Thanks, David! I had lost track of this one. It’s a K12 resolver issue, most 
likely.

Michael

> On 27 Aug 2021, at 08:51, David Farmer <> wrote:
> 
> The prefixes in 17.253.0.0/16 are part of Apple's regionalized CDN; the 
> /24s within it are only announced to peers at a particular peering point.  
> I refer you back to an email that Jeff sent back in 2015, seen below;
> 
> On Fri, Aug 27, 2021 at 06:59 Michael H Lambert <> wrote:
> I don’t know whether or not the Internet2 folks have a sufficient in with 
> Apple on I2PX peering, but we’re seeing the prefix 17.253.120.0/24 over 
> commodity but not I2PX. I don’t think it’s unique in that regard, but 
> having that traffic take a path from Apple over I2PX would be helpful from 
> the standpoint of a member’s commodity policers.
> 
> Michael
> 
> 
> On Wed, Nov 18, 2015 at 18:15 Jeff Bartig <> wrote:
> 
> Peering & Routing WG Members,
> 
> I've been working with Apple since the iOS9 release on issues
> relating to where their geolocation algorithm is directing users
> to download software updates.  Many R&E networks were seeing Apple
> direct their users to Apple download servers that were only available
> via their paid transit and not via TR/CPS or even local peering the
> R&E might have with Apple.
> 
> Apple has made some additional changes in the last 24 hours to their
> geolocation mapping.  They are requesting that R&E networks test
> this and report any issues.  I've created a spreadsheet where I've
> been having various R&E networks record the results of DNS queries:
> 
> https://docs.google.com/spreadsheets/d/1V5cBpmwlWRf0eq4kvl0ctcMDMklyAAB8e8gxTMexQY0/edit?usp=sharing
> 
> If you have a few minutes and could contribute some data, I would
> appreciate it.  I'm basically asking for you to look up the DNS A
> record for "appldnld.apple.com" and then look up the PTR record for
> one of the returned addresses.  Both the A and PTR results can be
> appended to the above spreadsheet along with time and location
> details.
> 
> Apple has pointed out some other issues that may be impacting R&E
> networks receiving Apple traffic via TR/CPS or their own local
> peering with Apple:
> 
> 1.  AS Path Prepending:  in some cases, Apple is seeing the same
> length AS path to a campus via both TR/CPS and a network the campus
> buys transit from.  If this network is one that settlement-free
> peers with Apple, Apple will treat it the same as TR/CPS and may
> choose that path over TR/CPS.  I think a common example of this may
> be Hurricane Electric paid transit.  Prepending towards paid transit
> can encourage traffic to route via TR/CPS, rather than via paid
> transit.
> 
> 2.  Apple is using an end user's DNS resolver IP (recursive DNS
> server) for Geolocation and determining the best path for routing
> to the user.  If the IP network of the DNS server and the IP network
> of the end user are advertised differently via BGP, Apple may pick
> a poor path to the end user.
> 
> 3.  Apple has now established dual routers and server clusters in
> each major city where they peer.  These routers/servers apparently
> are not interconnected.  If you are directed to one cluster, but
> peer with the other, the traffic from Apple may end up taking transit
> to reach the end user, even though there is local peering.  Internet2
> TR/CPS is working on establishing peering with both clusters in
> every city where we privately interconnect with Apple to address
> this issue.
> 
> Thanks for your help,
> 
> Jeff
> 
> --
> Jeff Bartig
> University of Wisconsin
> 
> (608) 262-8336