3 ms·

I basically use Cloudflare for dns management, they make it so easy....

thinkMOAR 9y ago
I use a ton of registrars, almost all have equal simple dns management as CF. Which requires a party less to use or leak traffic information to.
- _eht 9y ago
  What is the turnaround time for DNS to propogate on all of those registrars? Are you forced into waiting for TTL's to expire? I may be wrong but I think eugeneionesco is referencing instant DNS changes which come as a benefit of using Cloudflare and other large DNS management companies. I've never personally seen a registrar offer anything like that.
  - eugeneionesco 9y ago
    Almost instant DNS change is something that I kinda take for granted. Surprising that's so rare...
    - mugsie 9y ago
      well ... the protocol was designed not do that. DNS is "just" a globally distributed, eventually consistent, key:value store, with a ton of caching built into it. Also, while it may look instant to you, it may not be to your customers / users / other internet people.
      - always_good 9y ago
        It's instant because CloudFlare isn't changing DNS records, just where its pointers point to. Look at it / try it.
        iancarroll 9y ago
        Their DNS changes are fast even when the site is not being proxied through CF.
        mugsie 9y ago
        Yeah - the global propagation time from you hitting save, to it being live in all their POPs is impressive. As a reformed Akamai DNS customer it is like time travel :D
        mugsie 9y ago
        I have, and I use it. Thats not DNS, that is global load balancing. Try using something other than HTTP over that FQDN.
      - JakeTheAndroid 9y ago
        While DNS caches can sometimes impact DNS updates, we rebuild the entire zone file when a DNS value is updated, and purge the previous cache. Even for customers, this should happen pretty quickly. We maintain a 5 minute TTL on all proxied records internally. So, this happens much faster than most other DNS services.
        mugsie 9y ago
        Yeah - that's a pretty standard way of doing things, and thats how DNS servers themselves will operate (mostly) when you make an update to a recordset. Its not your cache that is the issue. People have miss behaving caches, that do not always respect TTLs, some apps can cache the DNS response (I remember a Java issue where the initial value found was cached for the lifetime of the process!).
        JakeTheAndroid 9y ago
        The TTL publicly is static and doesn't matter. The resolver you hit will just point to Cloudflare NS. Why we are faster, is because we point internally, and we don't have misconfigured TTLs or caching (I mean, things happen but it's not common). So once you update the global resolvers your visitors would hit to point to CF, their cache/TTL should never matter since we dictate where our internal DNS points the requested record.
        thinkMOAR 9y ago
        what mugsie wrote plus.. My post was regarding the management of the zonefile/domain, not so much performance or things related to TTL. What exactly if your function at CloudFlare Jake? Pondering if this is more marketing then technical/service function. Any chance you are in charge of social media and forum posts about CF?
        mugsie 9y ago
        That is not how resolution works. What happens is: #1 - Application (browser, chat client, etc) gets FQDN. It checks if it has the recordset in its cache, and if the TTL is expired. #2 - Application asks the OS for the recordset. The OS checks its cache, and TTL expiry. #3 - OS asks the configured local DNS resolvers for the recordset. They check their cache, and TTL expiry. #4 - These resolvers ask the configured upstream resolvers (e.g. ISP for most home users). They check their cache, and TTL expiry. (This step can repeat, depending on how networks are configured. E.G. ISPs may have DNS resolvers per city, which ask central servers) #5 - If all of those previous steps fail (the recordset is not cached, or the TTL is expired) the last resolver in the chain will ask the root for the NS records of the zone, which will get fresh records from CloudFlare. Remember - any of these recursive DNS servers could have an override to cache the recordset for longer than the publicly defined TTL. This is not as much of an issue anymore, but it used to be a massive one. And this is before applications decide that they know better. - see http://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html http://docs.oracle.com/javase/8/docs/technotes/guides/net/pr... (networkaddress.cache.ttl section)
    - rasz 9y ago
      are you one of those people running DNS with TTL measured in tens to hundreds of seconds?
- eugeneionesco 9y ago
  You don't leak any traffic information if you don't enable the proxy, which I don't. I like the simple easy to use interface and the fact that all the domains that I manage are there, no need to login to multiple registrars.

I use a ton of registrars, almost all have equal simple dns management as CF. Which requires a party less to use or leak traffic information to.

_eht 9y ago
What is the turnaround time for DNS to propogate on all of those registrars? Are you forced into waiting for TTL's to expire? I may be wrong but I think eugeneionesco is referencing instant DNS changes which come as a benefit of using Cloudflare and other large DNS management companies. I've never personally seen a registrar offer anything like that.
- eugeneionesco 9y ago
  Almost instant DNS change is something that I kinda take for granted. Surprising that's so rare...
  - mugsie 9y ago
    well ... the protocol was designed not do that. DNS is "just" a globally distributed, eventually consistent, key:value store, with a ton of caching built into it. Also, while it may look instant to you, it may not be to your customers / users / other internet people.
    - always_good 9y ago
      It's instant because CloudFlare isn't changing DNS records, just where its pointers point to. Look at it / try it.
      - iancarroll 9y ago
        Their DNS changes are fast even when the site is not being proxied through CF.
        mugsie 9y ago
        Yeah - the global propagation time from you hitting save, to it being live in all their POPs is impressive. As a reformed Akamai DNS customer it is like time travel :D
      - mugsie 9y ago
        I have, and I use it. Thats not DNS, that is global load balancing. Try using something other than HTTP over that FQDN.
    - JakeTheAndroid 9y ago
      While DNS caches can sometimes impact DNS updates, we rebuild the entire zone file when a DNS value is updated, and purge the previous cache. Even for customers, this should happen pretty quickly. We maintain a 5 minute TTL on all proxied records internally. So, this happens much faster than most other DNS services.
      - mugsie 9y ago
        Yeah - that's a pretty standard way of doing things, and thats how DNS servers themselves will operate (mostly) when you make an update to a recordset. Its not your cache that is the issue. People have miss behaving caches, that do not always respect TTLs, some apps can cache the DNS response (I remember a Java issue where the initial value found was cached for the lifetime of the process!).
        JakeTheAndroid 9y ago
        The TTL publicly is static and doesn't matter. The resolver you hit will just point to Cloudflare NS. Why we are faster, is because we point internally, and we don't have misconfigured TTLs or caching (I mean, things happen but it's not common). So once you update the global resolvers your visitors would hit to point to CF, their cache/TTL should never matter since we dictate where our internal DNS points the requested record.
        thinkMOAR 9y ago
        what mugsie wrote plus.. My post was regarding the management of the zonefile/domain, not so much performance or things related to TTL. What exactly if your function at CloudFlare Jake? Pondering if this is more marketing then technical/service function. Any chance you are in charge of social media and forum posts about CF?
        mugsie 9y ago
        That is not how resolution works. What happens is: #1 - Application (browser, chat client, etc) gets FQDN. It checks if it has the recordset in its cache, and if the TTL is expired. #2 - Application asks the OS for the recordset. The OS checks its cache, and TTL expiry. #3 - OS asks the configured local DNS resolvers for the recordset. They check their cache, and TTL expiry. #4 - These resolvers ask the configured upstream resolvers (e.g. ISP for most home users). They check their cache, and TTL expiry. (This step can repeat, depending on how networks are configured. E.G. ISPs may have DNS resolvers per city, which ask central servers) #5 - If all of those previous steps fail (the recordset is not cached, or the TTL is expired) the last resolver in the chain will ask the root for the NS records of the zone, which will get fresh records from CloudFlare. Remember - any of these recursive DNS servers could have an override to cache the recordset for longer than the publicly defined TTL. This is not as much of an issue anymore, but it used to be a massive one. And this is before applications decide that they know better. - see http://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html http://docs.oracle.com/javase/8/docs/technotes/guides/net/pr... (networkaddress.cache.ttl section)
  - rasz 9y ago
    are you one of those people running DNS with TTL measured in tens to hundreds of seconds?
eugeneionesco 9y ago
You don't leak any traffic information if you don't enable the proxy, which I don't. I like the simple easy to use interface and the fact that all the domains that I manage are there, no need to login to multiple registrars.