[Unbound-users] "Tunnel" dnssec through local forward-zone?

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Anders,

On 07/25/2011 06:40 PM, Anders Sundman wrote:
> Hello,
> 
> I'm running unbound locally on 127.0.0.1 and a DNS TCP proxy (ttdnsd) on
> 127.0.0.2. The setup is a simple forward-zone; I ask unbound and unbound
> asks ttdnsd:
> 
> forward-zone:
>   name: "."
>   forward-addr: 127.0.0.2
> 
> Now I'm trying to get dnssec working but I've run in to some problems.
> 
> The auto-trust-anchor-file (root.key in this case) has been successfully
> updated but:
> 
> $ dig com. SOA +dnssec @127.0.0.1
> 
> doesn't set the AD flags in the response. Instead I get the following in
> my logfile:
> 
> "validation failure <com. SOA IN>: key for validation com. is marked as
> invalid because of a previous validation failure <com. SOA IN>:
> signatures from unknown keys from 127.0.0.2 for DS com. while building
> chain of trust".
> 
> Querying ttdnsd with:
> 
> $ dig com. SOA +dnssec @127.0.0.2
> 
> Gives me a SOA and RRSIG record back (but no AD).
> 
> I'm guessing this is because ttdnsd doesn't support validating dnssec
> queries.

It need not support validation, but it has to support dnssec: pass
through RRSIGs and be able to fetch DNSSEC types, such as the DS record.
What does dig com. DS +dnssec @127.0.0.2 say?  I have the sneaky
suspicion that it does not properly fetch the DS record from the parent
servers on that zonecut, but provides the data from the child-side of
that zonecut (there is then no DS record there and it is all signed with
the wrong keys).

> Since I trust the local instance of ttdnsd - is there any way to "skip"
> that part of the validation chain and transparently "tunnel" through it?

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOLZRvAAoJEJ9vHC1+BF+NKREQAKhzY4dvYc+WYORrehqDU6lo
RDC8np0jMzHWltyBSvojxftGf49So4TNBibSRN2Fs42nZs7Hg4U9CV/0y1imHfrU
HPeVobdBy8KX68ejUBMOvfPudOa+0CgccOab7hCe6bmVMCTKevLXKpHyhwjxBEdx
PM9WiciOl3AU83DAgMD6MIy9D55wAM9NSrrC88ry4rpnV9Flu3zF9GDUJCHLB6b8
4ytLri1HUQJp+FK0l3uil++Sg/3FhXWw5pXkOVcMM6MYIDdJYQvCYT0RyD2MQOpM
bqOelepViIe+4kFJ3q4eQ5YBrXYnrGOH5pfD57MrsJ3U23/hxpGw4HNSLOmO0zKk
NCF0Rz0KaUuO10pMiSIIg8Yj7wi+4+b/DqygwUcvp97TQrALvWjlAwdlMky5PZIh
4u+yOFUhB2yl/1f8hyGArKaMvfaZ6svAiFaGeyiSVNP8bAtkstcdtrn6+Dw4wflj
skDqwEPj20yL9+vF+3TSz3YdC6KOGtTMe9t3Rght0AbgQmWST/5yYnTWmt8cXa8o
BasMmqyUxgFYVaIRryQhTlBb2jezJCRR9dqfmVKff3uRttp80YW5wa/sYjDgYUfQ
tvLNKmwu+cRpKRfDmbqZD70++BhfkidmatQOBA70n6Tvf/BCxUg7IW8lg0+dQvrU
XtLDoBidwg1mug2d3Nsm
=qZH2
-----END PGP SIGNATURE-----