Maik Zumstrull wrote: > On Wed, Jun 15, 2011 at 20:05, Robert Edmonds <edmo...@debian.org> wrote: > > it would be useful if you could get a packet trace of the failure. > > run something like: > > > > # tcpdump -s1518 -pni any -w dnsmasq-failure.pcap 'tcp port 53 or udp port > > 53' > > Sure, no problem. Attached. > > The trace leads me to assume that this might not be dnsmasq's fault, but this: > https://groups.google.com/d/topic/public-dns-discuss/9vXr9AJny4w/discussion > > On the other hand, forwarding from dnsmasq to a different server that > can return DS records doesn't fix it. So maybe it's double-broken: > Google doesn't deliver the DS records, but dnsmasq would trash them if > they did.
ok, i assume in this trace 192.168.47.197 is the address of your unbound
server, and 192.168.47.254 is the address of your dnsmasq server, and
127.0.0.1 is the address you are sending recursive queries to? and your
dnsmasq server is forwarding all queries to google's public DNS servers?
you're most likely running unbound in the default debian config which
enables DNSSEC validation. if you comment out the
"auto-trust-anchor-file" line in /etc/unbound/unbound.conf and restart
unbound, does it start working with your dnsmasq server? if so, this
would indicate that dnsmasq is broken.
you can see in the trace that unbound is (repeatedly) attempting to find
the DS record for com, and dnsmasq is responding with NXDOMAIN:
[179] [2011-06-15 18:16:08.802882000] [1:9 ISC dnsqr] [00000000] [] []
type: UDP_QUERY_RESPONSE
query_ip: 192.168.47.197
response_ip: 192.168.47.254
proto: UDP (17)
query_port: 20873
response_port: 53
id: 64244
qname: com.
qclass: IN (1)
qtype: DS (43)
rcode: NXDOMAIN (3)
delay: 0.002946
udp_checksum: CORRECT
query: [32 octets]
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 64244
;; flags: rd cd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;com. IN DS
;; ANSWER SECTION:
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
---
response: [21 octets]
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 64244
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;com. IN DS
;; ANSWER SECTION:
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
---
note that dnsmasq is responding with NXDOMAIN for "com". this is
hilariously wrong, as it means that dnsmasq claims that com does not
exist. but apart from that, unbound is unable to find the DS record for
com and thus DNSSEC validation fails.
i suspect that if you configure your dnsmasq server to forward to a
server that supports DNSSEC (e.g., level3's 4.2.2.2) that your unbound
forwarder may work, otherwise there are more bugs in dnsmasq.
--
Robert Edmonds
edmo...@debian.org
signature.asc
Description: Digital signature
