[alto] Warren Kumari's Discuss on draft-ietf-alto-xdom-disc-04: (with DISCUSS)

[Warren Kumari <[e-mail]>]

Warren Kumari has entered the following ballot position for
draft-ietf-alto-xdom-disc-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-alto-xdom-disc/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Note: I have not completed my review in detail (and so it may be answered
further down), but I wanted to get this in early...

I'm in no way an ALTO expert (I can barely spell it), so am hoping that I'm
missing something obvious, but I'm really concerned by the scaling implications
/ cost shifting of this.

Let's say this suddenly becomes very popular -- Apple includes this in the iOS
App Store / iMessage app, or Chrome / Firefox decides to start doing this to
find the best datacenter to send traffic to or something...

Until the huge majority of ISPs start answering with these records for all of
their subnets, it seems like there could be a sizable amount of traffic hitting
a: the ISPs recursive servers, b: RIRs, and possibly c: AS112 servers.

E.g: The address I get when I lookup www.google.com is 216.58.193.164.
These are the lookups I'd need to do (I think!) if my $application (or, more
worrying, framework / browser) were to use this:

wkumari$ dig +nocomment +nostats +nocmd NAPTR 164.193.58.216.in-addr.arpa
;164.193.58.216.in-addr.arpa.   IN      NAPTR
193.58.216.in-addr.arpa. 59     IN      SOA     ns1.google.com.
dns-admin.google.com. 226022060 900 900 1800 60

wkumari$ dig +nocomment +nostats +nocmd NAPTR 193.58.216.in-addr.arpa
;193.58.216.in-addr.arpa.       IN      NAPTR
193.58.216.in-addr.arpa. 59     IN      SOA     ns1.google.com.
dns-admin.google.com. 225983176 900 900 1800 60

wkumari$ dig +nocomment +nostats +nocmd NAPTR 58.216.in-addr.arpa
;58.216.in-addr.arpa.           IN      NAPTR
216.in-addr.arpa.       1539    IN      SOA     z.arin.net. dns-ops.arin.net.
2017026288 1800 900 691200 10800

wkumari$ dig +nocomment +nostats +nocmd NAPTR 216.in-addr.arpa
;216.in-addr.arpa.              IN      NAPTR
216.in-addr.arpa.       1665    IN      SOA     z.arin.net. dns-ops.arin.net.
2017026288 1800 900 691200 10800

This is 4 lookups per host / app / connection hitting my recursive servers. In
addition 2 of them hit Google's resolvers, and 2 hit ARINs. Yes, ARIN already
gets many "reverse" queries, and my recursive already does lots of lookups, but
the document doesn't (that I could see) discuss the potential fallout from
potentially *lots* more load. Caching is only slightly effective here -- there
are many many subnets, and e.g the ARIN NoData,NoError response will be cached
for 1800 seconds (30 minutes).

There are other examples -- for example, my laptop is currently on
192.168.0.65. If I try connect to 192.168.1.2 using an app which implements
this, I'll have 4 queries hitting my recursive server (3 of which will get
NXDOMAIN) and 192.in-addr.arpa. hitting ARINs servers.

I'm assuming that I must be missing something obvious here, because I cannot
see how the above sounds reasonable.