Re: [NANOG] Did Youtube not pay their domain bill?

From: Steve Gibbard (no email)
Date: Sat May 03 2008 - 18:10:56 EDT

  • Next message: Randy Bush: "Re: [NANOG] Did Youtube not pay their domain bill?"

    On Sat, 3 May 2008, Mike Lewinski wrote:

    > David Coulson wrote:
    >> Depends - It doesn't help if the DNS server is dead, but the front-end
    >> is still advertising the routes.
    >
    > Possibly a good argument for allowing the DNS servers to originate the
    > routes for them...? I've seen configuration where the routes were

    Running Quagga or something similar on the anycasted server to announce
    the routes is the standard way of setting up anycast. That way, if the
    server fails completely, the route goes away.

    A common improvement on that is to run a script on the server that checks
    to make sure the name server process is running and responding correctly,
    and kills BGP if it isn't. That covers cases where named has problems
    that don't take down the whole server.

    The first one depends heavily on the server, if it's going to fail,
    failing the right way. If it loses power or stops all processes, the
    route goes away and traffic gets redirected elsewhere. If named dies or
    stops responding, you're stuck. The second method solves a lot of that
    sort of problems, but there are still conceivable situations where the
    server would get into a state of partial failure and be unable to withdraw
    the route. Still, that's probably the best option. Another approach
    would be to run the monitoring script and BGP process on a separate host
    that would presumably be healthy even when the name server host is in
    trouble. That approach has issues too, in that you lose the guarantee
    that the route will go away if the name server box is turned off.

    The right solution is to design the anycast servers to be as sure as
    possible that the route will go away when you want it gone, but to have
    multiple non-interdependent anycast clouds in the NS records for each
    zone. If the local node in one cloud does fail improperly, something will
    still be responding on the other cloud's IP address.

    Note that any of these failure scenarios is still preferable to what you
    get with unicast servers. With unicast, if the server has trouble, the
    route always stays up, and the the traffic always ends up in a black hole.

    -Steve

    _______________________________________________
    NANOG mailing list

    http://mailman.nanog.org/mailman/listinfo/nanog


  • Next message: Randy Bush: "Re: [NANOG] Did Youtube not pay their domain bill?"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD