I was just introduced to the Domain Name System Security Extensions (DNSSEC) and it sounds very similar to the concept of DNS-over-HTTPS (DoH) and DNS-over-TLS: to add privacy and security into DNS lookups.
What are the main differences between these protocols? Do they compete/serve the same goals?
DNSSEC just signs answers, to check integrity and preserve DNS cache poisoning from unauthorized fake "servers". With DNSSEC, any eavesdropper can:
listen traffic
understand "this is DNS"
watch domain names for request/responses.
DOH is DNS over HTTPS. There is:
traffic encrypted
eavesdropper cannot understand - is this DNS or web http.
eavesdropper unable to see contains of requests/answers.
Advantage of DNSSEC - more quick.
Advantage of DOH - more private.
Related
As a short URL service provider what safety checks I should follow on URLs to keep minimum risk on my users. For example someone should not use my service to short their hacking, spamming, phishing, etc type of links.
For example I can do domain whitelisting on my service so only trusted domain URLs can be short through my service. Like that what other safety checks I should follow before shorting any URLs.
As a URL Shortner (Service Provider) this safety checklist should be followed before shorting any URLs to keep the risk at minimum. Please note that safety on the internet can not be provided by following or using only one checklist or certain rules. We must try new things on own and learn new things day by day. This checklist is part of my research on the internet.
Domain or IP Whitelisting/Blacklisting - This is one of the best safety mechanism we can implement to allow shorting URLs from only trusted domains/IPs. And we can also block certain domains/IPs like malicious domains and IPs. Sometime blacklisting is easy to bypass but whitelisting is hard to bypass so whitelisting is recommended. However we can do both according to our need.
Domain/IP Reputation Check - We can also implement a mechanism to check Domain/IP reputation on global internet before shorting it. For example malicious IPs/Domains might have bad reputation on global internet database, we can simply block those address for shorting.
Reference :-
https://talosintelligence.com/reputation_center/
https://www.ipqualityscore.com/ip-reputation-check
https://ipremoval.sms.symantec.com/lookup
Check DNS Records (mxtoolbox) - MxToolbox supports global Internet operations by providing free, fast and accurate network diagnostic and lookup tools. MxToolbox provide a great list of tools including blacklisting of any ip/host, whois lookup etc.
Virus Total IP/Domain check - Virus Total is an online service that analyzes suspicious files and URLs to detect types of malware and malicious content using antivirus engines and website scanners.
HTTPS Protocol use - Before shorting any URLs we must verify that the URL contain proper SSL/TLS certificate and it contains HTTPS protocol. It is high chance that malicious sites/IPs will communicate through HTTP protocol. So, we must avoid shorting of HTTP hosts.
Disallow known shortened links - Some users try to over smart the security system by shorting the URLs multiple times. As a short link service provider we know the security risks behind short links. So we must avoid shorting of links that are already shorted by other services or even our service.
Compare URLs to list of known badware - There are lots of online database that provide list of suspected malicious IPs and domains. Use this database to prevent shorting of this hosts.
Reference:-
https://zeltser.com/malicious-ip-blocklists/
https://www.trendmicro.com/vinfo/us/threat-encyclopedia/malicious-url
URL Filtering - We can implement some policies like firewall policies that blocks certain content. For example, spam, nudity, violence, weapons, drugs, hacking, etc.
In I/O 2018 Google announced their new .app TLD and they said that it will be HTTPS only.
I thought that DNS just maps domain names to IP's.
How are they forcing HTTPS?
(a little offtopic here)
It is called HSTS Preloading, see https://hstspreload.org/
HSTS (HTTP Strict Transport Security) is a way for servers to reply to clients: please contact me over HTTPS only (see https://www.troyhunt.com/the-6-step-happy-path-to-https/ for examples). It enhances security but still does not solve one case: the first connection to a given server can happen over HTTP before the browser learns it should have done an HTTPS instead.
Hence come the "preloading" of HSTS.
Basically this is an hardcoded list embarked in all major browsers code
(see https://caniuse.com/#feat=stricttransportsecurity for compatibility depending on browser and version, or see at bottom for links to code[1]) that says which domains/TLD are HSTS enabled, which means no HTTP connection allowed to them at all.
Note that:
Anyone can submit names to this list by following some requirements, see https://hstspreload.org/#submission-requirements
Google (as it started with Chrome but it is now spread among browsers) welcome inclusion of TLDs and not only hostnames, see end of document at https://hstspreload.org/ ("TLD Preloading")
They already did add .DEV in the past (the TLD by itself is not live yet, but Google will launch it "soon") which broke many developers setup where they used (wrongly) a .DEV domain name to name their local resources and as soon as their browsers were updated with the newer HSTS preloading list, they refused to connect to their local .DEV host without HTTPS. You can find here and elsewhere (ex: https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/) many horror stories of developers up in arms against that and also may people offering bad solutions for that (like disabling HSTS preloading which is a very bad idea).
Also when you buy a .APP domain name (and it will be same for .DEV), Google (as registry of .APP) made sure contractually with all registrars that they will, during checkout of a .APP domain name buy, display a prominent message saying something along the line of: ".APP is a secure TLD and websites will only work with an SSL certificate(sic); make sure to buy an SSL certificate" (SSL certificate is straight out of Google documentation and this is very sad to read out of them since it is a doubly wrong term, it should have been an "X.509 certificate" or, in order not to frighten anyone, at least a "certificate used for TLS communications", noone should use SSL anymore nowadays...).
By the way, .APP opened for the public at standard prices yesterday, May 8th.
Of course all of that is only related to web browsing. You could set any other kind of service, like email, on top of a .APP domain name, without any mandatory TLS (which of course is not a good idea nowadays but nothing will refrain you from doing that). For email, there is ongoing discussion to have basically HSTS but for MTAs, see https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/
[1] see some source codes with the HSTS preloading list:
https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json
https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsSTSPreloadList.inc
or you can use the API at https://hstspreload.com/ to learn if a name is on the list
It's just a policy. A domain name is a domain name, and DNS only cares about how the name is translated to other resources, like for example an IP address. Technically any IP address can be used together with any IP protocol (there are 256 to choose from, one of which is TCP) and when applicable, any port number (there are 65536 to choose from, two of which are HTTP and HTTPS respectively). There is no way to place restrictions on this via DNS, but of course the TLD registrar can attempt to do this via policy rules.
By trial and error I easily found an .app domain where HTTPS is not enforced:
curl -v -L http://foo.app/
This results in a couple of redirects, but none of them redirect to HTTPS, and the final response is a HTTP response from a GoDaddy address.
I got the opportunity to configure an IDN ccTLD.
I have already configured the DNS server and it is working properly.
Now I have a challenge to secure the dns service by DNSSEC.
I configured DNSSECC by self-signing.
But Now I can't understand where and how I should entry the DS record.
While Calle Dybedahl answered "where", I'd like to offer some pointers about "how" you should enable DNSSEC for your ccTLD (IDN or otherwise).
Viktor Dukhovni's "Common Mistakes" page deals with a lot of things specific to DANE (the use of DNSSEC as an anchor for certificates, particularly for SMTP), but his first two points (and the next to last one) are valid for any operator implementing DNSSEC, especially a TLD of any sort.
In particular, the first point, abridged below, is vital:
Publishing DNSSEC DS records ... as a fashion statement
Keeping these correct requires operational discipline. Administrators
who expect "fire and forget" should not publish DNSSEC signed zones...
Or they can pay others to host their zones... Operating poorly
maintained DNSSEC zones ... creates problems not only for the domain
in question, but also for all the domains trying to communicate with
such a domain. Everyone is better off if DNSSEC ... [is] taken
seriously.
There are a number of ccTLDs whose records in terms of maintaining their DNSSEC-signed zones in proper operation is far from stellar; there is a "hall of shame"—just look for the TLDs that appear more than once on the IANIX outages list.
Since your IDN ccTLD is a new TLD, DNSSEC is mandatory, so even if you were to swallow the red pill that IANIX offers you and renounce DNSSEC, you would still have no choice but to implement it. You should make all efforts to treat your DNSSEC deployment as a charge of the utmost gravity, since as a TLD, it directly affects the operation and security not only of your domain, but of any and all domains registered with it.
Furthermore, as difficult and problematic as DNSSEC is, it is unlikely to go away, and the number of clients that validate DNSSEC themselves (or rely solely on DNSSEC-validation resolution services like Google Public DNS, Comcast ISP, or Verisign Public DNS) is significant, exceeding 15% of all clients worldwide and significantly more in many countries that are likely candidates for an IDN ccTLD (see regional and per-country drill-downs at the previous link for examples like Kenya where 40% of clients rely on DNSSEC validation, and the .KE TLD had a significant DNSSEC outage last month).
There are good resources at ISOC, and a best practices PDF to help you manage DNSSEC if you want to "do it yourself" and roll your own DNSSEC zone signing. But it is very easy to get this wrong, and without regular monitoring and on-call response, your DNSSEC signatures can expire and render your entire domain unreachable to millions. Worse, if the private keys used for DNSSEC signing are compromised, the security of any domains depending on DNSSEC may be placed in jeopardy.
You may want to seriously consider whether it might not be easier and cheaper in the long run to host the zones for your IDN ccTLD with a commercial DNS provider that can provide managed DNSSEC (while you operate the registry side of the TLD and update the zones from your registry implementation using a DNS management API).
One final piece of advice; unless you are delegating millions of domains that have no DS records in your ccTLD and need NSEC3 opt-out, or you are operating in Europe where data privacy laws[1][2] may require that you use NSEC3, you should probably use old-style NSEC for now, as it allows Google Public DNS (and other implementations of aggressive NSEC caching) to absorb NXDOMAIN Denial of Service attacks and junk queries without forwarding them to your authoritative servers. If NSEC3 actually offered significant protection against zone enumeration it might be worth using, but it is not hard to break it if you have a decent GPU and the protection against NXDOMAIN attacks (in 2016–2017 only possible with NSEC) is more useful.
The DS record lives in the delegating zone, which if you actually are configuring a ccTLD is the root zone. So talk to your contact at ICANN about how to get the necessary information to them.
I recently started using linode to host my site.
Prior to using linode, I normally used hosting offered by my domain registrar. In those cases, i thought I understood how DNS worked, because the registrar automatically updated your DNS records to point to the server hosing the site.
When following linodes guide, to setting up a website: https://www.linode.com/docs/websites/hosting-a-website
Their instructions tell you to set the DNS servers as:
ns1.linode.com
ns2.linode.com
ns3.linode.com
...
But the point I am making is, that ANYONE can open an account on linode, and fill in the same DNS settings! So now anyone trying to access your website, could be directed to someone else who wants to pretend to be your site!
Am I correct in understanding how DNS works ? I know that the only way to ensure (from a visitors perspective) that a site being visited is actually the domain intended is to install a certificate (https) etc. But based on the above instructions, it seems almost trivial to pretend to be someone else, if they also use linode.
I am not an expert on DNS so my answer may be mistaken, but I had the same question so looked into this.
I think your understanding is correct, and this seems to be a problem but apparently it happens rarely in practice so hosting providers (including Linode) aren't doing anything about it.
Here is Ryan Quinn from DigitalOcean (another hosting company that has this problem) answering a similar question:
A domain can only exist on one account so any user attempting to add it would not be able to. Cases where a domain already exists or is hijacked are extremely rare (I've seen 3 cases in 2+ years and in each case it was a former owner of the domain who still had records in place). In these rare cases the user can open a support ticket where we will verify the domain whois information against their billing details to verify ownership.
Here is a question on Information Security Stack Exchange that asks the same thing.
In the case of DigitalOcean, I found a post (HackerNews discussion) of someone describing how they took over around 20,000 inactive domain names that pointed to DigitalOcean's nameservers. I haven't found anything similar for Linode, although I imagine basically the same attack is possible (2020 Update: This actually recently happened to someone I know, where their website got taken over by a spammer after they took down their Linode without changing the DNS settings to stop pointing to Linode).
Amazon Route 53 seems to use randomly generated nameservers (rather than Linode/DigitalOcean's constant ns1.linode.com etc.) to make this attack highly unlikely to succeed.
Apparently some other services (Google Apps?) "verify domain ownership by requiring the domain owner to add a TXT record to their domain with a special code."
So what? Someone may use the same DNS servers. But they can't register for the same domain. Once you have registered for example.org, you own that domain and nobody else will be able to register for it.
You have registered for example.org and use the following DNS configuration at Linode:
Domain | Nameserver
-------------------+---------------------
example.org | ns1.linode.com
example.org | ns2.linode.com
... | ...
An "evil hacker" may have registered evil-hacker.com and uses this configuration:
Domain | Nameserver
-------------------+----------------------
evil-hacker.com | ns1.linode.com
evil-hacker.com | ns2.linode.com
... | ...
example.org | ns1.linode.com << Those are the lines that bug you, right?
example.org | ns2.linode.com
For simplicity's sake let's say that the IP of your site is 1.1.1.1 and the IP of the evil hacker's site is 2.2.2.2. You are worried that because the "hacker" used the same DNS configuration, your site example.org might resolve to 2.2.2.2, right?
This is what happens, when I try to resolve example.org:
I connect to the DNS root servers to find out which nameserver is responsible for the org top-level domain.
I connect to the nameserver of the org top-level domain and ask it for the IP address of example.org. The org nameserver is managed by your domain registrar. It will look up the information you entered and tells me look at one of the linode nameservers.
I connect to ns1.linode.com and ask it for the IP address of example.org. Linode knows which IP your site has and answers me with 1.1.1.1.
In the above process, I will never see evil-hacker.com or 2.2.2.2. Since our evil hacker (hopefully) can't control the DNS root servers, the nameserver of the org top-level domain or the Linode nameservers, all DNS requests for your site will be answered by "trusted" name servers.
However, a hacker might intercept DNS traffic from my particular machine. He might install malware that always resolves example.org to his IP address 2.2.2.2 (e.g. /etc/hosts) or compromise my network router. So using an SSL certificate for your site is still a good idea :).
Our company develops a web application that other companies can license. Typically, our application runs on:
www.company.example
And a client's version of the application is run on:
client.company.example
Usually, a client runs their own site at:
www.client.example
Sometimes, clients request to have their version of the application available from:
application.client.example
This kind of setup is often seen with blogs (Wordpress, Blogger, Kickapps).
Technically, achieving this "DNS Masking" with a CNAME/A Record and some application configuration is straightforward. I've thought out some potential issues related to this, however, and wonder if you can think of any others that I've missed:
1) Traffic statistics (as measured by external providers, e.g., compete.com) will be lower since the traffic for company.example won't include that of application.client.example. (Local stats would not be affected, of course)
2) Potential cookie disclosure from application.client.example to company.example. If the client is setting cookies at .client.example, those cookies could be read by the company.example server.
3) Email Spoofing. Email could be sent from company.example with the domain application.client.example, possibly causing problems with spam blacklisting due to incompatible SPF records.
Thanks for any thoughts on this.
CNAME has been widely used for so long, especially by hosting companies. There are no major issues.
The biggest problem for us is when you have to use HTTPS. It's very difficult to support multiple CNAMEs on the same server. We use aliases in certificate (SAN extension). We have to get a new cert every time a new CNAME is added in DNS. Other than that, everything works great for us.
As to the issues you mentioned,
This should be an advantage. It's a lot easier to combine the stats than to separate them. So we prefer granular reports.
Cookies are not shared between domains, even if they are on the same IP. As long as apps are properly sandboxed on the server, they can't read each other's cookie.
You should rate-limit your own outgoing SMTP traffic on the server end so you don't get blacklisted.