Thank you very much, Masataka! Quoting Masataka Ohta <mo...@necom830.hpcl.titech.ac.jp>:
> I'm forwarding a mail from Xun as he mistakenly send it not to > the list but to me. > > Masataka Ohta > > -------- Original Message -------- > Quoting Masataka Ohta <mo...@necom830.hpcl.titech.ac.jp>: > > > xun...@isi.edu wrote: > > > > > One result of that work is that we think additional information > > > would make anycast dianosis much easier--- > > > > How can it be made much easier? > > > > All the anycast servers should have unicast addresses to be > > used for zone transfer, which can be used for most, if not all, > > diagnostics. > > > > So, what diagnosis, are you considering, becomes possible > > only by your proposal? > > I think the initial e-mail text we sent is short and incomplete, > our draft proposal is clearer. > > The particular diagnostic that our > proposal tries to provide is to tell which one of a set of > anycast servers responses to a DNS query. Unicast address of an > anycast server is very useful for many diagnostics, however, as > DNS queries is sent to the anycast address and the path is decided > by routing system, knowing the set of unicast address may not > sufficient to answer that question. > > For the diagnosis that becomes possible ONLY by our proposal, > to our knowledge, is the identification of anycast nodes in > catchments other than where the querier is currently located. > One example utility might be to tell which authoritative name > server provides answers to a recursive name server. > > > > > Also, I'm afraid a fantastic idea of "anycast node" of > > RFC4892 is a result of broken specification of IPv6 anycast > > (yes, IPv6 is broken in several ways), which assumes there > > should be more than one anycast servers sharing an anycast > > address on a link. Anyway, we can't discuss anything > > meaningful about "anycast node", because its definition > > is too fuzzy. > > I am not sure if I correctly understand your statement. Did > you mean multiple anycast servers sharing a same path is only > for IPv6? If so, I don't agree. We know that at least F root > has multiple anycast servers in a site (which we think has > same meaning to RFC4786 defined "anycast node") for > address 192.5.5.241. And I believe a load-balancing mechanism > is reasonable for anycasted authoritative name servers. So > "anycast node" should not be discarded at this time. > > > > > As the terminology is very confusing with "node" of domain > > tree and "node" of IPv6, the entire idea of "anycast node" > > should better be silently ignored. > > > > Masataka Ohta > > > > > > > _______________________________________________ > 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
