On Thu, 18 Jun 2015, Dan Williams wrote:
True. In fact with unbound it is pretty trivial to do. The equivalent
unbound python code for that would be:
import unbound
ctx = unbound.ub_ctx()
ctx.resolvconf("/this/networks/respresentation/of/resolv.conf")
Hmm, that doesn't really allow for split DNS though since it uses the
resolv.conf format? Ideally we could just send unbound a list of server
+domain, and then a fallback of server+"*" for anything not matching
that list.
that's tricky. What you'd do with a bunch of intermediate work queries.
You are probably better of splitting the work:
import unbound
ctxgoogle = unbound.ub_ctx()
ctxgoogle.set_fwd("8.8.8.8")
ctxlocal = ctx = unbound.ub_ctx()
ctxlocal = ctx.resolvconf("/this/networks/respresentation/of/resolv.conf")
and you can query using google:
ctxgoogle.resolve("www.google.com", unbound.RR_TYPE_A)
or your local setup:
ctxlocal.resolve("www.google.com", unbound.RR_TYPE_A)
I'm pretty sure though there will be equivalent python code that causes
the same as:
unbound-control forward_add fedoraproject.org 1.2.3.4 5.6.7.8
or if there isn't, that upstream wouldn't mind making that available.
something like this:
0) resolve.conf/unbound/whatever DNS is unpopulated
1) NetworkManager looks up connectivity server IP address
2) NetworkManager does the connectivity check using that IP address
3) assuming either #1 or #2 fails, NM signals HOTSPOT connectivity state
and provides the DNS information via the API, including any DHCP/WISPR
information received from the network
4) Hotspot agent (GNOME Shell, KDE, whatever) sees the HOTSPOT state,
reads the DNS servers, and spawns a sandboxed web browser using the
preliminary DNS servers
5) User completes hotspot logon or rejection, user agent signals that
hotspot operations complete
6) NetworkManager re-does connectivity checks, and assuming the result
is "success", indicates CONNECTED connectivity state
or something like that.
Yes.
But these steps could be split out into a
small, single-purpose connectivityd that used information from NM/other
sources and was triggered by NM/other sources, and then NM wouldn't have
to do it. NM could still proxy the state since NM would know when to
trigger connectivity checks anyway. But I digress.
Sure.
pull your credit card out), it assumes you have successfully authenticated
to the hotspot. It re-tests the supplied DNS servers. If these are still
determined to be too broken for using DNSSEC (eg too old bind,
dnsmasq) it tries to (silently) become a full itterative nameservers,
eg it will not use any forwards and do all the DNS work itself. If this
also fails, for example because the network blocks port 53 to all but
its own DNS servers, dnssec-trigger tries the other modes of DNS over
TCP/SSL. If any of this works the user isn't even consulted. Only when
all of this fails do we need to contact the user and ask them to go
"insecure" or "cache only"
This is the part that I feel like unbound should do, or if not unbound
then whatever local caching nameserver we do have. Perhaps that's
already built into unbound and only controlled by dnssec-trigger, but it
seems like something more integral to the resolver than outside of it?
No that is the core functionality of dnssec-trigger, not unbound. We
might be able to turn that into libdnssectrigger or something for
re-use. I don't think upstream wants to converge these two things into
one.
Paul
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
