search

letsencrypt / challtestsrv

Small TEST-ONLY server for mock DNS & responding to HTTP-01, DNS-01, and TLS-ALPN-01 ACME challenges.
Mozilla Public License 2.0
19 stars 21 forks source link

dns: add support for mocking SERVFAIL DNS responses. #10

Closed cpu closed 5 years ago

cpu commented 5 years ago

Supporting a way to return SERVFAIL for queries to the mock DNS server will make testing certain integration test scenarios in Boulder easier. We frequently see nameservers that return this rcode in the wild and should be able to test for it. E.g. an integration test for validating a name that returns SERVFAIL for A lookups, or one that returns SERVFAIL for a CAA revalidation.

cpu commented 5 years ago

what do you think of making this more general and allowing tests to set an arbitrary rcode?

Hmmm. I don't know that there are other rcodes we'd be likely to use enough to justify the change. Maybe NOTIMPL?

cpu commented 5 years ago

It will also introduce some complexity in the Pebble side for the JSON API related to mapping rcode names in the request to the integers used by the dns package.

rolandshoemaker commented 5 years ago

I think we're unlikely to really need to test anything coming form the resolver other than SERVFAIL, but also since we have no example test cases that use other RCODEs for now it seems like we should just wait and if we come up with some later we can add the functionality then.

jsha commented 5 years ago

In particular I was thinking of NXDOMAIN, which does seem like something we'd like to test. I agree that the others are probably not needed.

cpu commented 5 years ago

In particular I was thinking of NXDOMAIN, which does seem like something we'd like to test.

I think unless we're going to write a test based on NXDOMAIN responses in the next sprint or two we should merge as-is. I'm a yak or two deep on a test that will be served by just a SERVFAIL mock.