1. 15

After June 27th, any glue records which remain pointed to our old name server IP addresses will result in an interruption of your DNS service.

This change will force all DNS queries to be directed through CloudFlare. On June 27th, our DNS infrastructure will cease to answer DNS queries which are received on our old name server IP addresses. This upcoming change is the final step in a recent series of efforts to engineer a more resilient DNS service. The new architecture will isolate our authoritative name servers behind an edge layer, which will handle all contact with public traffic. Our old name server IP addresses will continue to be available at this edge layer to process zone transfers, but queries will need to be directed to our new name server IP addresses, which carry requests over the CloudFlare network.

  1.  

  2. 19

    I find this news quite disappointing. Apparently, they’re moving everyone to CloudFlare.

    CloudFlare has been documented to explicitly get in the way of people having unimpeded access to the internet. https://lobste.rs/s/9iifh5/cloudflare_is_ruining_internet_for_me

    They apparently may even be doing this purposefully by design, to further promote their service by being so noticeable even to the most non-technical users. https://lobste.rs/s/zirhln/cloudflare_making_internet_little_bit

    Yes, CloudFlare don’t appear to interfere with the DNS just yet, but do we really want the whole internet to be at the mercy of a single network?

    I’m thinking about moving my DNS away from all of these providers, and onto my own servers. For anyone else thinking about it, http://cr.yp.to/djbdns/third-party.html is worth a read.

    1. 1

      Gadams just confirmed this is not the case.

    2. 9

      This is great news if you are Cloudflare, and horrifying if you are any bit skeptical of a single entity controlling access to the Internet, which should be everyone else, but unfortunately isn’t.

      1. 5

        Note that Linode aren’t even announcing this to anyone – it looks like only the people who have their own glue records pointed directly at Linode DNS IP addresses are getting the memo.

        What’s more redundant? 5 distinct unicasts across 5 separate data-centres with 5 distinct AS numbers and in 5 separate /8 allocations, or an anycast from a single AS13335 and a single 162.159.24.0/22?

        Frankly, I’d just rather have the choice to decide by myself than having to blindly trust the corp running the latter.

      2. 15

        Talked with the founder of Linode Chris Aker (caker).

        <gadams> anyone know about this ? https://lobste.rs/s/aepbqi/linode_on_june_27th_our_dns

        <caker> yes, it’s total BS

        <caker> gadams: –^

        <gadams> thanks caker

        <caker> this affects like 300 people. if you didn’t get a ticket about it, don’t worry about it

        1. 1

          It’s total BS to make a major change like that, and sweep it under the carpet, without notifying all of your users.

          As far “like 300 people” is concerned – http://bgp.he.net/ip/65.19.178.10 still reports, only a couple of days prior to the shutdown:

          Address has 433 hosts associated with it.

          Moreover, what about the rest of the people that now have to follow up on the reports about CloudFlare outages and IP hijacking? Before this change, 5 (five) separate and independent networks would have to be responsible for an outage. Now all it takes is a single third-party company, and a single BGP hijack of a single /22.

          Your content could still be available via your Linode, but people won’t be able to reach it due to a third-party DNS outage (possibly only affecting users in Asia or Antarctica, so, you wouldn’t even know what’s going on). How nice. And Linode didn’t notify anyone why? Because CloudFlare’s too big to fail?

          1. 5

            You don’t have to use linode’s DNS servers to access Linode. When I hosted content on Linode, I used Amazon to host DNS.

            He’s right. This is a very minor change and it only affects people who were probably doing it wrong to start.

        2. 3

          As an aside, I’ve moved DNS off an IP address before. The set-up is simple enough: stand up a DNS server at the new IP address, update DNS, wait two weeks, shut down old IP address. The wait two weeks is a conservative period for propagating that change across the internet.

          What I found surprised me: The traffic drop-off on my old DNS server decayed almost perfectly over that period until it was receiving nothing but scan queries (e.g., shadowserver.net) at the end of two weeks. I seriously expected much worse behavior out of the internet.

          Instead I got exactly what you’d predict. Nearly the opposite of what has happened to me moving MX records. Legitimate mail from a tiny minority of providers can still arrive at your old IP address for a stupid long time.

          1. 2

            Interesting experience. I assume this is because the following of NS delegations is performed by a recursive DNS server, which tends to have a sane implementation, whereas the MX -> A -> IP resolution is performed by, and cached within, the MTA software, which in many cases has questionable/naive implementations or configs.

          2. 3

            I feel that having Cloudflare host a subset of DNS Linode servers would be great to add extra resiliency. Putting all DNS in the hands of an external provider and retiring Linode’s own servers seems a shame though.

            1. 2

              any glue records which remain pointed to our old name server IP addresses

              The purpose of glue records is to deal with a bootstrapping problem. If the nameserver (NS) for linode.com is ns1.linode.com how do you figure out the IP address of ns1 in order to query it?

              The answer is glue records. The .com zone will include an A/AAAA record for ns1.linode.com, and the .com nameservers will respond to queries for *.linode.com with the NS records for linode.com and the ns1 address in the additional information section.

              So in theory only linode.com should be affected by this, and using glue records or other IP address hardcoding is not recommended as it causes problems for changes like this that should be transparent. As the OP says:

              We would also like to take this opportunity to mention that configuring glue records to point directly to our name server IP addresses is not recommended and not supported. The reason for this is that the IP addresses of our infrastructure are subject to change without notice; we rely on DNS hostnames to ensure that our users are always connecting to the correct service

              1. 4

                As a domain owner hosting on linode, instead of pointing your NS record to ns1.linode.com, you could point it to ns1.example.com which would have the same IP address. You’d then make your own glue record for that with your registrar. I don’t think that’s a good idea, but a hosting provider the size of linode will have customers who have done things like that.

                I get that linode says they don’t support that; it’s a pain to notify all of your customers of a DNS IP change and have them comply by updating their glue records.

              2. 2

                This change will force all DNS queries to be directed through CloudFlare.

                Anyone has a link to the white paper describing captchas as proof-of-human/work for DNS requests? ;-)

                1. 2

                  Headline is misleadingly truncated. I was concerned Linode DNS is shutting down, but really they’re moving the public servers to Cloudflare and a small number of people who have custom glue records need to update them.