skynetservices / skydns1

DNS for skynet or any other service discovery
MIT License
528 stars 54 forks source link

Is it reasonable to return ServerFailure when no answer? #20

Closed googollee closed 10 years ago

googollee commented 10 years ago

I try to let skydns work with normal dns server, so I configure resolve.conf like below:

127.0.0.1 // skydns server
192.168.10.1 // normal dns server

but if I lookup normal domain like google.com, skydns will return no error with empty answer, which block normal dns lookup.

As skydns can't host like normal dns, is it better to return Server Failure when answer is empty? Or return Failure when request is not suffix with skydns domain?

erikstmartin commented 10 years ago

I'm not sure semantically that this would be considered a Failure. SkyDNS just happens to have no knowledge of that zone.

We haven't setup SkyDNS to be a traditional DNS server that would work in your resolve.conf, The way we use it is that we have NS records setup on our normal DNS server for our anchor domain skydns.local for example. This allows us to use our normal DNS server and it propagates requests to SkyDNS for any *.skydns.local, as well as caches it locally, when the lowest TTL expires it fetches new results.

miekg commented 10 years ago

If a dns server has no knowledge of a zone, the best thing to return is SERVFAIL, or REFUSED. Usually this makes a resolver "do the right thing" and it will ask another nameserver.

Letting skydns forward the query to another nameserver and thereby making it a recursor could also be done. Should be fairly easy actually, but I'm not sure if you want go that route.

bketelsen commented 10 years ago

I was just debating this at work with our system admin. I'm not against having SkyDNS be a primary resolver, and just refusing records it doesn't know about (is this called forwarding?). I think we just need to think through the implications of this. Would it mean an extra hop on requests to non-SkyDNS lookups? Is that a big deal for performance? Most DNS records aren't going to have the low TTL's that we expect in SkyDNS, so the cost would be on the first lookup.

Right now it's set up for zone delegation, which works nicely as long as you can set up delegation in your primary DNS servers. For us, we have a primary domain (internal only) of company.net, and DNS delegation set up for sky.company.net so that any DNS lookups for *.sky.company.net are serviced by SkyDNS. The downside of this is that the lookups are cached by the primary dns server according to the lowest TTL of a response record after a query. Having SkyDNS be primary would mean that we'd always guarantee the freshest and most accurate records.

miekg commented 10 years ago

I don't think you want to make skydns a generic forwarder/recursor (it needs a cache too then), just yet. It complicated matters for no real benefit. Also the DNS has a concept of eventual consistency, is "freshness" of records is in the eye of the beholder.

I add the handler for just "skydns.local" in the server, and not "." as it is now, the SERVFAIL behavior comes for free (i.e. handled by the library)

bketelsen commented 10 years ago

You mean here? https://github.com/skynetservices/skydns/blob/master/server.go#L112

We'd have to handle either skydns.local or whatever anchor is supplied on the command line flag.

miekg commented 10 years ago

Yes and yes (if your second sentence was a question)

bketelsen commented 10 years ago

When I compiled in the "skydns.local" instead of "." and set my laptop to be my primary dns with 8.8.4.4 as the secondary, skydns serves SERVFAIL, but I don't get a result as if it isn't trying a secondary dns service.

714s4r1:~ bketelsen$ dig google.com

; <<>> DiG 9.8.3-P1 <<>> google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17465 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION: ;google.com. IN A

;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Oct 17 09:49:47 2013 ;; MSG SIZE rcvd: 28

714s4r1:~ bketelsen$ dig something.skydns.local

; <<>> DiG 9.8.3-P1 <<>> something.skydns.local ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40673 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available

;; QUESTION SECTION: ;something.skydns.local. IN A

;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Oct 17 09:51:08 2013 ;; MSG SIZE rcvd: 40

Is it a problem with my local dns resolving?

miekg commented 10 years ago

Uhm, skydns can (and should) not be used as a recursor (i.e put in /etc/resolv.conf), what happens when you query directly? dig @ something.skydns.local, that should give reply, anything else should give SERVFAIL.

bketelsen commented 10 years ago

searching for things in skydns.local works as expected.

googollee commented 10 years ago

I have set skydns through dns delegation. But how to let skydns auto discover?

I run skydns server on 10.211.55.2:53, and run dnsmasq on 10.211.55.6:53 with conf:

server=/skydns.local/10.211.55.2

My /etc/resolv.conf on 10.211.55.6:

nameserver 127.0.0.1
search localdomain

When I try to run another skydns on 10.211.55.6, it report:

# skydns -dns="127.0.0.1:54" -discover=true
2013/10/21 17:44:06 lookup skydns.local. on [127.0.0.1]:53: server misbehaving

And on 10.211.55.2, skydns process print out:

0 []
set failed
0 []
set failed

Where am I wrong?

miekg commented 10 years ago

Fixed by making SkyDNS a forwarder.

thockin commented 8 years ago

I'm curious why the decision was to make it a forwarder rather than return SERVFAIL - was there more discussion?

bketelsen commented 8 years ago

This is long dead code - I don't think anybody uses skydns1 anymore - it's our old Raft backed implementation.