|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: possible ORG problems, maybe?
Bruce Campbell wrote: > > On Thu, 16 Oct 2003, Rodney Joffe wrote: > > However as the dns was walked, if indeed a server had a problem, in a > > non-anycast implementation you could tell which server ip address had > > the problem. But you could not always tell which actual machine had a > > problem if it was behind a load balancer of any kind, something > > increasingly common in large installations. > > > > Anycast is no different. > > Anycast is subtly different, as effectively the internal workings of the > load balancer are spread around the world for all to marvel at, rather > than at one end site. Perhaps I was not clear, once again, although you made the point even better than I was able to... Behind a load balancer, there are n nameservers. The queries all go to a single ip address, which hits the load balancer. Behind the load balancer, either in the same location, or perhaps even spread globally, all of these nameservers have different ip addresses, none of which is visible or used by the querying public. In that case, how would *you* know which of the myriad of marvelous nameservers you were being answered by? And because you wouldn't, this mirrors the situation with UltraDNS, and the only point I was making. > > > In terms of UltraDNS, we try to make it easier by having the following > > two records on every server: > > > > dig @[UltraDNS Anycast name or ip address] whoareyou.ultradns.net A > > and > > dig @[UltraDNS Anycast name or ip address] whoami.ultradns.net A > > For the end-user, where is this documented ? It is not. It is not an end-user feature. It is an UltraDNS troubleshooting feature, shared with customers during trouble-shooting, and available for them to use. I shared it here because as I understand it, some small portion of the folks who read UltraDNS run networks, have customers, and experienced apparent issues, and I felt it was an appropriate thing to mention so that when there appears to be an issue in the future with UltraDNS (not just .org) these tools might answer, partially, the concern that Randy correctly raised. And as more nameservers are migrated to using anycast (in its various implementations) it seemed appropriate that a mechanism *like* ours would be a "good idea"(tm). > I know to look for 'version.bind', 'id.server', 'version.server' and a few > others, but I hadn't considered asking for 'whoareyou.arbitary.domain'. You are not a customer. And you have never had an issue with UltraDNS where you contacted us to troubleshoot the same. > Why would other people consider it? I agree. Your point being? > Also, did the query that I'm debugging really go to the same host that I > just got the real IP address from? I believe I covered that in my initial response to Randy which you snipped. I said: "> Dan Senie has suggest the inclusion of a TXT record with the same data > so that the actual ip address of the actual server that responded to the > query that had a problem was available. Certainly more standardized and > elegant, but a subject for the WG mailing lists." The RFCs governing dns do not currently allow for the standard return of any record type in a dns answer that would indicate the ip address of the server being queried. So this valid issue should be addressed, of course through the appropriate process. > Does the nameserver on the 'real' IP > address function the same way as the anycasted virtual IP address? It is the same nameserver, so, yes. > ( Incidentally, exposing the actual IP address of the back-end server is > good for debugging, but really, really bad if the point of using anycast > is to protect from attacks. You only want to expose an identifier thats > only useful in-house. ) There is an additional series of addresses that drives the nameservers themselves, and there is a process of nat which produces the answers we are discussing here. Additionally, security by obscurity is inappropriate, given the extreme level of sophistication of the current group of hackers-for-hire. Be afraid. be *very* afraid. But that's a different issue I have with many of the "ostriches" in the NANOG community. > > I believe that there is an anycast tutorial or session in Chicago, if > > anyone wants to weigh in. > > I'll be there. > Great. It has nothing to do with me, or UltraDNS - although I assume UltraDNS will be dissected ;-) -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com "Technology so advanced, even we don't understand it!"(R)
|