Maybe not but thought I’d ask. If not, how do I encourage yast2 developers to include some this “advanced” network security options in yast2?
Me: Long time suse user; presently opensuse 42.2. Some call me a “power user”… But never messed w/DNS and from brief research, it looks like starting from zero is a real time sink.
This Q arose because I’ve been checking VPN options and it appears that DNS is a weak point - and that there are good solutions tested and in use, one of which is DNSSEC. However, I don’t see any “default” installations for the lay person. There appear to be many complexities in theory and installation which only somebody familiar w/both the underlying distro as well as DNS 'ware would be able set up properly.
Thus I look for a “yast type” solution for DNSSEC with a canned setup with a few options - probably integrated with other system setup and security. That’s the only way I can see making this important security option common to the individual networking environment. Desktop internet security gets more important every day. IMHO the loss of basic personal privacy, which we see accelerating each week as more and more deep-resource hackers attack anything and everything on the internet, will prove extremely costly. Not just to it’s individual victims but to the businesses and net work environment of the country. More and more large companies expect high level employees to connect from the field from small work stations. This type of connection will be far more reliably secure if the work station distro has made high security a long standing (and long tested and working) default in all its packaged configurations.
Well, anyway. Does anybody know an easy way to beef up suse’s basic DNS security?
I’ve only ever talked to people about configuring server to server DNSSEC.
Doing a little Internet search,
I <think> that all you need to do is point to a DNSSEC-enabled server, current BIND clients are supposed to already have the code to manage the connection to the DNSSEC server.
A number of search hits describe tools you can run to test your DNSSEC connection.
But, the above is mainly for normal DNS services without using a VPN.
When using a VPN, a <proper> setup will provide a DNS server within the VPN to avoid leaking (but this is not always done, so beware since this is the <real> problem to address).
Since you should be getting even your DNS from within your VPN, you should be fairly confident no one should be spoofing the DNS server… although I guess that DNSSEC can still be set up for extra validation.
So, if you have access to a DNSSEC server, go ahead and try just pointing to it and see if you have any problems…
And, if you want confirmation that the DNS server is configured correctly, then use one of those tools to do the verification.
And, would appreciate if you can post the result of any testing you do, it’d be helpful to verify or disprove.
Guessing because I haven’t thought about this before,
A dns server (farm), which already checks DNSSEC, before serving the answers, is Quad9 (18.104.22.168) from IBM &. others. If you use this server, you don’t need to check DNSSEC locally.
Another option is to set up a local dns server. I use dnsmasq, living on a Raspberrypi 1B in my tiny home network. It serves as a dns cache and can do DNSSEC validation.
Perhaps pdns-recursor (≥ 4.1.0 from the server:dns repo).
I have this in /etc/pdns/recursor.conf:
local-address=10.0.0.1, FC00::1, 127.0.0.1, ::1
(My router has 10.0.0.1/8 and FC00::1/64 on the inward facing NIC.)
Start the recursor with systemctl start pdns-recursor
Verify that it works (e.g. **dig powerdns.com a **@127.0.0.1).
When it works, change the nameserver(s) via YaST (I have ::1 on the server itself and FC00::1 otherwise).
Do not forget systemctl enable pdns-recursor.
I have not used dnssec with pdns-recursor (only without), but according to /etc/pdns/recursor.conf-dist, there is an option “dnssec”. More info here: https://doc.powerdns.com/recursor/dnssec.html
Thanks for the idea about simple testing. From your links I found these:
Setting DNS to point to google, 22.214.171.124 and 126.96.36.199 (which I would think would provide DNSSEC, both fail to find DNSSEC.
Setting DNS to 188.8.131.52 similarly fails to find DNSSEC
I will be testing VyprVPN in the next couple days and will see if I can determine what they’re DNS system offers.
Off topic, this paper from two years ago
casts a very poor light on vpn’s. I suspect it’s still largely relevant, although the IPv6 problem may have improved since publication (certainly hope so). But going from the overall situation, I’m inclined to try to implement and test any reasonable security I can, myself. I guess this poor product showing is not too surprising since most of the ready customers looking at vpn’s won’t ever be able to verify what they’re getting for their money in any way - except unless they’re buying access w/in a country region to get restricted media. That shows no/no-go clearly and immediately. And, of course, the negative case - when somebody cleans them out or comes knocking. That leaves reputation, business model, country of jurisdiction and company documents (usually none) to use to evaluate vpn offerings. Kinda like buying lucky charms from the witch doctor.
Thanks for your help.
Ah. The other thought:
Router issues. Have to see what I can see v/v the two routers in the path to AT&T U-verse. The best method hear would be a custom router, but again…time.
Thanks for those details. I got a package from tumbleweed billed dnssec but it complained a couple times and looked like a lot of messing with config files. I was kinda hoping things would work like TSU described, but oh well. The best bang for the buck may be just to plough into it and configure a custom router, either an appliance box (DD-Wrt or that other one), or see if one of the old desktops would suffice, with a new NIC or two.
Then you have 4.1.0, that’s is good.
billed dnssec but it complained a couple times and looked like a lot of messing with config files.
I just discovered that a /etc/pdns/recursor.conf of just 1 line (!) is enough to get the recursor running with dnssec on my work-station.
(local-addres, query-local-address and query-local-address6 are needed when running pdns-recursor on another server)
4-step recipe for the work-station after installing pdns-recursor on that work-station:
- Overwrite /etc/pdns/recursor.conf:
ws:~ # echo 'dnssec=validate' > /etc/pdns/recursor.conf
- Restart the recursor:
ws:~ # systemctl restart pdns-recursor
- Test (dig is in the bind-utils rpm):
ws:~ # dig forums.opensuse.org a @127.0.0.1
; <<>> DiG 9.9.9-P1 <<>> forums.opensuse.org a @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: **NOERROR**, id: 27682
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;forums.opensuse.org. IN A
;; ANSWER SECTION:
forums.opensuse.org. 300 IN A 184.108.40.206
;; Query time: 787 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 11 18:27:36 CET 2018
;; MSG SIZE rcvd: 64
- When all is well (NOERROR), use YaST to set the nameserver to 127.0.0.1 (or ::1)
Thanks for that detailed reply. Saved the lot.
Been spending a few hours getting my openvpn, openSSL and PKI concepts straight (straighter, anyway). I’m going to put the DNS question on the back burner until I get the VPN up and reliable. In fact, that may be a topic of another thread shortly. Then I’ll revisit the DNS question.
Thank you all for your great help.