Threads for StuntPope

  1. 8

    Someone who controls your network will simply drop the DNSKEY/DS records, so DNSSEC would not have provided any protection for “MyEtherwallet”. People who have already visited it were (hypothetically) protected by TLS, and people who hadn’t, would have received bogus records anyway.

    So DNSSEC could, in an ideal setting, provide a benefit similar to HPKP, but why wait? HPKP is here now.

    Furthermore, “DNSSEC wasn’t easy to implement” is a massive understatement.

    1. 7

      No, they can’t drop your DS records, because those reside in the parent TLD. They would have to also hack your domain registrar to do that.

      1. 1

        That’s completely wrong.

        If someone controls your network, they don’t need to hack anyone else: They can feed you whatever they want.

        1. 1

          If someone controls your network, they don’t need to hack anyone else: They can feed you whatever they want.

          That’s only true of non-DNSSEC signed records. DNSSEC is PKI allows one to cryptographically delegate authority of a zone. In practice, this means that the root zone signs the public keys of authoritative top-level domains, TLDs then sign the public keys of owners of regular domain names. These keys can then be used to sign any arbitrary DNS record. So, if you have a validating local resolver, it can use the public key of the root zone to cryptographically validate the chain of trust from ICANN down to the authoritative nameserver for a domain.

          DNSCurve isn’t a bad idea, I think lookup privacy is a good thing and I would much prefer to trust Google or Cloudflare than my local ISP for unsigned domain names. That being said, it doesn’t fix the massive problem of computers trusting the DNS cache of a 10-year-old router controlled by malware. It’s also really unhelpful when people claim that DNSCurve is some sort of alternative to DNSSEC.

          Seriously, go read Dan Kaminsky’s critique of the DNSCurve proposal.

          1. 1

            DNSSEC is PKI allows one to cryptographically delegate authority of a zone

            Which an attacker guarantees you’ll never see.

            This isn’t a hypothetical attack: Your computer asks your ISP’s nameservers, and it strips out all the DNSSEC records. Unless your computer expects those records, it won’t ever be able to tell you anything is wrong.

            if you have a validating local resolver, it can use the public key of the root zone to cryptographically validate the chain of trust from ICANN down to the authoritative nameserver for a domain.

            If you don’t, and for some reason use a “validating local resolver” on another machine, you have nothing.

            Even if you have a validating-capable resolver, and you never see that com has DS record 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 then you might never learn that you might find keys for cloudflare.com.

            Even if you do have a validating-capable resolver, and you see that com has DS record 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 you still can’t visit google.com safely.

            And what about .ae? Or other roots?

            DNSSEC supporters are happy enough to ignore the problem of deploying DNSSEC, like it’s somehow someone else’s problem.

            That being said, it doesn’t fix the massive problem of computers trusting the DNS cache of a 10-year-old router controlled by malware.

            What are you talking about?

            It’s also really unhelpful when people claim that DNSCurve is some sort of alternative to DNSSEC.

            It’s annoying that DNSSEC “supporters” hand-wave the fact that DNSSEC has no security, and doesn’t have a deployment plan except “do it”.

            IPv6 is at 23% deployment. After more than twenty years. DNSSEC is something like 0.5% of the dot-com. After more than twenty years (although admittedly they completely changed what DNSSEC was several times in that time). DNSSEC isn’t a real thing. It’s not even a spec for a real thing. How can I possibly take it seriously?

            Seriously, go read Dan Kaminsky’s critique of the DNSCurve proposal.

            Have you read it?

            It’s bonkers. It admits DNSSEC is a moving target that hasn’t yet been implemented “in all its glory” and puts this future fantasy version of DNSSEC that has been fully deployed and had all operating systems, routers and applications rewritten, against DNSCurve.

            Kaminsky is as brain-damaged as those IPv6 nutters, waiting for some magic moment for over twenty years that simply never came – and the only way his “critique” would have any value at all is if it were printed on bog roll.

            For what it’s worth: I think DNSCurve solves a problem I don’t have, but it attracts no ire from me.

            1. 3

              This isn’t a hypothetical attack: Your computer asks your ISP’s nameservers, and it strips out all the DNSSEC records. Unless your computer expects those records, it won’t ever be able to tell you anything is wrong.

              A resolver can refuse to perform DNSSEC validation or even strip out records, but a local resolver can detect this and even work around it.

              if you have a validating local resolver, it can use the public key of the root zone to cryptographically validate the chain of trust from ICANN down to the authoritative nameserver for a domain.

              If you don’t, and for some reason use a “validating local resolver” on another machine, you have nothing.

              What do you mean by using a validating local resolver on another machine? It’s local, there is no other machine.

              If you are saying that most clients rely on their router (or whatever) to do DNSSEC validation then yes, that router can perform a MITM attack. It’s still more secure than trusting every single upstream DNS resolver, but we need to move to local validation. The caching layer provided by DNS is a byproduct of the limited computing resources 1985.

              Even if you have a validating-capable resolver, and you never see that com has DS record 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 then you might never learn that you might find keys for cloudflare.com.

              It sounds like you are describing a broken resolver.

              Even if you do have a validating-capable resolver, and you see that com has DS record 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 you still can’t visit google.com safely.

              I believe the local resolver would just ask com for a DS record for google.com and receive either a DS record or an NSEC record. If it doesn’t receive one of those two records, then you are correct: you can’t visit google.com safely. It’s no different than an HTTPS downgrade attack.

              And what about .ae? Or other roots?

              1. We can deploy DNSSEC incrementally.
              2. ~96% of all domains are registered on a TLD that supports DNSSEC. The stats would probably be even better if they were based on traffic instead of total domains.
              3. All registrars are required to support DNSSEC.

              If we can get people to stop claiming that “DNSSEC does nothing for security” and make use of the cool stuff you can do with DNSSEC, then the market will force the last 10% of ccTLDs to adopt it.

              DNSSEC supporters are happy enough to ignore the problem of deploying DNSSEC, like it’s somehow someone else’s problem.

              I personally am working very, very hard on addressing every pain point there is. There are a lot of moving pieces and the standards left some holes until recently. I believe captive portals and VPN domains are thorny issues, but these issues can be addressed in an incremental fashion.

              It doesn’t help when people make erroneous claims about DNSSEC based on an incorrect understanding of DNS, DNSSEC, DNSCurve, and decentralized naming systems.

              That being said, it doesn’t fix the massive problem of computers trusting the DNS cache of a 10-year-old router controlled by malware.

              What are you talking about?

              DNSCurve relies on trusting the DNS resolver above you. For most people that is a 10-year-old router which has never gotten a security update. Best-case scenario is someone switching to Google DNS or Cloudflare - but with proper encryption, no upstream resolver would be capable of performing MITM attacks.

              It’s annoying that DNSSEC “supporters” hand-wave the fact that DNSSEC has no security

              I have patiently responded to every single claim you have made about DNSSEC’s security model. Please refrain from repeating this claim until you have figured out how a MITM attacker can force a local validating resolver to accept forged DS or NSEC records.

              IPv6 is at 23% deployment. After more than twenty years. DNSSEC is something like 0.5% of the dot-com. After more than twenty years (although admittedly they completely changed what DNSSEC was several times in that time). DNSSEC isn’t a real thing. It’s not even a spec for a real thing. How can I possibly take it seriously?

              So was IPv6 until ~6 years ago - now there is exponential growth. DNSSEC is at a similar tipping point: the basic security model was worked out a long time ago, but there were plenty of sharp corners until recently (large key sizes, NSEC3, etc). If we can stop people from claiming that the security model is broken then Cloudflare and other big providers will pour money into taking business away from the HTTPS certificate authorities.

              It’s also a necessity for decentralized DNS, which gives us an environment where we can implement everything without having to wait for legacy infrastructure to catch up.

              Seriously, go read Dan Kaminsky’s critique of the DNSCurve proposal.

              It’s bonkers. It admits DNSSEC is a moving target that hasn’t yet been implemented “in all its glory” and puts this future fantasy version of DNSSEC that has been fully deployed and had all operating systems, routers and applications rewritten, against DNSCurve.

              The post is mainly useful for explaining how DNSSEC and DNSCurve relate to one another. While the grand vision is the eventual goal, there are incremental benefits and huge gains can be had by simply making the application DNSSEC aware. For example, browsers are already switching to doing DNS resolution themselves, so the work required isn’t much more involved than that of upgrading to TLS.

              For what it’s worth: I think DNSCurve solves a problem I don’t have, but it attracts no ire from me.

              Then why hate on DNSSEC but evangelize DNSCurve? You can happily ignore DNSSEC as an end user or even as a system admin. If you care about security, well, that’s a different story.

          2. 0

            If they hack your primary nameserver and keep the zone signed, then maybe, as long as you’re running the primary. But as the original commenter said, “they can drop your DNSKEYs and DS”, no. They can drop the DNSKEY, but the DS resides in the parent node, and as long as it’s there, resolvers will look for DNSSEC validated responses, which they won’t get.

            1. 1

              If someone controls your network, whenever you request a DNSSEC “protected” domain, you will never know because the attacker can drop whatever records they want. DNSSEC clearly offers nothing.

              If someone controls the network of a website, they don’t need to interfere with the nameservers. They can simply MITM the traffic. Since they can request a TLS certificate from anyone who does HTTP or mail validation, DNSSEC still offers nothing. This is true whether they control the network by broadcasting “invalid” BGP routes, or whether they attack the physical infrastructure.

              Why are you defending this snake oil? “Hack[ing] your primary nameserver” is a pointless strawman that nobody cares about: “your primary nameserver” is likely controlled by Amazon or someone else competent. Your webserver is controlled by you, who lack the experience to identify the (complex) services at risk and properly secure them.

              1. 2

                f someone controls your network, whenever you request a DNSSEC “protected” domain, you will never know because the attacker can drop whatever records they want. DNSSEC clearly offers nothing.

                I don’t know what you mean by this. For starters, are you assuming “your network” includes all the nameservers? Let’s assume so. If DNSSEC is enabled, they can’t alter any of the DNS responses because they will break DNSSEC validation for aware resolvers. Sure, they can drop queries but what does that buy them other than a DDOS? They can’t stand up a fake site.

                Why are you defending this snake oil? “Hack[ing] your primary nameserver” is a pointless strawman that nobody cares about: “your primary nameserver” is likely controlled by Amazon or someone else competent. Your webserver is controlled by you, who lack the experience to identify the (complex) services at risk and properly secure them.

                Clearly you haven’t been paying attention. The entire chain of events that started my posts about this was a BGP hijack that was used to impersonate Route53 nameservers by hijacking Amazon IP space, which were the nameservers that MyEtherWallet was using. From there they stood up fake nameservers which directed victims to a fake myetherwallet site. That’s the exactly what happened, why don’t you go tell the people who had their wallet’s drained not to worry about it because it is all a pointless strawman.

        2. 2

          So DNSSEC could, in an ideal setting, provide a benefit similar to HPKP, but why wait?

          Doing PKI at the DNS level means that we can leverage it for every network and application protocol … including public key pinning. It would also enable us to do cool stuff like encrypt at both the network and application layers.

          It’s just that sysadmins didn’t want the headache of key management, so everyone engaged in bikeshedding. It didn’t help that a few (well intentioned!) security researchers threw shade on DNSSEC for not solving Zooko’s triangle or offering encryption for DNS lookups.

          So now we are stuck with Mozilla funding Let’s Encrypt to the tune of $2 million/year and non-HTTPS applications are forced to replicated all of the infrastructure required for a PKI. Which, in practice, means that it’s either non-existent (SSH) or barely functioning (GPG).

          HPKP is here now.

          Sadly, HPKP has been deprecated by Chrome. But, FWIW, these standards existed long before HPKP.

          1. 2

            It didn’t help that a few (well intentioned!) security researchers threw shade on DNSSEC for not solving Zooko’s triangle or offering encryption for DNS lookups.

            The current system (CA’s) is human meaningful, secure, and decentralized federated. It’s not perfect, but there are ways to improve the last point, so that we have more control over badly behaving CAs. But even as implemented, that’s better than human meaningful, secure, and a single point of failure (DNSSEC).

            So now we are stuck with Mozilla funding Let’s Encrypt to the tune of $2 million/year and non-HTTPS applications are forced to replicated all of the infrastructure required for a PKI.

            You can use x509 certificates from Let’s Encrypt to secure any IP connection. What’s the problem?

            1. 1

              It’s not perfect, but there are ways to improve the last point, so that we have more control over badly behaving CAs.

              For non-decentralized naming systems, the (abstract) DNSSEC chain of trust looks (roughly) like this:

              Government -> ICANN -> Registrar -> DNS Provider -> Local Validating Resolver -> Browser
              

              HTTPS certificate authorities “validate” control over a domain by checking DNS records (either TXT or via an email). Their chain of trust looks like this:

              Government -> ICANN -> Registrar -> DNS Provider -> ~650 CAs [1] -> Browser
              

              The best way to exercise more control over them is to cut them out of the trust chain entirely. Or switch to a decentralized naming system … which also relies on DNS (and thus DNSSEC) for compatibility reasons:

              Blockchain -> Lightclient w/ DNSSEC auto-signer -> Browser
              

              But even as implemented, that’s better than human meaningful, secure, and a single point of failure (DNSSEC).

              In terms of the security model, DNS is still a single point of failure. If you don’t like managing PKI you can always outsource it to someone … just like you do with HTTPS certificates.

              1. 1

                If I want to compromise you, attacking your DNS resolver doesn’t mean I’ve also attacked PayPal’s CA even if they used their DNS resolver to verify ownership of paypal.com

                1. 1

                  My point is that one can trick one of the ~650 CAs into generating an X509 certificate by hacking their upstream DNS client or performing a MitM attack. This would be pretty easy for any large network operator to pull off.

            2. 1

              Doing PKI at the DNS level means that we can leverage it for every network and application protocol … including public key pinning. It would also enable us to do cool stuff like encrypt at both the network and application layers.

              What exactly are you referring to: DNSCurve?

              DNSSEC doesn’t offer anything like this.

              It’s just that sysadmins didn’t want the headache of key management, so everyone engaged in bikeshedding.

              Paul Vixie, June 1995: “This sounds simple but it has deep reaching consequences in both the protocol and the implementation – which is why it’s taken more than a year to choose a security model and design a solution. We expect it to be another year before DNSSEC is in wide use on the leading edge, and at least a year after that before its use is commonplace on the Internet”

              Paul Vixie, November 2002: “We are still doing basic research on what kind of data model will work for DNS security. After three or four times of saying NOW we’ve got it THIS TIME for sure there’s finally some humility in the picture … Wonder if THIS’ll work? … It’s impossible to know how many more flag days we’ll have before it’s safe to burn ROMs … It sure isn’t plain old SIG+KEY, and it sure isn’t DS as currently specified. When will it be? We don’t know… There is no installed base. We’re starting from scratch.”

              It didn’t help that a few (well intentioned!) security researchers threw shade on DNSSEC for not solving Zooko’s triangle or offering encryption for DNS lookups.

              Or the fact DNSSEC creates DDOS opportunities, introduced lots of bugs in the already buggy BIND, and still offers no real security.

              No thanks.

              So now we are stuck with Mozilla funding Let’s Encrypt to the tune of $2 million/year

              DNSSEC has received millions of US tax dollars offers nothing, while Let’s Encrypt actually provides some transport security. Hrm…

              non-HTTPS applications are forced to replicated all of the infrastructure required for a PKI. Which, in practice, means that it’s either non-existent (SSH) or barely functioning (GPG).

              I don’t see how DNSSEC even begins to solve these problems.

              FWIW: Almost everything is HTTPS anyway.

              Sadly, HPKP has been deprecated by Chrome

              It is sad. Firefox and others still support it, and HSTS + Certificate Transparency is probably good enough anyway.

              1. 1

                Doing PKI at the DNS level means that we can leverage it for every network and application protocol … including public key pinning. It would also enable us to do cool stuff like encrypt at both the network and application layers.

                What exactly are you referring to: DNSCurve?

                No, using DNSSEC to bootstrap the public keys for … any cryptographic protocol. Just as DANE can be used to distribute the TLS keys for an HTTPS server, SSHFP records can be used to publish the public keys for a given SSH server. AWS, for example, could just publish SSHFP records when they provision a new instance and you would have end-to-end verification for your SSH connection. No need for Amazon to partner with Let’s Encrypt or force SSH clients to switch to X509 certificates.

                Since DNSSEC makes it simple to publish arbitrary public keys for a domain, you can use something like TCPCrypt to encrypt connections at the transport level. Transport level encryption reduces information leakage (SNI headers for HTTPS, what application you are using, network level “domain” fronting, etc) and mitigates flaws in any application layer encryption.

                WRT to your Paul Vixie quotes: they are 16 years old. I’ve tried really hard to find showstopper issues, but when you dig into criticisms of DNSSEC they boil down to complaints about DNS, problems that have already been fixed, or gripes about the complexity of managing PKI.

                Or the fact DNSSEC creates DDOS opportunities

                DNS reflection attacks are a thing because there are tens of thousands of public DNS resolvers willing to send DNS record requests to anyone. The worst offender here are ANY requests that return all records associated with a domain. The public key and signature used to verify a DNS response do not incur that much overhead 1 2.

                The response from DNS providers hasn’t been to rip out DNSSEC, but to rate limit requests that produce large responses. More fundamental changes include switching to TCP, ingress filtering of spoofed UDP packets, supporting edns_client_subnet, and shutting down public DNS servers.

                introduced lots of bugs in the already buggy BIND

                Please do not blame DNSSEC for BIND being a buggy POS.

                and still offers no real security.

                DNSSEC prevents a wide range of attacks. Are seriously arguing that removing trust in every DNS server between yourself and the registrar doesn’t materialistically improve security? What about removing trust in the ~650 CAs capable of producing an HTTPS certificate? Wouldn’t you like to live in a world where TCP, SSH, email, IRC, etc can take advantage of PKI instead of opportunistic crypto?

                non-HTTPS applications are forced to replicated all of the infrastructure required for a PKI. Which, in practice, means that it’s either non-existent (SSH) or barely functioning (GPG).

                I don’t see how DNSSEC even begins to solve these problems.

                Publish a DNS record with the public key for the encryption protocol you would like to use (see: SSHFP, DANE, PGP).

                It is sad. Firefox and others still support it, and HSTS + Certificate Transparency is probably good enough anyway.

                As a decentralized domain name nerd, I strongly disagree. We need a standard way for naming systems to declare the public keys for their services. Seriously, we have to sign TOR domains with HTTPS certificates from DigiCert because the browser doesn’t support DANE.

                1. 1

                  No, using DNSSEC to bootstrap the public keys for … any cryptographic protocol.

                  This is some fantasy version of DNSSEC that doesn’t exist yet and likely never will: Browers don’t do DANE because it’d piss people off.

                  Are seriously arguing that removing trust in every DNS server between yourself and the registrar doesn’t materialistically improve security?

                  Yes.

                  Until you know that you’re supposed to be seeing a DS/DNSKEY chain, every recursive resolver (and every stub resolver) gains nothing, and risks tricking people into thinking they have some security because they installed something called DNSSEC.

                  As a decentralized domain name nerd, I strongly disagree.

                  Well, you’re wrong. Decentralising trust just creates multiple single-points of failure unless you’re willing to wait for consensus, in which case you might as well use HSTS+Certificate Transparency (and your favourite mirror).

                  1. 1

                    This is some fantasy version of DNSSEC that doesn’t exist yet and likely never will: Browers don’t do DANE because it’d piss people off.

                    It would only piss off people who think DNSSEC is a bad thing. Chrome actually implemented it but it was removed due to lack of critical mass. I’m thinking of pitching Cloudflare on pushing for DANE.

                    Until you know that you’re supposed to be seeing a DS/DNSKEY chain, every recursive resolver (and every stub resolver) gains nothing, and risks tricking people into thinking they have some security because they installed something called DNSSEC.

                    If the parent zone is signed and has a DS key for the child zone, then your local resolver would know that the child zone is supposed to be signed.

                    As a decentralized domain name nerd, I strongly disagree.

                    Well, you’re wrong.

                    No, I’m not. This was a major issue with Namecoin: we had to MITM every HTTPS connection to check the certificate against the blockchain records then replace it with a local certificate. There was no uniform way of making this work: the hack required tweaking for every OS and application and prevented users from selecting their own SOCKS5 proxy. The entire team agreed that DANE was the only way forward and we even got DigiCert to ensure that they used DANE when minting their .onion certs.

                    Decentralising trust just creates multiple single-points of failure

                    Um, what?

                    unless you’re willing to wait for consensus

                    Consensus from the Blockchain?

          1. 4

            Most of the large resolver services such as Google. Quad9, OpenDNS and Cloudflare are all DNSSEC enabled.

            OpenDNS does not support DNSSEC at this time.

            1. 1

              Whoah. I could have sworn they did.

              1. 6

                OpenDNS does support DNSCurve, a protocol that faster, simpler, offers real incremental benefits (unlike DNSSEC which is all-or-nothing), and is easier to deploy than DNSSEC.

                DNSCurve however is unlikely to be implemented by ICANN for political reasons.

                1. 12

                  I’m getting really sick of people talking about DNSCurve as if it was an alternative to DNSSEC, the two do completely different things. DNSCurve secures the traffic between the authoritative nameserver and a DNSCurve enabled resolver (the only one I know of being OpenDNS). DNSSEC authenticates the validity of the DNS responses themselves.

                  1. 2

                    You’re right. DNSCurve protects all of your DNS traffic from tampering between you and the resolver and the resolver can implement their own security infrastructure for detecting and protecting from tampering and cache poisoning, while DNSSEC validates the DNS traffic of far less than 1% of all domains on the internet AND requires each client to not use a caching resolver if they want to be able to trust the results.

                    So DNSCurve has a real world impact on protecting users, and DNSSEC is still vaporware.

                    1. 0

                      You’re right. DNSCurve protects all of your DNS traffic from tampering between you and the resolver and the resolver can implement their own security infrastructure for detecting and protecting from tampering and cache poisoning.

                      The only way to reliably detect against tampering with DNS records is for the owner of the domain to sign them cryptographically.

                      while DNSSEC validates the DNS traffic of far less than 1% of all domains on the internet

                      IPv6 had pretty low adoption too, until things started to get bad enough.

                      AND requires each client to not use a caching resolver if they want to be able to trust the results.

                      They don’t have to use a caching resolver, that’s the whole point of the owner of the domain signing the DNS records - you can verify it for yourself! A client can also query the root name servers directly, it would increase load on the authoritative nameservers and has a different privacy profile … but there is nothing wrong with that.

                      1. 2
                        • DNSCrypt for privacy
                        • TLS for validation (and of course the other security benefits that come with)

                        That’s the stack everyone should be using. It works and is reliable; duplicate certificates forged by shady CAs is a thing of the past with CAA, certificate transparency, and the ability to do stapling. Pushing down the validation to DNS is the wrong approach.

                        1. 0
                          • DNSCrypt for privacy

                          DNSCrypt is dead. TLS adopted DJB’s curves and some IETF working groups wrote a few standards which can pass through firewalls.

                          • TLS for validation (and of course the other security benefits that come with)

                          TLS does not validate that a record came from a domain name name, it only validates that the response came from a third party resolver.

                          That’s the stack everyone should be using. It works and is reliable; duplicate certificates forged by shady CAs is a thing of the past with CAA, certificate transparency, and the ability to do stapling.

                          We still have to sign .onion domains using DigiCert’s certificate. Certificate transparency doesn’t protect against domains which aren’t using “high assurance” certificates. Nor does this protect any other protocol outside of TLS.

                          Pushing down the validation to DNS is the wrong approach.

                          Why are you so against cryptographic verification of DNS records?

                  2. 2

                    DJB threw a bunch of shade on DNSSEC when he announced DNSCurve, but he was (at best) misguided 1.

                    DNSCurve however is unlikely to be implemented by ICANN for political reasons.

                    DNSCurve doesn’t have anything for ICANN to implement as there is no signing of DNS records. It will validate that a response came from a specific DNS cache, but not that the records were produced by the owner of the domain.

                    He’s right that we need privacy for DNS lookup and the adults in room created DNS over TLS.

                  3. 0

                    OpenDNS doesn’t support DNSSEC, and prevents doing the validation yourself if you wanted to do so, by stripping required records before forwarding a response to you. 1

                    Their business model used to rely on NXDOMAIN hijacking, which DNSSEC prevents. They stopped doing that a while ago, but I just checked and they are still stripping out DNSSEC records 🤯!

                    I really wish I hadn’t gotten sick, I was going to help work on a standard for DNS filtering. At any rate, these are bad actors in the DNS ecosystem.

                1. 3

                  re no security protocols for BGP

                  There’s a bunch of security protocols for BGP. Here’s one I found with a quick Google that references many others. The problem is on deployment side. There’s little incentive for Tier 1-3’s to spend their money securing the Internet. So, we have to do a combination of software prevention and monitoring of interactions with middle parties that are effectively hostile. If no regulations can be issued, I keep thinking some class-action lawsuits over negligence or damages might help on insecure internetworking, lack of DDOS mitigation, etc.

                  “Now we have easyDNSSEC™ the world’s first Set-and-Forget DNSSEC™ deployment “

                  Didn’t Phreebird and Secure64 count as turn-key solutions for DNSSEC? Secure64 had extra benefit of security-focused OS, too.

                  Note for web admin: This is the only site I’ve seen in a few months where keyboard scrolling (i.e. pressing down) doesn’t work at all. Some require me to click on the text with my mouse to tell it what should have focus. One click, all keyboard from there on. This one didn’t work at all on Chrome. It does on Firefox, though.

                  1. 3

                    Phreebird and Secure64 are not registrars however, so they can’t insert your DS into the parent TLD or roll your KSKs.

                    (thanks for remarks re: blog, which has issues lately, we’re working on a do-over of the entire public website).

                    1. 2

                      Appreciate the tip. Not a DNS expert. I just remembered them saying they had software to take the pain out of DNSSEC deployment.

                  1. 1

                    The article doesn’t appear at all without Javascript :(

                    1. 6

                      There was an embedded image widget before from getty images which may have been a problem, I replaced it, can you try now? It should just be a plain vanilla wordpress post.

                      It’s also on Medium: https://medium.com/@markjeftovic/why-should-any-non-euro-companies-care-about-the-gdpr-68bd9907537c

                      1. 5

                        Works perfectly! Thank you so much :)