I have just kicked off the open source project VIRGO-DNS. I will lead my students and other colleagues to implement the draft. I got my Ph.d from 2003, and was senior research assocate in Cardiff University.
The cache route information by applying Zipf's law will make average hops much less than worst hops. By theretical calculation, in the case of total numbers of DNS servers with 1 million, alpha parameter 0.91 cache size is 1000, L is 32, then p is 0.537; and average hops is less than 3. >From: Phil Regnauld <[EMAIL PROTECTED]> >Reply-To: >To: Dean Anderson <[EMAIL PROTECTED]> >Subject: Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt >Date:Sun, 29 Jun 2008 00:27:11 +0200 > >Dean Anderson (dean) writes: >> A number of the points you raise have already been addressed. > > Hi Dean, > > Where ? > >> The IPV6 Reverse resolution question has been discussed at length in >> DNSEXT previously. In fact, it was proposed to remove reverse resolution >> entirely from IPV6 for just the reason Dr. Huang notes. > > Which one ? There's still nothing showing that there effectively > is going to be a bottleneck of traffic to the root. Some curve, > some data points, anything, we could use to extrapolate future > problems from current trends, or even a *simulation* of load > based on guesstimages/projections of network host population would > come in handy. > >> A 128 bit IPV6 >> address is 16 octets. To perform reverse resolution requires traversing >> 16 levels of DNS tree. > > How is that better than 32 steps for the proposed implementation ? > >(from the draft, ?.3) > >> The Total address space of IPv6 is huge. But, only the Reserve Domain Name >> Servers managing used IP addresses will join the Virtual Hierarchical >> Overlay Network for DNS. And the worst maxium query steps are 32. >> With route cache the query steps will be less than 32. Therefore, >> this strategy for Reverse Resolution is feasible. > > Note: I may very well have gotten lost in the logic, and if > there's something I missed, please point it out... > >> Even the delegations impose significantly larger >> trees on the registries. It is recognized that this isn't going to be >> very scalable, or even possible. > > Again, where ? The references you point to below are somewhat old, > and of course it doesn't make them any less relevant (after all, > IPv6 is only going to be get used more and more), but still, I fail > to see any kind of model that really does show that it will be a > problem. > > C. Huitema's argument that the "... operational implications are > daunting", > I can easily identify with -- autoconfiguration, if it does get used, > will mean that everything has to be automatized and most likely dynamic. > > Alain Durand does point out that due to the size of ipv6 space, > reverse information for large ranges of IP addresses will have to be > dynamically generated, use wildcard, only record some, or drop. > > But it still doesn't say how this is going to be a problem, that > Mr. (not a Dr. it seems) is arguing his draft is the solution to. > >> IPV6 proposes to use ICMP Node Identification query instead. > > You mean ICMP Node Information ? (RFC4620) > > Yes, it definitely looks like an interesting solution. It has issues, > though, for example, the fact that it assumes that every node on > the internet will be reachable so that they can be queries: > >(from RFC4620, ?. Security Considerations) > >> This protocol has the potential of revealing information useful to a >> would-be attacker. An implementation of this protocol MUST have a >> default configuration that refuses to answer queries from global- >> scope [3] addresses. > > ... and the protocol doesn't propose implementing a collector/ > local aggregator which could handle/reverse proxy such queries at the > edge router or firewall level, so I guess if you've got a firewall, > you haven't got reverse anyway. > >> At present, there is an IPV6 reverse >> tree, but it is not guarenteed it will stay. It is for transition--so >> that gethostbyaddr() still works on IPv6 during transition. > > That's not the impression I got. Decisions to phase out ip6.int and > use ip6.arpa look to me like ip6.arpa is here to stay. HOW we populate > it -- or rather: how do we make that namespace return something useful, > using gethostbyaddr(), is part of the challenge -- for the reasons > stated by the sources you site. > > But I don't see either of these issues in anyway related to the > "the overload of traffic in tree structure" that Mr. Huang says > should be avoided. > >> See for example the discussions here: >> >> http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00931.html >> http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01828.html > > Cheers, > Phil >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
