Problems resolving some sites

FRLinux · November 26, 2010, 12:29pm

Hello,

I am trying to understand a problem on resolving a small fraction of
sites from unbound. The server is a Debian Squeeze running behind a
Firewall. 53/tcp, icmp and full udp are open on the box to the
outside. Unbound is stock Debian (1.4.6-1). When i try to resolve this
host for instance, it fails: ice.grid.kiae.ru whereas bind works.

Here is my configuration, I would be grateful if someone could point
me to the problem:

server:
  verbosity: 1
  num-threads: 2
  interface: 0.0.0.0
  interface: ::0
  interface-automatic: yes
        access-control: 127.0.0.0/8 allow
        access-control: ::1 allow
        access-control: ::ffff:127.0.0.1 allow
        access-control: xxxxxxx allow (where xxxx is our public range)
        access-control: 0.0.0.0/0 refuse
        access-control: ::0/0 refuse
  chroot: ""
  username: "unbound"
  directory: "/etc/unbound"
  logfile: "/var/log/unbound/unbound.log"
  pidfile: "/var/run/unbound.pid"
  root-hints: "/etc/unbound/named.cache"
  harden-glue: yes
  harden-dnssec-stripped: yes
  harden-referral-path: yes
  use-caps-for-id: yes
  unwanted-reply-threshold: 10000000
  dlv-anchor-file: "/etc/unbound/dlv.isc.org.key"
  val-clean-additional: yes
  val-permissive-mode: no
python:

remote-control:
  control-enable: yes
  control-interface: 127.0.0.1
  control-interface: ::1
  control-port: 953
  server-key-file: "/etc/unbound/unbound_server.key"
  server-cert-file: "/etc/unbound/unbound_server.pem"
  control-key-file: "/etc/unbound/unbound_control.key"
  control-cert-file: "/etc/unbound/unbound_control.pem"

This is a paste of the queries using first the unbound server which
fails, then the bind one which works:

~ dig any ice.grid.kiae.ru @xxxx

; <<>> DiG 9.7.0-P1 <<>> any ice.grid.kiae.ru @unbound-server
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38830
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ice.grid.kiae.ru. IN ANY

;; Query time: 625 msec
;; SERVER: xxxxx#53(xxxx)
;; WHEN: Fri Nov 26 12:26:30 2010
;; MSG SIZE rcvd: 34

~ dig any ice.grid.kiae.ru @xxxxx

; <<>> DiG 9.7.0-P1 <<>> any ice.grid.kiae.ru @bind-server
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14537
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1

;; QUESTION SECTION:
;ice.grid.kiae.ru. IN ANY

;; ANSWER SECTION:
ice.grid.kiae.ru. 1068 IN A 144.206.66.32

;; AUTHORITY SECTION:
grid.kiae.ru. 1068 IN NS ns.grid.kiae.ru.
grid.kiae.ru. 1068 IN NS ns.kiae.ru.
grid.kiae.ru. 1068 IN NS ns2.grid.kiae.ru.
grid.kiae.ru. 1068 IN NS ns1.grid.kiae.ru.

;; ADDITIONAL SECTION:
ns.kiae.ru. 639 IN A 144.206.14.14

;; Query time: 0 msec
;; SERVER:xxxxxx#53(xxxxx)
;; WHEN: Fri Nov 26 12:26:25 2010
;; MSG SIZE rcvd: 136

Thanks in advance,
Steph

user20 · November 26, 2010, 1:48pm

Zitat von FRLinux <frlinux@gmail.com>:

Hello,

I am trying to understand a problem on resolving a small fraction of
sites from unbound. The server is a Debian Squeeze running behind a
Firewall. 53/tcp, icmp and full udp are open on the box to the
outside. Unbound is stock Debian (1.4.6-1). When i try to resolve this
host for instance, it fails: ice.grid.kiae.ru whereas bind works.

Here is my configuration, I would be grateful if someone could point
me to the problem:

server:
  verbosity: 1
  num-threads: 2
  interface: 0.0.0.0
  interface: ::0
  interface-automatic: yes
        access-control: 127.0.0.0/8 allow
        access-control: ::1 allow
        access-control: ::ffff:127.0.0.1 allow
        access-control: xxxxxxx allow (where xxxx is our public range)
        access-control: 0.0.0.0/0 refuse
        access-control: ::0/0 refuse
  chroot: ""
  username: "unbound"
  directory: "/etc/unbound"
  logfile: "/var/log/unbound/unbound.log"
  pidfile: "/var/run/unbound.pid"
  root-hints: "/etc/unbound/named.cache"
  harden-glue: yes
  harden-dnssec-stripped: yes
  harden-referral-path: yes

This is a non default and labeled as experimental in the docu. It works fine here with the default (no), maybe try to set it back to the default.
You could also try "+cdflag" to see if the non-result is related to DNSSEC.

BTW: Why do you not use the "auto-trust-anchor-file" setting as the root-zone is now signed?

Regards

Andreas

FRLinux · November 26, 2010, 3:51pm

Hello,

This is a non default and labeled as experimental in the docu. It works fine
here with the default (no), maybe try to set it back to the default.
You could also try "+cdflag" to see if the non-result is related to DNSSEC.

Yes indeed, works when using this. When you say this is a non default,
which setting are you referring to?

BTW: Why do you not use the "auto-trust-anchor-file" setting as the
root-zone is now signed?

Because at the time we implemented the setup, it wasn't This is now done.

Thanks for the prompt response, appreciated!

Cheers,
Steph

user20 · November 26, 2010, 4:01pm

Zitat von FRLinux <frlinux@gmail.com>:

Hello,

This is a non default and labeled as experimental in the docu. It works fine
here with the default (no), maybe try to set it back to the default.
You could also try "+cdflag" to see if the non-result is related to DNSSEC.

Yes indeed, works when using this. When you say this is a non default,
which setting are you referring to?

harden-referral-path: yes (The default is no/off at least according to the docs). See http://www.unbound.net/documentation/unbound.conf.html

Regards

Andreas

FRLinux · November 26, 2010, 4:09pm

Thanks, i have set this one to no, but still fails on a normal query
but works if I add +cdflag. Am I missing anything else? (my
configuration is the one i pasted on the first mail, with the change
you asked for, to set harden-referral-path: no).

Thanks for your help,
Steph

user20 · November 26, 2010, 5:49pm

Zitat von FRLinux <frlinux@gmail.com>:

harden-referral-path: yes (The default is no/off at least according to the
docs). See http://www.unbound.net/documentation/unbound.conf.html

Thanks, i have set this one to no, but still fails on a normal query
but works if I add +cdflag. Am I missing anything else? (my
configuration is the one i pasted on the first mail, with the change
you asked for, to set harden-referral-path: no).

We use unbound 1.4.7 and it has no problem to resolv

; <<>> DiG 9.4.2-P2.1 <<>> +dnssec ice.grid.kiae.ru A
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62330
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;ice.grid.kiae.ru. IN A

;; ANSWER SECTION:
ice.grid.kiae.ru. 3584 IN A 144.206.66.32

;; AUTHORITY SECTION:
grid.kiae.ru. 3584 IN NS ns.kiae.ru.
grid.kiae.ru. 3584 IN NS ns2.grid.kiae.ru.
grid.kiae.ru. 3584 IN NS ns.grid.kiae.ru.
grid.kiae.ru. 3584 IN NS ns1.grid.kiae.ru.

;; ADDITIONAL SECTION:
ns.grid.kiae.ru. 3584 IN A 144.206.66.1
ns1.grid.kiae.ru. 3584 IN A 144.206.66.80
ns2.grid.kiae.ru. 3584 IN A 144.206.66.90

Fact is if it resolv with +cdflag (checking disable) there is something wrong with DNSSEC or someone is screwing the result records.

Regards

Andreas

Kevin_Chadwick · November 26, 2010, 8:05pm

DNSSEC does open you up to far easier DOS attacks (I'm not saying,
this case was intentional), Eliptic Curve Crypto may reduce that
potential as originally proposed by DNSCURVE, but dnssec does make it
very unlikely that your given bogus dns data.

With SSHs recent adoption of ECC keys, maybe reducing the scope of
this trade-off will happen sooner than I was expecting. Then again the
ssh community is far more adaptable/pro-active than the DNSSEC people,
even with all that money, or maybe that's part of the problem.

I am not happy but I'm still intending to turn on DNSSEC, but it does
require monitoring.

Here's a quote from one of the original OpenSSH authors that was put on
the OpenBSD list about ipv6 (not dnssec but I think it probably
applys), which I notice FRLinux should recall.

Wouter · November 27, 2010, 11:32am

Hi,