DNS security

>posting about technology on /g/
Add smartphones and SJW to your next thread, nerd.

>>60721825
Is this fucking dns even real?

>>60722794
Yes, read up on it if you're interested.

>>60721825
>DNSSEC
This just moves the power of the CAs to DNS providers. Cancer.

>DNSCrypt or DNSCurve
Instead of making yet another standard for encrypted communication we could just do DNS requests via IPSec.
That being said, TLS already leaks the domain and subdomain names in plain text so neither of the above will protect you.

>If you're thinking about registering your own domain, check if your registrar offers DNSSEC
Most OpenNIC servers support it.

>>60722889
>>>60721825 (OP) (You)
>>DNSSEC
>This just moves the power of the CAs to DNS providers. Cancer.
DNSSEC itself and X.509 aren't mutually exclusive, but if you mean using DNSSEC with DANE, then you can use your *own* authoritative name servers, as opposed to blindly relying on CAs. DANE has the potential to unshackle us from CAs, unless you explicitly want to use them, which is a good thing.
>>DNSCrypt or DNSCurve
>Instead of making yet another standard for encrypted communication we could just do DNS requests via IPSec.
IPSec helps, indeed, but it faces the same obstacles as many other much needed technology is facing. The majority of the Internet community does either not have the know-how, or the budget, or holds on to legacy for other reasons (fear, politics, you name it). Which is sad, because in order to make IPSec (and DNSSEC, DANE, and many, many more technology) effective we need rapid adoption on a global scale. It needs to be all hands on deck for it to succeed, and that has been excruciatingly slow for decades now.
>That being said, TLS already leaks the domain and subdomain names in plain text so neither of the above will protect you.
TLS doesn't leak query names, and certainly not by design. Our current implementations just don't push DNS traffic over TLS, that's not leaking. There's also an interesting IETF RFC that aims to minimise the query name to a bare minimum [1] which I can recommend you to read as well. Basically the resolver only asks to resolve the first child from the apex in your query (I.e., omitting all subdomains). You'll then get a referral to the child's name server, which you then query for its child you're interested in next. This process repeats all the way to the end of the entity you're actually interested in, without the intermediate name servers knowing what you were actually looking for.

[1] https://tools.ietf.org/html/rfc7816

>>60723615
>DNSSEC itself and X.509 aren't mutually exclusive, but if you mean using DNSSEC with DANE, then you can use your *own* authoritative name servers, as opposed to blindly relying on CAs. DANE has the potential to unshackle us from CAs, unless you explicitly want to use them, which is a good thing.
Both DNSSec and DANE are retarded as fuck as at the end of the day you will still have some form of CA, be it the DNS server itself or an actual CA.

>IPSec helps, indeed, but it faces the same obstacles as many other much needed technology is facing. The majority of the Internet community does either not have the know-how, or the budget, or holds on to legacy for other reasons (fear, politics, you name it). Which is sad, because in order to make IPSec (and DNSSEC, DANE, and many, many more technology) effective we need rapid adoption on a global scale. It needs to be all hands on deck for it to succeed, and that has been excruciatingly slow for decades now.
This does not explain why yet another protocol was created instead of using IPSec.

>TLS doesn't leak query names, and certainly not by design
It leaks domain and subdomain names however, making DNSCrypt and friends useless in the privacy front as after you make the DNS request you will probably make a TLS+HTTP request on that domain.

>>60723706
>>>60723615 (You)
>>DNSSEC itself and X.509 aren't mutually exclusive, but if you mean using DNSSEC with DANE, then you can use your *own* authoritative name servers, as opposed to blindly relying on CAs. DANE has the potential to unshackle us from CAs, unless you explicitly want to use them, which is a good thing.
>Both DNSSec and DANE are retarded as fuck as at the end of the day you will still have some form of CA, be it the DNS server itself or an actual CA.
Which you can now own yourself, instead of blindly trusting a black box. Do you not see this?
>>IPSec helps, indeed, but it faces the same obstacles as many other much needed technology is facing. The majority of the Internet community does either not have the know-how, or the budget, or holds on to legacy for other reasons (fear, politics, you name it). Which is sad, because in order to make IPSec (and DNSSEC, DANE, and many, many more technology) effective we need rapid adoption on a global scale. It needs to be all hands on deck for it to succeed, and that has been excruciatingly slow for decades now.
>This does not explain why yet another protocol was created instead of using IPSec.
We have many tools that perform the same functionality, anon. This is just another example and it happens all the time. It's digital Darwinism out there and it's beautiful. Time will tell which tool works best. At least you have options.
>>TLS doesn't leak query names, and certainly not by design
>It leaks domain and subdomain names however, making DNSCrypt and friends useless in the privacy front as after you make the DNS request you will probably make a TLS+HTTP request on that domain.
That's by no means leaking, anon. That's default and expected behaviour when you make a connection. Of course an intermediate party can reverse lookup the IP addresses to which you connect. If you aim to obfuscate all your network traffic, use an anonymisation network such as Tor.

>>60724031
>Which you can now own yourself
No, the site owner is the one who needs to update the PK to the DNS. You can't own one yourself.

>We have many tools that perform the same functionality, anon. This is just another example and it happens all the time. It's digital Darwinism out there and it's beautiful. Time will tell which tool works best. At least you have options.
Causes fragmentation and slows adoption.

>That's by no means leaking, anon. That's default and expected behaviour when you make a connection. Of course an intermediate party can reverse lookup the IP addresses to which you connect. If you aim to obfuscate all your network traffic, use an anonymisation network such as Tor.
No, I am not talking about "leaking" the IP address. I talk about leaking the domain and subdomain names. See https://en.wikipedia.org/wiki/Server_Name_Indication

>>60724109
>No, the site owner is the one who needs to update the PK to the DNS. You can't own one yourself.
A PK RR does not exist, so I'm left to guessing what you mean. Perhaps you mean the TLSA RR, which contains either a base64-encoded string of the whole certificate, or a digest thereof.

And yes, we can own these ourselves. You validate the RRSIGs up to the root (DNS apex), also from other domains you don't own. It's completely transparent and you validate it yourself. You don't rely on a black box that tells you to trust it.
>Causes fragmentation and slows adoption.
Fragmentation (or competition) is everywhere and is not holding us back, also because neither of all solutions are being rapidly adopted and get the attention they deserve. No, the aforementioned reasons I summed up is what's holding us back, and they're much harder to tackle on a global scale [>>60723615].
>No, I am not talking about "leaking" the IP address. I talk about leaking the domain and subdomain names. See https://en.wikipedia.org/wiki/Server_Name_Indication
SNI only fixes the problem when you have more domains to host than you have public IPv4 addresses to assign. How is this leaking domain names?

>>60721825
I don't know what any of this means and only barely understand what DNS is, where do I start with this kind of thing? Networking, that is. Serious question, I'd like to learn.

>>60721825
so not really a dns question on the hosting side of things but a question nonetheless

so my isp blocks and transparently proxies dns requests ive looked into using dnscrypt as a way of getting around it but it seems like a lot of work to set it up on every device and i would rather do it once.

so i found BIND and im thinking that I could run it on my router, make and keep a copy of all the domain names and what they resolve to, do my own blocking and transparent proxying to get my devices to use bind for dns

that way i only have to configure my router and all my domain name resolution is done inside the network instead of asking google or opendns or opennic or any dns provider

is this not realistic?

monitoring this thread

File: 37515453-photo.jpg (617KB, 1600x1200px) Image search: [Google]

617KB, 1600x1200px

>>60724855
> Serious question, I'd like to learn.

TCP/IP Illustrated, Volume 1: The Protocols

Also, get the first edition, this is really important if your main objective is to learn.

>>60726539
Now I'm wondering whether you're serious or just making fun of those with lesser knowledge. /g/, please advise

>>60726768
Dude I just recommended you a classic written by the legendary UNIX expert W. Richard Stevens, what is your problem?

You said you like to learn, but are too lazy to Google the author to know who he is?

This is why I don't like spoon-feeding people.

>>60726855
Wasn't OP. My bad, didn't google it, and took the 'illustrated' part as a joke.