[HN Gopher] Ask HN: Is there a "wall of shame" for ISPs that don...
       ___________________________________________________________________
        
       Ask HN: Is there a "wall of shame" for ISPs that don't respect DNS
       TTLs?
        
       And other DNS resolvers as well.
        
       Author : anderspitman
       Score  : 45 points
       Date   : 2021-12-17 18:42 UTC (4 hours ago)
        
       | chunkyks wrote:
       | It's shorter to write down a list of good actors.
       | 
       | Generally I just assume a good old fashioned "48 hours", like in
       | the olden days, and I have yet to be disappointed.
        
         | anderspitman wrote:
         | There's a lot of cool services that could be built on top of
         | shorter/predictable TTLs. I'm on a mission to make domain names
         | easy enough for the average person to use, and selling someone
         | a product that can't be used for 48 hours is quite
         | disappointing.
        
         | aredplug wrote:
         | https://news.ycombinator.com/item?id=29598697 cites evidence
         | that 94% do the right thing.
         | 
         | Perhaps you're overly cynical?
         | 
         | Either way, a good demonstration of the value of empirical
         | evidence.
        
       | pvtmert wrote:
       | yes, any/all Turkish ISPs don't respect the TTL at all...
        
       | dsp wrote:
       | What problem are you encountering?
       | 
       | I worked on dns gslb for a long stretch at Facebook^WMeta, and
       | didn't see an excess of bad actors. The vast majority of users
       | follow our dns changes in an orderly fashion. Most delay sources
       | to clients themselves.
        
         | anderspitman wrote:
         | I'm implementing my own domain seller targeted towards making
         | domain names easy enough for the average person to use. I'd
         | like to move towards a world where you can read the current
         | authoritative TTL and guarantee the user everything will be
         | updated within that time, rather than saying "Up to 48 hours".
        
           | dsp wrote:
           | There will never be guarantees.
           | 
           | The "up to 48 hours" is commonly used because that's the ttl
           | of many things that matter. For instance, NS records for
           | names in the .com zone have 48 hour ttls.
           | 
           | You can give better estimates to your users if you know the
           | state you're transitioning from. For instance, a brand new
           | .com domain would be 15 min negative ttl plus the .com zone
           | file update frequency.
        
             | anderspitman wrote:
             | Well yeah nothing is 100% guaranteed. Including the 48 hour
             | rule. Technically ISPs could set every TTL to take weeks.
             | But I maintain we can make a lot of progress reducing the
             | size of the long tail. Sometimes you have to work with
             | broken systems, but why leave things broken that don't need
             | to be? DNS TLL compliance can be improved one organization
             | at a time.
        
               | dsp wrote:
               | Why are you so confident there's a big problem to solve
               | here?
        
       | Spivak wrote:
       | I think it's a fool's errand into bullying people into solving
       | your operational woes. You pretty much only have one option for
       | dealing with real life DNS.
       | 
       | * Design your system assuming a hostile environment and that
       | propagation time is on the order of hours.
       | 
       | * Draw and document a hard line above which you consider it your
       | user's problem; i.e. you start assuming the world has updated
       | after 2 hours and any stragglers can just get errors.
        
         | anderspitman wrote:
         | I suppose you can call it bullying. I call it providing
         | customers with additional information to help them decide
         | whether a particular company is worth giving money to.
         | 
         | And it doesn't have to be an antagonistic interaction. I fully
         | suspect that many if not most cases of TTL violations either a)
         | have a good explanation or b) are unintentional and easily
         | fixed. Let's open the dialog and start improving things.
        
       | tyingq wrote:
       | Ripe did some testing in 2017 that showed that most places (~94%)
       | are doing the right thing. Somewhere around 6% of the DNS servers
       | were either making the TTL last too long, or too short.
       | 
       | There's a downloadable zip file there where you could probably
       | figure out who the offenders were. Ripe did say that it was a mix
       | of both ISPs and Cloud providers.
       | 
       | https://labs.ripe.net/author/giovane_moura/dns-ttl-violation...
       | 
       | Edit: There are also probably some corporate MITM type "content
       | filtering" caches that are screwing things up too, by caching web
       | pages longer than they should.
        
       ___________________________________________________________________
       (page generated 2021-12-17 23:01 UTC)