Página 1 de 2 12 ÚltimoÚltimo
Resultados 1 a 10 de 12
  1. #1
    Louco pelo WHT Brasil
    Data de Ingresso
    Feb 2014
    Posts
    166

    TTL para uso de Failover

    Pessoal,

    Gostaria de iniciar uma discussão: Qual o melhor tempo para o TTL ?

    Estou usando o Route53 e tenho gostado muito pela rapidez e facilidade, além do recurso de Health Checks. Mas sempre fico na dúvida em usar um TTL muito baixo e isto ter algum problema futuro. Tenho algumas aplicações que precisam de uma propagação rápida em caso de falha.


  2. #2
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    15,045
    O número mágico é 118 segundos.

    Essa solução de failover usando DNS não funciona como geralmente pretendido.

  3. #3
    Louco pelo WHT Brasil
    Data de Ingresso
    Feb 2014
    Posts
    166
    Citação Postado originalmente por 5ms Ver Post
    O número mágico é 118 segundos.

    Essa solução de failover usando DNS não funciona como geralmente pretendido.
    Muito obrigado mas como chegou a esse número?

    Fiz alguns testes com o "Health checks" e funcionou certinho.

  4. #4
    Aspirante a Evangelist
    Data de Ingresso
    Feb 2012
    Localização
    Lisboa, Portugal
    Posts
    403
    Tenho uma história de um ISP em Portugal a uns anos demorar mais de uma semana a ir ler os dns...
    Sampling Line - Serviços e Internet, Lda.
    PTServidor - Alojamento Web, Domínios, Lojas, VPS, Radios, Dedicados, Housing/Colocation
    Blog PTServidor | Registrar Oficial FCCN|MS Partner|R1Soft

  5. #5
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    15,045
    Citação Postado originalmente por asturmas Ver Post
    Tenho uma história de um ISP em Portugal a uns anos demorar mais de uma semana a ir ler os dns...
    Nos EUA, o RoadRunner também era famoso pela mesma estorinha

  6. #6
    Moderador
    Data de Ingresso
    Oct 2010
    Localização
    Rio de Janeiro
    Posts
    2,679
    E no Brasil, a Oi Velox RJ...

  7. #7
    Louco pelo WHT Brasil
    Data de Ingresso
    Dec 2011
    Posts
    168
    Já tive que pessoalmente ligar para o Terra e explicar o problema a umas 15 pessoas (não é hipérbole) até chegar no root do servidor de DNS e convencer o cara a reiniciar o daemon. O motivo? O TTL da BRASnet que era de 900 segundos (= 15min) já tinha passado 5 dias e eles continuavam servindo irc.brasnet.org para os IPs antigos. Bons tempos...

    Não me pergunte o porquê mas sempre quando viro a chave de uma infraestrutura para outra, encontro de 1 a 3 ISPs que continuam batendo no IP antigo mesmo que o TTL já tenha expirado a mais de 24h. Tentei conduzir uma investigação pessoal e afunilar o caso a algum software de DNS específico mas em cada caso encontrei um diferente sendo usado.

  8. #8
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    15,045
    A Internet é um acordo de cavalheiros.

    "DNS Failover" como imaginado pelo OP parece uma solução fantástica. Pelo menos até você implementar Os problemas vão bem além do TTL ser eventualmente ignorado ou modificado -- ele é desconhecido pelas aplicações.

    O artigo clássico sobre esse assunto completou 10 anos:

    http://www.tenereillo.com/GSLBPageOfShame.htm

    O autor complementou com mais 2:

    http://www.tenereillo.com/GSLBPageOfShameII.htm

    http://www.tenereillo.com/BrowserDNSCache.htm

  9. #9
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    15,045
    Aqui rascunho antigo que não anotei a(s) fonte(s) -- talvez de algum link acima

    Client Applications


    Most client applications rely on the operating system and/or local DNS servers forDNS resolution and caching, and do not implement any type of DNS cachingthemselves.There is however one signification exception to this - Internet browser applications:

    Microsoft Internet Explorer browsers Internet Explorer 4, 5, and 7
    by default caches all DNS record for a period of 30 minutes no matter what the TTL value is.
    This means that there is up to a 30-minute delay before they will discover DNS changes.
    This of course only affects visitors who have visited the web site immediately before
    a DNS update. New visitors or return visitors who closed their browser or waited
    more than 30 minutes since their last visit are not affected.
    It is possible to adjust the length of time I.E. caches DNS records by updating a
    registry setting on the client machine. But this is of course only practical in an intranet scenario.

    Internet Explorer v. 6
    does not cache DNS A-record responses. It only caches DNS CNAME-record responses. Simple Failover only uses DNS A-records.
    This means that this browser version practically discover DNS changes made by
    Simple Failover instantly.

    Firefox and other Mozilla/Netscape browsers
    All versions of the Firefox and Mozilla/Netscape browsers since mid 2004 by default
    cache all DNS records for 1 minute no matter what the TTL value is.
    This means that they will discover DNS changes within one minute.
    Earlier versions of Mozilla/Netscape browsers cache all DNS records for 15 minutes no matter what the TTL value is.

  10. #10
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    15,045
    A origem dos 118 segundos

    The browser requests the IP address using a POSIX standard resolver library function (1) - either gethostbyname() or the newer version getaddrinfo() or in the MSIE case a non-POSIX equivalent call is used. The local resolver (2) initiates a standard DNS query to its locally defined DNS (3) - typically located at a service provider - which, being a recursive DNS, will initiate one or more DNS queries to the DNS infrastructure finally resulting in a query to the domain owners name servers (4). The responses to DNS queries contain the full DNS RR(s) including the TTL. Thus, the response paths 4->3 and 3->2 will contain the TTL data, say, 5 seconds. The library function (path 2->1) response is not specified to contain TTL data (even Microsoft's non-POSIX functions do not return TTLs values). The TTL information at that point is effectively lost. The browser - in order to speed up performance - maintains a cache of results which in the abscence of any other information is timed out after 30 minutes in the case of MS Explorer and 1 minute in the case of the Mozilla family (configurable in both cases). Thus the IP address will not be replaced, irrespective of the TTL value, for 1 to 30 minutes for existing site visitors. Finally we need to consider the time the browser and TCP/IP stack between them take to finally decide when a site is unreacable. In the case of MSIE this is around 2 minutes and in the case of Firefox around 3 minutes (the difference is entirely to do with retry strategies adopted by the respective browsers).
    Note: The increasingly common DSL/Cable modem (5) almost always contains a DNS Proxy whose functionality varies from the relatively benign (transparent) to the downright intrusive (preventing queries for a period - in some case 15+ minutes - by serving from a cache irrespective of the actual TTL value).
    Clearly new visitors whose browser has no cache entry will obtain a new IP address using the same process defined above and therefore the short TTL will have the desired effect of providing the up-to-the-second IP address.
    So the answer to the question "what is the most sensible minimum TTL?" depends on whether you think it more likely that the service will break during a visit - in which case 180 seconds (3 minutes - if all visitors are Firefox) or 1800 seconds (30 minutes - if all vistors are MSIE) seem reasonable values - or on the initial visit - in which case set the TTL to some very low value and spend serious bucks on DNS hardware.
    http://www.zytrax.com/books/dns/info/minimum-ttl.html#evil



    Note: Windows resolvers on XP and 2003 maintain a local cache at (2) which has no effect on the points made in this note but may reduce the number of external DNS queries.
    Since we assume that our browser is operating on a windows TCP/IP stack we now need to consider what happens when we fail to access the site:

    1. The specs for MS indicate the following error recovery times. On intial connection (when sending SYN) the MS TCP/IP stack tries three times with timeouts of 3 + 6 + 12 seconds = 21 seconds. If the site fails during an established TCP connection the MS TCP/IP stack tries 5 times with an initial timeout based on the RTT of the connection, assuming the RTT starts at 0.5 seconds the retries will timeout after 1 + 2 + 4 + 8 = 15 seconds.
    2. On completion of the TCP retry process each browser then initiates its own retries.
    3. Multiple A/AAAA RRs. Experiments showed a failover time of approximately 1 minutes 30 seconds to an alternate site when using multiple A (or AAAA) RRs for both browser families. Both browsers then stayed with the failed-over site and gave normal performance thereafter.
    4. Single IPs with a short TTL. Experiments showed it took 2 minutes for MSIE to finally give up and with its browser cache it would be a worse-case 28 minutes before a further attempt would be made to read the DNS record irrespective of its TTL value. In the case of Firefox it took approximately 3 minutes to finally admit defeat. But a further retry will cause a re-read of the DNS RR so a short TTL would be effective if it replaced the IP address.


    http://www.zytrax.com/books/dns/info/failover.html
    Última edição por 5ms; 21-04-2014 às 22:22.

Permissões de Postagem

  • Você não pode iniciar novos tópicos
  • Você não pode enviar respostas
  • Você não pode enviar anexos
  • Você não pode editar suas mensagens
  •