[Swan-dev] dnsec and namespaces tests

Paul Wouters paul at nohats.ca
Mon Feb 24 14:03:38 UTC 2020

On Sat, 22 Feb 2020, Antony Antony wrote:

> the issues raced irc:
> cagney>
> https://testing.libreswan.org/v3.30-92-g453384a8eb-master/ikev2-55-ipseckey-06/OUTPUT/nic.console.diff
> seems to be something wrong with ipseckey

I thought this the same issue as with slow-retransmits. The DNS query
won't wait for multiple seconds, so we are seeing a time out because a
VM or something froze for a number of seconds?

> Also I would like to clarify the follow up comment.
> LetoTo> but antony has been rewriting the nsd config to answer on a
> LetoTo> different port, so libreswan talks directly to nsd.
> The ipseckey* and dnsoe* tests have been running with nsd! Atlest the tests
> I know.  Now I am working to make it possible to choose between nsd or
> unbound.  While at it add namespace support.

They were running with unbound before you short-circuited it to nsd :)
There was a delay if unbound did not have internet access, although I
did not have those issues at the time.

> starting unbound offline with additional root anchors is tricky. Tuomo
> mentioned we may need more config.

When we generate our new dnssec keys and sign it, we can also AXFR the
root zone and load that into the unbound.conf DNS server config we use
with the "local root" option.

> It was unstable and takes long to startup. I think now it is fixed, LetoTo
> commited some changes  a while ago. It was still unstable.

Yes, it seemed your test setup still ran into issue at the time.

> My plan is when it is one
> swan-prep --dnssec will use nsd on 5353 + unbound port 53

Yes that should be the end goal.

> swan-prep --nsd will use only nsd on 53. I know there are strong opinions
> against this idea. I would recommend keep those for another thred.

Well, it is the core of the issue why this conflict of opinion exists on
using nsd instead of unbound. We are sending queries to authoritative
servers with recursion bits enabled - it is the wrong setup. We need to
use a recursive nameserver to properly emulate real deployments.

> argument this is the fastest and stable to run dnssec and it just works.
> We have been using this.

But how well does it emulate the real world scenario now? I know it
works and that is why I was reluctantly okay with it and let it go the
way it is now without further looking into moving it back to unbound

> However short not about dnssec tests and namespaces, I am not yet committing
> console output from namespaces as reference outputs. I mean sometimes I do
> by accident, then I try go back to use testing.libreswan.org produced output
> as reference. There are a few, minor and annoying, differences, between kvm
> and namespace outputs. It is a topic of its own:) I feel it is time to start
> thread on differences between namespace run and kvm runs.

I have spend a LOT of time sanitizing away most differences between
namespaces and KVM. The ones that are there should at this point be
properly fixed, so either can be used to submit results. In those cases
where I haven't fixed it yet, I've ensured the kvm output is used so
that testing.libreswan.org will pass the test.


More information about the Swan-dev mailing list