Web lists-archives.com

Re: Setting up a local DNS server but clients that use it can't access the internet




	Hi.

Let me reorder it a bit.

On Sat, Feb 24, 2018 at 02:20:57PM +0000, Aero Maxx wrote:
> On 24 February 2018 at 13:16, Aero Maxx <aero.maxx.d@xxxxxxxxx> wrote:
> 
> > On 24 February 2018 at 12:56, Reco <recoverym4n@xxxxxxxxx> wrote:
> >
> >> So, a SERVFAIL. That's curious, to say the least.
> >>
> >> OK, let's try this:
> >>
> >> 1) Put "dnssec-validation no;" in your named.conf.options.
> >>
> >> 2) Restart (as in - stop then start) BIND.
> >>
> >> 3) Execute "dig in a debian.org @127.0.0.1" once more.
> >>
> >> 4) Please provide BIND logs from its last restart.
> >>
> >
> > I made those changes and apt-get update now works.

Figures. Certain ISPs are unable to implement DNSSec even if someone's
life would depend on it. A figure of speech, just in case.


> > Have attached the output of the commands, and my syslog file as I didn't
> > have a log file specifically for bind9.

Your e-mail came without the logs, but it hardly matters now, as we have
a viable workaround.
In Modern™ Debian one should be able to get BIND log like this:

grep named /var/log/daemon.log


> Is there anything I can do to make it work with dnssec-validation set to
> auto?

I suggest you to bring it to Virgin Media. After all, its them who
deliberately crippled their DNS, or used some toy instead of a real DNS.


> If I change the forwarding ip addresses to the google public dns servers it
> works with auto, but the other virgin media address for dns don't work with
> auto, why is that, have they configured something different to google?

Sure they are.

Exibit 1 (Amazon AWS, just in case):

$ dig in a debian.org +trace +recurse

; <<>> DiG 9.10.3-P4-Debian <<>> in a debian.org +trace +recurse
;; global options: +cmd
.                       518400  IN      NS      B.ROOT-SERVERS.NET.
...
org.                    172800  IN      NS      d0.org.afilias-nst.org.
org.                    86400   IN      DS      9795 7 1 364D...
org.                    86400   IN      DS      9795 7 2 3922...
org.                    86400   IN      RRSIG   DS 8 1 86400
20180309050000 20180224040000 41824 . ..
;; Received 812 bytes from 193.0.14.129#53(K.ROOT-SERVERS.NET) in 2 ms

debian.org.             86400   IN      NS      dnsnode.debian.org.
debian.org.             86400   IN      DS      6487 8 2 A952...
debian.org.             86400   IN      RRSIG   DS 7 2 86400 20...
;; Received 364 bytes from 199.249.112.1#53(a2.org.afilias-nst.info) in
74 ms

debian.org.             300     IN      A       5.153.231.4
debian.org.             300     IN      A       128.31.0.62
debian.org.             300     IN      A       130.89.148.14
debian.org.             300     IN      A       149.20.4.15
debian.org.             300     IN      RRSIG   A 8 2 300 20180...
;; Received 337 bytes from 192.174.68.100#53(sec1.rcode0.net) in 75 ms

Observe numerous DS and RRSIG records, which are provided by every DNS
starting from the root one.


Exibit 2 (Google DNS)

$ dig in a debian.org +trace +recurse @8.8.8.8

; <<>> DiG 9.10.3-P4-Debian <<>> in a debian.org +trace +recurse
...
.                       129251  IN      NS      m.root-servers.net.
.                       129251  IN      RRSIG   NS 8 0 518400 20...
;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 2 ms

<and more or less the same as Exibit 1 of "dig" doing the recursion>

As long as your forwarder provides a valid RRSIG record - your DNSSec
validation is a go.


Apparently your forwarders do not bother with RRSIG.
Since you have your DNS working - you might as well check it out, and
share a result with the community.

Reco