Bug#699641: unbound: Returns SERVFAIL for every query if there was no internet access when started

2013-02-23 Thread Roger Lynn
On 02/02/13 20:07, Robert Edmonds wrote:
 Robert Edmonds wrote:
 Roger Lynn wrote:
  Every query returns SERVFAIL even after internet access appears and even 
  for
  queries which are forwarded to a local server. Unbound has to be restarted
  after internet access appears before it will work.
  
  This is a significant problem as if there is no internet access when 
  unbound
  is started then there is no DNS at all for the local network until internet
  access can be restored.
 
 i agree, that's definitely an issue.  it looks like there might have
 been some relevant fixes in unbound 1.4.19, do you think you could
 install unbound 1.4.19-1 from unstable and see if it behaves any better?
 i believe the dependencies are all the same, so you ought to be able to
 just pin the unbound packages from unstable.
 
 by the way, i believe you can set the domain-insecure option on your
 local domains in order to prevent DNSSEC failures from impacting the
 resolution of those domains.

I've tested this again this after adding 'domain-insecure: mydomain.co.uk'
to the configuration and upgrading to 1.4.17-3 from Testing.

I still get the following lines logged after a starting with no internet access:
Feb 22 18:25:34 alphonse unbound-anchor: /var/lib/unbound/root.key has content
Feb 22 18:25:34 alphonse unbound-anchor: fail: the anchor is NOT ok and
could not be fixed
Feb 22 18:25:35 alphonse unbound: [3910:0] notice: init module 0: validator
Feb 22 18:25:35 alphonse unbound: [3910:0] notice: init module 1: iterator
Feb 22 18:25:35 alphonse unbound: [3910:0] info: start of service (unbound
1.4.17).

But I no longer get the lines about failed to prime trust anchor -- could
not fetch DNSKEY rrset . DNSKEY IN. Resolution of local domains now works,
presumably because of the addition of the domain-insecure option.

When an internet connection is established then all DNS requests work as
normal, without having to restart unbound, so this problem seems to have
gone away. I don't understand why, as the changelog suggests an unrelated
minor update.

As I am no longer able to reproduce the original problem I am happy for this
bug to be closed, unless you think there is a need for further investigation.

Thank you for your time,

Roger


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#699641: unbound: Returns SERVFAIL for every query if there was no internet access when started

2013-02-02 Thread Roger Lynn
Package: unbound
Version: 1.4.17-2
Severity: normal

If there is no internet access when unbound is started (which there isn't on
my server immediately after a reboot), then unbound logs:
Feb  1 18:19:23 alphonse unbound-anchor: /var/lib/unbound/root.key has content
Feb  1 18:19:23 alphonse unbound-anchor: fail: the anchor is NOT ok and could 
not be fixed
Feb  1 18:19:23 alphonse unbound: [8860:0] notice: init module 0: validator
Feb  1 18:19:23 alphonse unbound: [8860:0] notice: init module 1: iterator
Feb  1 18:19:23 alphonse unbound: [8860:0] info: start of service (unbound 
1.4.17).
Feb  1 18:19:25 alphonse unbound: [8860:0] info: failed to prime trust anchor 
-- could not fetch DNSKEY rrset . DNSKEY IN
Feb  1 18:19:25 alphonse unbound: [8860:0] info: failed to prime trust anchor 
-- could not fetch DNSKEY rrset . DNSKEY IN
Feb  1 18:19:25 alphonse unbound: [8860:0] info: failed to prime trust anchor 
-- could not fetch DNSKEY rrset . DNSKEY IN
Feb  1 18:19:25 alphonse unbound: [8860:0] info: failed to prime trust anchor 
-- could not fetch DNSKEY rrset . DNSKEY IN
Feb  1 18:19:25 alphonse unbound: [8860:0] info: failed to prime trust anchor 
-- could not fetch DNSKEY rrset . DNSKEY IN
Feb  1 18:19:25 alphonse unbound: [8860:0] info: failed to prime trust anchor 
-- could not fetch DNSKEY rrset . DNSKEY IN

Every query returns SERVFAIL even after internet access appears and even for
queries which are forwarded to a local server. Unbound has to be restarted
after internet access appears before it will work.

This is a significant problem as if there is no internet access when unbound
is started then there is no DNS at all for the local network until internet
access can be restored.

Thanks,

Roger

-- System Information:
Debian Release: 7.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), 
(500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages unbound depends on:
ii  adduser 3.113+nmu3
ii  libc6   2.13-37
ii  libevent-2.0-5  2.0.19-stable-3
ii  libgcc1 1:4.7.2-5
ii  libldns11.6.13-1
ii  libpython2.72.7.3-6
ii  libssl1.0.0 1.0.1c-4
ii  openssl 1.0.1c-4
ii  unbound-anchor  1.4.17-2

unbound recommends no packages.

unbound suggests no packages.

-- Configuration Files:
/etc/unbound/unbound.conf changed:
server:
# The following line will configure unbound to perform cryptographic
# DNSSEC validation using the root trust anchor.
auto-trust-anchor-file: /var/lib/unbound/root.key
# verbosity number, 0 is least verbose. 1 is default.
verbosity: 1
# print statistics to the log (for every thread) every N seconds.
# Set to  or 0 to disable. Default is disabled.
statistics-interval: 86400
# print one line with time, IP, name, type, class for every query.
# log-queries: yes
# specify the interfaces to answer queries from by ip-address.
# The default is to listen to localhost (127.0.0.1 and ::1).
# specify 0.0.0.0 and ::0 to bind to all available interfaces.
# specify every interface[@port] on a new 'interface:' labelled line.
# The listen interfaces are not changed on reload, only on restart.
# interface: 2001:DB8::5
interface: 127.0.0.1
interface: 192.168.10.1
interface: 192.168.11.1
# specify the interfaces to send outgoing queries to authoritative
# server from by ip-address. If none, the default (all) interface
# is used. Specify every interface on a 'outgoing-interface:' line.
# outgoing-interface: 192.0.2.153
# outgoing-interface: 2001:DB8::5
# the time to live (TTL) value lower bound, in seconds. Default 0.
# If more than an hour could easily give trouble due to stale data.
cache-min-ttl: 60
# the time to live (TTL) value cap for RRsets and messages in the
# cache. Items are not cached for longer. In seconds.
cache-max-ttl: 172800
# control which clients are allowed to make (recursive) queries
# to this server. Specify classless netblocks with /size and action.
# By default everything is refused, except for localhost.
# Choose deny (drop message), refuse (polite error reply),
# allow (recursive ok), allow_snoop (recursive and nonrecursive ok)
access-control: 0.0.0.0/0 refuse
access-control: 127.0.0.0/8 allow
access-control: 192.168.10.0/23 allow
# Use 0x20-encoded random bits in the query to foil spoof attempts.
# This feature is an experimental implementation of draft dns-0x20.
# use-caps-for-id: no
# Enforce privacy of these addresses. Strips them away from answers. 
# It may cause DNSSEC validation to additionally mark 

Bug#699641: unbound: Returns SERVFAIL for every query if there was no internet access when started

2013-02-02 Thread Robert Edmonds
Robert Edmonds wrote:
 Roger Lynn wrote:
  Every query returns SERVFAIL even after internet access appears and even for
  queries which are forwarded to a local server. Unbound has to be restarted
  after internet access appears before it will work.
  
  This is a significant problem as if there is no internet access when unbound
  is started then there is no DNS at all for the local network until internet
  access can be restored.
 
 hi, roger:
 
 i agree, that's definitely an issue.  it looks like there might have
 been some relevant fixes in unbound 1.4.19, do you think you could
 install unbound 1.4.19-1 from unstable and see if it behaves any better?
 i believe the dependencies are all the same, so you ought to be able to
 just pin the unbound packages from unstable.

by the way, i believe you can set the domain-insecure option on your
local domains in order to prevent DNSSEC failures from impacting the
resolution of those domains.

-- 
Robert Edmonds
edmo...@debian.org


signature.asc
Description: Digital signature


Bug#699641: unbound: Returns SERVFAIL for every query if there was no internet access when started

2013-02-02 Thread Robert Edmonds
Roger Lynn wrote:
 Every query returns SERVFAIL even after internet access appears and even for
 queries which are forwarded to a local server. Unbound has to be restarted
 after internet access appears before it will work.
 
 This is a significant problem as if there is no internet access when unbound
 is started then there is no DNS at all for the local network until internet
 access can be restored.

hi, roger:

i agree, that's definitely an issue.  it looks like there might have
been some relevant fixes in unbound 1.4.19, do you think you could
install unbound 1.4.19-1 from unstable and see if it behaves any better?
i believe the dependencies are all the same, so you ought to be able to
just pin the unbound packages from unstable.

-- 
Robert Edmonds
edmo...@debian.org


signature.asc
Description: Digital signature


Bug#699641: unbound: Returns SERVFAIL for every query if there was no internet access when started

2013-02-02 Thread Roger Lynn
On 02/02/13 20:07, Robert Edmonds wrote:
 Robert Edmonds wrote:
 hi, roger:
 
 i agree, that's definitely an issue.  it looks like there might have
 been some relevant fixes in unbound 1.4.19, do you think you could
 install unbound 1.4.19-1 from unstable and see if it behaves any better?
 i believe the dependencies are all the same, so you ought to be able to
 just pin the unbound packages from unstable.
 
 by the way, i believe you can set the domain-insecure option on your
 local domains in order to prevent DNSSEC failures from impacting the
 resolution of those domains.

Thank you for the suggestions and the quick response. It may be a couple of
weeks before I have an opportunity to carry out further testing.

Roger


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org