I understand your question. It's good. I think an ISP could probaly register the SRV record of the local ALTO server to each of the DNS server for the access network domain (that retrieved from the DHCP option) that this particular ALTO server covers. Then it does not need to do this kind of strip leftmost iterative lookup.
Initially, I had thought of mapping IP addresses to domain names using reverse lookup of DNS (just like BEP-22), but that domain name may not be relative to your access network. So it will bring problems if the ALTO server provider (ISP) wants to register its ALTO server record to that domain. Thanks! Haibin >-----Original Message----- >From: Thomson, Martin [mailto:[email protected]] >Sent: Tuesday, July 14, 2009 7:57 AM >To: John Leslie; Song Haibin >Cc: [email protected]; TOMSU, Marco; [email protected] >Subject: RE: [alto] [Alto-disc] [Fwd: New Version >Notificationfordraft-song-alto-server-discovery-01] > >+1 > >We once proposed exactly the same mechanism. It wasn't popular. > >There's no reason why the parent domain has any particular >ability to provide the information you are looking for. Add >to that the cases John pointed to where it's going to do harm, >and you end up in trouble. > >There's a tendency to think of the DNS hierarchy as mapping to >other hierarchical systems, such as the networks linking a >host to the Internet. This is demonstrably not the case. >There's an (IAB?) RFC that covers the topic, but I can't >remember its number nor find it; I'll leave that to the experts. > >--Martin > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf >> Of John Leslie >> Sent: Monday, 13 July 2009 10:29 PM >> To: Song Haibin >> Cc: [email protected]; 'TOMSU, Marco'; [email protected] >> Subject: Re: [alto] [Alto-disc] [Fwd: New Version >> Notificationfordraft- song-alto-server-discovery-01] >> >> Song Haibin <[email protected]> wrote: >> > >> > Here is the link for the merged document. More comments are >> appreciated! >> > >> > http://tools.ietf.org/id/draft-song-alto-server-discovery-01.txt >> >> One quick comment: >> ] >> ] 5.1.2.1. Using DHCP option for access domain name ] ] There are >> DHCP options (OPTION_V4_ACCESS_DOMAIN and ] >OPTION_V6_ACCESS_DOMAIN) >> proposed in [I-D.ietf-geopriv-lis- discovery] ] to discover >the local >> access domain names. The retrieved access ] domain name >can be used >> to form a SRV name by prefixing the ALTO ] service label to the >> access domain name. If it failed with the SRV ] lookup with this >> service name, then it will remove one tag from the ] left >hand of the >> access domain name and prefix the ALTO service label ] to >form a new >> SRV name. It will iterate the process until it ] succeeds >in getting >> an ATLO server information or failed. >> >> This iterative process can lead to problems, both in that it will >> search towards Top-Level-Domains that have no relation to >the network >> to which the host is actually attached, and in that (if ALTO usage >> grows) >> it could generate excessive (and pointless) DNS queries at >or near the >> Top-Level-Domain servers. >> >> In particular, note that many of the .us locality servers have >> limited bandwidth; and I'm sure there are other Country-Code servers >> whose bandwidth is even more limited. >> >> I recommend caution in applying this strip-the-leftmost >tactic even >> once, and strongly recommend against applying it iteratively without >> limit. >> >> If used at all, there is a need for a standardized signal to say >> "Search no further". >> >> -- >> John Leslie <[email protected]> >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto > >--------------------------------------------------------------- >--------------------------------- >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >--------------------------------------------------------------- >--------------------------------- >[mf2] > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
