8.8.8.8

Papp_Tamás · June 26, 2010, 10:57pm

hi!

When I use google's public dns service as a forwarder with unbound, I cannot resolve a Round-Robin dns A record, for example pool.ntp.org, it answers servfail.

It's interesting, because for PTR it's working, for example to the IP 194.0.164.1 .

Can somebody confirm this?

I tested it on Ubuntu 10.04 x86_64 with 1.4.1 and Debian 5.0, with 1.4.5.

Thank you,

tamas

Leen_Besselink · June 27, 2010, 6:54am

hi!

Hi,

When I use google's public dns service as a forwarder with unbound, I cannot resolve a Round-Robin dns A record, for example pool.ntp.org, it answers servfail.

It's interesting, because for PTR it's working, for example to the IP 194.0.164.1 .

Can somebody confirm this?

I tested it on Ubuntu 10.04 x86_64 with 1.4.1 and Debian 5.0, with 1.4.5.

I tested it on Ubuntu 10.04 with 1.4.5 and a copy of doc/example.conf with just 2 few lines changed:

use-syslog: no

forward-zone:
name: "."
forward-addr: 8.8.8.8

And it resolves pool.ntp.org, europe.pool.ntp.org and 3.europe.pool.ntp.org on 127.0.0.1 just fine.

It is obviously cached, in the same order, for the TTL (270 seconds) and does a query after that time.

PS Maybe you should also add ?: 8.8.4.4

Papp_Tamás · June 27, 2010, 8:35am

Leen Besselink wrote, On 2010. 06. 27. 8:54:

I tested it on Ubuntu 10.04 with 1.4.5 and a copy of doc/example.conf with just 2 few lines changed:

use-syslog: no

forward-zone:
name: "."
forward-addr: 8.8.8.8

And it resolves pool.ntp.org, europe.pool.ntp.org and 3.europe.pool.ntp.org on 127.0.0.1 just fine.

Thank you.

I obviously should try this example.conf by myself:(

So I've juest tested it bit, and this option is the problem:

dlv-anchor-file: "/etc/unbound/dlv.isc.org.key"

The file was downloaded from the url suggested by the config file.

This is the whole config:

server:
    verbosity: 1
    num-threads: 2
    do-daemonize: yes
    access-control: 10.0.0.0/8 allow
    access-control: 127.0.0.0/8 allow
    chroot: ""
    directory: "/etc/unbound"
    use-syslog: yes
    root-hints: "/etc/unbound/named.cache"
    private-address: 10.0.0.0/8
    private-domain: "adverticum.local"
    unwanted-reply-threshold: 10000000
# dlv-anchor-file: "/etc/unbound/dlv.isc.org.key"
    do-ip6: no

python:

remote-control:
    control-enable: yes
    control-interface: 127.0.0.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"

stub-zone:
    name: "adverticum.local"
    stub-addr: 10.1.1.253
    stub-addr: 10.1.1.254
    stub-prime: no

stub-zone:
    name: "10.in-addr.arpa"
    stub-addr: 10.1.1.253
    stub-addr: 10.1.1.254
    stub-prime: no

forward-zone:
    name: "."
    forward-addr: 8.8.8.8
    forward-addr: 8.8.4.4

Is this a problem of the servers from google?

BTW, what does stub-prime exactly do? I'm afraid, it's not clear to me, what does "it performs NS set priming" mean?

Thank you,

tamas

Florian_Weimer · June 27, 2010, 2:23pm

* Papp Tamás:

So I've juest tested it bit, and this option is the problem:

dlv-anchor-file: "/etc/unbound/dlv.isc.org.key"

Google's resolvers do not support DNSSEC.

Out of curiosity, why do you configure as a forwarder?

PaulWouters · June 27, 2010, 3:52pm

So I've juest tested it bit, and this option is the problem:

dlv-anchor-file: "/etc/unbound/dlv.isc.org.key"

It seems google's DNS does not understand DLV records:

dig +norecur -t dlv isc.org.dlv.isc.org @8.8.8.8

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63442
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;isc.org.dlv.isc.org. IN DLV

;; Query time: 44 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Jun 27 11:48:35 2010
;; MSG SIZE rcvd: 37

So you cannot use google as forwarding while using DLV.

BTW, what does stub-prime exactly do? I'm afraid, it's not clear to me, what does "it performs NS set priming" mean?

It is used when you want to "override" the real NS set and do the lookup of
a zone via nameservers that are not in the "official zone".

For example, to reach the Canadian testbed for DNSSEC, which runs a signed
shadow tree for the entire .ca zone, you would use:

stub-zone:
   name:"ca."
   stub-prime:"no"
   stub-addr:192.228.22.190
   stub-addr:192.228.22.189

Now instead of using the NS records in the root zone that point to ca. unbound
will use these two addresses instead.

Paul

Florian_Weimer · June 27, 2010, 5:46pm

* Paul Wouters:

It seems google's DNS does not understand DLV records:

dig +norecur -t dlv isc.org.dlv.isc.org @8.8.8.8

Obviously, you need to drop the +norecur. DLV records are not the
problem. It's the lack of DNSSEC support.

PaulWouters · June 27, 2010, 7:11pm

Oops. left over from verifying dlv.isc.org directly.....

more coffee for me...

Paul

Papp_Tamás · June 28, 2010, 2:27pm

Paul Wouters wrote, On 2010. 06. 27. 17:52:

BTW, what does stub-prime exactly do? I'm afraid, it's not clear to me, what does "it performs NS set priming" mean?

It is used when you want to "override" the real NS set and do the lookup of
a zone via nameservers that are not in the "official zone".

For example, to reach the Canadian testbed for DNSSEC, which runs a signed
shadow tree for the entire .ca zone, you would use:

stub-zone:
    name:"ca."
    stub-prime:"no"
    stub-addr:192.228.22.190
    stub-addr:192.228.22.189

Now instead of using the NS records in the root zone that point to ca. unbound
will use these two addresses instead.

Yes, I understand this. I don't unserstand the difference between stub-prime:"no" and stub-prime:"yes".

Thanks,

tamas

Hauke_Lampe · June 28, 2010, 3:56pm

Google's resolvers do not support DNSSEC.

They seem to support DNSSEC partially, with no special handling of DS
records:

hauke@pope:~$ dig +dnssec org.dlv.isc.org dlv @8.8.8.8
[...]
;; ANSWER SECTION:
org.dlv.isc.org. 3265 IN DLV 21366 7 2 96EEB2FFD9B00CD4694E78278B5EFDAB0A80446567B69F634DA078F0 D90F01BA
org.dlv.isc.org. 3265 IN DLV 21366 7 1 E6C1716CFB6BDC84E84CE1AB5510DAC69173B5B2
org.dlv.isc.org. 3265 IN RRSIG DLV 5 4 3600 20100728141503 20100628141503 64263 dlv.isc.org. IXjBYCKFyVMMYWZqDNAf5J0QM4g31/p3piHjNgIty3qvGKTtkQOCdEh/ XhBqIPiuaB1VWnRg7GI1dbBxeKYPlpcCdIPOG98v+wAYU5+cuXJFGDqF X1TlP9Z4gxVCXvoMErJOvja3bkubE+cx8ezfnIz1j9oeRDg/SsMaNYL8 RZc=

but:

hauke@pope:~$ dig +dnssec ntp.org ds @8.8.8.8
[...]
;; AUTHORITY SECTION:
ntp.org. 3559 IN SOA maccarony.ntp.org. postmaster.www.ntp.org. 2010062400 21600 14400 60480 60480

So, while unbound successfully validates the DLV records, it can't
complete the chain without DS/NSEC.

Out of curiosity, why do you configure as a forwarder?

I for one run a validating unbound resolver on my "smartphone" and use
Google DNS (and others) as forwarders to reduce the number of queries
made over slow GPRS links

Until now, I didn't notice any problems with Google's resolvers and
DNSSEC, as unbound automatically retries the query with a different
forwarder.

Hauke.

PaulWouters · June 28, 2010, 4:08pm

It's to override the DNSSEC signed NS servers for the domain. With a shadow
tree, when signing a production zone and serving it on non-production name
servers, the NS records for the zone are wrong, and your dnssec signed NS
set would point to production instead of the shadow servers. This is the
override.

Paul

Hauke_Lampe · June 28, 2010, 4:50pm

The difference is indirection.

With "stub-prime: no", unbound uses the configured nameservers directly to resolve queries.

With "stub-prime: yes", unbound asks the nameservers for the zones's NS records (i.e. "priming") and then uses those records to resolve names within the zone.

Delegations would be followed in both cases.

HTH,
Hauke