You are not logged in.

#1 2018-02-17 00:47:32

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Local DNS server (ft. unbound)

The stock BunsenLabs desktop defers all DNS queries to the gateway IP address, ie, the router.

In practical terms this means that when an attempt is made to connect to any given URL BunsenLabs will request the actual IP address from the internet service provider.

Unfortunately, the plain DNS protocol is not secure and is vulnerable from various attacks (eg, cache poisoning). DNSSEC is a DNS extension which enables the client to verify the DNS query response and make sure there is no attacker to spoof some records.

Whilst the ISP may provide DNSSEC validation, the possibility of man-in-the-middle-attacks (especially when connected to untrusted networks) cannot be eliminated unless a local DNS server is used.

Fortunately, the dnssec-trigger package offers a simple way to install and configure a local DNS server in a Debian (& BunsenLabs) system:

sudo apt install dnssec-trigger

The package will configure unbound and also autostart a systray icon that will display the DNSSEC status and allow the user to toggle it's operation for those sites that need it to be turned off.

Once the system is up & running, test it like this:

dig org. SOA +dnssec

Which should return a large block of output, the important stuff is at the top:

; <<>> DiG 9.11.2-P1 <<>> org. SOA +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29954
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 1

The ad in the "flags" section and the "status: NOERROR" bit in the HEADER section tell us that all is working as expected.

Then double-check with a "bad" address:

dig +noall +comments dnssec-failed.org

Which is a little easier to interpret:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24025
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096

I think this would make a good addition to our stock desktop.


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#2 2018-02-17 17:15:05

martix
Kim Jong-un Stunt Double
Registered: 2016-02-19
Posts: 1,267

Re: Local DNS server (ft. unbound)

How is it supposed to work with nscd and openresolv? Or are there maybe config issues if someone is using a vpn?

I remembered a thread about unbound which I just did not find. Maybe I just recalled those posts from cloverskull's thread. Anyhow I gave it a try and it says for probe results: "OK; error, no answer NOTIMPL; OK, error, no answer; NOTIMPL" and that dig org. delivers Query: 1, everything else is 0.

Offline

#3 2018-02-17 18:06:43

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: Local DNS server (ft. unbound)

martix wrote:

How is it supposed to work with nscd and openresolv?

The dnssec-trigger package is supposed to auto-configure everything and should populate /etc/resolv.conf with a single nameserver that points to the localhost so it is intended to replace such solutions rather than co-operate with them.

martix wrote:

Or are there maybe config issues if someone is using a vpn?

Only if the VPN's DNS server is required to connect to the VPN, the systray icon can be used to toggle activation for such circumstances, I would think.

Having said that, I have no personal experience of VPNs so I'm probably missing something.

martix wrote:

I gave it a try and it says for probe results: "OK; error, no answer NOTIMPL; OK, error, no answer; NOTIMPL" and that dig org. delivers Query: 1, everything else is 0.

The full error message would be more useful.

Has /etc/resolv.conf been changed to point to 127.0.0.1?

Is the unbound server actually running?


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#4 2018-02-17 19:44:36

martix
Kim Jong-un Stunt Double
Registered: 2016-02-19
Posts: 1,267

Re: Local DNS server (ft. unbound)

Head_on_a_Stick wrote:

The full error message would be more useful.

Has /etc/resolv.conf been changed to point to 127.0.0.1?

Is the unbound server actually running?

It's running:

service unbound status
● unbound.service - Unbound DNS server
   Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enab
   Active: active (running) since Sat 2018-02-17 16:35:04 CET; 3h 54min ago
     Docs: man:unbound(8)
  Process: 6079 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_updat
  Process: 5897 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exit
 Main PID: 6217 (unbound)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/unbound.service
           └─6217 /usr/sbin/unbound -d

And resolv.conf is changed:

# Generated by dnssec-trigger-script
nameserver 127.0.0.1

Results:

dnssec-trigger 0.13
results from probe at 2018-02-17 20:25:59
tcp80 185.49.140.67: OK 
authority 192.5.5.241: error no answer, NOTIMPL
http fedoraproject.org (209.132.181.16): OK 
cache 208.67.222.222: error no answer, NOTIMPL

DNSSEC results fetched from relay resolvers over TCP

"Unfortunately, the plain DNS protocol is not secure and is vulnerable from various attacks (eg, cache poisoning)." - Is this the same with unbound+nscd+openresolv? It's actually working now with dnssec, maybe I should remove those other two packages.

Offline

#5 2018-02-17 20:08:08

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: Local DNS server (ft. unbound)

martix wrote:

Is this the same with unbound+nscd+openresolv?

It is possible to manually configure unbound for DNSSEC validation without using the dnssec-trigger package:

https://wiki.archlinux.org/index.php/Un … validation

maybe I should remove those other two packages.

They seem to be co-operating, resolv.conf has the correct contents.


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#6 2018-02-17 20:39:27

martix
Kim Jong-un Stunt Double
Registered: 2016-02-19
Posts: 1,267

Re: Local DNS server (ft. unbound)

^Do you get four OKs?

Offline

#7 2018-02-17 20:59:50

Sun For Miles
Member
Registered: 2017-04-12
Posts: 203

Re: Local DNS server (ft. unbound)

Kudos for raising this proposal.

The question of DNS security has to be one of the most underrated issues present in today networks. Why this is not an alarming status everywhere is beyond me. Spoofing DNS requests is so trivial today. Even I poison my own local network by redirecting DNS packets to known servers I'd prefer to use, but this white hat scenario is probably not seen very often in "the wild".


Señor Chang, why do you teach Spanish?

Offline

#8 2018-02-17 21:29:05

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: Local DNS server (ft. unbound)

^ Thanks for the words of support.

martix wrote:

Do you get four OKs?

Use the `dig` command to check for sure:

dig pir.org +dnssec +multi

Should give:

; <<>> DiG 9.10.3-P4-Debian <<>> pir.org +dnssec +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30020
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 1
[...]

Although that output is from QEMU and the host also has unbound running so I'm not sure how that effects things.


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#9 2018-02-18 00:14:21

martix
Kim Jong-un Stunt Double
Registered: 2016-02-19
Posts: 1,267

Re: Local DNS server (ft. unbound)

^+1 for Sun For Miles. I think for the general public it's just too nerdy stuff, people don't care about things like that - as long as it works. But within the tech community I got the feeling too that this topic does not get the attention that it deserves. Although DNSCrypt was a step in the right direction, but generally there should be more focus on DNS security.

Meanwhile I did some digging and my issue might have something to do with the (ISP's) DNS server set by the network-manager (/etc/resolvconf/resolv.conf.d/original). The IP belonging to cache (above under results) comes from this file and using that dns server delivers

error no RRSIGs in reply

Also that dig command has a bit different output, besides a different id I have flags without "ad", Answer: 1, Authority and Additional: 0. The rest is the same.

Offline

#10 2018-02-18 23:20:33

martix
Kim Jong-un Stunt Double
Registered: 2016-02-19
Posts: 1,267

Re: Local DNS server (ft. unbound)

There are really interesting linux articles in french sometimes, like here (same error messages), wish I understood it better.

I'm wondering regarding this dnssec configuration: Stopping resolv.conf using the dns server set by the ISP via this method (at the end) is completely unnecessary after installing the package? Just cannot see in which way the dns server set by the isp is relevant after installing the dnssec package.

So far it's working fine, did not understand that error message yet though.

Offline

#11 2018-02-18 23:24:33

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: Local DNS server (ft. unbound)

martix wrote:

Stopping resolv.conf using the dns server set by the ISP via this method (at the end) is completely unnecessary after installing the package?

I don't use NetworkMangler so perhaps you could try it and see?

NM is the usual connection method so I'm sure dnssec-trigger can accommodate it without the need for any Arch-style hackery.


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#12 2018-02-20 00:01:12

martix
Kim Jong-un Stunt Double
Registered: 2016-02-19
Posts: 1,267

Re: Local DNS server (ft. unbound)

It's good to learn more about dnssec (and be aware of its limitations): "you are only protected when accessing websites that have chosen to enable DNSSEC on the server side. If server side DNSSEC is not implemented for a particular domain, you may still receive tampered DNS responses for that domain. " Also: "DNSSEC was introduced to address the lack of authentication and integrity checks when resolving domain names using DNS. It does not address the problem of confidentiality."

The basic process with network-manager looks like this according to a redhat description:
"Once unbound is installed and configured in /etc/resolv.conf, all DNS queries from applications are processed by unbound. dnssec-trigger only reconfigures the unbound resolver when triggered to do so. This mostly applies to roaming client machines, such as laptops, that connect to different Wi-Fi networks. The process is as follows:

    - NetworkManager “triggers” dnssec-trigger when a new DNS server is obtained through DHCP.
    - Dnssec-trigger then performs a number of tests against the server and decides whether or not it properly supports DNSSEC.
    - If it does, then dnssec-trigger reconfigures unbound to use that DNS server as a forwarder for all queries.
    - If the tests fail, dnssec-trigger will ignore the new DNS server and try a few available fall-back methods.
    - If it determines that an unrestricted port 53 (UDP and TCP) is available, it will tell unbound to become a full recursive DNS server    without using any forwarder.
    - If this is not possible, for example because port 53 is blocked by a firewall for everything except reaching the network's DNS server itself, it will try to use DNS to port 80, or TLS encapsulated DNS to port 443. Servers running DNS on port 80 and 443 can be configured in /etc/dnssec-trigger/dnssec-trigger.conf. Commented out examples should be available in the default configuration file.
    - If these fall-back methods also fail, dnssec-trigger offers to either operate insecurely, which would bypass DNSSEC completely, or run in “cache only” mode where it will not attempt new DNS queries but will answer for everything it already has in the cache.

Wi-Fi Hotspots increasingly redirect users to a sign-on page before granting access to the Internet. During the probing sequence outlined above, if a redirection is detected, the user is prompted to ask if a login is required to gain Internet access. The dnssec-trigger daemon continues to probe for DNSSEC resolvers every ten seconds."

It also works with vpn: "the combination of unbound, dnssec-trigger, and NetworkManager can properly support domains and name servers provided by VPN software." - Indeed, so far I tested it looks ok.

If I understand correctly this DNS setup is still insecure as far as the dns requests are not encrypted. And avoiding the dns server set by the ISP is still kind of mystery to me. But it works ok so far, including that "dig" command.

Offline

#13 2018-02-20 07:36:11

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: Local DNS server (ft. unbound)

^ Thanks for the information, that is very interesting.

martix wrote:

If I understand correctly this DNS setup is still insecure as far as the dns requests are not encrypted.

Security and anonymity are two different things and DNSSEC is really supposed to protect against spoofing and man-in-the-middle attacks rather than conceal the user's identity and actions.

martix wrote:

avoiding the dns server set by the ISP

My various unbound daemons seem to accept the ISP-provided servers but at least I now know that their DNSSEC is working  angel


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#14 2018-02-20 15:42:01

martix
Kim Jong-un Stunt Double
Registered: 2016-02-19
Posts: 1,267

Re: Local DNS server (ft. unbound)

Head_on_a_Stick wrote:

Security and anonymity are two different things and DNSSEC is really supposed to protect against spoofing and man-in-the-middle attacks rather than conceal the user's identity and actions.

Dnssec is surely a step in the right directions, but a dns configuration can (should) be even better with dnscrypt together: "DNSCrypt and DNSSEC are complementary. DNSSEC does a number of things. First, it provides authentication. (Is the DNS record I’m getting a response for coming from the owner of the domain name I’m asking about or has it been tampered with?) Second, DNSSEC provides a chain of trust to help establish confidence that the answers you’re getting are verifiable. But unfortunately, DNSSEC doesn’t actually provide encryption for DNS records, even those signed by DNSSEC. Even if everyone in the world used DNSSEC, the need to encrypt all DNS traffic would not go away. Moreover, DNSSEC today represents a near-zero percentage of overall domain names and an increasingly smaller percentage of DNS records each day as the Internet grows. That said, DNSSEC and DNSCrypt can work perfectly together. They aren’t conflicting in any way. Think of DNSCrypt as a wrapper around all DNS traffic and DNSSEC as a way of signing and providing validation for a subset of those records. There are benefits to DNSSEC that DNSCrypt isn’t trying to address."

Head_on_a_Stick wrote:

My various unbound daemons seem to accept the ISP-provided servers but at least I now know that their DNSSEC is working  angel

Since ISPs started to collect every piece of information about their customers - in order to make money out of the data -, it's probably better to be careful with handing over personal info (like dns queries).

Thinking about it - as it is the basic of the basics of networking - such a setup with dnssec and dnscrypt should be standard at least in the linux world (but the current stand is far away from it). Good (short) sum up of the issues I found:

"    - Each time your web browser retrieves information from a server on the Internet, it performs a DNS query to get the IP address of that server. Thus, someone with access to DNS query logs can determine what Internet sites you’ve been visiting and when.
    - DNS queries are typically transmitted unencrypted, so can be passively monitored.
    - Instead of performing a DNS lookup and returning the result, a malicious DNS server can fake the response to direct your browser elsewhere (DNS hijacking: https://en.wikipedia.org/wiki/DNS_hijacking), block access to certain websites or domains, or if the lookup fails, direct you to a page of advertisements.
    - DNS “black holes” can be set up. While these can be useful for blocking spam, on the other hand even legitimate DNS servers can be manipulated by governments to censor parts of the Internet (e.g. Twitter, YouTube) for political or commercial reasons.
    - DNS hijacking by consumer ISPs for their own gain rather than customer benefit is unfortunately not uncommon (see the references on the Wiki page above and http://gigaom.com/2014/05/13/atts-gigap … d-choose/). Furthermore, there might be pressures on ISPs from governments and law enforcement agencies to compromise their customers’ privacy or censor their browsing."

Offline

#15 2018-02-20 21:23:49

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: Local DNS server (ft. unbound)

^ It is possible to configure unbound to forward requests to specific nameservers:

https://wiki.archlinux.org/index.php/un … g_requests


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#16 2018-02-22 15:33:23

martix
Kim Jong-un Stunt Double
Registered: 2016-02-19
Posts: 1,267

Re: Local DNS server (ft. unbound)

^That is out-of-the-box in the file /var/cache/unbound/resolvconf_resolvers.conf. It looks like that Arch configuration is a bit different, also the anchor .key file is in /var/lib/unbound/root.key

There is an older blog post suggesting it's not a good idea using dnssec, but it still looks like to me that dnssec and dnscrypt with unbound + a carefully choosen dns server (not the ISP's) is a good (best possible?) set up right now (that Arch guide suggests that also the expat package is needed for those dnssec validation commands).

There were news about ending the development of dnscrypt but there is dnscrypt-proxy having a package in the repos (and even a dnscrypt-proxy-gui on github). dnscrypt-proxy suggests installing resolvconf, but it would remove dnssec-trigger (also openresolv). The set-up can be a mess, although there are several guides to find on the net.

Offline

#17 2018-02-22 15:46:09

devnull
Member
Registered: 2017-06-29
Posts: 69

Re: Local DNS server (ft. unbound)

I agree that while SSL mitigates a DNS poisoning quite much, it is still a bitch, and if the ssl certificate is also a valid one then having an out of the box protection against it can really be an awesome thing, thanks!

Last edited by devnull (2018-02-22 15:46:47)

Offline

#18 2018-02-22 23:33:26

martix
Kim Jong-un Stunt Double
Registered: 2016-02-19
Posts: 1,267

Re: Local DNS server (ft. unbound)

I checked Synaptic and the packages openresolv or resolvconf are unchecked. I'm wondering why there are still such packages to remove (and to install).

sudo apt purge resolvconf 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  resolvconf*
0 upgraded, 0 newly installed, 1 to remove and 9 not upgraded.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.



sudo apt install resolvconf
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  gir1.2-networkmanager-1.0 libldns2
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  dnssec-trigger
The following NEW packages will be installed:
  resolvconf
0 upgraded, 1 newly installed, 1 to remove and 9 not upgraded.
Need to get 74.2 kB of archives.
After this operation, 180 kB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.



sudo apt purge openresolv
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  openresolv*
0 upgraded, 0 newly installed, 1 to remove and 9 not upgraded.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.


sudo apt install openresolv
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  gir1.2-networkmanager-1.0 libldns2
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  dnssec-trigger
The following NEW packages will be installed:
  openresolv
0 upgraded, 1 newly installed, 1 to remove and 9 not upgraded.
Need to get 22.9 kB of archives.
After this operation, 283 kB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.

Checking apt-cache:

apt-cache show openresolv*
Package: openresolv
Version: 3.8.0-1
Installed-Size: 91
Maintainer: Jose dos Santos Junior <j.s.junior@live.com>
Architecture: amd64
Provides: resolvconf
Conflicts: resolvconf
Description-en: management framework for resolv.conf
 Allows multiple daemons to manage resolv.conf and configures
 local resolvers such as dnsmasq and unbound.
 .
 This package may require some manual configuration.
 Please read resolvconf(8) and resolvconf.conf(5) for detailed instructions.
Description-md5: 6e7537951e253b4f50975d1c54aa3407
Homepage: http://roy.marples.name/projects/openresolv/home
Section: net
Priority: optional
Filename: pool/main/o/openresolv/openresolv_3.8.0-1_amd64.deb
Size: 22870
MD5sum: 9952e73dc41bdfe83d5373d4d74418b2
SHA256: 408e1b1d0cf2f0f03fa212060ac7a711ebc24255e488ba38d9e7f884e212e21a


apt-cache show resolvconf*
Package: resolvconf
Version: 1.79
Installed-Size: 191
Maintainer: resolvconf maintainers <resolvconf-devel@lists.alioth.debian.org>
Architecture: all
Depends: ifupdown, lsb-base (>= 4.1+Debian3), debconf (>= 0.5) | debconf-2.0, init-system-helpers (>= 1.18~)
Enhances: dhcpcd, dnsmasq, ifupdown, isc-dhcp-client, libc6, network-manager, nscd, pdnsd, ppp, pump, udhcpc
Breaks: dhcp3-client (<< 4.1.1-P1-15+squeeze1), dnscache-run, sysv-rc (<< 2.88dsf-42)
Description-en: name server information handler
 Resolvconf is a framework for keeping up to date the system's
 information about name servers. It sets itself up as the intermediary
 between programs that supply this information (such as ifup and
 ifdown, DHCP clients, the PPP daemon and local name servers) and
 programs that use this information (such as DNS caches and resolver
 libraries).
 .
 This package may require some manual configuration. Please
 read the README file for detailed instructions.
Description-md5: e009e7114cd0b15ac6dbe0d813ec9472
Homepage: http://alioth.debian.org/projects/resolvconf/
Tag: admin::configuring, interface::commandline, network::configuration,
 protocol::dns, role::program, use::configuring
Section: net
Priority: optional
Filename: pool/main/r/resolvconf/resolvconf_1.79_all.deb
Size: 74158
MD5sum: 7055f59950997f453aa2634ffa7412fe
SHA256: 7d564b42807cd5d97ed2f5e6b2032b946225800f60cb24dbd9eb7e15cbaf84e6

Offline

#19 2018-02-23 07:47:27

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: Local DNS server (ft. unbound)

^ It's a bit confusing but I think openresolv is an alternative to resolvconf that is supposed to work with dnssec-trigger but I'm not really sure tbh.


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#20 2018-02-23 12:22:09

martix
Kim Jong-un Stunt Double
Registered: 2016-02-19
Posts: 1,267

Re: Local DNS server (ft. unbound)

^Yes, it's confusing as on the same system it shows 1 to remove (resolvconf*, although Synaptic does not show any installed resolvconf package) while for apt install it is 1 newly installed (resolvconf), 1 to remove (dnssec-trigger). I was just trying to figure it out because there is a resolvconf.conf in /etc and also resolvconf_resolvers.conf in /var/cache/unbound.

DNSsec and DNScrypt are supposed to working fine together like in this short guide, but I also have the same issues like here.

In that firs guide it is saying: "To switch away from your ISP's default DNS resolver to a DNSCrypt resolver, simply install the dnscrypt-proxy package and then set it as the default resolver either in /etc/resolv.conf: nameserver 127.0.2.1" - this way it won't work that simply, because dnssec-trigger-script in /usr/lib/dnssec-trigger and it looks to me that this script always overwrites the content of resolv.conf to "nameserver 127.0.0.1" and also makes it only readable.

Offline

#21 2018-02-25 11:28:03

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: Local DNS server (ft. unbound)

If dhclient is invoked after the desktop has been started then /etc/resov.conf may be overwritten, to prevent this add a file at /etc/dhcp/dhclient-enter-hooks.d/nodnsupdate with the following content:

#!/bin/sh
make_resolv_conf() {
    true
}

Then make it executable:

sudo chmod +x /etc/dhcp/dhclient-enter-hooks.d/nodnsupdate

“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#22 2018-02-26 14:23:48

martix
Kim Jong-un Stunt Double
Registered: 2016-02-19
Posts: 1,267

Re: Local DNS server (ft. unbound)

^Tried it but did not work.

For

sudo lsof -nPi | grep \:53

I get

systemd       1            root   50u  IPv4  15348      0t0  TCP 127.0.2.1:53 (LISTEN)
systemd       1            root   51u  IPv4  15349      0t0  UDP 127.0.2.1:53 
dnscrypt-  6276 _dnscrypt-proxy    3u  IPv4  15348      0t0  TCP 127.0.2.1:53 (LISTEN)
dnscrypt-  6276 _dnscrypt-proxy    4u  IPv4  15349      0t0  UDP 127.0.2.1:53 
unbound    6585         unbound    3u  IPv6  28099      0t0  UDP [::1]:53 
unbound    6585         unbound    4u  IPv6  28100      0t0  TCP [::1]:53 (LISTEN)
unbound    6585         unbound    5u  IPv4  28101      0t0  UDP 127.0.0.1:53 
unbound    6585         unbound    6u  IPv4  28102      0t0  TCP 127.0.0.1:53 (LISTEN)

Somehow dnssec is still getting back to the isp's dns while testing a connection, inspite of forward-zone in the config file. Also noticed that root.key has TWO dnskeys (one is at least the key which I get via get-trust-anchor script from github).

Offline

#23 2018-02-26 22:30:22

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: Local DNS server (ft. unbound)

martix wrote:

^Tried it but did not work.

Sorry but that was a general comment (related to a problem I uncovered in my live ISO image) rather than a suggestion for you.

I will have to get back to you about this, Helium development is ramping up so this will have to take a back seat for a bit, sorry.


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

Board footer

Powered by FluxBB