DNS: Fall back to permissive mode if recursor mode is unavailable
| Message ID | 20170301161141.4628-1-michael.tremer@ipfire.org |
|---|---|
| State | Accepted |
| Commit | e432689aa99ec262879081fc80161c31b8c4a890 |
| Headers |
Return-Path: <development-bounces@lists.ipfire.org> Received: from mail01.ipfire.org (unknown [172.28.1.200]) by web02.ipfire.org (Postfix) with ESMTP id 106866217A for <patchwork@ipfire.org>; Wed, 1 Mar 2017 17:12:03 +0100 (CET) Received: from mail01.ipfire.org (localhost [IPv6:::1]) by mail01.ipfire.org (Postfix) with ESMTP id 6A5E57E3; Wed, 1 Mar 2017 17:12:00 +0100 (CET) Received: from hughes.tremer.info (188.29.165.170.threembb.co.uk [188.29.165.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 978611FA; Wed, 1 Mar 2017 17:11:56 +0100 (CET) From: Michael Tremer <michael.tremer@ipfire.org> To: development@lists.ipfire.org Subject: [PATCH] DNS: Fall back to permissive mode if recursor mode is unavailable Date: Wed, 1 Mar 2017 16:11:41 +0000 Message-Id: <20170301161141.4628-1-michael.tremer@ipfire.org> X-Mailer: git-send-email 2.9.3 X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFire development talk <development.lists.ipfire.org> List-Unsubscribe: <http://lists.ipfire.org/mailman/options/development>, <mailto:development-request@lists.ipfire.org?subject=unsubscribe> List-Archive: <http://lists.ipfire.org/pipermail/development/> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development-request@lists.ipfire.org?subject=help> List-Subscribe: <http://lists.ipfire.org/mailman/listinfo/development>, <mailto:development-request@lists.ipfire.org?subject=subscribe> Cc: Michael Tremer <michael.tremer@ipfire.org> Errors-To: development-bounces@lists.ipfire.org Sender: "Development" <development-bounces@lists.ipfire.org> |
Message
Michael Tremer
March 2, 2017, 3:11 a.m. UTC
The tests when assigning DNS name servers has been extended so that
if no working forwarder can be found, we will test if the local recursor
mode is an option.
If not, we will configure unbound's validator module into permissive
mode so that at least some DNS functionality is available.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
---
config/rootfiles/core/110/filelists/files | 1 +
lfs/unbound | 1 +
src/initscripts/init.d/unbound | 67 ++++++++++++++++++++--
...ting-validator-permissive-mode-at-runtime.patch | 43 ++++++++++++++
4 files changed, 107 insertions(+), 5 deletions(-)
create mode 100644 src/patches/unbound-allow-setting-validator-permissive-mode-at-runtime.patch
Comments
Hello, so I wanted to highlight this patch a little which has been merged into next. It will change fallback behaviour of DNS again which before switched to recursor mode if no usable forwarder could be found. Now IPFire will test if any of the root servers is available and if so, fall back to recursor mode. If not, it will change DNSSEC into permissive mode and will use all given forwarders. The idea behind this is to always be able to provide at least *some* DNS, although DNSSEC will be practically deactivated. It is still missing that we show a big warning where necessary, but at least for some people who were forced by their providers to use their own name servers which do not support DNSSEC at all. So, for the people who have been affected by this issue I can only recommend to test this and give us feedback within about one week. I would like to close the merge window for the next core update around then. Best, -Michael On Wed, 2017-03-01 at 16:11 +0000, Michael Tremer wrote: > The tests when assigning DNS name servers has been extended so that > if no working forwarder can be found, we will test if the local > recursor > mode is an option. > > If not, we will configure unbound's validator module into permissive > mode so that at least some DNS functionality is available. > > Signed-off-by: Michael Tremer <michael.tremer@ipfire.org> > --- > config/rootfiles/core/110/filelists/files | 1 + > lfs/unbound | 1 + > src/initscripts/init.d/unbound | 67 > ++++++++++++++++++++-- > ...ting-validator-permissive-mode-at-runtime.patch | 43 > ++++++++++++++ > 4 files changed, 107 insertions(+), 5 deletions(-) > create mode 100644 src/patches/unbound-allow-setting-validator- > permissive-mode-at-runtime.patch > > diff --git a/config/rootfiles/core/110/filelists/files > b/config/rootfiles/core/110/filelists/files > index 670b9ae..f4ce989 100644 > --- a/config/rootfiles/core/110/filelists/files > +++ b/config/rootfiles/core/110/filelists/files > @@ -1,5 +1,6 @@ > etc/system-release > etc/issue > +etc/rc.d/init.d/unbound > srv/web/ipfire/cgi-bin/index.cgi > srv/web/ipfire/cgi-bin/vpnmain.cgi > usr/lib/libssp.so.0 > diff --git a/lfs/unbound b/lfs/unbound > index 2b7745c..f361f24 100644 > --- a/lfs/unbound > +++ b/lfs/unbound > @@ -70,6 +70,7 @@ $(subst %,%_MD5,$(objects)) : > $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) > @$(PREBUILD) > @rm -rf $(DIR_APP) && cd $(DIR_SRC) && tar axf > $(DIR_DL)/$(DL_FILE) > + cd $(DIR_APP) && patch -Np1 < > $(DIR_SRC)/src/patches/unbound-allow-setting-validator-permissive- > mode-at-runtime.patch > cd $(DIR_APP) && \ > ./configure \ > --prefix=/usr \ > diff --git a/src/initscripts/init.d/unbound > b/src/initscripts/init.d/unbound > index 8802781..bbf9c00 100644 > --- a/src/initscripts/init.d/unbound > +++ b/src/initscripts/init.d/unbound > @@ -114,17 +114,38 @@ update_forwarders() { > echo_warning > fi > > - if [ -n "${broken_forwarders}" -a -z "${forwarders}" > ]; then > - boot_mesg "Falling back to recursor mode" > ${WARNING} > - echo_warning > - > - elif [ -n "${forwarders}" ]; then > + if [ -n "${forwarders}" ]; then > boot_mesg "Configuring upstream name > server(s): ${forwarders:1}" ${INFO} > echo_ok > > + # Make sure DNSSEC is activated > + enable_dnssec > + > echo "${forwarders}" > /var/ipfire/red/dns > unbound-control -q forward ${forwarders} > return 0 > + > + # In case we have found no working forwarders > + else > + # Test if the recursor mode is available > + if can_resolve_root > +bufsize=${new_edns_buffer_size}; then > + # Make sure DNSSEC is activated > + enable_dnssec > + > + boot_mesg "Falling back to recursor > mode" ${WARNING} > + echo_warning > + > + # If not, we set DNSSEC in permissive mode > and allow using all recursors > + elif [ -n "${broken_forwarders}" ]; then > + disable_dnssec > + > + boot_mesg "DNSSEC has been set to > permissive mode" ${FAILURE} > + echo_failure > + > + echo "${broken_forwarders}" > > /var/ipfire/red/dns > + unbound-control -q forward > ${broken_forwarders} > + return 0 > + fi > fi > fi > > @@ -370,6 +391,42 @@ ns_determine_edns_buffer_size() { > return 1 > } > > +get_root_nameservers() { > + while read -r hostname ttl record address; do > + # Searching for A records > + [ "${record}" = "A" ] || continue > + > + echo "${address}" > + done < /etc/unbound/root.hints > +} > + > +can_resolve_root() { > + local ns > + for ns in $(get_root_nameservers); do > + if dig @${ns} +dnssec SOA . $@ >/dev/null; then > + return 0 > + fi > + done > + > + # none of the servers was reachable > + return 1 > +} > + > +enable_dnssec() { > + local status=$(unbound-control get_option val-permissive- > mode) > + > + # Don't do anything if DNSSEC is already activated > + [ "${status}" = "no" ] && return 0 > + > + # Activate DNSSEC and flush cache with any stale and > unvalidated data > + unbound-control -q set_option val-permissive-mode: no > + unbound-control -q flush_zone . > +} > + > +disable_dnssec() { > + unbound-control -q set_option val-permissive-mode: yes > +} > + > case "$1" in > start) > # Print a nicer messagen when unbound is already > running > diff --git a/src/patches/unbound-allow-setting-validator-permissive- > mode-at-runtime.patch b/src/patches/unbound-allow-setting-validator- > permissive-mode-at-runtime.patch > new file mode 100644 > index 0000000..f476d08 > --- /dev/null > +++ b/src/patches/unbound-allow-setting-validator-permissive-mode-at- > runtime.patch > @@ -0,0 +1,43 @@ > +diff --git a/validator/validator.c b/validator/validator.c > +index 676dcdf..7c19f3d 100644 > +--- a/validator/validator.c > ++++ b/validator/validator.c > +@@ -113,7 +113,7 @@ val_apply_cfg(struct module_env* env, struct > val_env* val_env, > + int c; > + val_env->bogus_ttl = (uint32_t)cfg->bogus_ttl; > + val_env->clean_additional = cfg->val_clean_additional; > +- val_env->permissive_mode = cfg->val_permissive_mode; > ++ val_env->permissive_mode = &cfg->val_permissive_mode; > + if(!env->anchors) > + env->anchors = anchors_create(); > + if(!env->anchors) { > +@@ -170,7 +170,6 @@ val_init(struct module_env* env, int id) > + } > + env->modinfo[id] = (void*)val_env; > + env->need_to_validate = 1; > +- val_env->permissive_mode = 0; > + lock_basic_init(&val_env->bogus_lock); > + lock_protect(&val_env->bogus_lock, &val_env- > >num_rrset_bogus, > + sizeof(val_env->num_rrset_bogus)); > +@@ -2084,7 +2083,7 @@ processFinished(struct module_qstate* qstate, > struct val_qstate* vq, > + } > + } > + /* If we are in permissive mode, bogus gets > indeterminate */ > +- if(ve->permissive_mode) > ++ if(*ve->permissive_mode) > + vq->orig_msg->rep->security = > sec_status_indeterminate; > + } > + > +diff --git a/validator/validator.h b/validator/validator.h > +index 23d3072..f8464b8 100644 > +--- a/validator/validator.h > ++++ b/validator/validator.h > +@@ -104,7 +104,7 @@ struct val_env { > + * This allows an operator to run validation 'shadow' > without > + * hurting responses to clients. > + */ > +- int permissive_mode; > ++ int* permissive_mode; > + > + /** > + * Number of entries in the NSEC3 maximum iteration count > table.
On Wed, 2017-03-01 at 16:17 +0000, Michael Tremer wrote: > Hello, > > so I wanted to highlight this patch a little which has been merged > into > next. > > It will change fallback behaviour of DNS again which before switched > to > recursor mode if no usable forwarder could be found. Now IPFire will > test if any of the root servers is available and if so, fall back to > recursor mode. If not, it will change DNSSEC into permissive mode and > will use all given forwarders. > > The idea behind this is to always be able to provide at least *some* > DNS, although DNSSEC will be practically deactivated. > > It is still missing that we show a big warning where necessary, but > at > least for some people who were forced by their providers to use their > own name servers which do not support DNSSEC at all. > > So, for the people who have been affected by this issue I can only > recommend to test this and give us feedback within about one week. I > would like to close the merge window for the next core update around > then. > > Best, > -Michael > > On Wed, 2017-03-01 at 16:11 +0000, Michael Tremer wrote: > > The tests when assigning DNS name servers has been extended so that > > if no working forwarder can be found, we will test if the local > > recursor > > mode is an option. > > > > If not, we will configure unbound's validator module into > > permissive > > mode so that at least some DNS functionality is available. > > > > Signed-off-by: Michael Tremer <michael.tremer@ipfire.org> > > --- > > config/rootfiles/core/110/filelists/files | 1 + > > lfs/unbound | 1 + > > src/initscripts/init.d/unbound | 67 > > ++++++++++++++++++++-- > > ...ting-validator-permissive-mode-at-runtime.patch | 43 > > ++++++++++++++ > > 4 files changed, 107 insertions(+), 5 deletions(-) > > create mode 100644 src/patches/unbound-allow-setting-validator- > > permissive-mode-at-runtime.patch > > > > diff --git a/config/rootfiles/core/110/filelists/files > > b/config/rootfiles/core/110/filelists/files > > index 670b9ae..f4ce989 100644 > > --- a/config/rootfiles/core/110/filelists/files > > +++ b/config/rootfiles/core/110/filelists/files > > @@ -1,5 +1,6 @@ > > etc/system-release > > etc/issue > > +etc/rc.d/init.d/unbound > > srv/web/ipfire/cgi-bin/index.cgi > > srv/web/ipfire/cgi-bin/vpnmain.cgi > > usr/lib/libssp.so.0 > > diff --git a/lfs/unbound b/lfs/unbound > > index 2b7745c..f361f24 100644 > > --- a/lfs/unbound > > +++ b/lfs/unbound > > @@ -70,6 +70,7 @@ $(subst %,%_MD5,$(objects)) : > > $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) > > @$(PREBUILD) > > @rm -rf $(DIR_APP) && cd $(DIR_SRC) && tar axf > > $(DIR_DL)/$(DL_FILE) > > + cd $(DIR_APP) && patch -Np1 < > > $(DIR_SRC)/src/patches/unbound-allow-setting-validator-permissive- > > mode-at-runtime.patch > > cd $(DIR_APP) && \ > > ./configure \ > > --prefix=/usr \ > > diff --git a/src/initscripts/init.d/unbound > > b/src/initscripts/init.d/unbound > > index 8802781..bbf9c00 100644 > > --- a/src/initscripts/init.d/unbound > > +++ b/src/initscripts/init.d/unbound > > @@ -114,17 +114,38 @@ update_forwarders() { > > echo_warning > > fi > > > > - if [ -n "${broken_forwarders}" -a -z > > "${forwarders}" > > ]; then > > - boot_mesg "Falling back to recursor mode" > > ${WARNING} > > - echo_warning > > - > > - elif [ -n "${forwarders}" ]; then > > + if [ -n "${forwarders}" ]; then > > boot_mesg "Configuring upstream name > > server(s): ${forwarders:1}" ${INFO} > > echo_ok > > > > + # Make sure DNSSEC is activated > > + enable_dnssec > > + > > echo "${forwarders}" > /var/ipfire/red/dns > > unbound-control -q forward ${forwarders} > > return 0 > > + > > + # In case we have found no working forwarders > > + else > > + # Test if the recursor mode is available > > + if can_resolve_root > > +bufsize=${new_edns_buffer_size}; then > > + # Make sure DNSSEC is activated > > + enable_dnssec > > + > > + boot_mesg "Falling back to > > recursor > > mode" ${WARNING} > > + echo_warning > > + > > + # If not, we set DNSSEC in permissive mode > > and allow using all recursors > > + elif [ -n "${broken_forwarders}" ]; then > > + disable_dnssec > > + > > + boot_mesg "DNSSEC has been set to > > permissive mode" ${FAILURE} > > + echo_failure > > + > > + echo "${broken_forwarders}" > > > /var/ipfire/red/dns > > + unbound-control -q forward > > ${broken_forwarders} > > + return 0 > > + fi > > fi > > fi > > > > @@ -370,6 +391,42 @@ ns_determine_edns_buffer_size() { > > return 1 > > } > > > > +get_root_nameservers() { > > + while read -r hostname ttl record address; do > > + # Searching for A records > > + [ "${record}" = "A" ] || continue > > + > > + echo "${address}" > > + done < /etc/unbound/root.hints > > +} > > + > > +can_resolve_root() { > > + local ns > > + for ns in $(get_root_nameservers); do > > + if dig @${ns} +dnssec SOA . $@ >/dev/null; then > > + return 0 > > + fi > > + done > > + > > + # none of the servers was reachable > > + return 1 > > +} > > + > > +enable_dnssec() { > > + local status=$(unbound-control get_option val-permissive- > > mode) > > + > > + # Don't do anything if DNSSEC is already activated > > + [ "${status}" = "no" ] && return 0 > > + > > + # Activate DNSSEC and flush cache with any stale and > > unvalidated data > > + unbound-control -q set_option val-permissive-mode: no > > + unbound-control -q flush_zone . > > +} > > + > > +disable_dnssec() { > > + unbound-control -q set_option val-permissive-mode: yes > > +} > > + > > case "$1" in > > start) > > # Print a nicer messagen when unbound is already > > running > > diff --git a/src/patches/unbound-allow-setting-validator- > > permissive- > > mode-at-runtime.patch b/src/patches/unbound-allow-setting- > > validator- > > permissive-mode-at-runtime.patch > > new file mode 100644 > > index 0000000..f476d08 > > --- /dev/null > > +++ b/src/patches/unbound-allow-setting-validator-permissive-mode- > > at- > > runtime.patch > > @@ -0,0 +1,43 @@ > > +diff --git a/validator/validator.c b/validator/validator.c > > +index 676dcdf..7c19f3d 100644 > > +--- a/validator/validator.c > > ++++ b/validator/validator.c > > +@@ -113,7 +113,7 @@ val_apply_cfg(struct module_env* env, struct > > val_env* val_env, > > + int c; > > + val_env->bogus_ttl = (uint32_t)cfg->bogus_ttl; > > + val_env->clean_additional = cfg->val_clean_additional; > > +- val_env->permissive_mode = cfg->val_permissive_mode; > > ++ val_env->permissive_mode = &cfg->val_permissive_mode; > > + if(!env->anchors) > > + env->anchors = anchors_create(); > > + if(!env->anchors) { > > +@@ -170,7 +170,6 @@ val_init(struct module_env* env, int id) > > + } > > + env->modinfo[id] = (void*)val_env; > > + env->need_to_validate = 1; > > +- val_env->permissive_mode = 0; > > + lock_basic_init(&val_env->bogus_lock); > > + lock_protect(&val_env->bogus_lock, &val_env- > > > num_rrset_bogus, > > > > + sizeof(val_env->num_rrset_bogus)); > > +@@ -2084,7 +2083,7 @@ processFinished(struct module_qstate* > > qstate, > > struct val_qstate* vq, > > + } > > + } > > + /* If we are in permissive mode, bogus gets > > indeterminate */ > > +- if(ve->permissive_mode) > > ++ if(*ve->permissive_mode) > > + vq->orig_msg->rep->security = > > sec_status_indeterminate; > > + } > > + > > +diff --git a/validator/validator.h b/validator/validator.h > > +index 23d3072..f8464b8 100644 > > +--- a/validator/validator.h > > ++++ b/validator/validator.h > > +@@ -104,7 +104,7 @@ struct val_env { > > + * This allows an operator to run validation 'shadow' > > without > > + * hurting responses to clients. > > + */ > > +- int permissive_mode; > > ++ int* permissive_mode; > > + > > + /** > > + * Number of entries in the NSEC3 maximum iteration count > > table. > I have nightly commit c016773b9816ad9be4ffc8643c30457e87c094e3 available locally, and will beg my users for downtime to test. Thank you, and best regards, Paul >
On Wed, 2017-03-01 at 12:00 -0600, Paul Simmons wrote: > On Wed, 2017-03-01 at 16:17 +0000, Michael Tremer wrote: > > Hello, > > > > so I wanted to highlight this patch a little which has been merged > > into > > next. > > > > It will change fallback behaviour of DNS again which before > > switched > > to > > recursor mode if no usable forwarder could be found. Now IPFire > > will > > test if any of the root servers is available and if so, fall back > > to > > recursor mode. If not, it will change DNSSEC into permissive mode > > and > > will use all given forwarders. > > > > The idea behind this is to always be able to provide at least > > *some* > > DNS, although DNSSEC will be practically deactivated. > > > > It is still missing that we show a big warning where necessary, but > > at > > least for some people who were forced by their providers to use > > their > > own name servers which do not support DNSSEC at all. > > > > So, for the people who have been affected by this issue I can only > > recommend to test this and give us feedback within about one week. > > I > > would like to close the merge window for the next core update > > around > > then. > > > > Best, > > -Michael > > > > On Wed, 2017-03-01 at 16:11 +0000, Michael Tremer wrote: > > > The tests when assigning DNS name servers has been extended so > > > that > > > if no working forwarder can be found, we will test if the local > > > recursor > > > mode is an option. > > > > > > If not, we will configure unbound's validator module into > > > permissive > > > mode so that at least some DNS functionality is available. > > > > > > Signed-off-by: Michael Tremer <michael.tremer@ipfire.org> > > > --- > > > config/rootfiles/core/110/filelists/files | 1 + > > > lfs/unbound | 1 + > > > src/initscripts/init.d/unbound | 67 > > > ++++++++++++++++++++-- > > > ...ting-validator-permissive-mode-at-runtime.patch | 43 > > > ++++++++++++++ > > > 4 files changed, 107 insertions(+), 5 deletions(-) > > > create mode 100644 src/patches/unbound-allow-setting-validator- > > > permissive-mode-at-runtime.patch > > > > > > diff --git a/config/rootfiles/core/110/filelists/files > > > b/config/rootfiles/core/110/filelists/files > > > index 670b9ae..f4ce989 100644 > > > --- a/config/rootfiles/core/110/filelists/files > > > +++ b/config/rootfiles/core/110/filelists/files > > > @@ -1,5 +1,6 @@ > > > etc/system-release > > > etc/issue > > > +etc/rc.d/init.d/unbound > > > srv/web/ipfire/cgi-bin/index.cgi > > > srv/web/ipfire/cgi-bin/vpnmain.cgi > > > usr/lib/libssp.so.0 > > > diff --git a/lfs/unbound b/lfs/unbound > > > index 2b7745c..f361f24 100644 > > > --- a/lfs/unbound > > > +++ b/lfs/unbound > > > @@ -70,6 +70,7 @@ $(subst %,%_MD5,$(objects)) : > > > $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) > > > @$(PREBUILD) > > > @rm -rf $(DIR_APP) && cd $(DIR_SRC) && tar axf > > > $(DIR_DL)/$(DL_FILE) > > > + cd $(DIR_APP) && patch -Np1 < > > > $(DIR_SRC)/src/patches/unbound-allow-setting-validator- > > > permissive- > > > mode-at-runtime.patch > > > cd $(DIR_APP) && \ > > > ./configure \ > > > --prefix=/usr \ > > > diff --git a/src/initscripts/init.d/unbound > > > b/src/initscripts/init.d/unbound > > > index 8802781..bbf9c00 100644 > > > --- a/src/initscripts/init.d/unbound > > > +++ b/src/initscripts/init.d/unbound > > > @@ -114,17 +114,38 @@ update_forwarders() { > > > echo_warning > > > fi > > > > > > - if [ -n "${broken_forwarders}" -a -z > > > "${forwarders}" > > > ]; then > > > - boot_mesg "Falling back to recursor > > > mode" > > > ${WARNING} > > > - echo_warning > > > - > > > - elif [ -n "${forwarders}" ]; then > > > + if [ -n "${forwarders}" ]; then > > > boot_mesg "Configuring upstream name > > > server(s): ${forwarders:1}" ${INFO} > > > echo_ok > > > > > > + # Make sure DNSSEC is activated > > > + enable_dnssec > > > + > > > echo "${forwarders}" > > > > /var/ipfire/red/dns > > > unbound-control -q forward ${forwarders} > > > return 0 > > > + > > > + # In case we have found no working forwarders > > > + else > > > + # Test if the recursor mode is available > > > + if can_resolve_root > > > +bufsize=${new_edns_buffer_size}; then > > > + # Make sure DNSSEC is activated > > > + enable_dnssec > > > + > > > + boot_mesg "Falling back to > > > recursor > > > mode" ${WARNING} > > > + echo_warning > > > + > > > + # If not, we set DNSSEC in permissive > > > mode > > > and allow using all recursors > > > + elif [ -n "${broken_forwarders}" ]; then > > > + disable_dnssec > > > + > > > + boot_mesg "DNSSEC has been set > > > to > > > permissive mode" ${FAILURE} > > > + echo_failure > > > + > > > + echo "${broken_forwarders}" > > > > /var/ipfire/red/dns > > > + unbound-control -q forward > > > ${broken_forwarders} > > > + return 0 > > > + fi > > > fi > > > fi > > > > > > @@ -370,6 +391,42 @@ ns_determine_edns_buffer_size() { > > > return 1 > > > } > > > > > > +get_root_nameservers() { > > > + while read -r hostname ttl record address; do > > > + # Searching for A records > > > + [ "${record}" = "A" ] || continue > > > + > > > + echo "${address}" > > > + done < /etc/unbound/root.hints > > > +} > > > + > > > +can_resolve_root() { > > > + local ns > > > + for ns in $(get_root_nameservers); do > > > + if dig @${ns} +dnssec SOA . $@ >/dev/null; then > > > + return 0 > > > + fi > > > + done > > > + > > > + # none of the servers was reachable > > > + return 1 > > > +} > > > + > > > +enable_dnssec() { > > > + local status=$(unbound-control get_option val- > > > permissive- > > > mode) > > > + > > > + # Don't do anything if DNSSEC is already activated > > > + [ "${status}" = "no" ] && return 0 > > > + > > > + # Activate DNSSEC and flush cache with any stale and > > > unvalidated data > > > + unbound-control -q set_option val-permissive-mode: no > > > + unbound-control -q flush_zone . > > > +} > > > + > > > +disable_dnssec() { > > > + unbound-control -q set_option val-permissive-mode: yes > > > +} > > > + > > > case "$1" in > > > start) > > > # Print a nicer messagen when unbound is already > > > running > > > diff --git a/src/patches/unbound-allow-setting-validator- > > > permissive- > > > mode-at-runtime.patch b/src/patches/unbound-allow-setting- > > > validator- > > > permissive-mode-at-runtime.patch > > > new file mode 100644 > > > index 0000000..f476d08 > > > --- /dev/null > > > +++ b/src/patches/unbound-allow-setting-validator-permissive- > > > mode- > > > at- > > > runtime.patch > > > @@ -0,0 +1,43 @@ > > > +diff --git a/validator/validator.c b/validator/validator.c > > > +index 676dcdf..7c19f3d 100644 > > > +--- a/validator/validator.c > > > ++++ b/validator/validator.c > > > +@@ -113,7 +113,7 @@ val_apply_cfg(struct module_env* env, struct > > > val_env* val_env, > > > + int c; > > > + val_env->bogus_ttl = (uint32_t)cfg->bogus_ttl; > > > + val_env->clean_additional = cfg->val_clean_additional; > > > +- val_env->permissive_mode = cfg->val_permissive_mode; > > > ++ val_env->permissive_mode = &cfg->val_permissive_mode; > > > + if(!env->anchors) > > > + env->anchors = anchors_create(); > > > + if(!env->anchors) { > > > +@@ -170,7 +170,6 @@ val_init(struct module_env* env, int id) > > > + } > > > + env->modinfo[id] = (void*)val_env; > > > + env->need_to_validate = 1; > > > +- val_env->permissive_mode = 0; > > > + lock_basic_init(&val_env->bogus_lock); > > > + lock_protect(&val_env->bogus_lock, &val_env- > > > > num_rrset_bogus, > > > > > > + sizeof(val_env->num_rrset_bogus)); > > > +@@ -2084,7 +2083,7 @@ processFinished(struct module_qstate* > > > qstate, > > > struct val_qstate* vq, > > > + } > > > + } > > > + /* If we are in permissive mode, bogus gets > > > indeterminate */ > > > +- if(ve->permissive_mode) > > > ++ if(*ve->permissive_mode) > > > + vq->orig_msg->rep->security = > > > sec_status_indeterminate; > > > + } > > > + > > > +diff --git a/validator/validator.h b/validator/validator.h > > > +index 23d3072..f8464b8 100644 > > > +--- a/validator/validator.h > > > ++++ b/validator/validator.h > > > +@@ -104,7 +104,7 @@ struct val_env { > > > + * This allows an operator to run validation 'shadow' > > > without > > > + * hurting responses to clients. > > > + */ > > > +- int permissive_mode; > > > ++ int* permissive_mode; > > > + > > > + /** > > > + * Number of entries in the NSEC3 maximum iteration > > > count > > > table. > > I have nightly commit c016773b9816ad9be4ffc8643c30457e87c094e3 > available locally, and will beg my users for downtime to test. > > Thank you, and best regards, > Paul > > Bad juju - build c016773b couldn't resolve any hosts (other than those in "localdomain"). Provider is "hughes.net" and is the only ISP available (no hardlines or other LOS/NLOS WISPs available). Tried assigning DNS servers 74.113.60.185 and 156.154.70.1 - no change. Paul >
Hi, can you confirm if unbound is running? What is the output of /etc/init.d/unbound restart? -Michael On Fri, 2017-03-03 at 14:54 -0600, Paul Simmons wrote: > On Wed, 2017-03-01 at 12:00 -0600, Paul Simmons wrote: > > On Wed, 2017-03-01 at 16:17 +0000, Michael Tremer wrote: > > > Hello, > > > > > > so I wanted to highlight this patch a little which has been > > > merged > > > into > > > next. > > > > > > It will change fallback behaviour of DNS again which before > > > switched > > > to > > > recursor mode if no usable forwarder could be found. Now IPFire > > > will > > > test if any of the root servers is available and if so, fall back > > > to > > > recursor mode. If not, it will change DNSSEC into permissive mode > > > and > > > will use all given forwarders. > > > > > > The idea behind this is to always be able to provide at least > > > *some* > > > DNS, although DNSSEC will be practically deactivated. > > > > > > It is still missing that we show a big warning where necessary, > > > but > > > at > > > least for some people who were forced by their providers to use > > > their > > > own name servers which do not support DNSSEC at all. > > > > > > So, for the people who have been affected by this issue I can > > > only > > > recommend to test this and give us feedback within about one > > > week. > > > I > > > would like to close the merge window for the next core update > > > around > > > then. > > > > > > Best, > > > -Michael > > > > > > On Wed, 2017-03-01 at 16:11 +0000, Michael Tremer wrote: > > > > The tests when assigning DNS name servers has been extended so > > > > that > > > > if no working forwarder can be found, we will test if the local > > > > recursor > > > > mode is an option. > > > > > > > > If not, we will configure unbound's validator module into > > > > permissive > > > > mode so that at least some DNS functionality is available. > > > > > > > > Signed-off-by: Michael Tremer <michael.tremer@ipfire.org> > > > > --- > > > > config/rootfiles/core/110/filelists/files | 1 + > > > > lfs/unbound | 1 + > > > > src/initscripts/init.d/unbound | 67 > > > > ++++++++++++++++++++-- > > > > ...ting-validator-permissive-mode-at-runtime.patch | 43 > > > > ++++++++++++++ > > > > 4 files changed, 107 insertions(+), 5 deletions(-) > > > > create mode 100644 src/patches/unbound-allow-setting- > > > > validator- > > > > permissive-mode-at-runtime.patch > > > > > > > > diff --git a/config/rootfiles/core/110/filelists/files > > > > b/config/rootfiles/core/110/filelists/files > > > > index 670b9ae..f4ce989 100644 > > > > --- a/config/rootfiles/core/110/filelists/files > > > > +++ b/config/rootfiles/core/110/filelists/files > > > > @@ -1,5 +1,6 @@ > > > > etc/system-release > > > > etc/issue > > > > +etc/rc.d/init.d/unbound > > > > srv/web/ipfire/cgi-bin/index.cgi > > > > srv/web/ipfire/cgi-bin/vpnmain.cgi > > > > usr/lib/libssp.so.0 > > > > diff --git a/lfs/unbound b/lfs/unbound > > > > index 2b7745c..f361f24 100644 > > > > --- a/lfs/unbound > > > > +++ b/lfs/unbound > > > > @@ -70,6 +70,7 @@ $(subst %,%_MD5,$(objects)) : > > > > $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) > > > > @$(PREBUILD) > > > > @rm -rf $(DIR_APP) && cd $(DIR_SRC) && tar axf > > > > $(DIR_DL)/$(DL_FILE) > > > > + cd $(DIR_APP) && patch -Np1 < > > > > $(DIR_SRC)/src/patches/unbound-allow-setting-validator- > > > > permissive- > > > > mode-at-runtime.patch > > > > cd $(DIR_APP) && \ > > > > ./configure \ > > > > --prefix=/usr \ > > > > diff --git a/src/initscripts/init.d/unbound > > > > b/src/initscripts/init.d/unbound > > > > index 8802781..bbf9c00 100644 > > > > --- a/src/initscripts/init.d/unbound > > > > +++ b/src/initscripts/init.d/unbound > > > > @@ -114,17 +114,38 @@ update_forwarders() { > > > > echo_warning > > > > fi > > > > > > > > - if [ -n "${broken_forwarders}" -a -z > > > > "${forwarders}" > > > > ]; then > > > > - boot_mesg "Falling back to recursor > > > > mode" > > > > ${WARNING} > > > > - echo_warning > > > > - > > > > - elif [ -n "${forwarders}" ]; then > > > > + if [ -n "${forwarders}" ]; then > > > > boot_mesg "Configuring upstream name > > > > server(s): ${forwarders:1}" ${INFO} > > > > echo_ok > > > > > > > > + # Make sure DNSSEC is activated > > > > + enable_dnssec > > > > + > > > > echo "${forwarders}" > > > > > /var/ipfire/red/dns > > > > unbound-control -q forward > > > > ${forwarders} > > > > return 0 > > > > + > > > > + # In case we have found no working forwarders > > > > + else > > > > + # Test if the recursor mode is > > > > available > > > > + if can_resolve_root > > > > +bufsize=${new_edns_buffer_size}; then > > > > + # Make sure DNSSEC is > > > > activated > > > > + enable_dnssec > > > > + > > > > + boot_mesg "Falling back to > > > > recursor > > > > mode" ${WARNING} > > > > + echo_warning > > > > + > > > > + # If not, we set DNSSEC in permissive > > > > mode > > > > and allow using all recursors > > > > + elif [ -n "${broken_forwarders}" ]; > > > > then > > > > + disable_dnssec > > > > + > > > > + boot_mesg "DNSSEC has been set > > > > to > > > > permissive mode" ${FAILURE} > > > > + echo_failure > > > > + > > > > + echo "${broken_forwarders}" > > > > > /var/ipfire/red/dns > > > > + unbound-control -q forward > > > > ${broken_forwarders} > > > > + return 0 > > > > + fi > > > > fi > > > > fi > > > > > > > > @@ -370,6 +391,42 @@ ns_determine_edns_buffer_size() { > > > > return 1 > > > > } > > > > > > > > +get_root_nameservers() { > > > > + while read -r hostname ttl record address; do > > > > + # Searching for A records > > > > + [ "${record}" = "A" ] || continue > > > > + > > > > + echo "${address}" > > > > + done < /etc/unbound/root.hints > > > > +} > > > > + > > > > +can_resolve_root() { > > > > + local ns > > > > + for ns in $(get_root_nameservers); do > > > > + if dig @${ns} +dnssec SOA . $@ >/dev/null; > > > > then > > > > + return 0 > > > > + fi > > > > + done > > > > + > > > > + # none of the servers was reachable > > > > + return 1 > > > > +} > > > > + > > > > +enable_dnssec() { > > > > + local status=$(unbound-control get_option val- > > > > permissive- > > > > mode) > > > > + > > > > + # Don't do anything if DNSSEC is already activated > > > > + [ "${status}" = "no" ] && return 0 > > > > + > > > > + # Activate DNSSEC and flush cache with any stale and > > > > unvalidated data > > > > + unbound-control -q set_option val-permissive-mode: no > > > > + unbound-control -q flush_zone . > > > > +} > > > > + > > > > +disable_dnssec() { > > > > + unbound-control -q set_option val-permissive-mode: yes > > > > +} > > > > + > > > > case "$1" in > > > > start) > > > > # Print a nicer messagen when unbound is > > > > already > > > > running > > > > diff --git a/src/patches/unbound-allow-setting-validator- > > > > permissive- > > > > mode-at-runtime.patch b/src/patches/unbound-allow-setting- > > > > validator- > > > > permissive-mode-at-runtime.patch > > > > new file mode 100644 > > > > index 0000000..f476d08 > > > > --- /dev/null > > > > +++ b/src/patches/unbound-allow-setting-validator-permissive- > > > > mode- > > > > at- > > > > runtime.patch > > > > @@ -0,0 +1,43 @@ > > > > +diff --git a/validator/validator.c b/validator/validator.c > > > > +index 676dcdf..7c19f3d 100644 > > > > +--- a/validator/validator.c > > > > ++++ b/validator/validator.c > > > > +@@ -113,7 +113,7 @@ val_apply_cfg(struct module_env* env, > > > > struct > > > > val_env* val_env, > > > > + int c; > > > > + val_env->bogus_ttl = (uint32_t)cfg->bogus_ttl; > > > > + val_env->clean_additional = cfg- > > > > >val_clean_additional; > > > > +- val_env->permissive_mode = cfg->val_permissive_mode; > > > > ++ val_env->permissive_mode = &cfg->val_permissive_mode; > > > > + if(!env->anchors) > > > > + env->anchors = anchors_create(); > > > > + if(!env->anchors) { > > > > +@@ -170,7 +170,6 @@ val_init(struct module_env* env, int id) > > > > + } > > > > + env->modinfo[id] = (void*)val_env; > > > > + env->need_to_validate = 1; > > > > +- val_env->permissive_mode = 0; > > > > + lock_basic_init(&val_env->bogus_lock); > > > > + lock_protect(&val_env->bogus_lock, &val_env- > > > > > num_rrset_bogus, > > > > > > > > + sizeof(val_env->num_rrset_bogus)); > > > > +@@ -2084,7 +2083,7 @@ processFinished(struct module_qstate* > > > > qstate, > > > > struct val_qstate* vq, > > > > + } > > > > + } > > > > + /* If we are in permissive mode, bogus gets > > > > indeterminate */ > > > > +- if(ve->permissive_mode) > > > > ++ if(*ve->permissive_mode) > > > > + vq->orig_msg->rep->security = > > > > sec_status_indeterminate; > > > > + } > > > > + > > > > +diff --git a/validator/validator.h b/validator/validator.h > > > > +index 23d3072..f8464b8 100644 > > > > +--- a/validator/validator.h > > > > ++++ b/validator/validator.h > > > > +@@ -104,7 +104,7 @@ struct val_env { > > > > + * This allows an operator to run validation 'shadow' > > > > without > > > > + * hurting responses to clients. > > > > + */ > > > > +- int permissive_mode; > > > > ++ int* permissive_mode; > > > > + > > > > + /** > > > > + * Number of entries in the NSEC3 maximum iteration > > > > count > > > > table. > > > > I have nightly commit c016773b9816ad9be4ffc8643c30457e87c094e3 > > available locally, and will beg my users for downtime to test. > > > > Thank you, and best regards, > > Paul > > > > > > Bad juju - build c016773b couldn't resolve any hosts (other than > those in "localdomain"). > > Provider is "hughes.net" and is the only ISP available (no hardlines > or other LOS/NLOS WISPs available). > > Tried assigning DNS servers 74.113.60.185 and 156.154.70.1 - no > change. > > Paul > > >
On Sun, 2017-03-05 at 11:42 +0000, Michael Tremer wrote: > Hi, > > can you confirm if unbound is running? > > What is the output of /etc/init.d/unbound restart? > > -Michael > > > > > ----<% snip %>---- > > > > > > I have nightly commit c016773b9816ad9be4ffc8643c30457e87c094e3 > > > available locally, and will beg my users for downtime to test. > > > > > > Thank you, and best regards, > > > Paul > > > > > > > > > > Bad juju - build c016773b couldn't resolve any hosts (other than > > those in "localdomain"). > > > > Provider is "hughes.net" and is the only ISP available (no > > hardlines > > or other LOS/NLOS WISPs available). > > > > Tried assigning DNS servers 74.113.60.185 and 156.154.70.1 - no > > change. > > > > Paul > > Sorry for the lllooonnnggg delay - had to get a testing time window. Unbound was indeed running - verified with "/etc/init.d/unbound status" Command and output from "restart": # /etc/init.d/unbound restart Stopping Unbound DNS Proxy... [ OK ] Starting Unbound DNS Proxy... [ OK ] Ignoring broken upstream name server(s): 74.113.60.185 156.154.70.1 [ WARN ] Falling back to recursor mode [ WARN ] Thank you, Paul
Hi, On Mon, 2017-03-06 at 12:18 -0600, Paul Simmons wrote: > On Sun, 2017-03-05 at 11:42 +0000, Michael Tremer wrote: > > > > Hi, > > > > can you confirm if unbound is running? > > > > What is the output of /etc/init.d/unbound restart? > > > > -Michael > > > > > > > > > > > > > > > > > > > ----<% snip %>---- > > > > > > > > I have nightly commit c016773b9816ad9be4ffc8643c30457e87c094e3 > > > > available locally, and will beg my users for downtime to test. > > > > > > > > Thank you, and best regards, > > > > Paul > > > > > > > > > > > > > > Bad juju - build c016773b couldn't resolve any hosts (other than > > > those in "localdomain"). > > > > > > Provider is "hughes.net" and is the only ISP available (no > > > hardlines > > > or other LOS/NLOS WISPs available). > > > > > > Tried assigning DNS servers 74.113.60.185 and 156.154.70.1 - no > > > change. > > > > > > Paul > > > > > Sorry for the lllooonnnggg delay - had to get a testing time window. > > Unbound was indeed running - verified with "/etc/init.d/unbound status" > > Command and output from "restart": > > # /etc/init.d/unbound restart > Stopping Unbound DNS > Proxy... [ OK ] > Starting Unbound DNS > Proxy... [ OK ] > Ignoring broken upstream name server(s): 74.113.60.185 > 156.154.70.1 [ WARN ] > Falling back to recursor > mode [ WARN ] So, can you remind me what your provider does again? Is any access to other name servers forbidden? If so the updated script should have detected that and should not have activated the recursor mode. Could you manually execute the following commands from the console of IPFire for me? dig @198.41.0.4 +dnssec SOA . The dot at the end is important. What is the output of it? Best, -Michael > > > Thank you, > Paul
On Mon, 2017-03-06 at 21:00 +0000, Michael Tremer wrote: > Hi, > > On Mon, 2017-03-06 at 12:18 -0600, Paul Simmons wrote: > > On Sun, 2017-03-05 at 11:42 +0000, Michael Tremer wrote: > > > > > > Hi, > > > > > > can you confirm if unbound is running? > > > > > > What is the output of /etc/init.d/unbound restart? > > > > > > -Michael > > > > > > > > > > > > > > > > > > > > > > > > ----<% snip %>---- > > > > > > > > > > I have nightly commit > > > > > c016773b9816ad9be4ffc8643c30457e87c094e3 > > > > > available locally, and will beg my users for downtime to > > > > > test. > > > > > > > > > > Thank you, and best regards, > > > > > Paul > > > > > > > > > > > > > > > > > > Bad juju - build c016773b couldn't resolve any hosts (other > > > > than > > > > those in "localdomain"). > > > > > > > > Provider is "hughes.net" and is the only ISP available (no > > > > hardlines > > > > or other LOS/NLOS WISPs available). > > > > > > > > Tried assigning DNS servers 74.113.60.185 and 156.154.70.1 - no > > > > change. > > > > > > > > Paul > > > > > > > > Sorry for the lllooonnnggg delay - had to get a testing time > > window. > > > > Unbound was indeed running - verified with "/etc/init.d/unbound > > status" > > > > Command and output from "restart": > > > > # /etc/init.d/unbound restart > > Stopping Unbound DNS > > Proxy... [ OK ] > > Starting Unbound DNS > > Proxy... [ OK ] > > Ignoring broken upstream name server(s): 74.113.60.185 > > 156.154.70.1 [ WARN ] > > Falling back to recursor > > mode [ WARN ] > > So, can you remind me what your provider does again? Is any access to > other name > servers forbidden? If so the updated script should have detected that > and should > not have activated the recursor mode. > > Could you manually execute the following commands from the console of > IPFire for > me? > > dig @198.41.0.4 +dnssec SOA . > > The dot at the end is important. What is the output of it? > > Best, > -Michael > > > > > > > Thank you, > > Paul > # dig @198.41.0.4 +dnssec SOA . ; <<>> DiG 9.11.0-P3 <<>> @198.41.0.4 +dnssec SOA . ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 811 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: 27 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;. IN SOA ;; ANSWER SECTION: . 86400 IN SOA a.root- servers.net. nstld.verisign-grs.com. 2017030601 1800 900 604800 86400 . 86400 IN RRSIG SOA 8 0 86400 20170319170000 20170306160000 61045 . X2xWv3z0ZmFxXkF9ybMgxMv6dcZ+SmnG3XHcNtAavuPNPLW3cVBwolDP lOU5/tfOaKwbu7HENFWysaekMpb6O7ycg+kryuCP7z6Q4WyG0O2160l1 DDG0UbBW5yidfcghq1r6sdz30RI5cSBGcAOmlktnPkjs9wv9/S/ZPyrC qMPJR9A60R52NcWEONS3DiyGxR66KA4S4grJnDgcI6pcytJGXm/b5WRO +v51tnLT0UVbgXvV03Itn/3MR72muzKXWzzj5LFJST5iqWCgAHJryG3T vNKEYLQ76nwl6B3YVJDjC1InmpIujwXBbxMKpyL1Sh0RLdlHq2TtZS8O qk4V0Q== ;; AUTHORITY SECTION: . 518400 IN NS e.root- servers.net. . 518400 IN NS h.root- servers.net. . 518400 IN NS l.root- servers.net. . 518400 IN NS i.root- servers.net. . 518400 IN NS a.root- servers.net. . 518400 IN NS d.root- servers.net. . 518400 IN NS c.root- servers.net. . 518400 IN NS b.root- servers.net. . 518400 IN NS j.root- servers.net. . 518400 IN NS k.root- servers.net. . 518400 IN NS g.root- servers.net. . 518400 IN NS m.root- servers.net. . 518400 IN NS f.root- servers.net. . 518400 IN RRSIG NS 8 0 518400 20170319170000 20170306160000 61045 . iQVPY67dNDj6w14dY1tDFgwRFqhEXVVLmY8q1woIX1eU7t1k/XaPi+tX 3+PDCFQlrQmWSWUtLPaA6pmrACB6EL2YvWzAiLVyocGCBpUpnbUCNAwm nD4SvBZb0ET2jWbSiAzo8iy+1+Hr84I8RXtbcrcpF5Y/J5Oataxt5z9o dHGQSKru0eYEbwfszq0L5L8KECk6skm7iQ0RAIspdTfjDsIwtvoAhEGV B8qjFQP5Bkcn38b35eWHneCmc3cgG0J+pK/eX/YHpqClcINGh3eavBlC 1KpUkDDMAwCvo+X/MhDE2Ol/VR00/M/YCzXbEv97IWenM1Xi4ArX9F1C xBc0gA== ;; ADDITIONAL SECTION: e.root-servers.net. 518400 IN A 192.203.230 .10 e.root-servers.net. 518400 IN AAAA 2001:500 :a8::e h.root-servers.net. 518400 IN A 198.97.190. 53 h.root-servers.net. 518400 IN AAAA 2001:500 :1::53 l.root-servers.net. 518400 IN A 199.7.83.42 l.root-servers.net. 518400 IN AAAA 2001:500 :9f::42 i.root-servers.net. 518400 IN A 192.36.148. 17 i.root-servers.net. 518400 IN AAAA 2001:7fe ::53 a.root-servers.net. 518400 IN A 198.41.0.4 a.root-servers.net. 518400 IN AAAA 2001:503 :ba3e::2:30 d.root-servers.net. 518400 IN A 199.7.91.13 d.root-servers.net. 518400 IN AAAA 2001:500 :2d::d c.root-servers.net. 518400 IN A 192.33.4.12 c.root-servers.net. 518400 IN AAAA 2001:500 :2::c b.root-servers.net. 518400 IN A 192.228.79. 201 b.root-servers.net. 518400 IN AAAA 2001:500 :84::b j.root-servers.net. 518400 IN A 192.58.128. 30 j.root-servers.net. 518400 IN AAAA 2001:503 :c27::2:30 k.root-servers.net. 518400 IN A 193.0.14.12 9 k.root-servers.net. 518400 IN AAAA 2001:7fd ::1 g.root-servers.net. 518400 IN A 192.112.36. 4 g.root-servers.net. 518400 IN AAAA 2001:500 :12::d0d m.root-servers.net. 518400 IN A 202.12.27.3 3 m.root-servers.net. 518400 IN AAAA 2001:dc3 ::35 f.root-servers.net. 518400 IN A 192.5.5.241 f.root-servers.net. 518400 IN AAAA 2001:500 :2f::f ;; Query time: 836 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Mon Mar 06 15:40:58 CST 2017 ;; MSG SIZE rcvd: 1440 # I suspect the ISP mangles DNS requests directed outside their net. Thank you, Paul
Hi, On Mon, 2017-03-06 at 15:47 -0600, Paul Simmons wrote: > On Mon, 2017-03-06 at 21:00 +0000, Michael Tremer wrote: > > > > Hi, > > > > On Mon, 2017-03-06 at 12:18 -0600, Paul Simmons wrote: > > > > > > On Sun, 2017-03-05 at 11:42 +0000, Michael Tremer wrote: > > > > > > > > > > > > Hi, > > > > > > > > can you confirm if unbound is running? > > > > > > > > What is the output of /etc/init.d/unbound restart? > > > > > > > > -Michael > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----<% snip %>---- > > > > > > > > > > > > I have nightly commit > > > > > > c016773b9816ad9be4ffc8643c30457e87c094e3 > > > > > > available locally, and will beg my users for downtime to > > > > > > test. > > > > > > > > > > > > Thank you, and best regards, > > > > > > Paul > > > > > > > > > > > > > > > > > > > > > > Bad juju - build c016773b couldn't resolve any hosts (other > > > > > than > > > > > those in "localdomain"). > > > > > > > > > > Provider is "hughes.net" and is the only ISP available (no > > > > > hardlines > > > > > or other LOS/NLOS WISPs available). > > > > > > > > > > Tried assigning DNS servers 74.113.60.185 and 156.154.70.1 - no > > > > > change. > > > > > > > > > > Paul > > > > > > > > > > > Sorry for the lllooonnnggg delay - had to get a testing time > > > window. > > > > > > Unbound was indeed running - verified with "/etc/init.d/unbound > > > status" > > > > > > Command and output from "restart": > > > > > > # /etc/init.d/unbound restart > > > Stopping Unbound DNS > > > Proxy... [ OK ] > > > Starting Unbound DNS > > > Proxy... [ OK ] > > > Ignoring broken upstream name server(s): 74.113.60.185 > > > 156.154.70.1 [ WARN ] > > > Falling back to recursor > > > mode [ WARN ] > > > > So, can you remind me what your provider does again? Is any access to > > other name > > servers forbidden? If so the updated script should have detected that > > and should > > not have activated the recursor mode. > > > > Could you manually execute the following commands from the console of > > IPFire for > > me? > > > > dig @198.41.0.4 +dnssec SOA . > > > > The dot at the end is important. What is the output of it? > > > > Best, > > -Michael > > > > > > > > > > > > > > Thank you, > > > Paul > > > > # dig @198.41.0.4 +dnssec SOA . > > ; <<>> DiG 9.11.0-P3 <<>> @198.41.0.4 +dnssec SOA . > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 811 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: 27 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;. IN SOA > > ;; ANSWER SECTION: > . 86400 IN SOA a.root- > servers.net. nstld.verisign-grs.com. 2017030601 1800 900 604800 86400 > . 86400 IN RRSIG SOA 8 0 > 86400 20170319170000 20170306160000 61045 . > X2xWv3z0ZmFxXkF9ybMgxMv6dcZ+SmnG3XHcNtAavuPNPLW3cVBwolDP > lOU5/tfOaKwbu7HENFWysaekMpb6O7ycg+kryuCP7z6Q4WyG0O2160l1 > DDG0UbBW5yidfcghq1r6sdz30RI5cSBGcAOmlktnPkjs9wv9/S/ZPyrC > qMPJR9A60R52NcWEONS3DiyGxR66KA4S4grJnDgcI6pcytJGXm/b5WRO > +v51tnLT0UVbgXvV03Itn/3MR72muzKXWzzj5LFJST5iqWCgAHJryG3T > vNKEYLQ76nwl6B3YVJDjC1InmpIujwXBbxMKpyL1Sh0RLdlHq2TtZS8O qk4V0Q== > > ;; AUTHORITY SECTION: > . 518400 IN NS e.root- > servers.net. > . 518400 IN NS h.root- > servers.net. > . 518400 IN NS l.root- > servers.net. > . 518400 IN NS i.root- > servers.net. > . 518400 IN NS a.root- > servers.net. > . 518400 IN NS d.root- > servers.net. > . 518400 IN NS c.root- > servers.net. > . 518400 IN NS b.root- > servers.net. > . 518400 IN NS j.root- > servers.net. > . 518400 IN NS k.root- > servers.net. > . 518400 IN NS g.root- > servers.net. > . 518400 IN NS m.root- > servers.net. > . 518400 IN NS f.root- > servers.net. > . 518400 IN RRSIG NS 8 0 > 518400 20170319170000 20170306160000 61045 . > iQVPY67dNDj6w14dY1tDFgwRFqhEXVVLmY8q1woIX1eU7t1k/XaPi+tX > 3+PDCFQlrQmWSWUtLPaA6pmrACB6EL2YvWzAiLVyocGCBpUpnbUCNAwm > nD4SvBZb0ET2jWbSiAzo8iy+1+Hr84I8RXtbcrcpF5Y/J5Oataxt5z9o > dHGQSKru0eYEbwfszq0L5L8KECk6skm7iQ0RAIspdTfjDsIwtvoAhEGV > B8qjFQP5Bkcn38b35eWHneCmc3cgG0J+pK/eX/YHpqClcINGh3eavBlC > 1KpUkDDMAwCvo+X/MhDE2Ol/VR00/M/YCzXbEv97IWenM1Xi4ArX9F1C xBc0gA== > > ;; ADDITIONAL SECTION: > e.root-servers.net. 518400 IN A 192.203.230 > .10 > e.root-servers.net. 518400 IN AAAA 2001:500 > :a8::e > h.root-servers.net. 518400 IN A 198.97.190. > 53 > h.root-servers.net. 518400 IN AAAA 2001:500 > :1::53 > l.root-servers.net. 518400 IN A 199.7.83.42 > l.root-servers.net. 518400 IN AAAA 2001:500 > :9f::42 > i.root-servers.net. 518400 IN A 192.36.148. > 17 > i.root-servers.net. 518400 IN AAAA 2001:7fe > ::53 > a.root-servers.net. 518400 IN A 198.41.0.4 > a.root-servers.net. 518400 IN AAAA 2001:503 > :ba3e::2:30 > d.root-servers.net. 518400 IN A 199.7.91.13 > d.root-servers.net. 518400 IN AAAA 2001:500 > :2d::d > c.root-servers.net. 518400 IN A 192.33.4.12 > c.root-servers.net. 518400 IN AAAA 2001:500 > :2::c > b.root-servers.net. 518400 IN A 192.228.79. > 201 > b.root-servers.net. 518400 IN AAAA 2001:500 > :84::b > j.root-servers.net. 518400 IN A 192.58.128. > 30 > j.root-servers.net. 518400 IN AAAA 2001:503 > :c27::2:30 > k.root-servers.net. 518400 IN A 193.0.14.12 > 9 > k.root-servers.net. 518400 IN AAAA 2001:7fd > ::1 > g.root-servers.net. 518400 IN A 192.112.36. > 4 > g.root-servers.net. 518400 IN AAAA 2001:500 > :12::d0d > m.root-servers.net. 518400 IN A 202.12.27.3 > 3 > m.root-servers.net. 518400 IN AAAA 2001:dc3 > ::35 > f.root-servers.net. 518400 IN A 192.5.5.241 > f.root-servers.net. 518400 IN AAAA 2001:500 > :2f::f > > ;; Query time: 836 msec > ;; SERVER: 198.41.0.4#53(198.41.0.4) > ;; WHEN: Mon Mar 06 15:40:58 CST 2017 > ;; MSG SIZE rcvd: 1440 > # > > I suspect the ISP mangles DNS requests directed outside their net. Well, that command shouldn't have worked then. Could you give me an example for something that you cannot resolve? -Michael > > Thank you, > Paul >
On Mon, 2017-03-06 at 22:37 +0000, Michael Tremer wrote: > Hi, > > On Mon, 2017-03-06 at 15:47 -0600, Paul Simmons wrote: > > On Mon, 2017-03-06 at 21:00 +0000, Michael Tremer wrote: > > > > > > Hi, > > > > > > On Mon, 2017-03-06 at 12:18 -0600, Paul Simmons wrote: > > > > > > > > On Sun, 2017-03-05 at 11:42 +0000, Michael Tremer wrote: > > > > > > > > > > > > > > > Hi, > > > > > > > > > > can you confirm if unbound is running? > > > > > > > > > > What is the output of /etc/init.d/unbound restart? > > > > > > > > > > -Michael > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----<% snip %>---- > > > > > > > > > > > > > > I have nightly commit > > > > > > > c016773b9816ad9be4ffc8643c30457e87c094e3 > > > > > > > available locally, and will beg my users for downtime to > > > > > > > test. > > > > > > > > > > > > > > Thank you, and best regards, > > > > > > > Paul > > > > > > > > > > > > > > > > > > > > > > > > > > Bad juju - build c016773b couldn't resolve any hosts (other > > > > > > than > > > > > > those in "localdomain"). > > > > > > > > > > > > Provider is "hughes.net" and is the only ISP available (no > > > > > > hardlines > > > > > > or other LOS/NLOS WISPs available). > > > > > > > > > > > > Tried assigning DNS servers 74.113.60.185 and 156.154.70.1 > > > > > > - no > > > > > > change. > > > > > > > > > > > > Paul > > > > > > > > > > > > > > Sorry for the lllooonnnggg delay - had to get a testing time > > > > window. > > > > > > > > Unbound was indeed running - verified with "/etc/init.d/unbound > > > > status" > > > > > > > > Command and output from "restart": > > > > > > > > # /etc/init.d/unbound restart > > > > Stopping Unbound DNS > > > > Proxy... [ OK ] > > > > Starting Unbound DNS > > > > Proxy... [ OK ] > > > > Ignoring broken upstream name server(s): 74.113.60.185 > > > > 156.154.70.1 [ WARN ] > > > > Falling back to recursor > > > > mode [ WARN ] > > > > > > So, can you remind me what your provider does again? Is any > > > access to > > > other name > > > servers forbidden? If so the updated script should have detected > > > that > > > and should > > > not have activated the recursor mode. > > > > > > Could you manually execute the following commands from the > > > console of > > > IPFire for > > > me? > > > > > > dig @198.41.0.4 +dnssec SOA . > > > > > > The dot at the end is important. What is the output of it? > > > > > > Best, > > > -Michael > > > > > > > > > > > > > > > > > > > Thank you, > > > > Paul > > > > # dig @198.41.0.4 +dnssec SOA . > > > > ; <<>> DiG 9.11.0-P3 <<>> @198.41.0.4 +dnssec SOA . > > ; (1 server found) > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 811 > > ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: > > 27 > > ;; WARNING: recursion requested but not available > > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags: do; udp: 4096 > > ;; QUESTION SECTION: > > ;. IN SOA > > > > ;; ANSWER SECTION: > > . 86400 IN SOA a.root- > > servers.net. nstld.verisign-grs.com. 2017030601 1800 900 604800 > > 86400 > > . 86400 IN RRSIG SOA 8 > > 0 > > 86400 20170319170000 20170306160000 61045 . > > X2xWv3z0ZmFxXkF9ybMgxMv6dcZ+SmnG3XHcNtAavuPNPLW3cVBwolDP > > lOU5/tfOaKwbu7HENFWysaekMpb6O7ycg+kryuCP7z6Q4WyG0O2160l1 > > DDG0UbBW5yidfcghq1r6sdz30RI5cSBGcAOmlktnPkjs9wv9/S/ZPyrC > > qMPJR9A60R52NcWEONS3DiyGxR66KA4S4grJnDgcI6pcytJGXm/b5WRO > > +v51tnLT0UVbgXvV03Itn/3MR72muzKXWzzj5LFJST5iqWCgAHJryG3T > > vNKEYLQ76nwl6B3YVJDjC1InmpIujwXBbxMKpyL1Sh0RLdlHq2TtZS8O qk4V0Q== > > > > ;; AUTHORITY SECTION: > > . 518400 IN NS e.root- > > servers.net. > > . 518400 IN NS h.root- > > servers.net. > > . 518400 IN NS l.root- > > servers.net. > > . 518400 IN NS i.root- > > servers.net. > > . 518400 IN NS a.root- > > servers.net. > > . 518400 IN NS d.root- > > servers.net. > > . 518400 IN NS c.root- > > servers.net. > > . 518400 IN NS b.root- > > servers.net. > > . 518400 IN NS j.root- > > servers.net. > > . 518400 IN NS k.root- > > servers.net. > > . 518400 IN NS g.root- > > servers.net. > > . 518400 IN NS m.root- > > servers.net. > > . 518400 IN NS f.root- > > servers.net. > > . 518400 IN RRSIG NS 8 > > 0 > > 518400 20170319170000 20170306160000 61045 . > > iQVPY67dNDj6w14dY1tDFgwRFqhEXVVLmY8q1woIX1eU7t1k/XaPi+tX > > 3+PDCFQlrQmWSWUtLPaA6pmrACB6EL2YvWzAiLVyocGCBpUpnbUCNAwm > > nD4SvBZb0ET2jWbSiAzo8iy+1+Hr84I8RXtbcrcpF5Y/J5Oataxt5z9o > > dHGQSKru0eYEbwfszq0L5L8KECk6skm7iQ0RAIspdTfjDsIwtvoAhEGV > > B8qjFQP5Bkcn38b35eWHneCmc3cgG0J+pK/eX/YHpqClcINGh3eavBlC > > 1KpUkDDMAwCvo+X/MhDE2Ol/VR00/M/YCzXbEv97IWenM1Xi4ArX9F1C xBc0gA== > > > > ;; ADDITIONAL SECTION: > > e.root-servers.net. 518400 IN A 192.203 > > .230 > > .10 > > e.root-servers.net. 518400 IN AAAA 2001 > > :500 > > :a8::e > > h.root-servers.net. 518400 IN A 198.97. > > 190. > > 53 > > h.root-servers.net. 518400 IN AAAA 2001 > > :500 > > :1::53 > > l.root-servers.net. 518400 IN A 199.7.8 > > 3.42 > > l.root-servers.net. 518400 IN AAAA 2001 > > :500 > > :9f::42 > > i.root-servers.net. 518400 IN A 192.36. > > 148. > > 17 > > i.root-servers.net. 518400 IN AAAA 2001 > > :7fe > > ::53 > > a.root-servers.net. 518400 IN A 198.41. > > 0.4 > > a.root-servers.net. 518400 IN AAAA 2001 > > :503 > > :ba3e::2:30 > > d.root-servers.net. 518400 IN A 199.7.9 > > 1.13 > > d.root-servers.net. 518400 IN AAAA 2001 > > :500 > > :2d::d > > c.root-servers.net. 518400 IN A 192.33. > > 4.12 > > c.root-servers.net. 518400 IN AAAA 2001 > > :500 > > :2::c > > b.root-servers.net. 518400 IN A 192.228 > > .79. > > 201 > > b.root-servers.net. 518400 IN AAAA 2001 > > :500 > > :84::b > > j.root-servers.net. 518400 IN A 192.58. > > 128. > > 30 > > j.root-servers.net. 518400 IN AAAA 2001 > > :503 > > :c27::2:30 > > k.root-servers.net. 518400 IN A 193.0.1 > > 4.12 > > 9 > > k.root-servers.net. 518400 IN AAAA 2001 > > :7fd > > ::1 > > g.root-servers.net. 518400 IN A 192.112 > > .36. > > 4 > > g.root-servers.net. 518400 IN AAAA 2001 > > :500 > > :12::d0d > > m.root-servers.net. 518400 IN A 202.12. > > 27.3 > > 3 > > m.root-servers.net. 518400 IN AAAA 2001 > > :dc3 > > ::35 > > f.root-servers.net. 518400 IN A 192.5.5 > > .241 > > f.root-servers.net. 518400 IN AAAA 2001 > > :500 > > :2f::f > > > > ;; Query time: 836 msec > > ;; SERVER: 198.41.0.4#53(198.41.0.4) > > ;; WHEN: Mon Mar 06 15:40:58 CST 2017 > > ;; MSG SIZE rcvd: 1440 > > # > > > > I suspect the ISP mangles DNS requests directed outside their net. > > Well, that command shouldn't have worked then. > > Could you give me an example for something that you cannot resolve? > > -Michael > > > > > Thank you, > > Paul > Ah, I see... so the problem is that we're not forwarding requests outside the local domain? Latest testing sequence follows: # /etc/init.d/unbound restart Stopping Unbound DNS Proxy... [ OK ] Starting Unbound DNS Proxy... [ OK ] Ignoring broken upstream name server(s): 74.113.60.185 156.154.70.1 [ WARN ] Falling back to recursor mode [ WARN ] # dig @198.41.0.4 +dnssec SOA . ; <<>> DiG 9.11.0-P3 <<>> @198.41.0.4 +dnssec SOA . ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23002 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: 27 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1472 ;; QUESTION SECTION: ;. IN SOA ;; ANSWER SECTION: . 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2017030601 1800 900 604800 86400 . 86400 IN RRSIG SOA 8 0 86400 20170319170000 20170306160000 61045 . X2xWv3z0ZmFxXkF9ybMgxMv6dcZ+SmnG3XHcNtAavuPNPLW3cVBwolDP lOU5/tfOaKwbu7HENFWysaekMpb6O7ycg+kryuCP7z6Q4WyG0O2160l1 DDG0UbBW5yidfcghq1r6sdz30RI5cSBGcAOmlktnPkjs9wv9/S/ZPyrC qMPJR9A60R52NcWEONS3DiyGxR66KA4S4grJnDgcI6pcytJGXm/b5WRO +v51tnLT0UVbgXvV03Itn/3MR72muzKXWzzj5LFJST5iqWCgAHJryG3T vNKEYLQ76nwl6B3YVJDjC1InmpIujwXBbxMKpyL1Sh0RLdlHq2TtZS8O qk4V0Q== ;; AUTHORITY SECTION: . 518400 IN NS a.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN RRSIG NS 8 0 518400 20170319170000 20170306160000 61045 . iQVPY67dNDj6w14dY1tDFgwRFqhEXVVLmY8q1woIX1eU7t1k/XaPi+tX 3+PDCFQlrQmWSWUtLPaA6pmrACB6EL2YvWzAiLVyocGCBpUpnbUCNAwm nD4SvBZb0ET2jWbSiAzo8iy+1+Hr84I8RXtbcrcpF5Y/J5Oataxt5z9o dHGQSKru0eYEbwfszq0L5L8KECk6skm7iQ0RAIspdTfjDsIwtvoAhEGV B8qjFQP5Bkcn38b35eWHneCmc3cgG0J+pK/eX/YHpqClcINGh3eavBlC 1KpUkDDMAwCvo+X/MhDE2Ol/VR00/M/YCzXbEv97IWenM1Xi4ArX9F1C xBc0gA== ;; ADDITIONAL SECTION: a.root-servers.net. 518400 IN A 198.41.0.4 b.root-servers.net. 518400 IN A 192.228.79.201 c.root-servers.net. 518400 IN A 192.33.4.12 d.root-servers.net. 518400 IN A 199.7.91.13 e.root-servers.net. 518400 IN A 192.203.230.10 f.root-servers.net. 518400 IN A 192.5.5.241 g.root-servers.net. 518400 IN A 192.112.36.4 h.root-servers.net. 518400 IN A 198.97.190.53 i.root-servers.net. 518400 IN A 192.36.148.17 j.root-servers.net. 518400 IN A 192.58.128.30 k.root-servers.net. 518400 IN A 193.0.14.129 l.root-servers.net. 518400 IN A 199.7.83.42 m.root-servers.net. 518400 IN A 202.12.27.33 a.root-servers.net. 518400 IN AAAA 2001:503:ba3e::2:30 b.root-servers.net. 518400 IN AAAA 2001:500:84::b c.root-servers.net. 518400 IN AAAA 2001:500:2::c d.root-servers.net. 518400 IN AAAA 2001:500:2d::d e.root-servers.net. 518400 IN AAAA 2001:500:a8::e f.root-servers.net. 518400 IN AAAA 2001:500:2f::f g.root-servers.net. 518400 IN AAAA 2001:500:12::d0d h.root-servers.net. 518400 IN AAAA 2001:500:1::53 i.root-servers.net. 518400 IN AAAA 2001:7fe::53 j.root-servers.net. 518400 IN AAAA 2001:503:c27::2:30 k.root-servers.net. 518400 IN AAAA 2001:7fd::1 l.root-servers.net. 518400 IN AAAA 2001:500:9f::42 m.root-servers.net. 518400 IN AAAA 2001:dc3::35 ;; Query time: 797 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Mon Mar 06 17:03:12 CST 2017 ;; MSG SIZE rcvd: 1440 # host www.google.com Host www.google.com not found: 2(SERVFAIL) # host www.ipfire.org ;; connection timed out; no servers could be reached # nslookup www.google.com Server: 127.0.0.1 Address: 127.0.0.1#53 ** server can't find www.google.com: SERVFAIL # nslookup www.ipfire.org 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: www.ipfire.org class="Apple-tab-span" style="white-space:pre"> canonical name = web01.ipfire.org. Name: web01.ipfire.org Address: 81.3.27.41 Thanks, Paul
No, it is supposed to resolve everything. For that it only needs to be able to contact the root name servers and practically all others on the internet. That seems to fail here. What does unbound log? > On 6 Mar 2017, at 11:29 pm, Paul Simmons <redneckmother@hughes.net> wrote: > >> On Mon, 2017-03-06 at 22:37 +0000, Michael Tremer wrote: >> Hi, >> >>> On Mon, 2017-03-06 at 15:47 -0600, Paul Simmons wrote: >>>> On Mon, 2017-03-06 at 21:00 +0000, Michael Tremer wrote: >>>> >>>> Hi, >>>> >>>>> On Mon, 2017-03-06 at 12:18 -0600, Paul Simmons wrote: >>>>> >>>>>> On Sun, 2017-03-05 at 11:42 +0000, Michael Tremer wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> can you confirm if unbound is running? >>>>>> >>>>>> What is the output of /etc/init.d/unbound restart? >>>>>> >>>>>> -Michael >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ----<% snip %>---- >>>>>>>> >>>>>>>> I have nightly commit >>>>>>>> c016773b9816ad9be4ffc8643c30457e87c094e3 >>>>>>>> available locally, and will beg my users for downtime to >>>>>>>> test. >>>>>>>> >>>>>>>> Thank you, and best regards, >>>>>>>> Paul >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Bad juju - build c016773b couldn't resolve any hosts (other >>>>>>> than >>>>>>> those in "localdomain"). >>>>>>> >>>>>>> Provider is "hughes.net" and is the only ISP available (no >>>>>>> hardlines >>>>>>> or other LOS/NLOS WISPs available). >>>>>>> >>>>>>> Tried assigning DNS servers 74.113.60.185 and 156.154.70.1 >>>>>>> - no >>>>>>> change. >>>>>>> >>>>>>> Paul >>>>>>> >>>>> >>>>> Sorry for the lllooonnnggg delay - had to get a testing time >>>>> window. >>>>> >>>>> Unbound was indeed running - verified with "/etc/init.d/unbound >>>>> status" >>>>> >>>>> Command and output from "restart": >>>>> >>>>> # /etc/init.d/unbound restart >>>>> Stopping Unbound DNS >>>>> Proxy... [ OK ] >>>>> Starting Unbound DNS >>>>> Proxy... [ OK ] >>>>> Ignoring broken upstream name server(s): 74.113.60.185 >>>>> 156.154.70.1 [ WARN ] >>>>> Falling back to recursor >>>>> mode [ WARN ] >>>> >>>> So, can you remind me what your provider does again? Is any >>>> access to >>>> other name >>>> servers forbidden? If so the updated script should have detected >>>> that >>>> and should >>>> not have activated the recursor mode. >>>> >>>> Could you manually execute the following commands from the >>>> console of >>>> IPFire for >>>> me? >>>> >>>> dig @198.41.0.4 +dnssec SOA . >>>> >>>> The dot at the end is important. What is the output of it? >>>> >>>> Best, >>>> -Michael >>>> >>>>> >>>>> >>>>> >>>>> Thank you, >>>>> Paul >>> >>> # dig @198.41.0.4 +dnssec SOA . >>> >>> ; <<>> DiG 9.11.0-P3 <<>> @198.41.0.4 +dnssec SOA . >>> ; (1 server found) >>> ;; global options: +cmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 811 >>> ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: >>> 27 >>> ;; WARNING: recursion requested but not available >>> >>> ;; OPT PSEUDOSECTION: >>> ; EDNS: version: 0, flags: do; udp: 4096 >>> ;; QUESTION SECTION: >>> ;. IN SOA >>> >>> ;; ANSWER SECTION: >>> . 86400 IN SOA a.root- >>> servers.net. nstld.verisign-grs.com. 2017030601 1800 900 604800 >>> 86400 >>> . 86400 IN RRSIG SOA 8 >>> 0 >>> 86400 20170319170000 20170306160000 61045 . >>> X2xWv3z0ZmFxXkF9ybMgxMv6dcZ+SmnG3XHcNtAavuPNPLW3cVBwolDP >>> lOU5/tfOaKwbu7HENFWysaekMpb6O7ycg+kryuCP7z6Q4WyG0O2160l1 >>> DDG0UbBW5yidfcghq1r6sdz30RI5cSBGcAOmlktnPkjs9wv9/S/ZPyrC >>> qMPJR9A60R52NcWEONS3DiyGxR66KA4S4grJnDgcI6pcytJGXm/b5WRO >>> +v51tnLT0UVbgXvV03Itn/3MR72muzKXWzzj5LFJST5iqWCgAHJryG3T >>> vNKEYLQ76nwl6B3YVJDjC1InmpIujwXBbxMKpyL1Sh0RLdlHq2TtZS8O qk4V0Q== >>> >>> ;; AUTHORITY SECTION: >>> . 518400 IN NS e.root- >>> servers.net. >>> . 518400 IN NS h.root- >>> servers.net. >>> . 518400 IN NS l.root- >>> servers.net. >>> . 518400 IN NS i.root- >>> servers.net. >>> . 518400 IN NS a.root- >>> servers.net. >>> . 518400 IN NS d.root- >>> servers.net. >>> . 518400 IN NS c.root- >>> servers.net. >>> . 518400 IN NS b.root- >>> servers.net. >>> . 518400 IN NS j.root- >>> servers.net. >>> . 518400 IN NS k.root- >>> servers.net. >>> . 518400 IN NS g.root- >>> servers.net. >>> . 518400 IN NS m.root- >>> servers.net. >>> . 518400 IN NS f.root- >>> servers.net. >>> . 518400 IN RRSIG NS 8 >>> 0 >>> 518400 20170319170000 20170306160000 61045 . >>> iQVPY67dNDj6w14dY1tDFgwRFqhEXVVLmY8q1woIX1eU7t1k/XaPi+tX >>> 3+PDCFQlrQmWSWUtLPaA6pmrACB6EL2YvWzAiLVyocGCBpUpnbUCNAwm >>> nD4SvBZb0ET2jWbSiAzo8iy+1+Hr84I8RXtbcrcpF5Y/J5Oataxt5z9o >>> dHGQSKru0eYEbwfszq0L5L8KECk6skm7iQ0RAIspdTfjDsIwtvoAhEGV >>> B8qjFQP5Bkcn38b35eWHneCmc3cgG0J+pK/eX/YHpqClcINGh3eavBlC >>> 1KpUkDDMAwCvo+X/MhDE2Ol/VR00/M/YCzXbEv97IWenM1Xi4ArX9F1C xBc0gA== >>> >>> ;; ADDITIONAL SECTION: >>> e.root-servers.net. 518400 IN A 192.203 >>> .230 >>> .10 >>> e.root-servers.net. 518400 IN AAAA 2001 >>> :500 >>> :a8::e >>> h.root-servers.net. 518400 IN A 198.97. >>> 190. >>> 53 >>> h.root-servers.net. 518400 IN AAAA 2001 >>> :500 >>> :1::53 >>> l.root-servers.net. 518400 IN A 199.7.8 >>> 3.42 >>> l.root-servers.net. 518400 IN AAAA 2001 >>> :500 >>> :9f::42 >>> i.root-servers.net. 518400 IN A 192.36. >>> 148. >>> 17 >>> i.root-servers.net. 518400 IN AAAA 2001 >>> :7fe >>> ::53 >>> a.root-servers.net. 518400 IN A 198.41. >>> 0.4 >>> a.root-servers.net. 518400 IN AAAA 2001 >>> :503 >>> :ba3e::2:30 >>> d.root-servers.net. 518400 IN A 199.7.9 >>> 1.13 >>> d.root-servers.net. 518400 IN AAAA 2001 >>> :500 >>> :2d::d >>> c.root-servers.net. 518400 IN A 192.33. >>> 4.12 >>> c.root-servers.net. 518400 IN AAAA 2001 >>> :500 >>> :2::c >>> b.root-servers.net. 518400 IN A 192.228 >>> .79. >>> 201 >>> b.root-servers.net. 518400 IN AAAA 2001 >>> :500 >>> :84::b >>> j.root-servers.net. 518400 IN A 192.58. >>> 128. >>> 30 >>> j.root-servers.net. 518400 IN AAAA 2001 >>> :503 >>> :c27::2:30 >>> k.root-servers.net. 518400 IN A 193.0.1 >>> 4.12 >>> 9 >>> k.root-servers.net. 518400 IN AAAA 2001 >>> :7fd >>> ::1 >>> g.root-servers.net. 518400 IN A 192.112 >>> .36. >>> 4 >>> g.root-servers.net. 518400 IN AAAA 2001 >>> :500 >>> :12::d0d >>> m.root-servers.net. 518400 IN A 202.12. >>> 27.3 >>> 3 >>> m.root-servers.net. 518400 IN AAAA 2001 >>> :dc3 >>> ::35 >>> f.root-servers.net. 518400 IN A 192.5.5 >>> .241 >>> f.root-servers.net. 518400 IN AAAA 2001 >>> :500 >>> :2f::f >>> >>> ;; Query time: 836 msec >>> ;; SERVER: 198.41.0.4#53(198.41.0.4) >>> ;; WHEN: Mon Mar 06 15:40:58 CST 2017 >>> ;; MSG SIZE rcvd: 1440 >>> # >>> >>> I suspect the ISP mangles DNS requests directed outside their net. >> >> Well, that command shouldn't have worked then. >> >> Could you give me an example for something that you cannot resolve? >> >> -Michael >> >>> >>> Thank you, >>> Paul >> > > Ah, I see... so the problem is that we're not forwarding requests > outside the local domain? Latest testing sequence follows: > > # /etc/init.d/unbound restart > Stopping Unbound DNS > Proxy... [ OK ] > Starting Unbound DNS > Proxy... [ OK ] > Ignoring broken upstream name server(s): 74.113.60.185 > 156.154.70.1 [ WARN ] > Falling back to recursor > mode [ WARN ] > > # dig @198.41.0.4 +dnssec SOA . > > ; <<>> DiG 9.11.0-P3 <<>> @198.41.0.4 +dnssec SOA . > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23002 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: 27 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 1472 > ;; QUESTION SECTION: > ;. IN SOA > > ;; ANSWER SECTION: > . 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2017030601 1800 900 604800 86400 > . 86400 IN RRSIG SOA 8 0 86400 20170319170000 20170306160000 61045 . X2xWv3z0ZmFxXkF9ybMgxMv6dcZ+SmnG3XHcNtAavuPNPLW3cVBwolDP lOU5/tfOaKwbu7HENFWysaekMpb6O7ycg+kryuCP7z6Q4WyG0O2160l1 DDG0UbBW5yidfcghq1r6sdz30RI5cSBGcAOmlktnPkjs9wv9/S/ZPyrC qMPJR9A60R52NcWEONS3DiyGxR66KA4S4grJnDgcI6pcytJGXm/b5WRO +v51tnLT0UVbgXvV03Itn/3MR72muzKXWzzj5LFJST5iqWCgAHJryG3T vNKEYLQ76nwl6B3YVJDjC1InmpIujwXBbxMKpyL1Sh0RLdlHq2TtZS8O qk4V0Q== > > ;; AUTHORITY SECTION: > . 518400 IN NS a.root-servers.net. > . 518400 IN NS b.root-servers.net. > . 518400 IN NS c.root-servers.net. > . 518400 IN NS d.root-servers.net. > . 518400 IN NS e.root-servers.net. > . 518400 IN NS f.root-servers.net. > . 518400 IN NS g.root-servers.net. > . 518400 IN NS h.root-servers.net. > . 518400 IN NS i.root-servers.net. > . 518400 IN NS j.root-servers.net. > . 518400 IN NS k.root-servers.net. > . 518400 IN NS l.root-servers.net. > . 518400 IN NS m.root-servers.net. > . 518400 IN RRSIG NS 8 0 518400 20170319170000 20170306160000 61045 . iQVPY67dNDj6w14dY1tDFgwRFqhEXVVLmY8q1woIX1eU7t1k/XaPi+tX 3+PDCFQlrQmWSWUtLPaA6pmrACB6EL2YvWzAiLVyocGCBpUpnbUCNAwm nD4SvBZb0ET2jWbSiAzo8iy+1+Hr84I8RXtbcrcpF5Y/J5Oataxt5z9o dHGQSKru0eYEbwfszq0L5L8KECk6skm7iQ0RAIspdTfjDsIwtvoAhEGV B8qjFQP5Bkcn38b35eWHneCmc3cgG0J+pK/eX/YHpqClcINGh3eavBlC 1KpUkDDMAwCvo+X/MhDE2Ol/VR00/M/YCzXbEv97IWenM1Xi4ArX9F1C xBc0gA== > > ;; ADDITIONAL SECTION: > a.root-servers.net. 518400 IN A 198.41.0.4 > b.root-servers.net. 518400 IN A 192.228.79.201 > c.root-servers.net. 518400 IN A 192.33.4.12 > d.root-servers.net. 518400 IN A 199.7.91.13 > e.root-servers.net. 518400 IN A 192.203.230.10 > f.root-servers.net. 518400 IN A 192.5.5.241 > g.root-servers.net. 518400 IN A 192.112.36.4 > h.root-servers.net. 518400 IN A 198.97.190.53 > i.root-servers.net. 518400 IN A 192.36.148.17 > j.root-servers.net. 518400 IN A 192.58.128.30 > k.root-servers.net. 518400 IN A 193.0.14.129 > l.root-servers.net. 518400 IN A 199.7.83.42 > m.root-servers.net. 518400 IN A 202.12.27.33 > a.root-servers.net. 518400 IN AAAA 2001:503:ba3e::2:30 > b.root-servers.net. 518400 IN AAAA 2001:500:84::b > c.root-servers.net. 518400 IN AAAA 2001:500:2::c > d.root-servers.net. 518400 IN AAAA 2001:500:2d::d > e.root-servers.net. 518400 IN AAAA 2001:500:a8::e > f.root-servers.net. 518400 IN AAAA 2001:500:2f::f > g.root-servers.net. 518400 IN AAAA 2001:500:12::d0d > h.root-servers.net. 518400 IN AAAA 2001:500:1::53 > i.root-servers.net. 518400 IN AAAA 2001:7fe::53 > j.root-servers.net. 518400 IN AAAA 2001:503:c27::2:30 > k.root-servers.net. 518400 IN AAAA 2001:7fd::1 > l.root-servers.net. 518400 IN AAAA 2001:500:9f::42 > m.root-servers.net. 518400 IN AAAA 2001:dc3::35 > > ;; Query time: 797 msec > ;; SERVER: 198.41.0.4#53(198.41.0.4) > ;; WHEN: Mon Mar 06 17:03:12 CST 2017 > ;; MSG SIZE rcvd: 1440 > > # host www.google.com > Host www.google.com not found: 2(SERVFAIL) > > # host www.ipfire.org > ;; connection timed out; no servers could be reached > > > # nslookup www.google.com > Server: 127.0.0.1 > Address: 127.0.0.1#53 > > ** server can't find www.google.com: SERVFAIL > > # nslookup www.ipfire.org 8.8.8.8 > Server: 8.8.8.8 > Address: 8.8.8.8#53 > > Non-authoritative answer: > www.ipfire.org class="Apple-tab-span" style="white-space:pre"> canonical name = web01.ipfire.org. > Name: web01.ipfire.org > Address: 81.3.27.41 > > > Thanks, > Paul >
On Tue, 2017-03-07 at 09:58 -0600, Paul Simmons wrote: > On Tue, 2017-03-07 at 12:06 +0000, Michael Tremer wrote: > > No, it is supposed to resolve everything. > > > > For that it only needs to be able to contact the root name servers > > and practically all others on the internet. That seems to fail > > here. > > > > What does unbound log? > > > > > On 6 Mar 2017, at 11:29 pm, Paul Simmons <redneckmother@hughes.ne > > > t> > > > wrote: > > > > > > > On Mon, 2017-03-06 at 22:37 +0000, Michael Tremer wrote: > > > > Hi, > > > > > > > > > On Mon, 2017-03-06 at 15:47 -0600, Paul Simmons wrote: > > > > > > On Mon, 2017-03-06 at 21:00 +0000, Michael Tremer wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > > On Mon, 2017-03-06 at 12:18 -0600, Paul Simmons wrote: > > > > > > > > > > > > > > > On Sun, 2017-03-05 at 11:42 +0000, Michael Tremer > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > can you confirm if unbound is running? > > > > > > > > > > > > > > > > What is the output of /etc/init.d/unbound restart? > > > > > > > > > > > > > > > > -Michael > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----<% snip %>---- > > > > > > > > > > > > > > > > > > > > I have nightly commit > > > > > > > > > > c016773b9816ad9be4ffc8643c30457e87c094e3 > > > > > > > > > > available locally, and will beg my users for > > > > > > > > > > downtime > > > > > > > > > > to > > > > > > > > > > test. > > > > > > > > > > > > > > > > > > > > Thank you, and best regards, > > > > > > > > > > Paul > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bad juju - build c016773b couldn't resolve any hosts > > > > > > > > > (other > > > > > > > > > than > > > > > > > > > those in "localdomain"). > > > > > > > > > > > > > > > > > > Provider is "hughes.net" and is the only ISP > > > > > > > > > available > > > > > > > > > (no > > > > > > > > > hardlines > > > > > > > > > or other LOS/NLOS WISPs available). > > > > > > > > > > > > > > > > > > Tried assigning DNS servers 74.113.60.185 and > > > > > > > > > 156.154.70.1 > > > > > > > > > - no > > > > > > > > > change. > > > > > > > > > > > > > > > > > > Paul > > > > > > > > > > > > > > > > > > > > > > > Sorry for the lllooonnnggg delay - had to get a testing > > > > > > > time > > > > > > > window. > > > > > > > > > > > > > > Unbound was indeed running - verified with > > > > > > > "/etc/init.d/unbound > > > > > > > status" > > > > > > > > > > > > > > Command and output from "restart": > > > > > > > > > > > > > > # /etc/init.d/unbound restart > > > > > > > Stopping Unbound DNS > > > > > > > Proxy... [ OK > > > > > > > ] > > > > > > > Starting Unbound DNS > > > > > > > Proxy... [ OK > > > > > > > ] > > > > > > > Ignoring broken upstream name server(s): 74.113.60.185 > > > > > > > 156.154.70.1 [ WARN ] > > > > > > > Falling back to recursor > > > > > > > mode [ WARN ] > > > > > > > > > > > > So, can you remind me what your provider does again? Is any > > > > > > access to > > > > > > other name > > > > > > servers forbidden? If so the updated script should have > > > > > > detected > > > > > > that > > > > > > and should > > > > > > not have activated the recursor mode. > > > > > > > > > > > > Could you manually execute the following commands from the > > > > > > console of > > > > > > IPFire for > > > > > > me? > > > > > > > > > > > > dig @198.41.0.4 +dnssec SOA . > > > > > > > > > > > > The dot at the end is important. What is the output of it? > > > > > > > > > > > > Best, > > > > > > -Michael > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > Paul > > > > > > > > > > # dig @198.41.0.4 +dnssec SOA . > > > > > > > > > > ; <<>> DiG 9.11.0-P3 <<>> @198.41.0.4 +dnssec SOA . > > > > > ; (1 server found) > > > > > ;; global options: +cmd > > > > > ;; Got answer: > > > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 811 > > > > > ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 14, > > > > > ADDITIONAL: > > > > > 27 > > > > > ;; WARNING: recursion requested but not available > > > > > > > > > > ;; OPT PSEUDOSECTION: > > > > > ; EDNS: version: 0, flags: do; udp: 4096 > > > > > ;; QUESTION SECTION: > > > > > ;. IN SOA > > > > > > > > > > ;; ANSWER SECTION: > > > > > . 86400 IN SOA a.root- > > > > > servers.net. nstld.verisign-grs.com. 2017030601 1800 900 > > > > > 604800 > > > > > 86400 > > > > > . 86400 IN RRSIG SOA 8 > > > > > 0 > > > > > 86400 20170319170000 20170306160000 61045 . > > > > > X2xWv3z0ZmFxXkF9ybMgxMv6dcZ+SmnG3XHcNtAavuPNPLW3cVBwolDP > > > > > lOU5/tfOaKwbu7HENFWysaekMpb6O7ycg+kryuCP7z6Q4WyG0O2160l1 > > > > > DDG0UbBW5yidfcghq1r6sdz30RI5cSBGcAOmlktnPkjs9wv9/S/ZPyrC > > > > > qMPJR9A60R52NcWEONS3DiyGxR66KA4S4grJnDgcI6pcytJGXm/b5WRO > > > > > +v51tnLT0UVbgXvV03Itn/3MR72muzKXWzzj5LFJST5iqWCgAHJryG3T > > > > > vNKEYLQ76nwl6B3YVJDjC1InmpIujwXBbxMKpyL1Sh0RLdlHq2TtZS8O > > > > > qk4V0Q== > > > > > > > > > > ;; AUTHORITY SECTION: > > > > > . 518400 IN NS e.root- > > > > > servers.net. > > > > > . 518400 IN NS h.root- > > > > > servers.net. > > > > > . 518400 IN NS l.root- > > > > > servers.net. > > > > > . 518400 IN NS i.root- > > > > > servers.net. > > > > > . 518400 IN NS a.root- > > > > > servers.net. > > > > > . 518400 IN NS d.root- > > > > > servers.net. > > > > > . 518400 IN NS c.root- > > > > > servers.net. > > > > > . 518400 IN NS b.root- > > > > > servers.net. > > > > > . 518400 IN NS j.root- > > > > > servers.net. > > > > > . 518400 IN NS k.root- > > > > > servers.net. > > > > > . 518400 IN NS g.root- > > > > > servers.net. > > > > > . 518400 IN NS m.root- > > > > > servers.net. > > > > > . 518400 IN NS f.root- > > > > > servers.net. > > > > > . 518400 IN RRSIG NS 8 > > > > > 0 > > > > > 518400 20170319170000 20170306160000 61045 . > > > > > iQVPY67dNDj6w14dY1tDFgwRFqhEXVVLmY8q1woIX1eU7t1k/XaPi+tX > > > > > 3+PDCFQlrQmWSWUtLPaA6pmrACB6EL2YvWzAiLVyocGCBpUpnbUCNAwm > > > > > nD4SvBZb0ET2jWbSiAzo8iy+1+Hr84I8RXtbcrcpF5Y/J5Oataxt5z9o > > > > > dHGQSKru0eYEbwfszq0L5L8KECk6skm7iQ0RAIspdTfjDsIwtvoAhEGV > > > > > B8qjFQP5Bkcn38b35eWHneCmc3cgG0J+pK/eX/YHpqClcINGh3eavBlC > > > > > 1KpUkDDMAwCvo+X/MhDE2Ol/VR00/M/YCzXbEv97IWenM1Xi4ArX9F1C > > > > > xBc0gA== > > > > > > > > > > ;; ADDITIONAL SECTION: > > > > > e.root-servers.net. 518400 IN A 192.203 > > > > > .230 > > > > > .10 > > > > > e.root-servers.net. 518400 IN AAAA 2001 > > > > > :500 > > > > > :a8::e > > > > > h.root-servers.net. 518400 IN A 198.97. > > > > > 190. > > > > > 53 > > > > > h.root-servers.net. 518400 IN AAAA 2001 > > > > > :500 > > > > > :1::53 > > > > > l.root-servers.net. 518400 IN A 199.7.8 > > > > > 3.42 > > > > > l.root-servers.net. 518400 IN AAAA 2001 > > > > > :500 > > > > > :9f::42 > > > > > i.root-servers.net. 518400 IN A 192.36. > > > > > 148. > > > > > 17 > > > > > i.root-servers.net. 518400 IN AAAA 2001 > > > > > :7fe > > > > > ::53 > > > > > a.root-servers.net. 518400 IN A 198.41. > > > > > 0.4 > > > > > a.root-servers.net. 518400 IN AAAA 2001 > > > > > :503 > > > > > :ba3e::2:30 > > > > > d.root-servers.net. 518400 IN A 199.7.9 > > > > > 1.13 > > > > > d.root-servers.net. 518400 IN AAAA 2001 > > > > > :500 > > > > > :2d::d > > > > > c.root-servers.net. 518400 IN A 192.33. > > > > > 4.12 > > > > > c.root-servers.net. 518400 IN AAAA 2001 > > > > > :500 > > > > > :2::c > > > > > b.root-servers.net. 518400 IN A 192.228 > > > > > .79. > > > > > 201 > > > > > b.root-servers.net. 518400 IN AAAA 2001 > > > > > :500 > > > > > :84::b > > > > > j.root-servers.net. 518400 IN A 192.58. > > > > > 128. > > > > > 30 > > > > > j.root-servers.net. 518400 IN AAAA 2001 > > > > > :503 > > > > > :c27::2:30 > > > > > k.root-servers.net. 518400 IN A 193.0.1 > > > > > 4.12 > > > > > 9 > > > > > k.root-servers.net. 518400 IN AAAA 2001 > > > > > :7fd > > > > > ::1 > > > > > g.root-servers.net. 518400 IN A 192.112 > > > > > .36. > > > > > 4 > > > > > g.root-servers.net. 518400 IN AAAA 2001 > > > > > :500 > > > > > :12::d0d > > > > > m.root-servers.net. 518400 IN A 202.12. > > > > > 27.3 > > > > > 3 > > > > > m.root-servers.net. 518400 IN AAAA 2001 > > > > > :dc3 > > > > > ::35 > > > > > f.root-servers.net. 518400 IN A 192.5.5 > > > > > .241 > > > > > f.root-servers.net. 518400 IN AAAA 2001 > > > > > :500 > > > > > :2f::f > > > > > > > > > > ;; Query time: 836 msec > > > > > ;; SERVER: 198.41.0.4#53(198.41.0.4) > > > > > ;; WHEN: Mon Mar 06 15:40:58 CST 2017 > > > > > ;; MSG SIZE rcvd: 1440 > > > > > # > > > > > > > > > > I suspect the ISP mangles DNS requests directed outside their > > > > > net. > > > > > > > > Well, that command shouldn't have worked then. > > > > > > > > Could you give me an example for something that you cannot > > > > resolve? > > > > > > > > -Michael > > > > > > > > > Thank you, > > > > > Paul > > > > > > Ah, I see... so the problem is that we're not forwarding requests > > > outside the local domain? Latest testing sequence follows: > > > > > > # /etc/init.d/unbound restart > > > Stopping Unbound DNS > > > Proxy... [ OK ] > > > Starting Unbound DNS > > > Proxy... [ OK ] > > > Ignoring broken upstream name server(s): 74.113.60.185 > > > 156.154.70.1 [ WARN ] > > > Falling back to recursor > > > mode [ WARN ] > > > > > > # dig @198.41.0.4 +dnssec SOA . > > > > > > ; <<>> DiG 9.11.0-P3 <<>> @198.41.0.4 +dnssec SOA . > > > ; (1 server found) > > > ;; global options: +cmd > > > ;; Got answer: > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23002 > > > ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 14, > > > ADDITIONAL: > > > 27 > > > ;; WARNING: recursion requested but not available > > > > > > ;; OPT PSEUDOSECTION: > > > ; EDNS: version: 0, flags: do; udp: 1472 > > > ;; QUESTION SECTION: > > > ;. IN SOA > > > > > > ;; ANSWER SECTION: > > > . 86400 IN SOA a.root-servers.net. > > > nstld.verisign-grs.com. 2017030601 1800 900 604800 86400 > > > . 86400 IN RRSIG SOA 8 0 86400 20170319170000 > > > 20170306160000 61045 . > > > X2xWv3z0ZmFxXkF9ybMgxMv6dcZ+SmnG3XHcNtAavuPNPLW3cVBwolDP > > > lOU5/tfOaKwbu7HENFWysaekMpb6O7ycg+kryuCP7z6Q4WyG0O2160l1 > > > DDG0UbBW5yidfcghq1r6sdz30RI5cSBGcAOmlktnPkjs9wv9/S/ZPyrC > > > qMPJR9A60R52NcWEONS3DiyGxR66KA4S4grJnDgcI6pcytJGXm/b5WRO > > > +v51tnLT0UVbgXvV03Itn/3MR72muzKXWzzj5LFJST5iqWCgAHJryG3T > > > vNKEYLQ76nwl6B3YVJDjC1InmpIujwXBbxMKpyL1Sh0RLdlHq2TtZS8O qk4V0Q== > > > > > > ;; AUTHORITY SECTION: > > > . 518400 IN NS a.root-servers.net. > > > . 518400 IN NS b.root-servers.net. > > > . 518400 IN NS c.root-servers.net. > > > . 518400 IN NS d.root-servers.net. > > > . 518400 IN NS e.root-servers.net. > > > . 518400 IN NS f.root-servers.net. > > > . 518400 IN NS g.root-servers.net. > > > . 518400 IN NS h.root-servers.net. > > > . 518400 IN NS i.root-servers.net. > > > . 518400 IN NS j.root-servers.net. > > > . 518400 IN NS k.root-servers.net. > > > . 518400 IN NS l.root-servers.net. > > > . 518400 IN NS m.root-servers.net. > > > . 518400 IN RRSIG NS 8 0 518400 > > > 20170319170000 > > > 20170306160000 61045 . > > > iQVPY67dNDj6w14dY1tDFgwRFqhEXVVLmY8q1woIX1eU7t1k/XaPi+tX > > > 3+PDCFQlrQmWSWUtLPaA6pmrACB6EL2YvWzAiLVyocGCBpUpnbUCNAwm > > > nD4SvBZb0ET2jWbSiAzo8iy+1+Hr84I8RXtbcrcpF5Y/J5Oataxt5z9o > > > dHGQSKru0eYEbwfszq0L5L8KECk6skm7iQ0RAIspdTfjDsIwtvoAhEGV > > > B8qjFQP5Bkcn38b35eWHneCmc3cgG0J+pK/eX/YHpqClcINGh3eavBlC > > > 1KpUkDDMAwCvo+X/MhDE2Ol/VR00/M/YCzXbEv97IWenM1Xi4ArX9F1C xBc0gA== > > > > > > ;; ADDITIONAL SECTION: > > > a.root-servers.net. 518400 IN A 198.41.0.4 > > > b.root-servers.net. 518400 IN A 192.228.79.201 > > > c.root-servers.net. 518400 IN A 192.33.4.12 > > > d.root-servers.net. 518400 IN A 199.7.91.13 > > > e.root-servers.net. 518400 IN A 192.203.230.10 > > > f.root-servers.net. 518400 IN A 192.5.5.241 > > > g.root-servers.net. 518400 IN A 192.112.36.4 > > > h.root-servers.net. 518400 IN A 198.97.190.53 > > > i.root-servers.net. 518400 IN A 192.36.148.17 > > > j.root-servers.net. 518400 IN A 192.58.128.30 > > > k.root-servers.net. 518400 IN A 193.0.14.129 > > > l.root-servers.net. 518400 IN A 199.7.83.42 > > > m.root-servers.net. 518400 IN A 202.12.27.33 > > > a.root- > > > servers.net. 518400 IN AAAA 2001:503:ba3e::2:30 > > > b.root-servers.net. 518400 IN AAAA 2001:500:84::b > > > c.root-servers.net. 518400 IN AAAA 2001:500:2::c > > > d.root-servers.net. 518400 IN AAAA 2001:500:2d::d > > > e.root-servers.net. 518400 IN AAAA 2001:500:a8::e > > > f.root-servers.net. 518400 IN AAAA 2001:500:2f::f > > > g.root-servers.net. 518400 IN AAAA 2001:500:12::d0d > > > h.root-servers.net. 518400 IN AAAA 2001:500:1::53 > > > i.root-servers.net. 518400 IN AAAA 2001:7fe::53 > > > j.root-servers.net. 518400 IN AAAA 2001:503:c27::2:30 > > > k.root-servers.net. 518400 IN AAAA 2001:7fd::1 > > > l.root-servers.net. 518400 IN AAAA 2001:500:9f::42 > > > m.root-servers.net. 518400 IN AAAA 2001:dc3::35 > > > > > > ;; Query time: 797 msec > > > ;; SERVER: 198.41.0.4#53(198.41.0.4) > > > ;; WHEN: Mon Mar 06 17:03:12 CST 2017 > > > ;; MSG SIZE rcvd: 1440 > > > > > > # host www.google.com > > > Host www.google.com not found: 2(SERVFAIL) > > > > > > # host www.ipfire.org > > > ;; connection timed out; no servers could be reached > > > > > > > > > # nslookup www.google.com > > > Server: 127.0.0.1 > > > Address: 127.0.0.1#53 > > > > > > ** server can't find www.google.com: SERVFAIL > > > > > > # nslookup www.ipfire.org 8.8.8.8 > > > Server: 8.8.8.8 > > > Address: 8.8.8.8#53 > > > > > > Non-authoritative answer: > > > www.ipfire.org class="Apple-tab-span" style="white- > > > space:pre"> canonical name = web01.ipfire.org. > > > Name: web01.ipfire.org > > > Address: 81.3.27.41 > > > > > > > > > Thanks, > > > Paul > > > > > Log from unbound (via web interface): > > IPFire diagnostics > Section: unbound > Date: March 07, 2017 > > 09:53:05 unbound: [3485:0] info: validation failure > ns02.fedoraproject.org. AAAA IN > 09:53:05 unbound: [3485:0] info: validation failure > ns05.fedoraproject.org. AAAA IN > 09:53:05 unbound: [3485:0] info: validation failure > fedoraproject.org. AAAA IN > 09:52:36 unbound: [3485:1] info: validation failure > fedoraproject.org.localdomain. AAAA IN > 09:52:29 unbound: [3485:0] info: failed to prime trust anchor -- > could not fetch DNSKEY rrset . DNSKEY IN > 09:52:19 unbound: [3485:0] info: failed to prime trust anchor -- > could not fetch DNSKEY rrset . DNSKEY IN > 09:51:29 unbound: [3485:0] info: start of service (unbound 1.6.1). > 09:51:29 unbound: [3485:0] notice: init module 1: iterator > 09:51:29 unbound: [3485:0] notice: init module 0: validator > 09:51:27 unbound: [1406:0] info: 4.000000 8.000000 1 > 09:51:27 unbound: [1406:0] info: 2.000000 4.000000 1 > 09:51:27 unbound: [1406:0] info: 0.524288 1.000000 2 > 09:51:27 unbound: [1406:0] info: 0.262144 0.524288 5 > 09:51:27 unbound: [1406:0] info: 0.131072 0.262144 1 > 09:51:27 unbound: [1406:0] info: 0.016384 0.032768 1 > 09:51:27 unbound: [1406:0] info: 0.008192 0.016384 1 > 09:51:27 unbound: [1406:0] info: 0.000000 0.000001 7 > 09:51:27 unbound: [1406:0] info: lower(secs) upper(secs) recursions > 09:51:27 unbound: [1406:0] info: [25%]=6.78571e-07 > median[50%]=0.196608 [75%]=0.484966 > 09:51:27 unbound: [1406:0] info: histogram of recursion processing > times > 09:51:27 unbound: [1406:0] info: average recursion processing time > 0.581705 sec > 09:51:27 unbound: [1406:0] info: server stats for thread 1: > requestlist max 3 avg 0.526316 exceeded 0 jostled 0 > 09:51:27 unbound: [1406:0] info: server stats for thread 1: 45 > queries, 26 answers from cache, 19 recursions, 0 prefetch, 0 rejected > by ip ratelimiting > 09:51:27 unbound: [1406:0] info: 32.000000 64.000000 6 > 09:51:27 unbound: [1406:0] info: 16.000000 32.000000 6 > 09:51:27 unbound: [1406:0] info: 8.000000 16.000000 11 > 09:51:27 unbound: [1406:0] info: 4.000000 8.000000 5 > 09:51:27 unbound: [1406:0] info: 2.000000 4.000000 2 > 09:51:27 unbound: [1406:0] info: 1.000000 2.000000 2 > 09:51:27 unbound: [1406:0] info: 0.262144 0.524288 4 > 09:51:27 unbound: [1406:0] info: 0.131072 0.262144 1 > 09:51:27 unbound: [1406:0] info: 0.000000 0.000001 2 > 09:51:27 unbound: [1406:0] info: lower(secs) upper(secs) recursions > 09:51:27 unbound: [1406:0] info: [25%]=2.75 median[50%]=10.5455 > [75%]=22 > 09:51:27 unbound: [1406:0] info: histogram of recursion processing > times > 09:51:27 unbound: [1406:0] info: average recursion processing time > 15.696339 sec > 09:51:27 unbound: [1406:0] info: server stats for thread 0: > requestlist max 68 avg 23.925 exceeded 0 jostled 0 > 09:51:27 unbound: [1406:0] info: server stats for thread 0: 67 > queries, 28 answers from cache, 39 recursions, 1 prefetch, 0 rejected > by ip ratelimiting > 09:51:27 unbound: [1406:0] info: service stopped (unbound 1.6.1). > 09:50:18 unbound: [1406:0] info: validation failure b.gtld- > servers.net. AAAA IN > 09:50:18 unbound: [1406:0] info: validation failure a.gtld- > servers.net. AAAA IN > 09:50:17 unbound: [1406:0] info: validation failure a.root- > servers.net. AAAA IN > 09:50:17 unbound: [1406:0] info: validation failure m.root- > servers.net. AAAA IN > 09:50:17 unbound: [1406:0] info: validation failure c.root- > servers.net. AAAA IN > 09:50:17 unbound: [1406:0] info: validation failure b.root- > servers.net. AAAA IN > 09:50:17 unbound: [1406:0] info: validation failure l.root- > servers.net. AAAA IN > 09:50:17 unbound: [1406:0] info: validation failure k.root- > servers.net. AAAA IN > 09:50:17 unbound: [1406:0] info: validation failure j.root- > servers.net. AAAA IN > 09:50:17 unbound: [1406:0] info: validation failure i.root- > servers.net. AAAA IN > 09:50:17 unbound: [1406:0] info: validation failure h.root- > servers.net. AAAA IN > 09:50:17 unbound: [1406:0] info: validation failure g.root- > servers.net. AAAA IN > 09:50:17 unbound: [1406:0] info: validation failure f.root- > servers.net. AAAA IN > 09:50:17 unbound: [1406:0] info: validation failure e.root- > servers.net. AAAA IN > 09:50:17 unbound: [1406:0] info: validation failure d.root- > servers.net. AAAA IN > 09:49:55 unbound: [1406:0] info: validation failure > ns02.fedoraproject.org. AAAA IN > 09:49:55 unbound: [1406:0] info: validation failure > ns05.fedoraproject.org. AAAA IN > 09:49:51 unbound: [1406:0] info: validation failure > fedoraproject.org. AAAA IN > 09:49:48 unbound: [1406:0] info: validation failure > fireinfo.ipfire.org. AAAA IN > 09:49:46 unbound: [1406:0] info: validation failure > ns1.lightningwirelabs.com. AAAA IN > 09:49:46 unbound: [1406:0] info: validation failure > ns3.lightningwirelabs.com. AAAA IN > 09:49:46 unbound: [1406:0] info: validation failure > ns2.lightningwirelabs.com. AAAA IN > 09:49:42 unbound: [1406:1] info: validation failure > fedoraproject.org. AAAA IN > 09:49:18 unbound: [1406:0] info: validation failure > fedoraproject.org.localdomain. AAAA IN > 09:49:18 unbound: [1406:0] info: validation failure > fireinfo.ipfire.org.localdomain. AAAA IN > 09:48:21 unbound: [1406:0] info: start of service (unbound 1.6.1). > 09:48:21 unbound: [1406:0] notice: init module 1: iterator > 09:48:21 unbound: [1406:0] notice: init module 0: validator > > > Thank you, > Paul Forgot to cc: the list...Paul
Hmm... That's interesting that only AAAA records fail. No idea why the system is resolving those any ways, but hey... So when you do dig @198.41.0.4 a.root-servers.net AAAA +dnssec does that work? What does dig @8.8.8.8 +sigchase +dnssec www.ipfire.org do? -Michael On Tue, 2017-03-07 at 10:15 -0600, Paul Simmons wrote: > On Tue, 2017-03-07 at 09:58 -0600, Paul Simmons wrote: > > On Tue, 2017-03-07 at 12:06 +0000, Michael Tremer wrote: > > > > > > No, it is supposed to resolve everything. > > > > > > For that it only needs to be able to contact the root name servers > > > and practically all others on the internet. That seems to fail here. > > > > > > What does unbound log? > > > > > > > > > > > On 6 Mar 2017, at 11:29 pm, Paul Simmons <redneckmother@hughes.net> > > > > wrote: > > > > > > > > > > > > > > On Mon, 2017-03-06 at 22:37 +0000, Michael Tremer wrote: > > > > > Hi, > > > > > > > > > > > > > > > > > On Mon, 2017-03-06 at 15:47 -0600, Paul Simmons wrote: > > > > > > > > > > > > > > On Mon, 2017-03-06 at 21:00 +0000, Michael Tremer wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > On Mon, 2017-03-06 at 12:18 -0600, Paul Simmons wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 2017-03-05 at 11:42 +0000, Michael Tremer wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > can you confirm if unbound is running? > > > > > > > > > > > > > > > > > > What is the output of /etc/init.d/unbound restart? > > > > > > > > > > > > > > > > > > -Michael > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----<% snip %>---- > > > > > > > > > > > > > > > > > > > > > > I have nightly commit > > > > > > > > > > > c016773b9816ad9be4ffc8643c30457e87c094e3 > > > > > > > > > > > available locally, and will beg my users for downtime > > > > > > > > > > > to > > > > > > > > > > > test. > > > > > > > > > > > > > > > > > > > > > > Thank you, and best regards, > > > > > > > > > > > Paul > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bad juju - build c016773b couldn't resolve any hosts > > > > > > > > > > (other > > > > > > > > > > than > > > > > > > > > > those in "localdomain"). > > > > > > > > > > > > > > > > > > > > Provider is "hughes.net" and is the only ISP available > > > > > > > > > > (no > > > > > > > > > > hardlines > > > > > > > > > > or other LOS/NLOS WISPs available). > > > > > > > > > > > > > > > > > > > > Tried assigning DNS servers 74.113.60.185 and > > > > > > > > > > 156.154.70.1 > > > > > > > > > > - no > > > > > > > > > > change. > > > > > > > > > > > > > > > > > > > > Paul > > > > > > > > > > > > > > > > > > > > > > > > > > Sorry for the lllooonnnggg delay - had to get a testing > > > > > > > > time > > > > > > > > window. > > > > > > > > > > > > > > > > Unbound was indeed running - verified with > > > > > > > > "/etc/init.d/unbound > > > > > > > > status" > > > > > > > > > > > > > > > > Command and output from "restart": > > > > > > > > > > > > > > > > # /etc/init.d/unbound restart > > > > > > > > Stopping Unbound DNS > > > > > > > > Proxy... [ OK ] > > > > > > > > Starting Unbound DNS > > > > > > > > Proxy... [ OK ] > > > > > > > > Ignoring broken upstream name server(s): 74.113.60.185 > > > > > > > > 156.154.70.1 [ WARN ] > > > > > > > > Falling back to recursor > > > > > > > > mode [ WARN ] > > > > > > > > > > > > > > So, can you remind me what your provider does again? Is any > > > > > > > access to > > > > > > > other name > > > > > > > servers forbidden? If so the updated script should have > > > > > > > detected > > > > > > > that > > > > > > > and should > > > > > > > not have activated the recursor mode. > > > > > > > > > > > > > > Could you manually execute the following commands from the > > > > > > > console of > > > > > > > IPFire for > > > > > > > me? > > > > > > > > > > > > > > dig @198.41.0.4 +dnssec SOA . > > > > > > > > > > > > > > The dot at the end is important. What is the output of it? > > > > > > > > > > > > > > Best, > > > > > > > -Michael > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > Paul > > > > > > > > > > > > # dig @198.41.0.4 +dnssec SOA . > > > > > > > > > > > > ; <<>> DiG 9.11.0-P3 <<>> @198.41.0.4 +dnssec SOA . > > > > > > ; (1 server found) > > > > > > ;; global options: +cmd > > > > > > ;; Got answer: > > > > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 811 > > > > > > ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 14, > > > > > > ADDITIONAL: > > > > > > 27 > > > > > > ;; WARNING: recursion requested but not available > > > > > > > > > > > > ;; OPT PSEUDOSECTION: > > > > > > ; EDNS: version: 0, flags: do; udp: 4096 > > > > > > ;; QUESTION SECTION: > > > > > > ;. IN SOA > > > > > > > > > > > > ;; ANSWER SECTION: > > > > > > . 86400 IN SOA a.root- > > > > > > servers.net. nstld.verisign-grs.com. 2017030601 1800 900 604800 > > > > > > 86400 > > > > > > . 86400 IN RRSIG SOA 8 > > > > > > 0 > > > > > > 86400 20170319170000 20170306160000 61045 . > > > > > > X2xWv3z0ZmFxXkF9ybMgxMv6dcZ+SmnG3XHcNtAavuPNPLW3cVBwolDP > > > > > > lOU5/tfOaKwbu7HENFWysaekMpb6O7ycg+kryuCP7z6Q4WyG0O2160l1 > > > > > > DDG0UbBW5yidfcghq1r6sdz30RI5cSBGcAOmlktnPkjs9wv9/S/ZPyrC > > > > > > qMPJR9A60R52NcWEONS3DiyGxR66KA4S4grJnDgcI6pcytJGXm/b5WRO > > > > > > +v51tnLT0UVbgXvV03Itn/3MR72muzKXWzzj5LFJST5iqWCgAHJryG3T > > > > > > vNKEYLQ76nwl6B3YVJDjC1InmpIujwXBbxMKpyL1Sh0RLdlHq2TtZS8O > > > > > > qk4V0Q== > > > > > > > > > > > > ;; AUTHORITY SECTION: > > > > > > . 518400 IN NS e.root- > > > > > > servers.net. > > > > > > . 518400 IN NS h.root- > > > > > > servers.net. > > > > > > . 518400 IN NS l.root- > > > > > > servers.net. > > > > > > . 518400 IN NS i.root- > > > > > > servers.net. > > > > > > . 518400 IN NS a.root- > > > > > > servers.net. > > > > > > . 518400 IN NS d.root- > > > > > > servers.net. > > > > > > . 518400 IN NS c.root- > > > > > > servers.net. > > > > > > . 518400 IN NS b.root- > > > > > > servers.net. > > > > > > . 518400 IN NS j.root- > > > > > > servers.net. > > > > > > . 518400 IN NS k.root- > > > > > > servers.net. > > > > > > . 518400 IN NS g.root- > > > > > > servers.net. > > > > > > . 518400 IN NS m.root- > > > > > > servers.net. > > > > > > . 518400 IN NS f.root- > > > > > > servers.net. > > > > > > . 518400 IN RRSIG NS 8 > > > > > > 0 > > > > > > 518400 20170319170000 20170306160000 61045 . > > > > > > iQVPY67dNDj6w14dY1tDFgwRFqhEXVVLmY8q1woIX1eU7t1k/XaPi+tX > > > > > > 3+PDCFQlrQmWSWUtLPaA6pmrACB6EL2YvWzAiLVyocGCBpUpnbUCNAwm > > > > > > nD4SvBZb0ET2jWbSiAzo8iy+1+Hr84I8RXtbcrcpF5Y/J5Oataxt5z9o > > > > > > dHGQSKru0eYEbwfszq0L5L8KECk6skm7iQ0RAIspdTfjDsIwtvoAhEGV > > > > > > B8qjFQP5Bkcn38b35eWHneCmc3cgG0J+pK/eX/YHpqClcINGh3eavBlC > > > > > > 1KpUkDDMAwCvo+X/MhDE2Ol/VR00/M/YCzXbEv97IWenM1Xi4ArX9F1C > > > > > > xBc0gA== > > > > > > > > > > > > ;; ADDITIONAL SECTION: > > > > > > e.root-servers.net. 518400 IN A 192.203 > > > > > > .230 > > > > > > .10 > > > > > > e.root-servers.net. 518400 IN AAAA 2001 > > > > > > :500 > > > > > > :a8::e > > > > > > h.root-servers.net. 518400 IN A 198.97. > > > > > > 190. > > > > > > 53 > > > > > > h.root-servers.net. 518400 IN AAAA 2001 > > > > > > :500 > > > > > > :1::53 > > > > > > l.root-servers.net. 518400 IN A 199.7.8 > > > > > > 3.42 > > > > > > l.root-servers.net. 518400 IN AAAA 2001 > > > > > > :500 > > > > > > :9f::42 > > > > > > i.root-servers.net. 518400 IN A 192.36. > > > > > > 148. > > > > > > 17 > > > > > > i.root-servers.net. 518400 IN AAAA 2001 > > > > > > :7fe > > > > > > ::53 > > > > > > a.root-servers.net. 518400 IN A 198.41. > > > > > > 0.4 > > > > > > a.root-servers.net. 518400 IN AAAA 2001 > > > > > > :503 > > > > > > :ba3e::2:30 > > > > > > d.root-servers.net. 518400 IN A 199.7.9 > > > > > > 1.13 > > > > > > d.root-servers.net. 518400 IN AAAA 2001 > > > > > > :500 > > > > > > :2d::d > > > > > > c.root-servers.net. 518400 IN A 192.33. > > > > > > 4.12 > > > > > > c.root-servers.net. 518400 IN AAAA 2001 > > > > > > :500 > > > > > > :2::c > > > > > > b.root-servers.net. 518400 IN A 192.228 > > > > > > .79. > > > > > > 201 > > > > > > b.root-servers.net. 518400 IN AAAA 2001 > > > > > > :500 > > > > > > :84::b > > > > > > j.root-servers.net. 518400 IN A 192.58. > > > > > > 128. > > > > > > 30 > > > > > > j.root-servers.net. 518400 IN AAAA 2001 > > > > > > :503 > > > > > > :c27::2:30 > > > > > > k.root-servers.net. 518400 IN A 193.0.1 > > > > > > 4.12 > > > > > > 9 > > > > > > k.root-servers.net. 518400 IN AAAA 2001 > > > > > > :7fd > > > > > > ::1 > > > > > > g.root-servers.net. 518400 IN A 192.112 > > > > > > .36. > > > > > > 4 > > > > > > g.root-servers.net. 518400 IN AAAA 2001 > > > > > > :500 > > > > > > :12::d0d > > > > > > m.root-servers.net. 518400 IN A 202.12. > > > > > > 27.3 > > > > > > 3 > > > > > > m.root-servers.net. 518400 IN AAAA 2001 > > > > > > :dc3 > > > > > > ::35 > > > > > > f.root-servers.net. 518400 IN A 192.5.5 > > > > > > .241 > > > > > > f.root-servers.net. 518400 IN AAAA 2001 > > > > > > :500 > > > > > > :2f::f > > > > > > > > > > > > ;; Query time: 836 msec > > > > > > ;; SERVER: 198.41.0.4#53(198.41.0.4) > > > > > > ;; WHEN: Mon Mar 06 15:40:58 CST 2017 > > > > > > ;; MSG SIZE rcvd: 1440 > > > > > > # > > > > > > > > > > > > I suspect the ISP mangles DNS requests directed outside their > > > > > > net. > > > > > > > > > > Well, that command shouldn't have worked then. > > > > > > > > > > Could you give me an example for something that you cannot > > > > > resolve? > > > > > > > > > > -Michael > > > > > > > > > > > > > > > > > > > > > > > Thank you, > > > > > > Paul > > > > > > > > Ah, I see... so the problem is that we're not forwarding requests > > > > outside the local domain? Latest testing sequence follows: > > > > > > > > # /etc/init.d/unbound restart > > > > Stopping Unbound DNS > > > > Proxy... [ OK ] > > > > Starting Unbound DNS > > > > Proxy... [ OK ] > > > > Ignoring broken upstream name server(s): 74.113.60.185 > > > > 156.154.70.1 [ WARN ] > > > > Falling back to recursor > > > > mode [ WARN ] > > > > > > > > # dig @198.41.0.4 +dnssec SOA . > > > > > > > > ; <<>> DiG 9.11.0-P3 <<>> @198.41.0.4 +dnssec SOA . > > > > ; (1 server found) > > > > ;; global options: +cmd > > > > ;; Got answer: > > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23002 > > > > ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: > > > > 27 > > > > ;; WARNING: recursion requested but not available > > > > > > > > ;; OPT PSEUDOSECTION: > > > > ; EDNS: version: 0, flags: do; udp: 1472 > > > > ;; QUESTION SECTION: > > > > ;. IN SOA > > > > > > > > ;; ANSWER SECTION: > > > > . 86400 IN SOA a.root-servers.net. > > > > nstld.verisign-grs.com. 2017030601 1800 900 604800 86400 > > > > . 86400 IN RRSIG SOA 8 0 86400 20170319170000 > > > > 20170306160000 61045 . > > > > X2xWv3z0ZmFxXkF9ybMgxMv6dcZ+SmnG3XHcNtAavuPNPLW3cVBwolDP > > > > lOU5/tfOaKwbu7HENFWysaekMpb6O7ycg+kryuCP7z6Q4WyG0O2160l1 > > > > DDG0UbBW5yidfcghq1r6sdz30RI5cSBGcAOmlktnPkjs9wv9/S/ZPyrC > > > > qMPJR9A60R52NcWEONS3DiyGxR66KA4S4grJnDgcI6pcytJGXm/b5WRO > > > > +v51tnLT0UVbgXvV03Itn/3MR72muzKXWzzj5LFJST5iqWCgAHJryG3T > > > > vNKEYLQ76nwl6B3YVJDjC1InmpIujwXBbxMKpyL1Sh0RLdlHq2TtZS8O qk4V0Q== > > > > > > > > ;; AUTHORITY SECTION: > > > > . 518400 IN NS a.root-servers.net. > > > > . 518400 IN NS b.root-servers.net. > > > > . 518400 IN NS c.root-servers.net. > > > > . 518400 IN NS d.root-servers.net. > > > > . 518400 IN NS e.root-servers.net. > > > > . 518400 IN NS f.root-servers.net. > > > > . 518400 IN NS g.root-servers.net. > > > > . 518400 IN NS h.root-servers.net. > > > > . 518400 IN NS i.root-servers.net. > > > > . 518400 IN NS j.root-servers.net. > > > > . 518400 IN NS k.root-servers.net. > > > > . 518400 IN NS l.root-servers.net. > > > > . 518400 IN NS m.root-servers.net. > > > > . 518400 IN RRSIG NS 8 0 518400 20170319170000 > > > > 20170306160000 61045 . > > > > iQVPY67dNDj6w14dY1tDFgwRFqhEXVVLmY8q1woIX1eU7t1k/XaPi+tX > > > > 3+PDCFQlrQmWSWUtLPaA6pmrACB6EL2YvWzAiLVyocGCBpUpnbUCNAwm > > > > nD4SvBZb0ET2jWbSiAzo8iy+1+Hr84I8RXtbcrcpF5Y/J5Oataxt5z9o > > > > dHGQSKru0eYEbwfszq0L5L8KECk6skm7iQ0RAIspdTfjDsIwtvoAhEGV > > > > B8qjFQP5Bkcn38b35eWHneCmc3cgG0J+pK/eX/YHpqClcINGh3eavBlC > > > > 1KpUkDDMAwCvo+X/MhDE2Ol/VR00/M/YCzXbEv97IWenM1Xi4ArX9F1C xBc0gA== > > > > > > > > ;; ADDITIONAL SECTION: > > > > a.root-servers.net. 518400 IN A 198.41.0.4 > > > > b.root-servers.net. 518400 IN A 192.228.79.201 > > > > c.root-servers.net. 518400 IN A 192.33.4.12 > > > > d.root-servers.net. 518400 IN A 199.7.91.13 > > > > e.root-servers.net. 518400 IN A 192.203.230.10 > > > > f.root-servers.net. 518400 IN A 192.5.5.241 > > > > g.root-servers.net. 518400 IN A 192.112.36.4 > > > > h.root-servers.net. 518400 IN A 198.97.190.53 > > > > i.root-servers.net. 518400 IN A 192.36.148.17 > > > > j.root-servers.net. 518400 IN A 192.58.128.30 > > > > k.root-servers.net. 518400 IN A 193.0.14.129 > > > > l.root-servers.net. 518400 IN A 199.7.83.42 > > > > m.root-servers.net. 518400 IN A 202.12.27.33 > > > > a.root-servers.net. 518400 IN AAAA 2001:503:ba3e::2:30 > > > > b.root-servers.net. 518400 IN AAAA 2001:500:84::b > > > > c.root-servers.net. 518400 IN AAAA 2001:500:2::c > > > > d.root-servers.net. 518400 IN AAAA 2001:500:2d::d > > > > e.root-servers.net. 518400 IN AAAA 2001:500:a8::e > > > > f.root-servers.net. 518400 IN AAAA 2001:500:2f::f > > > > g.root-servers.net. 518400 IN AAAA 2001:500:12::d0d > > > > h.root-servers.net. 518400 IN AAAA 2001:500:1::53 > > > > i.root-servers.net. 518400 IN AAAA 2001:7fe::53 > > > > j.root-servers.net. 518400 IN AAAA 2001:503:c27::2:30 > > > > k.root-servers.net. 518400 IN AAAA 2001:7fd::1 > > > > l.root-servers.net. 518400 IN AAAA 2001:500:9f::42 > > > > m.root-servers.net. 518400 IN AAAA 2001:dc3::35 > > > > > > > > ;; Query time: 797 msec > > > > ;; SERVER: 198.41.0.4#53(198.41.0.4) > > > > ;; WHEN: Mon Mar 06 17:03:12 CST 2017 > > > > ;; MSG SIZE rcvd: 1440 > > > > > > > > # host www.google.com > > > > Host www.google.com not found: 2(SERVFAIL) > > > > > > > > # host www.ipfire.org > > > > ;; connection timed out; no servers could be reached > > > > > > > > > > > > # nslookup www.google.com > > > > Server: 127.0.0.1 > > > > Address: 127.0.0.1#53 > > > > > > > > ** server can't find www.google.com: SERVFAIL > > > > > > > > # nslookup www.ipfire.org 8.8.8.8 > > > > Server: 8.8.8.8 > > > > Address: 8.8.8.8#53 > > > > > > > > Non-authoritative answer: > > > > www.ipfire.org class="Apple-tab-span" style="white- > > > > space:pre"> canonical name = web01.ipfire.org. > > > > Name: web01.ipfire.org > > > > Address: 81.3.27.41 > > > > > > > > > > > > Thanks, > > > > Paul > > > > > > > > > > > Log from unbound (via web interface): > > > > IPFire diagnostics > > Section: unbound > > Date: March 07, 2017 > > > > 09:53:05 unbound: [3485:0] info: validation failure ns02.fedoraproject.org. > > AAAA IN > > 09:53:05 unbound: [3485:0] info: validation failure ns05.fedoraproject.org. > > AAAA IN > > 09:53:05 unbound: [3485:0] info: validation failure fedoraproject.org. AAAA > > IN > > 09:52:36 unbound: [3485:1] info: validation failure > > fedoraproject.org.localdomain. AAAA IN > > 09:52:29 unbound: [3485:0] info: failed to prime trust anchor -- could not > > fetch DNSKEY rrset . DNSKEY IN > > 09:52:19 unbound: [3485:0] info: failed to prime trust anchor -- could not > > fetch DNSKEY rrset . DNSKEY IN > > 09:51:29 unbound: [3485:0] info: start of service (unbound 1.6.1). > > 09:51:29 unbound: [3485:0] notice: init module 1: iterator > > 09:51:29 unbound: [3485:0] notice: init module 0: validator > > 09:51:27 unbound: [1406:0] info: 4.000000 8.000000 1 > > 09:51:27 unbound: [1406:0] info: 2.000000 4.000000 1 > > 09:51:27 unbound: [1406:0] info: 0.524288 1.000000 2 > > 09:51:27 unbound: [1406:0] info: 0.262144 0.524288 5 > > 09:51:27 unbound: [1406:0] info: 0.131072 0.262144 1 > > 09:51:27 unbound: [1406:0] info: 0.016384 0.032768 1 > > 09:51:27 unbound: [1406:0] info: 0.008192 0.016384 1 > > 09:51:27 unbound: [1406:0] info: 0.000000 0.000001 7 > > 09:51:27 unbound: [1406:0] info: lower(secs) upper(secs) recursions > > 09:51:27 unbound: [1406:0] info: [25%]=6.78571e-07 median[50%]=0.196608 > > [75%]=0.484966 > > 09:51:27 unbound: [1406:0] info: histogram of recursion processing times > > 09:51:27 unbound: [1406:0] info: average recursion processing time 0.581705 > > sec > > 09:51:27 unbound: [1406:0] info: server stats for thread 1: requestlist max > > 3 avg 0.526316 exceeded 0 jostled 0 > > 09:51:27 unbound: [1406:0] info: server stats for thread 1: 45 queries, 26 > > answers from cache, 19 recursions, 0 prefetch, 0 rejected by ip ratelimiting > > 09:51:27 unbound: [1406:0] info: 32.000000 64.000000 6 > > 09:51:27 unbound: [1406:0] info: 16.000000 32.000000 6 > > 09:51:27 unbound: [1406:0] info: 8.000000 16.000000 11 > > 09:51:27 unbound: [1406:0] info: 4.000000 8.000000 5 > > 09:51:27 unbound: [1406:0] info: 2.000000 4.000000 2 > > 09:51:27 unbound: [1406:0] info: 1.000000 2.000000 2 > > 09:51:27 unbound: [1406:0] info: 0.262144 0.524288 4 > > 09:51:27 unbound: [1406:0] info: 0.131072 0.262144 1 > > 09:51:27 unbound: [1406:0] info: 0.000000 0.000001 2 > > 09:51:27 unbound: [1406:0] info: lower(secs) upper(secs) recursions > > 09:51:27 unbound: [1406:0] info: [25%]=2.75 median[50%]=10.5455 [75%]=22 > > 09:51:27 unbound: [1406:0] info: histogram of recursion processing times > > 09:51:27 unbound: [1406:0] info: average recursion processing time > > 15.696339 sec > > 09:51:27 unbound: [1406:0] info: server stats for thread 0: requestlist max > > 68 avg 23.925 exceeded 0 jostled 0 > > 09:51:27 unbound: [1406:0] info: server stats for thread 0: 67 queries, 28 > > answers from cache, 39 recursions, 1 prefetch, 0 rejected by ip ratelimiting > > 09:51:27 unbound: [1406:0] info: service stopped (unbound 1.6.1). > > 09:50:18 unbound: [1406:0] info: validation failure b.gtld-servers.net. > > AAAA IN > > 09:50:18 unbound: [1406:0] info: validation failure a.gtld-servers.net. > > AAAA IN > > 09:50:17 unbound: [1406:0] info: validation failure a.root-servers.net. > > AAAA IN > > 09:50:17 unbound: [1406:0] info: validation failure m.root-servers.net. > > AAAA IN > > 09:50:17 unbound: [1406:0] info: validation failure c.root-servers.net. > > AAAA IN > > 09:50:17 unbound: [1406:0] info: validation failure b.root-servers.net. > > AAAA IN > > 09:50:17 unbound: [1406:0] info: validation failure l.root-servers.net. > > AAAA IN > > 09:50:17 unbound: [1406:0] info: validation failure k.root-servers.net. > > AAAA IN > > 09:50:17 unbound: [1406:0] info: validation failure j.root-servers.net. > > AAAA IN > > 09:50:17 unbound: [1406:0] info: validation failure i.root-servers.net. > > AAAA IN > > 09:50:17 unbound: [1406:0] info: validation failure h.root-servers.net. > > AAAA IN > > 09:50:17 unbound: [1406:0] info: validation failure g.root-servers.net. > > AAAA IN > > 09:50:17 unbound: [1406:0] info: validation failure f.root-servers.net. > > AAAA IN > > 09:50:17 unbound: [1406:0] info: validation failure e.root-servers.net. > > AAAA IN > > 09:50:17 unbound: [1406:0] info: validation failure d.root-servers.net. > > AAAA IN > > 09:49:55 unbound: [1406:0] info: validation failure ns02.fedoraproject.org. > > AAAA IN > > 09:49:55 unbound: [1406:0] info: validation failure ns05.fedoraproject.org. > > AAAA IN > > 09:49:51 unbound: [1406:0] info: validation failure fedoraproject.org. AAAA > > IN > > 09:49:48 unbound: [1406:0] info: validation failure fireinfo.ipfire.org. > > AAAA IN > > 09:49:46 unbound: [1406:0] info: validation failure > > ns1.lightningwirelabs.com. AAAA IN > > 09:49:46 unbound: [1406:0] info: validation failure > > ns3.lightningwirelabs.com. AAAA IN > > 09:49:46 unbound: [1406:0] info: validation failure > > ns2.lightningwirelabs.com. AAAA IN > > 09:49:42 unbound: [1406:1] info: validation failure fedoraproject.org. AAAA > > IN > > 09:49:18 unbound: [1406:0] info: validation failure > > fedoraproject.org.localdomain. AAAA IN > > 09:49:18 unbound: [1406:0] info: validation failure > > fireinfo.ipfire.org.localdomain. AAAA IN > > 09:48:21 unbound: [1406:0] info: start of service (unbound 1.6.1). > > 09:48:21 unbound: [1406:0] notice: init module 1: iterator > > 09:48:21 unbound: [1406:0] notice: init module 0: validator > > > > > > Thank you, > > Paul > > Forgot to cc: the list... > Paul
On Wed, 2017-03-08 at 12:09 +0000, Michael Tremer wrote: > Hmm... > > That's interesting that only AAAA records fail. No idea why the > system is > resolving those any ways, but hey... > > So when you do > > dig @198.41.0.4 a.root-servers.net AAAA +dnssec > > does that work? > > What does > > dig @8.8.8.8 +sigchase +dnssec www.ipfire.org > > do? > > -Michael > > ---->% massive snippage here %<---- Sorry for the delay. I have to chase everyone off the network and reboot with another disk (development image) to test, then have to reboot with Core105 and DNSSEC disabled to resume email :). Here are the results: # dig @198.41.0.4 a.root-servers.net AAAA +dnssec ; <<>> DiG 9.11.0-P3 <<>> @198.41.0.4 a.root-servers.net AAAA +dnssec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65258 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: Message has 23 extra bytes at end ;; QUESTION SECTION: ;a.root-servers.net. IN AAAA ;; Query time: 1 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Wed Mar 08 09:56:11 CST 2017 ;; MSG SIZE rcvd: 59 # dig @8.8.8.8 +sigchase +dnssec www.ipfire.org ;; Warning: Message parser reports malformed message packet. ;; NO ANSWERS: no more We want to prove the non-existence of a type of rdata 1 or of the zone: ;; nothing in authority section : impossible to validate the non-existence : FAILED ;; Impossible to verify the Non-existence, the NSEC RRset can't be validated: FAILED Thank you, Paul
On Wed, 2017-03-08 at 10:19 -0600, Paul Simmons wrote: > On Wed, 2017-03-08 at 12:09 +0000, Michael Tremer wrote: > > Hmm... > > > > That's interesting that only AAAA records fail. No idea why the > > system is > > resolving those any ways, but hey... > > > > So when you do > > > > dig @198.41.0.4 a.root-servers.net AAAA +dnssec > > > > does that work? > > > > What does > > > > dig @8.8.8.8 +sigchase +dnssec www.ipfire.org > > > > do? > > > > -Michael > > > > ---->% massive snippage here %<---- > > Sorry for the delay. I have to chase everyone off the network and > reboot with another disk (development image) to test, then have to > reboot with Core105 and DNSSEC disabled to resume email :). > > Here are the results: > > # dig @198.41.0.4 a.root-servers.net AAAA +dnssec > > ; <<>> DiG 9.11.0-P3 <<>> @198.41.0.4 a.root-servers.net AAAA +dnssec > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65258 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: > 0 > ;; WARNING: Message has 23 extra bytes at end > > ;; QUESTION SECTION: > ;a.root-servers.net. IN AAAA > > ;; Query time: 1 msec > ;; SERVER: 198.41.0.4#53(198.41.0.4) > ;; WHEN: Wed Mar 08 09:56:11 CST 2017 > ;; MSG SIZE rcvd: 59 > > # dig @8.8.8.8 +sigchase +dnssec www.ipfire.org > ;; Warning: Message parser reports malformed message packet. > ;; NO ANSWERS: no more > We want to prove the non-existence of a type of rdata 1 or of the > zone: > ;; nothing in authority section : impossible to validate the non- > existence : FAILED > > ;; Impossible to verify the Non-existence, the NSEC RRset can't be > validated: FAILED > > Thank you, > Paul Additional information: On Core105, I have an override in /etc/sysconfig/dnsmasq: ENABLE_DNSSEC=0 If I remove this, DNS resolution outside of my private network fails. I've had a long conversation with HughesNet Community Support (such as it is), to no avail. Hughes has no plans to support DNSSEC in the near future, and there's no way to prevent the modem (HN9000) from caching / spoofing / mangling DNS traffic. There are no other providers available - no DSL, no cable, no fiber, no wireless, no cellular, no anything. If I had the funds, I'd create my own NLOS WISP and make a tidy profit out here "in the sticks". Goodness knows, I'd like a reprieve from high cost, data caps, high latency, rain fade, and miserable throughput. Please, is there any way to fall back to insecure DNS with IPFire's unbound configuration? I realize my situation is a "corner case", but I like IPFire, have a lot of time and effort invested, and am loath to switch to a different firewall. Best regards, Paul
Hey Paul, I really don't want you to switch away from IPFire since there is no need to. We will get this fixed. And although this is a corner case I am willing to work on this. However I cannot test. So just to get me up to date again: Did you apply the changes from Core Update 110? Did that work or not? -Michael On Sat, 2017-03-25 at 10:20 -0500, Paul Simmons wrote: > On Wed, 2017-03-08 at 10:19 -0600, Paul Simmons wrote: > > On Wed, 2017-03-08 at 12:09 +0000, Michael Tremer wrote: > > > > > > Hmm... > > > > > > That's interesting that only AAAA records fail. No idea why the > > > system is > > > resolving those any ways, but hey... > > > > > > So when you do > > > > > > dig @198.41.0.4 a.root-servers.net AAAA +dnssec > > > > > > does that work? > > > > > > What does > > > > > > dig @8.8.8.8 +sigchase +dnssec www.ipfire.org > > > > > > do? > > > > > > -Michael > > > > > > ---->% massive snippage here %<---- > > > > Sorry for the delay. I have to chase everyone off the network and > > reboot with another disk (development image) to test, then have to > > reboot with Core105 and DNSSEC disabled to resume email :). > > > > Here are the results: > > > > # dig @198.41.0.4 a.root-servers.net AAAA +dnssec > > > > ; <<>> DiG 9.11.0-P3 <<>> @198.41.0.4 a.root-servers.net AAAA +dnssec > > ; (1 server found) > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65258 > > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; WARNING: Message has 23 extra bytes at end > > > > ;; QUESTION SECTION: > > ;a.root-servers.net. IN AAAA > > > > ;; Query time: 1 msec > > ;; SERVER: 198.41.0.4#53(198.41.0.4) > > ;; WHEN: Wed Mar 08 09:56:11 CST 2017 > > ;; MSG SIZE rcvd: 59 > > > > # dig @8.8.8.8 +sigchase +dnssec www.ipfire.org > > ;; Warning: Message parser reports malformed message packet. > > ;; NO ANSWERS: no more > > We want to prove the non-existence of a type of rdata 1 or of the zone: > > ;; nothing in authority section : impossible to validate the non-existence : > > FAILED > > > > ;; Impossible to verify the Non-existence, the NSEC RRset can't be > > validated: FAILED > > > > Thank you, > > Paul > > Additional information: > > On Core105, I have an override in /etc/sysconfig/dnsmasq: > ENABLE_DNSSEC=0 > > If I remove this, DNS resolution outside of my private network fails. > > I've had a long conversation with HughesNet Community Support (such as it is), > to no avail. > > Hughes has no plans to support DNSSEC in the near future, and there's no way > to prevent the modem (HN9000) from caching / spoofing / mangling DNS traffic. > > There are no other providers available - no DSL, no cable, no fiber, no > wireless, no cellular, no anything. If I had the funds, I'd create my own NLOS > WISP and make a tidy profit out here "in the sticks". Goodness knows, I'd like > a reprieve from high cost, data caps, high latency, rain fade, and miserable > throughput. > > Please, is there any way to fall back to insecure DNS with IPFire's unbound > configuration? I realize my situation is a "corner case", but I like IPFire, > have a lot of time and effort invested, and am loath to switch to a different > firewall. > > Best regards, > Paul
On Thu, 2017-03-30 at 17:51 +0100, Michael Tremer wrote: > Hey Paul, > > I really don't want you to switch away from IPFire since there is no > need to. We > will get this fixed. > > And although this is a corner case I am willing to work on this. > However I > cannot test. > > So just to get me up to date again: Did you apply the changes from > Core Update > 110? Did that work or not? > > -Michael > > On Sat, 2017-03-25 at 10:20 -0500, Paul Simmons wrote: > > On Wed, 2017-03-08 at 10:19 -0600, Paul Simmons wrote: > > > On Wed, 2017-03-08 at 12:09 +0000, Michael Tremer wrote: > > > > > > > > Hmm... > > > > > > > > That's interesting that only AAAA records fail. No idea why the > > > > system is > > > > resolving those any ways, but hey... > > > > > > > > So when you do > > > > > > > > dig @198.41.0.4 a.root-servers.net AAAA +dnssec > > > > > > > > does that work? > > > > > > > > What does > > > > > > > > dig @8.8.8.8 +sigchase +dnssec www.ipfire.org > > > > > > > > do? > > > > > > > > -Michael > > > > > > > > ---->% massive snippage here %<---- > > > > > > Sorry for the delay. I have to chase everyone off the network and > > > reboot with another disk (development image) to test, then have > > > to > > > reboot with Core105 and DNSSEC disabled to resume email :). > > > > > > Here are the results: > > > > > > # dig @198.41.0.4 a.root-servers.net AAAA +dnssec > > > > > > ; <<>> DiG 9.11.0-P3 <<>> @198.41.0.4 a.root-servers.net AAAA > > > +dnssec > > > ; (1 server found) > > > ;; global options: +cmd > > > ;; Got answer: > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65258 > > > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, > > > ADDITIONAL: 0 > > > ;; WARNING: Message has 23 extra bytes at end > > > > > > ;; QUESTION SECTION: > > > ;a.root-servers.net. IN AAAA > > > > > > ;; Query time: 1 msec > > > ;; SERVER: 198.41.0.4#53(198.41.0.4) > > > ;; WHEN: Wed Mar 08 09:56:11 CST 2017 > > > ;; MSG SIZE rcvd: 59 > > > > > > # dig @8.8.8.8 +sigchase +dnssec www.ipfire.org > > > ;; Warning: Message parser reports malformed message packet. > > > ;; NO ANSWERS: no more > > > We want to prove the non-existence of a type of rdata 1 or of the > > > zone: > > > ;; nothing in authority section : impossible to validate the non- > > > existence : > > > FAILED > > > > > > ;; Impossible to verify the Non-existence, the NSEC RRset can't > > > be > > > validated: FAILED > > > > > > Thank you, > > > Paul > > > > Additional information: > > > > On Core105, I have an override in /etc/sysconfig/dnsmasq: > > ENABLE_DNSSEC=0 > > > > If I remove this, DNS resolution outside of my private network > > fails. > > > > I've had a long conversation with HughesNet Community Support (such > > as it is), > > to no avail. > > > > Hughes has no plans to support DNSSEC in the near future, and > > there's no way > > to prevent the modem (HN9000) from caching / spoofing / mangling > > DNS traffic. > > > > There are no other providers available - no DSL, no cable, no > > fiber, no > > wireless, no cellular, no anything. If I had the funds, I'd create > > my own NLOS > > WISP and make a tidy profit out here "in the sticks". Goodness > > knows, I'd like > > a reprieve from high cost, data caps, high latency, rain fade, and > > miserable > > throughput. > > > > Please, is there any way to fall back to insecure DNS with IPFire's > > unbound > > configuration? I realize my situation is a "corner case", but I > > like IPFire, > > have a lot of time and effort invested, and am loath to switch to a > > different > > firewall. > > > > Best regards, > > Paul > Hey Michael. Sorry to be a pain. Thank you for your help. I tested with commit c016773b9816ad9be4ffc8643c30457e87c094e3 and had no luck. I tried using both the ISP provided DNS and known "good" validating servers. Shall I rebuild the test image with a later commit? Paul
No, I don't think that any of the changes after that commit would have helped. What I need to have is a test that allows me to identify if these name servers are able to pass on the public key of the root zone. If so, then DNSSEC would work fine in recursor mode. If not, unbound should now disable DNSSEC validation. What is the output of "/etc/init.d/unbound restart" on that system? -Michael On Thu, 2017-03-30 at 13:21 -0500, Paul Simmons wrote: > On Thu, 2017-03-30 at 17:51 +0100, Michael Tremer wrote: > > > > Hey Paul, > > > > I really don't want you to switch away from IPFire since there is no > > need to. We > > will get this fixed. > > > > And although this is a corner case I am willing to work on this. > > However I > > cannot test. > > > > So just to get me up to date again: Did you apply the changes from > > Core Update > > 110? Did that work or not? > > > > -Michael > > > > On Sat, 2017-03-25 at 10:20 -0500, Paul Simmons wrote: > > > > > > On Wed, 2017-03-08 at 10:19 -0600, Paul Simmons wrote: > > > > > > > > On Wed, 2017-03-08 at 12:09 +0000, Michael Tremer wrote: > > > > > > > > > > > > > > > Hmm... > > > > > > > > > > That's interesting that only AAAA records fail. No idea why the > > > > > system is > > > > > resolving those any ways, but hey... > > > > > > > > > > So when you do > > > > > > > > > > dig @198.41.0.4 a.root-servers.net AAAA +dnssec > > > > > > > > > > does that work? > > > > > > > > > > What does > > > > > > > > > > dig @8.8.8.8 +sigchase +dnssec www.ipfire.org > > > > > > > > > > do? > > > > > > > > > > -Michael > > > > > > > > > > ---->% massive snippage here %<---- > > > > > > > > Sorry for the delay. I have to chase everyone off the network and > > > > reboot with another disk (development image) to test, then have > > > > to > > > > reboot with Core105 and DNSSEC disabled to resume email :). > > > > > > > > Here are the results: > > > > > > > > # dig @198.41.0.4 a.root-servers.net AAAA +dnssec > > > > > > > > ; <<>> DiG 9.11.0-P3 <<>> @198.41.0.4 a.root-servers.net AAAA > > > > +dnssec > > > > ; (1 server found) > > > > ;; global options: +cmd > > > > ;; Got answer: > > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65258 > > > > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, > > > > ADDITIONAL: 0 > > > > ;; WARNING: Message has 23 extra bytes at end > > > > > > > > ;; QUESTION SECTION: > > > > ;a.root-servers.net. IN AAAA > > > > > > > > ;; Query time: 1 msec > > > > ;; SERVER: 198.41.0.4#53(198.41.0.4) > > > > ;; WHEN: Wed Mar 08 09:56:11 CST 2017 > > > > ;; MSG SIZE rcvd: 59 > > > > > > > > # dig @8.8.8.8 +sigchase +dnssec www.ipfire.org > > > > ;; Warning: Message parser reports malformed message packet. > > > > ;; NO ANSWERS: no more > > > > We want to prove the non-existence of a type of rdata 1 or of the > > > > zone: > > > > ;; nothing in authority section : impossible to validate the non- > > > > existence : > > > > FAILED > > > > > > > > ;; Impossible to verify the Non-existence, the NSEC RRset can't > > > > be > > > > validated: FAILED > > > > > > > > Thank you, > > > > Paul > > > > > > Additional information: > > > > > > On Core105, I have an override in /etc/sysconfig/dnsmasq: > > > ENABLE_DNSSEC=0 > > > > > > If I remove this, DNS resolution outside of my private network > > > fails. > > > > > > I've had a long conversation with HughesNet Community Support (such > > > as it is), > > > to no avail. > > > > > > Hughes has no plans to support DNSSEC in the near future, and > > > there's no way > > > to prevent the modem (HN9000) from caching / spoofing / mangling > > > DNS traffic. > > > > > > There are no other providers available - no DSL, no cable, no > > > fiber, no > > > wireless, no cellular, no anything. If I had the funds, I'd create > > > my own NLOS > > > WISP and make a tidy profit out here "in the sticks". Goodness > > > knows, I'd like > > > a reprieve from high cost, data caps, high latency, rain fade, and > > > miserable > > > throughput. > > > > > > Please, is there any way to fall back to insecure DNS with IPFire's > > > unbound > > > configuration? I realize my situation is a "corner case", but I > > > like IPFire, > > > have a lot of time and effort invested, and am loath to switch to a > > > different > > > firewall. > > > > > > Best regards, > > > Paul > > > > Hey Michael. Sorry to be a pain. Thank you for your help. > > I tested with commit c016773b9816ad9be4ffc8643c30457e87c094e3 and had no luck. > > I tried using both the ISP provided DNS and known "good" validating servers. > > Shall I rebuild the test image with a later commit? > > Paul
On Fri, 2017-03-31 at 17:53 +0100, Michael Tremer wrote: > No, I don't think that any of the changes after that commit would > have helped. > > What I need to have is a test that allows me to identify if these > name servers > are able to pass on the public key of the root zone. > > If so, then DNSSEC would work fine in recursor mode. > > If not, unbound should now disable DNSSEC validation. > > What is the output of "/etc/init.d/unbound restart" on that system? > > -Michael > > On Thu, 2017-03-30 at 13:21 -0500, Paul Simmons wrote: > > On Thu, 2017-03-30 at 17:51 +0100, Michael Tremer wrote: > > > > > > Hey Paul, > > > > > > I really don't want you to switch away from IPFire since there is > > > no > > > need to. We > > > will get this fixed. > > > > > > And although this is a corner case I am willing to work on this. > > > However I > > > cannot test. > > > > > > So just to get me up to date again: Did you apply the changes > > > from > > > Core Update > > > 110? Did that work or not? > > > > > > -Michael > > > > > > On Sat, 2017-03-25 at 10:20 -0500, Paul Simmons wrote: > > > > > > > > On Wed, 2017-03-08 at 10:19 -0600, Paul Simmons wrote: > > > > > > > > > > On Wed, 2017-03-08 at 12:09 +0000, Michael Tremer wrote: > > > > > > > > > > > > > > > > > > Hmm... > > > > > > > > > > > > That's interesting that only AAAA records fail. No idea why > > > > > > the > > > > > > system is > > > > > > resolving those any ways, but hey... > > > > > > > > > > > > So when you do > > > > > > > > > > > > dig @198.41.0.4 a.root-servers.net AAAA +dnssec > > > > > > > > > > > > does that work? > > > > > > > > > > > > What does > > > > > > > > > > > > dig @8.8.8.8 +sigchase +dnssec www.ipfire.org > > > > > > > > > > > > do? > > > > > > > > > > > > -Michael > > > > > > > > > > > > ---->% massive snippage here %<---- > > > > > > > > > > Sorry for the delay. I have to chase everyone off the network > > > > > and > > > > > reboot with another disk (development image) to test, then > > > > > have > > > > > to > > > > > reboot with Core105 and DNSSEC disabled to resume email :). > > > > > > > > > > Here are the results: > > > > > > > > > > # dig @198.41.0.4 a.root-servers.net AAAA +dnssec > > > > > > > > > > ; <<>> DiG 9.11.0-P3 <<>> @198.41.0.4 a.root-servers.net AAAA > > > > > +dnssec > > > > > ; (1 server found) > > > > > ;; global options: +cmd > > > > > ;; Got answer: > > > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65258 > > > > > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, > > > > > ADDITIONAL: 0 > > > > > ;; WARNING: Message has 23 extra bytes at end > > > > > > > > > > ;; QUESTION SECTION: > > > > > ;a.root-servers.net. IN AAAA > > > > > > > > > > ;; Query time: 1 msec > > > > > ;; SERVER: 198.41.0.4#53(198.41.0.4) > > > > > ;; WHEN: Wed Mar 08 09:56:11 CST 2017 > > > > > ;; MSG SIZE rcvd: 59 > > > > > > > > > > # dig @8.8.8.8 +sigchase +dnssec www.ipfire.org > > > > > ;; Warning: Message parser reports malformed message packet. > > > > > ;; NO ANSWERS: no more > > > > > We want to prove the non-existence of a type of rdata 1 or of > > > > > the > > > > > zone: > > > > > ;; nothing in authority section : impossible to validate the > > > > > non- > > > > > existence : > > > > > FAILED > > > > > > > > > > ;; Impossible to verify the Non-existence, the NSEC RRset > > > > > can't > > > > > be > > > > > validated: FAILED > > > > > > > > > > Thank you, > > > > > Paul > > > > > > > > Additional information: > > > > > > > > On Core105, I have an override in /etc/sysconfig/dnsmasq: > > > > ENABLE_DNSSEC=0 > > > > > > > > If I remove this, DNS resolution outside of my private network > > > > fails. > > > > > > > > I've had a long conversation with HughesNet Community Support > > > > (such > > > > as it is), > > > > to no avail. > > > > > > > > Hughes has no plans to support DNSSEC in the near future, and > > > > there's no way > > > > to prevent the modem (HN9000) from caching / spoofing / > > > > mangling > > > > DNS traffic. > > > > > > > > There are no other providers available - no DSL, no cable, no > > > > fiber, no > > > > wireless, no cellular, no anything. If I had the funds, I'd > > > > create > > > > my own NLOS > > > > WISP and make a tidy profit out here "in the sticks". Goodness > > > > knows, I'd like > > > > a reprieve from high cost, data caps, high latency, rain fade, > > > > and > > > > miserable > > > > throughput. > > > > > > > > Please, is there any way to fall back to insecure DNS with > > > > IPFire's > > > > unbound > > > > configuration? I realize my situation is a "corner case", but I > > > > like IPFire, > > > > have a lot of time and effort invested, and am loath to switch > > > > to a > > > > different > > > > firewall. > > > > > > > > Best regards, > > > > Paul > > > > Hey Michael. Sorry to be a pain. Thank you for your help. > > > > I tested with commit c016773b9816ad9be4ffc8643c30457e87c094e3 and > > had no luck. > > > > I tried using both the ISP provided DNS and known "good" validating > > servers. > > > > Shall I rebuild the test image with a later commit? > > > > Paul > Finally got a test window... made the best of it. ---------------------------------------------------------- Output from unbound restart: # /etc/init.d/unbound restart Stopping Unbound DNS Proxy... [ OK ] Starting Unbound DNS Proxy... [ OK ] Ignoring broken upstream name server(s): 67.142.173.10 67.142.173.11 [ WARN ] Falling back to recursor mode [ WARN ] ---------------------------------------------------------- A couple of simple resolution tests: # nslookup www.google.com Server: 127.0.0.1 Address: 127.0.0.1#53 ** server can't find www.google.com: SERVFAIL # host www.google.com Host www.google.com not found: 2(SERVFAIL) ---------------------------------------------------------- Export of unbound log (reverse chronological): IPFire diagnostics Section: unbound Date: April 02, 2017 10:48:30 unbound: [3763:1] info: validation failure self- repair.mozilla.org. AAAA IN 10:47:31 unbound: [3763:0] info: validation failure ns2.cctld.co. AAAA IN 10:47:28 unbound: [3763:1] info: validation failure c.ns.nic.cz. AAAA IN 10:47:28 unbound: [3763:1] info: validation failure a.ns.nic.cz. AAAA IN 10:47:28 unbound: [3763:1] info: validation failure b.ns.nic.cz. AAAA IN 10:47:28 unbound: [3763:1] info: validation failure d.ns.nic.cz. AAAA IN 10:47:24 unbound: [3763:0] info: validation failure ns4.cctld.co. AAAA IN 10:47:24 unbound: [3763:0] info: validation failure ns3.cctld.co. AAAA IN 10:47:24 unbound: [3763:0] info: validation failure ns5.cctld.co. AAAA IN 10:47:24 unbound: [3763:0] info: validation failure ns1.cctld.co. AAAA IN 10:47:24 unbound: [3763:0] info: validation failure ns6.cctld.co. AAAA IN 10:47:03 unbound: [3763:0] info: validation failure ns02.fedoraproject.org. AAAA IN 10:47:01 unbound: [3763:0] info: validation failure ns05.fedoraproject.org. AAAA IN 10:46:51 unbound: [3763:1] info: validation failure ns3.cloudflare.com. AAAA IN 10:46:51 unbound: [3763:1] info: validation failure ns6.cloudflare.com. AAAA IN 10:46:50 unbound: [3763:1] info: validation failure ns7.cloudflare.com. AAAA IN 10:46:49 unbound: [3763:0] info: validation failure fedoraproject.org. AAAA IN 10:46:38 unbound: [3763:1] info: validation failure ns5.cloudflare.com. AAAA IN 10:46:38 unbound: [3763:1] info: validation failure ns4.cloudflare.com. AAAA IN 10:44:08 unbound: [3763:0] info: validation failure www.facebook.com.l ocaldomain. AAAA IN 10:43:28 unbound: [3763:0] info: start of service (unbound 1.6.1). 10:43:28 unbound: [3763:0] notice: init module 1: iterator 10:43:28 unbound: [3763:0] notice: init module 0: validator 10:43:26 unbound: [1407:0] info: 32.000000 64.000000 4 10:43:26 unbound: [1407:0] info: 16.000000 32.000000 5 10:43:26 unbound: [1407:0] info: 8.000000 16.000000 4 10:43:26 unbound: [1407:0] info: 4.000000 8.000000 2 10:43:26 unbound: [1407:0] info: 2.000000 4.000000 3 10:43:26 unbound: [1407:0] info: 0.524288 1.000000 4 10:43:26 unbound: [1407:0] info: 0.262144 0.524288 1 10:43:26 unbound: [1407:0] info: 0.131072 0.262144 1 10:43:26 unbound: [1407:0] info: 0.004096 0.008192 2 10:43:26 unbound: [1407:0] info: 0.000000 0.000001 8 10:43:26 unbound: [1407:0] info: lower(secs) upper(secs) recursions 10:43:26 unbound: [1407:0] info: [25%]=0.00512 median[50%]=2.66667 [75%]=17.6 10:43:26 unbound: [1407:0] info: histogram of recursion processing times 10:43:26 unbound: [1407:0] info: average recursion processing time 10.613770 sec 10:43:26 unbound: [1407:0] info: server stats for thread 1: requestlist max 40 avg 6.79412 exceeded 0 jostled 0 10:43:26 unbound: [1407:0] info: server stats for thread 1: 76 queries, 42 answers from cache, 34 recursions, 0 prefetch, 0 rejected by ip ratelimiting 10:43:26 unbound: [1407:0] info: 32.000000 64.000000 4 10:43:26 unbound: [1407:0] info: 16.000000 32.000000 9 10:43:26 unbound: [1407:0] info: 8.000000 16.000000 6 10:43:26 unbound: [1407:0] info: 4.000000 8.000000 6 10:43:26 unbound: [1407:0] info: 2.000000 4.000000 5 10:43:26 unbound: [1407:0] info: 1.000000 2.000000 3 10:43:26 unbound: [1407:0] info: 0.524288 1.000000 5 10:43:26 unbound: [1407:0] info: 0.262144 0.524288 1 10:43:26 unbound: [1407:0] info: 0.131072 0.262144 6 10:43:26 unbound: [1407:0] info: 0.016384 0.032768 1 10:43:26 unbound: [1407:0] info: 0.000000 0.000001 9 10:43:26 unbound: [1407:0] info: lower(secs) upper(secs) recursions 10:43:26 unbound: [1407:0] info: [25%]=0.212992 median[50%]=3 [75%]=15 10:43:26 unbound: [1407:0] info: histogram of recursion processing times 10:43:26 unbound: [1407:0] info: average recursion processing time 8.866802 sec 10:43:26 unbound: [1407:0] info: server stats for thread 0: requestlist max 63 avg 17.7679 exceeded 0 jostled 0 10:43:26 unbound: [1407:0] info: server stats for thread 0: 83 queries, 28 answers from cache, 55 recursions, 1 prefetch, 0 rejected by ip ratelimiting 10:43:26 unbound: [1407:0] info: service stopped (unbound 1.6.1). 10:42:07 unbound: [1407:0] info: validation failure sfba.sns- pb.isc.org. AAAA IN 10:42:03 unbound: [1407:0] info: validation failure adns3.upenn.edu. AAAA IN 10:42:02 unbound: [1407:0] info: validation failure ord.sns- pb.isc.org. AAAA IN 10:42:01 unbound: [1407:0] info: validation failure ams.sns- pb.isc.org. AAAA IN 10:41:57 unbound: [1407:0] info: validation failure adns2.upenn.edu. AAAA IN 10:41:51 unbound: [1407:0] info: validation failure adns1.upenn.edu. AAAA IN 10:41:42 unbound: [1407:0] info: validation failure ns05.fedoraproject.org. AAAA IN 10:41:42 unbound: [1407:0] info: validation failure ns02.fedoraproject.org. AAAA IN 10:41:41 unbound: [1407:1] info: validation failure ns05.fedoraproject.org. AAAA IN 10:41:41 unbound: [1407:1] info: validation failure ns02.fedoraproject.org. AAAA IN 10:41:31 unbound: [1407:0] info: validation failure fedoraproject.org. AAAA IN 10:41:23 unbound: [1407:1] info: validation failure fedoraproject.org. AAAA IN 10:41:19 unbound: [1407:0] info: validation failure ns3.pch.net. AAAA IN 10:41:19 unbound: [1407:0] info: validation failure anyns.pch.net. AAAA IN 10:41:18 unbound: [1407:0] info: validation failure ns2.pch.net. AAAA IN 10:41:04 unbound: [1407:0] info: validation failure ns5.cloudflare.net. AAAA IN 10:41:04 unbound: [1407:0] info: validation failure ns4.cloudflare.net. AAAA IN 10:41:03 unbound: [1407:0] info: validation failure ns2.cloudflare.net. AAAA IN 10:41:03 unbound: [1407:0] info: validation failure ns3.cloudflare.net. AAAA IN 10:41:02 unbound: [1407:0] info: validation failure ns1.cloudflare.net. AAAA IN 10:40:55 unbound: [1407:1] info: validation failure fireinfo.ipfire.org. AAAA IN 10:40:54 unbound: [1407:1] info: validation failure ns2.lightningwirelabs.com. AAAA IN 10:40:54 unbound: [1407:1] info: validation failure ns1.lightningwirelabs.com. AAAA IN 10:40:54 unbound: [1407:1] info: validation failure ns3.lightningwirelabs.com. AAAA IN 10:40:27 unbound: [1407:0] info: validation failure fireinfo.ipfire.org.localdomain. AAAA IN 10:39:36 unbound: [1407:0] info: start of service (unbound 1.6.1). 10:39:36 unbound: [1407:0] notice: init module 1: iterator 10:39:36 unbound: [1407:0] notice: init module 0: validator ---------------------------------------------------------- Hope this helps. Used ISP (HughesNet) DNS servers as provided through DHCP on RED. Ping of 8.8.4.4 was good during the test window. Best, Paul
Hi, this does help, yes. You are falling back to recursor mode which is not really what should happen. That means the test does not indicate correctly what I hoped it would do. Are those name servers your ISP is forcing you to use publicly available? If so I could test on my own. Best, -Michael On Sun, 2017-04-02 at 11:37 -0500, Paul Simmons wrote: > On Fri, 2017-03-31 at 17:53 +0100, Michael Tremer wrote: > > No, I don't think that any of the changes after that commit would > > have helped. > > > > What I need to have is a test that allows me to identify if these > > name servers > > are able to pass on the public key of the root zone. > > > > If so, then DNSSEC would work fine in recursor mode. > > > > If not, unbound should now disable DNSSEC validation. > > > > What is the output of "/etc/init.d/unbound restart" on that system? > > > > -Michael > > > > On Thu, 2017-03-30 at 13:21 -0500, Paul Simmons wrote: > > > On Thu, 2017-03-30 at 17:51 +0100, Michael Tremer wrote: > > > > > > > > Hey Paul, > > > > > > > > I really don't want you to switch away from IPFire since there > > > > is > > > > no > > > > need to. We > > > > will get this fixed. > > > > > > > > And although this is a corner case I am willing to work on > > > > this. > > > > However I > > > > cannot test. > > > > > > > > So just to get me up to date again: Did you apply the changes > > > > from > > > > Core Update > > > > 110? Did that work or not? > > > > > > > > -Michael > > > > > > > > On Sat, 2017-03-25 at 10:20 -0500, Paul Simmons wrote: > > > > > > > > > > On Wed, 2017-03-08 at 10:19 -0600, Paul Simmons wrote: > > > > > > > > > > > > On Wed, 2017-03-08 at 12:09 +0000, Michael Tremer wrote: > > > > > > > > > > > > > > > > > > > > > Hmm... > > > > > > > > > > > > > > That's interesting that only AAAA records fail. No idea > > > > > > > why > > > > > > > the > > > > > > > system is > > > > > > > resolving those any ways, but hey... > > > > > > > > > > > > > > So when you do > > > > > > > > > > > > > > dig @198.41.0.4 a.root-servers.net AAAA +dnssec > > > > > > > > > > > > > > does that work? > > > > > > > > > > > > > > What does > > > > > > > > > > > > > > dig @8.8.8.8 +sigchase +dnssec www.ipfire.org > > > > > > > > > > > > > > do? > > > > > > > > > > > > > > -Michael > > > > > > > > > > > > > > ---->% massive snippage here %<---- > > > > > > > > > > > > Sorry for the delay. I have to chase everyone off the > > > > > > network > > > > > > and > > > > > > reboot with another disk (development image) to test, then > > > > > > have > > > > > > to > > > > > > reboot with Core105 and DNSSEC disabled to resume email :). > > > > > > > > > > > > Here are the results: > > > > > > > > > > > > # dig @198.41.0.4 a.root-servers.net AAAA +dnssec > > > > > > > > > > > > ; <<>> DiG 9.11.0-P3 <<>> @198.41.0.4 a.root-servers.net > > > > > > AAAA > > > > > > +dnssec > > > > > > ; (1 server found) > > > > > > ;; global options: +cmd > > > > > > ;; Got answer: > > > > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65258 > > > > > > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, > > > > > > ADDITIONAL: 0 > > > > > > ;; WARNING: Message has 23 extra bytes at end > > > > > > > > > > > > ;; QUESTION SECTION: > > > > > > ;a.root-servers.net. IN AAAA > > > > > > > > > > > > ;; Query time: 1 msec > > > > > > ;; SERVER: 198.41.0.4#53(198.41.0.4) > > > > > > ;; WHEN: Wed Mar 08 09:56:11 CST 2017 > > > > > > ;; MSG SIZE rcvd: 59 > > > > > > > > > > > > # dig @8.8.8.8 +sigchase +dnssec www.ipfire.org > > > > > > ;; Warning: Message parser reports malformed message > > > > > > packet. > > > > > > ;; NO ANSWERS: no more > > > > > > We want to prove the non-existence of a type of rdata 1 or > > > > > > of > > > > > > the > > > > > > zone: > > > > > > ;; nothing in authority section : impossible to validate > > > > > > the > > > > > > non- > > > > > > existence : > > > > > > FAILED > > > > > > > > > > > > ;; Impossible to verify the Non-existence, the NSEC RRset > > > > > > can't > > > > > > be > > > > > > validated: FAILED > > > > > > > > > > > > Thank you, > > > > > > Paul > > > > > > > > > > Additional information: > > > > > > > > > > On Core105, I have an override in /etc/sysconfig/dnsmasq: > > > > > ENABLE_DNSSEC=0 > > > > > > > > > > If I remove this, DNS resolution outside of my private > > > > > network > > > > > fails. > > > > > > > > > > I've had a long conversation with HughesNet Community Support > > > > > (such > > > > > as it is), > > > > > to no avail. > > > > > > > > > > Hughes has no plans to support DNSSEC in the near future, and > > > > > there's no way > > > > > to prevent the modem (HN9000) from caching / spoofing / > > > > > mangling > > > > > DNS traffic. > > > > > > > > > > There are no other providers available - no DSL, no cable, no > > > > > fiber, no > > > > > wireless, no cellular, no anything. If I had the funds, I'd > > > > > create > > > > > my own NLOS > > > > > WISP and make a tidy profit out here "in the sticks". > > > > > Goodness > > > > > knows, I'd like > > > > > a reprieve from high cost, data caps, high latency, rain > > > > > fade, > > > > > and > > > > > miserable > > > > > throughput. > > > > > > > > > > Please, is there any way to fall back to insecure DNS with > > > > > IPFire's > > > > > unbound > > > > > configuration? I realize my situation is a "corner case", but > > > > > I > > > > > like IPFire, > > > > > have a lot of time and effort invested, and am loath to > > > > > switch > > > > > to a > > > > > different > > > > > firewall. > > > > > > > > > > Best regards, > > > > > Paul > > > > > > Hey Michael. Sorry to be a pain. Thank you for your help. > > > > > > I tested with commit c016773b9816ad9be4ffc8643c30457e87c094e3 and > > > had no luck. > > > > > > I tried using both the ISP provided DNS and known "good" > > > validating > > > servers. > > > > > > Shall I rebuild the test image with a later commit? > > > > > > Paul > > Finally got a test window... made the best of it. > > ---------------------------------------------------------- > Output from unbound restart: > > # /etc/init.d/unbound restart > Stopping Unbound DNS > Proxy... [ OK ] > Starting Unbound DNS > Proxy... [ OK ] > Ignoring broken upstream name server(s): 67.142.173.10 > 67.142.173.11 [ WARN ] > Falling back to recursor > mode [ WARN ] > ---------------------------------------------------------- > A couple of simple resolution tests: > > # nslookup www.google.com > Server: 127.0.0.1 > Address: 127.0.0.1#53 > > ** server can't find www.google.com: SERVFAIL > > # host www.google.com > Host www.google.com not found: 2(SERVFAIL) > ---------------------------------------------------------- > Export of unbound log (reverse chronological): > > IPFire diagnostics > Section: unbound > Date: April 02, 2017 > > 10:48:30 unbound: [3763:1] info: validation failure self- > repair.mozilla.org. AAAA IN > 10:47:31 unbound: [3763:0] info: validation failure ns2.cctld.co. > AAAA > IN > 10:47:28 unbound: [3763:1] info: validation failure c.ns.nic.cz. > AAAA > IN > 10:47:28 unbound: [3763:1] info: validation failure a.ns.nic.cz. > AAAA > IN > 10:47:28 unbound: [3763:1] info: validation failure b.ns.nic.cz. > AAAA > IN > 10:47:28 unbound: [3763:1] info: validation failure d.ns.nic.cz. > AAAA > IN > 10:47:24 unbound: [3763:0] info: validation failure ns4.cctld.co. > AAAA > IN > 10:47:24 unbound: [3763:0] info: validation failure ns3.cctld.co. > AAAA > IN > 10:47:24 unbound: [3763:0] info: validation failure ns5.cctld.co. > AAAA > IN > 10:47:24 unbound: [3763:0] info: validation failure ns1.cctld.co. > AAAA > IN > 10:47:24 unbound: [3763:0] info: validation failure ns6.cctld.co. > AAAA > IN > 10:47:03 unbound: [3763:0] info: validation failure > ns02.fedoraproject.org. AAAA IN > 10:47:01 unbound: [3763:0] info: validation failure > ns05.fedoraproject.org. AAAA IN > 10:46:51 unbound: [3763:1] info: validation failure > ns3.cloudflare.com. AAAA IN > 10:46:51 unbound: [3763:1] info: validation failure > ns6.cloudflare.com. AAAA IN > 10:46:50 unbound: [3763:1] info: validation failure > ns7.cloudflare.com. AAAA IN > 10:46:49 unbound: [3763:0] info: validation failure > fedoraproject.org. > AAAA IN > 10:46:38 unbound: [3763:1] info: validation failure > ns5.cloudflare.com. AAAA IN > 10:46:38 unbound: [3763:1] info: validation failure > ns4.cloudflare.com. AAAA IN > 10:44:08 unbound: [3763:0] info: validation failure www.facebook.com > .l > ocaldomain. AAAA IN > 10:43:28 unbound: [3763:0] info: start of service (unbound 1.6.1). > 10:43:28 unbound: [3763:0] notice: init module 1: iterator > 10:43:28 unbound: [3763:0] notice: init module 0: validator > 10:43:26 unbound: [1407:0] info: 32.000000 64.000000 4 > 10:43:26 unbound: [1407:0] info: 16.000000 32.000000 5 > 10:43:26 unbound: [1407:0] info: 8.000000 16.000000 4 > 10:43:26 unbound: [1407:0] info: 4.000000 8.000000 2 > 10:43:26 unbound: [1407:0] info: 2.000000 4.000000 3 > 10:43:26 unbound: [1407:0] info: 0.524288 1.000000 4 > 10:43:26 unbound: [1407:0] info: 0.262144 0.524288 1 > 10:43:26 unbound: [1407:0] info: 0.131072 0.262144 1 > 10:43:26 unbound: [1407:0] info: 0.004096 0.008192 2 > 10:43:26 unbound: [1407:0] info: 0.000000 0.000001 8 > 10:43:26 unbound: [1407:0] info: lower(secs) upper(secs) recursions > 10:43:26 unbound: [1407:0] info: [25%]=0.00512 median[50%]=2.66667 > [75%]=17.6 > 10:43:26 unbound: [1407:0] info: histogram of recursion processing > times > 10:43:26 unbound: [1407:0] info: average recursion processing time > 10.613770 sec > 10:43:26 unbound: [1407:0] info: server stats for thread 1: > requestlist max 40 avg 6.79412 exceeded 0 jostled 0 > 10:43:26 unbound: [1407:0] info: server stats for thread 1: 76 > queries, 42 answers from cache, 34 recursions, 0 prefetch, 0 rejected > by ip ratelimiting > 10:43:26 unbound: [1407:0] info: 32.000000 64.000000 4 > 10:43:26 unbound: [1407:0] info: 16.000000 32.000000 9 > 10:43:26 unbound: [1407:0] info: 8.000000 16.000000 6 > 10:43:26 unbound: [1407:0] info: 4.000000 8.000000 6 > 10:43:26 unbound: [1407:0] info: 2.000000 4.000000 5 > 10:43:26 unbound: [1407:0] info: 1.000000 2.000000 3 > 10:43:26 unbound: [1407:0] info: 0.524288 1.000000 5 > 10:43:26 unbound: [1407:0] info: 0.262144 0.524288 1 > 10:43:26 unbound: [1407:0] info: 0.131072 0.262144 6 > 10:43:26 unbound: [1407:0] info: 0.016384 0.032768 1 > 10:43:26 unbound: [1407:0] info: 0.000000 0.000001 9 > 10:43:26 unbound: [1407:0] info: lower(secs) upper(secs) recursions > 10:43:26 unbound: [1407:0] info: [25%]=0.212992 median[50%]=3 > [75%]=15 > 10:43:26 unbound: [1407:0] info: histogram of recursion processing > times > 10:43:26 unbound: [1407:0] info: average recursion processing time > 8.866802 sec > 10:43:26 unbound: [1407:0] info: server stats for thread 0: > requestlist max 63 avg 17.7679 exceeded 0 jostled 0 > 10:43:26 unbound: [1407:0] info: server stats for thread 0: 83 > queries, 28 answers from cache, 55 recursions, 1 prefetch, 0 rejected > by ip ratelimiting > 10:43:26 unbound: [1407:0] info: service stopped (unbound 1.6.1). > 10:42:07 unbound: [1407:0] info: validation failure sfba.sns- > pb.isc.org. AAAA IN > 10:42:03 unbound: [1407:0] info: validation failure adns3.upenn.edu. > AAAA IN > 10:42:02 unbound: [1407:0] info: validation failure ord.sns- > pb.isc.org. AAAA IN > 10:42:01 unbound: [1407:0] info: validation failure ams.sns- > pb.isc.org. AAAA IN > 10:41:57 unbound: [1407:0] info: validation failure adns2.upenn.edu. > AAAA IN > 10:41:51 unbound: [1407:0] info: validation failure adns1.upenn.edu. > AAAA IN > 10:41:42 unbound: [1407:0] info: validation failure > ns05.fedoraproject.org. AAAA IN > 10:41:42 unbound: [1407:0] info: validation failure > ns02.fedoraproject.org. AAAA IN > 10:41:41 unbound: [1407:1] info: validation failure > ns05.fedoraproject.org. AAAA IN > 10:41:41 unbound: [1407:1] info: validation failure > ns02.fedoraproject.org. AAAA IN > 10:41:31 unbound: [1407:0] info: validation failure > fedoraproject.org. > AAAA IN > 10:41:23 unbound: [1407:1] info: validation failure > fedoraproject.org. > AAAA IN > 10:41:19 unbound: [1407:0] info: validation failure ns3.pch.net. > AAAA > IN > 10:41:19 unbound: [1407:0] info: validation failure anyns.pch.net. > AAAA IN > 10:41:18 unbound: [1407:0] info: validation failure ns2.pch.net. > AAAA > IN > 10:41:04 unbound: [1407:0] info: validation failure > ns5.cloudflare.net. AAAA IN > 10:41:04 unbound: [1407:0] info: validation failure > ns4.cloudflare.net. AAAA IN > 10:41:03 unbound: [1407:0] info: validation failure > ns2.cloudflare.net. AAAA IN > 10:41:03 unbound: [1407:0] info: validation failure > ns3.cloudflare.net. AAAA IN > 10:41:02 unbound: [1407:0] info: validation failure > ns1.cloudflare.net. AAAA IN > 10:40:55 unbound: [1407:1] info: validation failure > fireinfo.ipfire.org. AAAA IN > 10:40:54 unbound: [1407:1] info: validation failure > ns2.lightningwirelabs.com. AAAA IN > 10:40:54 unbound: [1407:1] info: validation failure > ns1.lightningwirelabs.com. AAAA IN > 10:40:54 unbound: [1407:1] info: validation failure > ns3.lightningwirelabs.com. AAAA IN > 10:40:27 unbound: [1407:0] info: validation failure > fireinfo.ipfire.org.localdomain. AAAA IN > 10:39:36 unbound: [1407:0] info: start of service (unbound 1.6.1). > 10:39:36 unbound: [1407:0] notice: init module 1: iterator > 10:39:36 unbound: [1407:0] notice: init module 0: validator > ---------------------------------------------------------- > > > Hope this helps. Used ISP (HughesNet) DNS servers as provided > through > DHCP on RED. Ping of 8.8.4.4 was good during the test window. > > Best, > Paul
On Sun, 2017-04-02 at 19:03 +0100, Michael Tremer wrote: > Hi, > > this does help, yes. > > You are falling back to recursor mode which is not really what should > happen. That means the test does not indicate correctly what I hoped > it > would do. > > Are those name servers your ISP is forcing you to use publicly > available? If so I could test on my own. > > Best, > -Michael > > On Sun, 2017-04-02 at 11:37 -0500, Paul Simmons wrote: > > On Fri, 2017-03-31 at 17:53 +0100, Michael Tremer wrote: > > > No, I don't think that any of the changes after that commit would > > > have helped. > > > > > > What I need to have is a test that allows me to identify if these > > > name servers > > > are able to pass on the public key of the root zone. > > > > > > If so, then DNSSEC would work fine in recursor mode. > > > > > > If not, unbound should now disable DNSSEC validation. > > > > > > What is the output of "/etc/init.d/unbound restart" on that > > > system? > > > > > > -Michael > > > > > > On Thu, 2017-03-30 at 13:21 -0500, Paul Simmons wrote: > > > > On Thu, 2017-03-30 at 17:51 +0100, Michael Tremer wrote: > > > > > > > > > > Hey Paul, > > > > > > > > > > I really don't want you to switch away from IPFire since > > > > > there > > > > > is > > > > > no > > > > > need to. We > > > > > will get this fixed. > > > > > > > > > > And although this is a corner case I am willing to work on > > > > > this. > > > > > However I > > > > > cannot test. > > > > > > > > > > So just to get me up to date again: Did you apply the changes > > > > > from > > > > > Core Update > > > > > 110? Did that work or not? > > > > > > > > > > -Michael > > > > > > > > > > On Sat, 2017-03-25 at 10:20 -0500, Paul Simmons wrote: > > > > > > > > > > > > On Wed, 2017-03-08 at 10:19 -0600, Paul Simmons wrote: > > > > > > > > > > > > > > On Wed, 2017-03-08 at 12:09 +0000, Michael Tremer wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hmm... > > > > > > > > > > > > > > > > That's interesting that only AAAA records fail. No idea > > > > > > > > why > > > > > > > > the > > > > > > > > system is > > > > > > > > resolving those any ways, but hey... > > > > > > > > > > > > > > > > So when you do > > > > > > > > > > > > > > > > dig @198.41.0.4 a.root-servers.net AAAA +dnssec > > > > > > > > > > > > > > > > does that work? > > > > > > > > > > > > > > > > What does > > > > > > > > > > > > > > > > dig @8.8.8.8 +sigchase +dnssec www.ipfire.org > > > > > > > > > > > > > > > > do? > > > > > > > > > > > > > > > > -Michael > > > > > > > > > > > > > > > > ---->% massive snippage here %<---- > > > > > > > > > > > > > > Sorry for the delay. I have to chase everyone off the > > > > > > > network > > > > > > > and > > > > > > > reboot with another disk (development image) to test, > > > > > > > then > > > > > > > have > > > > > > > to > > > > > > > reboot with Core105 and DNSSEC disabled to resume email > > > > > > > :). > > > > > > > > > > > > > > Here are the results: > > > > > > > > > > > > > > # dig @198.41.0.4 a.root-servers.net AAAA +dnssec > > > > > > > > > > > > > > ; <<>> DiG 9.11.0-P3 <<>> @198.41.0.4 a.root-servers.net > > > > > > > AAAA > > > > > > > +dnssec > > > > > > > ; (1 server found) > > > > > > > ;; global options: +cmd > > > > > > > ;; Got answer: > > > > > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65258 > > > > > > > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, > > > > > > > ADDITIONAL: 0 > > > > > > > ;; WARNING: Message has 23 extra bytes at end > > > > > > > > > > > > > > ;; QUESTION SECTION: > > > > > > > ;a.root-servers.net. IN AAAA > > > > > > > > > > > > > > ;; Query time: 1 msec > > > > > > > ;; SERVER: 198.41.0.4#53(198.41.0.4) > > > > > > > ;; WHEN: Wed Mar 08 09:56:11 CST 2017 > > > > > > > ;; MSG SIZE rcvd: 59 > > > > > > > > > > > > > > # dig @8.8.8.8 +sigchase +dnssec www.ipfire.org > > > > > > > ;; Warning: Message parser reports malformed message > > > > > > > packet. > > > > > > > ;; NO ANSWERS: no more > > > > > > > We want to prove the non-existence of a type of rdata 1 > > > > > > > or > > > > > > > of > > > > > > > the > > > > > > > zone: > > > > > > > ;; nothing in authority section : impossible to validate > > > > > > > the > > > > > > > non- > > > > > > > existence : > > > > > > > FAILED > > > > > > > > > > > > > > ;; Impossible to verify the Non-existence, the NSEC RRset > > > > > > > can't > > > > > > > be > > > > > > > validated: FAILED > > > > > > > > > > > > > > Thank you, > > > > > > > Paul > > > > > > > > > > > > Additional information: > > > > > > > > > > > > On Core105, I have an override in /etc/sysconfig/dnsmasq: > > > > > > ENABLE_DNSSEC=0 > > > > > > > > > > > > If I remove this, DNS resolution outside of my private > > > > > > network > > > > > > fails. > > > > > > > > > > > > I've had a long conversation with HughesNet Community > > > > > > Support > > > > > > (such > > > > > > as it is), > > > > > > to no avail. > > > > > > > > > > > > Hughes has no plans to support DNSSEC in the near future, > > > > > > and > > > > > > there's no way > > > > > > to prevent the modem (HN9000) from caching / spoofing / > > > > > > mangling > > > > > > DNS traffic. > > > > > > > > > > > > There are no other providers available - no DSL, no cable, > > > > > > no > > > > > > fiber, no > > > > > > wireless, no cellular, no anything. If I had the funds, I'd > > > > > > create > > > > > > my own NLOS > > > > > > WISP and make a tidy profit out here "in the sticks". > > > > > > Goodness > > > > > > knows, I'd like > > > > > > a reprieve from high cost, data caps, high latency, rain > > > > > > fade, > > > > > > and > > > > > > miserable > > > > > > throughput. > > > > > > > > > > > > Please, is there any way to fall back to insecure DNS with > > > > > > IPFire's > > > > > > unbound > > > > > > configuration? I realize my situation is a "corner case", > > > > > > but > > > > > > I > > > > > > like IPFire, > > > > > > have a lot of time and effort invested, and am loath to > > > > > > switch > > > > > > to a > > > > > > different > > > > > > firewall. > > > > > > > > > > > > Best regards, > > > > > > Paul > > > > > > > > Hey Michael. Sorry to be a pain. Thank you for your help. > > > > > > > > I tested with commit c016773b9816ad9be4ffc8643c30457e87c094e3 > > > > and > > > > had no luck. > > > > > > > > I tried using both the ISP provided DNS and known "good" > > > > validating > > > > servers. > > > > > > > > Shall I rebuild the test image with a later commit? > > > > > > > > Paul > > > > Finally got a test window... made the best of it. > > > > ---------------------------------------------------------- > > Output from unbound restart: > > > > # /etc/init.d/unbound restart > > Stopping Unbound DNS > > Proxy... [ OK ] > > Starting Unbound DNS > > Proxy... [ OK ] > > Ignoring broken upstream name server(s): 67.142.173.10 > > 67.142.173.11 [ WARN ] > > Falling back to recursor > > mode [ WARN ] > > ---------------------------------------------------------- > > A couple of simple resolution tests: > > > > # nslookup www.google.com > > Server: 127.0.0.1 > > Address: 127.0.0.1#53 > > > > ** server can't find www.google.com: SERVFAIL > > > > # host www.google.com > > Host www.google.com not found: 2(SERVFAIL) > > ---------------------------------------------------------- > > Export of unbound log (reverse chronological): > > > > IPFire diagnostics > > Section: unbound > > Date: April 02, 2017 > > > > 10:48:30 unbound: [3763:1] info: validation failure self- > > repair.mozilla.org. AAAA IN > > 10:47:31 unbound: [3763:0] info: validation failure ns2.cctld.co. > > AAAA > > IN > > 10:47:28 unbound: [3763:1] info: validation failure c.ns.nic.cz. > > AAAA > > IN > > 10:47:28 unbound: [3763:1] info: validation failure a.ns.nic.cz. > > AAAA > > IN > > 10:47:28 unbound: [3763:1] info: validation failure b.ns.nic.cz. > > AAAA > > IN > > 10:47:28 unbound: [3763:1] info: validation failure d.ns.nic.cz. > > AAAA > > IN > > 10:47:24 unbound: [3763:0] info: validation failure ns4.cctld.co. > > AAAA > > IN > > 10:47:24 unbound: [3763:0] info: validation failure ns3.cctld.co. > > AAAA > > IN > > 10:47:24 unbound: [3763:0] info: validation failure ns5.cctld.co. > > AAAA > > IN > > 10:47:24 unbound: [3763:0] info: validation failure ns1.cctld.co. > > AAAA > > IN > > 10:47:24 unbound: [3763:0] info: validation failure ns6.cctld.co. > > AAAA > > IN > > 10:47:03 unbound: [3763:0] info: validation failure > > ns02.fedoraproject.org. AAAA IN > > 10:47:01 unbound: [3763:0] info: validation failure > > ns05.fedoraproject.org. AAAA IN > > 10:46:51 unbound: [3763:1] info: validation failure > > ns3.cloudflare.com. AAAA IN > > 10:46:51 unbound: [3763:1] info: validation failure > > ns6.cloudflare.com. AAAA IN > > 10:46:50 unbound: [3763:1] info: validation failure > > ns7.cloudflare.com. AAAA IN > > 10:46:49 unbound: [3763:0] info: validation failure > > fedoraproject.org. > > AAAA IN > > 10:46:38 unbound: [3763:1] info: validation failure > > ns5.cloudflare.com. AAAA IN > > 10:46:38 unbound: [3763:1] info: validation failure > > ns4.cloudflare.com. AAAA IN > > 10:44:08 unbound: [3763:0] info: validation failure www.facebook.c > > om > > .l > > ocaldomain. AAAA IN > > 10:43:28 unbound: [3763:0] info: start of service (unbound 1.6.1). > > 10:43:28 unbound: [3763:0] notice: init module 1: iterator > > 10:43:28 unbound: [3763:0] notice: init module 0: validator > > 10:43:26 unbound: [1407:0] info: 32.000000 64.000000 4 > > 10:43:26 unbound: [1407:0] info: 16.000000 32.000000 5 > > 10:43:26 unbound: [1407:0] info: 8.000000 16.000000 4 > > 10:43:26 unbound: [1407:0] info: 4.000000 8.000000 2 > > 10:43:26 unbound: [1407:0] info: 2.000000 4.000000 3 > > 10:43:26 unbound: [1407:0] info: 0.524288 1.000000 4 > > 10:43:26 unbound: [1407:0] info: 0.262144 0.524288 1 > > 10:43:26 unbound: [1407:0] info: 0.131072 0.262144 1 > > 10:43:26 unbound: [1407:0] info: 0.004096 0.008192 2 > > 10:43:26 unbound: [1407:0] info: 0.000000 0.000001 8 > > 10:43:26 unbound: [1407:0] info: lower(secs) upper(secs) > > recursions > > 10:43:26 unbound: [1407:0] info: [25%]=0.00512 median[50%]=2.66667 > > [75%]=17.6 > > 10:43:26 unbound: [1407:0] info: histogram of recursion processing > > times > > 10:43:26 unbound: [1407:0] info: average recursion processing time > > 10.613770 sec > > 10:43:26 unbound: [1407:0] info: server stats for thread 1: > > requestlist max 40 avg 6.79412 exceeded 0 jostled 0 > > 10:43:26 unbound: [1407:0] info: server stats for thread 1: 76 > > queries, 42 answers from cache, 34 recursions, 0 prefetch, 0 > > rejected > > by ip ratelimiting > > 10:43:26 unbound: [1407:0] info: 32.000000 64.000000 4 > > 10:43:26 unbound: [1407:0] info: 16.000000 32.000000 9 > > 10:43:26 unbound: [1407:0] info: 8.000000 16.000000 6 > > 10:43:26 unbound: [1407:0] info: 4.000000 8.000000 6 > > 10:43:26 unbound: [1407:0] info: 2.000000 4.000000 5 > > 10:43:26 unbound: [1407:0] info: 1.000000 2.000000 3 > > 10:43:26 unbound: [1407:0] info: 0.524288 1.000000 5 > > 10:43:26 unbound: [1407:0] info: 0.262144 0.524288 1 > > 10:43:26 unbound: [1407:0] info: 0.131072 0.262144 6 > > 10:43:26 unbound: [1407:0] info: 0.016384 0.032768 1 > > 10:43:26 unbound: [1407:0] info: 0.000000 0.000001 9 > > 10:43:26 unbound: [1407:0] info: lower(secs) upper(secs) > > recursions > > 10:43:26 unbound: [1407:0] info: [25%]=0.212992 median[50%]=3 > > [75%]=15 > > 10:43:26 unbound: [1407:0] info: histogram of recursion processing > > times > > 10:43:26 unbound: [1407:0] info: average recursion processing time > > 8.866802 sec > > 10:43:26 unbound: [1407:0] info: server stats for thread 0: > > requestlist max 63 avg 17.7679 exceeded 0 jostled 0 > > 10:43:26 unbound: [1407:0] info: server stats for thread 0: 83 > > queries, 28 answers from cache, 55 recursions, 1 prefetch, 0 > > rejected > > by ip ratelimiting > > 10:43:26 unbound: [1407:0] info: service stopped (unbound 1.6.1). > > 10:42:07 unbound: [1407:0] info: validation failure sfba.sns- > > pb.isc.org. AAAA IN > > 10:42:03 unbound: [1407:0] info: validation failure > > adns3.upenn.edu. > > AAAA IN > > 10:42:02 unbound: [1407:0] info: validation failure ord.sns- > > pb.isc.org. AAAA IN > > 10:42:01 unbound: [1407:0] info: validation failure ams.sns- > > pb.isc.org. AAAA IN > > 10:41:57 unbound: [1407:0] info: validation failure > > adns2.upenn.edu. > > AAAA IN > > 10:41:51 unbound: [1407:0] info: validation failure > > adns1.upenn.edu. > > AAAA IN > > 10:41:42 unbound: [1407:0] info: validation failure > > ns05.fedoraproject.org. AAAA IN > > 10:41:42 unbound: [1407:0] info: validation failure > > ns02.fedoraproject.org. AAAA IN > > 10:41:41 unbound: [1407:1] info: validation failure > > ns05.fedoraproject.org. AAAA IN > > 10:41:41 unbound: [1407:1] info: validation failure > > ns02.fedoraproject.org. AAAA IN > > 10:41:31 unbound: [1407:0] info: validation failure > > fedoraproject.org. > > AAAA IN > > 10:41:23 unbound: [1407:1] info: validation failure > > fedoraproject.org. > > AAAA IN > > 10:41:19 unbound: [1407:0] info: validation failure ns3.pch.net. > > AAAA > > IN > > 10:41:19 unbound: [1407:0] info: validation failure anyns.pch.net. > > AAAA IN > > 10:41:18 unbound: [1407:0] info: validation failure ns2.pch.net. > > AAAA > > IN > > 10:41:04 unbound: [1407:0] info: validation failure > > ns5.cloudflare.net. AAAA IN > > 10:41:04 unbound: [1407:0] info: validation failure > > ns4.cloudflare.net. AAAA IN > > 10:41:03 unbound: [1407:0] info: validation failure > > ns2.cloudflare.net. AAAA IN > > 10:41:03 unbound: [1407:0] info: validation failure > > ns3.cloudflare.net. AAAA IN > > 10:41:02 unbound: [1407:0] info: validation failure > > ns1.cloudflare.net. AAAA IN > > 10:40:55 unbound: [1407:1] info: validation failure > > fireinfo.ipfire.org. AAAA IN > > 10:40:54 unbound: [1407:1] info: validation failure > > ns2.lightningwirelabs.com. AAAA IN > > 10:40:54 unbound: [1407:1] info: validation failure > > ns1.lightningwirelabs.com. AAAA IN > > 10:40:54 unbound: [1407:1] info: validation failure > > ns3.lightningwirelabs.com. AAAA IN > > 10:40:27 unbound: [1407:0] info: validation failure > > fireinfo.ipfire.org.localdomain. AAAA IN > > 10:39:36 unbound: [1407:0] info: start of service (unbound 1.6.1). > > 10:39:36 unbound: [1407:0] notice: init module 1: iterator > > 10:39:36 unbound: [1407:0] notice: init module 0: validator > > ---------------------------------------------------------- > > > > > > Hope this helps. Used ISP (HughesNet) DNS servers as provided > > through > > DHCP on RED. Ping of 8.8.4.4 was good during the test window. > > > > Best, > > Paul > Thanks for the feedback, Michael. I can't say for sure that the servers are available to you... I'd recommend testing them. If you have a suite of tests you'd like me to perform, I'll "schedule" another window. (As in: "Oops, the 'net is down for a few minutes... sorry... I have three of my best men working on it right now. Their names are Larry, Moe, and Curly." :-) (Reiterating) The ISP supplied (proprietary) modem caches DNS, and that setting can't be changed (I've b*tched about it, but they don't care). Don't know if that impacts anything. Thanks again for your efforts! Paul