## page was renamed from 201405DevSummit/DNS
== FreeBSD Developer Summit: Roadmap for DNS Library and Tools ==
Wednesday May 14, 13:00-16:00
=== Overview ===
FreeBSD 10.0 now ships with DNSSEC validation enabled out of the box provided by a local unbound caching daemon. What do we want to do for FreeBSD 11?
If you would like to participate, contact the working group chairs below and CC {{{devsummit@}}}. You will be then added to this page. Please include a list of things you want to talk about or the areas you are interested in. This helps us in planning the session and to bring people together with common interests.
It is possible to bring in people who cannot attend in person via video conference or chat tools. Notes during the session will be published later on for the whole community to see what we discussed.
=== Goals ===
In particular, we would like to cover the following topics. This is not an exhaustive list and if you feel there is something missing that you want to talk about, contact one of the session chairs and we will include your topic here. Note that the numbering of the topics does not represent an ordering or importance indication of any kind, but rather a reference to the second table with the "topic of interest" column.
=== Topics ===
Part one
09:00 - 10:30
'''Future of package building'''
|| '''#''' || '''Who''' || '''Topic Description''' ||
|| 0 || all || Introductions ||
|| 1 || ? || Status and evaluation of unbound in 10 ||
|| 1a || ? || Plans for 10.1-RELEASE ||
|| 2 || MichaelBentkofsky || getdns-api ||
|| 3 || ? || Capsicum/Casper ||
|| 4 || ? || CLI: dig, ldns-dane, ... ||
|| 5 || ? || FreeBSD 11.x ||
|| 6 || plosher || Client Subnet-ID privacy ||
Break
10:30 - 11:00
Part two
11:00-12:00
|| '''#''' || '''Who''' || '''Topic Description''' ||
|| 14 || * || Brainstorm: common complaints and wantlist ||
''Note: General presentations about work you have done that does not require further discussions should be submitted for the FreeBSD Developer Summit track at BSDCan (see the [[DevSummit/201305|general developer summit]] page).''
=== Attending ===
In order to attend you need register for the [[DevSummit|developer summit]] as well as by email for the session and be confirmed by the working group organizer. Follow the guidelines described on the [[DevSummit/201305|main page]] or what you received by email. For questions or if in doubt ask the session chairs.
|| '''Name''' || '''Username / Affiliation''' || '''Topics of Interest''' || '''Notes''' ||
|| MathieuArnold || mat || * || Session knitter (and BIND maintainer…) ||
|| ErwinLansing || erwin || * || Session chair ||
|| MatthewSeaman || matthew || * || ||
|| BjoernZeeb || bz || * || ||
|| BrooksDavis || brooks || * || ||
|| MikeKarels || !McAfee || * || ||
|| DavidCroal || Sentex || * || ||
|| PeterWemm || peter || * || ||
|| PeterLosher || ISC || * || ||
|| DagErlingSmørgrav || des || * || ||
|| MichaelBentkofsky || Verisign || * || ||
|| RyanSteinmetz || zi || * || ||
|| StaceySon || sson || * || ||
|| BradDavis || brd || * || ||
|| DavidDischer || || * || ||
|| JonathanAnderson || jonathan || * || ||
=== Notes ===
=== Results ===
DNS Session
-----------
Introductions
Finalize agenda -- guOttawa problems with DNSSEC, forces you to ignore signatures
plosh asked and had it confirmed that SSHFP records exist for all FreeBSD
servers and are signed via DNSSEC
DES:
State of DNS pretty much the same as just before 10.0 release, due to
DES' breavement. Is in 10.x and head.
- LDNS in base
- unbound in base as local-unbound to avoid conflict with ports.
Exists to provide local caching resolver; nothing more. Not
intended to provide DNS service for whole network.
local-unbound not built with libevent, won't scale.
wanted to be kept a bit hidden as plan is to remove it later.
- conflicts with ports. This caused a delay of about 9 months in
committing. Use of /usr/lib/private as solution.
Control sockets are still an issue. unbound-control was not
renamed: if you install from ports it may control the wrong
instance.
ilya has patch to use unix domain socket. NL Net rejected patch
-- would have it in contrib, or might accept it if FreeBSD used
it.
- PTR lookups on RFC1918 -- unbound filters those addresses. Mixed
reports of what config changes do or do not work. DES would
prefer a code change to have an option to turn off built-in
domains
- We're two versions behin on ldns release. Should try and catch
up for the next 10.x release.
- DES has submitted patches upstream but been unable to follow up.
More patches are in the works. One patch to
- Code "tastes" odd: written by good programmers, who are not
apparently completely fluent in C. Problems with const, static
functions, public functions without prototypes. Mismatched
prototypes in different compilation units (which didn't actually
matter...) Code quality is not horrid, but not quite what DES
would like.
- Cleanup patches that have been submitted have been accepted.
- Ilya has has bad experiences with NL Net not wanting to support
patches and just leaving them in contrib to rot. OTOH, if DES
commits it in FreeBSD then NL Net might accept them.
- It's not as daft as it sounds. Putting it in FreeBSD means
patches get tested by a large amount of users, which is useful
from NL Net's pov..
- Similar things with adding unix socket to postgresql in the past.
- Verisign has strong relationship with NL Net: any possibility for
outreach? Other people have strong relations but
- Historic behaviour of different TCP stacks wrt unix domain
sockets (BSD-ish just works, Solaris Sys-V was painful) Mostly a
thing of the past. Doesn't work on Windows...
- SSHFP: will tell you if matching key was found in DNS, but not if
key was DNSSEC signed. SSH key checking trains users to type
'YES [enter]' based on incomplete information. SSH code for
verifying host keys is horrendous. They keep adding one measure
after another, and there's no overarching vision.
- DES has changed the default. A signed key will be accepted without
asking. Seems to have been accepted without complaint.
- Location of the root DNSSEC key different between port unbound
and local-unbound. drill in base won't find ports version by
default.
- Came up with Firefox / Chrome DNSSEC validator plugin expects to
find the root key in the port's unnbound location.
- Recently solved bug: localhost in /etc/resolv.conf would prevent
unbound fetching the root anchor. This is a soft error in
unbound, and there's a compiled-in copy in unbound. The port
expects the rc-script to fetch the key. The key file doesn't
have to be there: unbound installs it for the convenience of
other apps. Should be included in the package. Port shouldn't
fail even if the file is unavailable.
ERWIN:
- Command-line tools. Erwin misses dig in base.
- DES had a patch at one point but can't find it at the moment.
- Bind 8.x dig easy enough to compile stand-alone but doesn't have
the important DNSSEC bits.
- dig-alike written as shell wrapper around drill supports all the
same options except for the +arguments stuff.
- PW ldns-dane wasn't imported. This is the best tool for
generating entries to go into DNS. Would be good to import
- dig replacement to be actionned by DES. PW offers to help with
unix domain socket patch and the like.
- BZ: if we're adding stuff to unbound, how much are we (FreeBSD)
willing to accept. BZ has a DNS64 patch NL Net were reluctant to
accept.
- DES would commit locally, and push upstream.
- Doesn't DNS64 contradict the point of having a DNSEC validating
local resolver? No -- validate lookups *before* translation on
local machine.
- val-permissive-mode -- allows you to ask "is this valid or not"
PW: should be on by default, improves usability but not so
impervious to foot-shooting. Helps with the "Starbucks" problem.
- DES agrees on turning it on by default. Mustn't rewrite peoples'
existing unbound.conf. We might have an included file we feel
free to modify.
- Can we do it ports style? Replace the file if unmodified from default?
Only if default version laying about.
- Do we know what !RedHat are going to do by default?
- Should we have config questions about this in sysinstall?
- PW Turning permissive mode on is really snatching defeat from the
jaws of victory.
- OS X tool: unbound-trigger (?) checks to see if DNSSEC validation
is possible and prompts user accordingly. Really of relevance to
laptop uses (PC-BSD mostly, as they can do the ask user thing)?
- Maybe 3rd option for defaults: on; off; on-if-it-works -- do smoke
test on startup.
- Can you get a NTP association with on-if-it-works mode is on?
- Easy to attack by black-hat forcing initial failure.
- Big red flashing light for users saying "This network is broken"
would be desirable.
- Broken internally at Google and Yahoo (Google has go. domain
internally for URL shortening.)
- Add a hook to the resolv-conf script to test any new DNS Servers
each time it gets run? Should we have a foo.freebsd.org target
specifically for checking validity? DoS-ing against that could
DoS all FreeBSD machines that happen to be restarting at the
time...
- Issue with machines always phoning home on startup -- not good for
the more paranoid amongst us.
- Validation check will only interact with the usual resolving
DNSes.
- Many OSes 'phone home' by looking up stuff in the DNS. ISC wanted
to do a similar thing to find old bind versions, but ran into the
same political problems.
- DES has too much on plate. PW/plosh/erwin/zi to deal. Should be
doable in time for 10.1. brooks: can we get this into head very
soon? Needs testing before our usual late import to stable.
----- coffee break ----
- Action for gjb -- knob in bsdinstall to disable unbound
plosher:
- asked to bring topic up by his management.
----- coffee break, take 2 -----
** T-shirts! **
plosher
- senior systems architect at ISC. Runs F-root: 55 sites all
running FreeBSD. Write bind, dhcp
- Recent changes to ISC and bind. Management change last October:
definitely for the better. 2 year bumpy period. Painful changes
-- bind 10 has been dropped. Will be transitioned to public Git
repo. DHCP component will be the next-gen DHCP for ISC. Will be
continuing with bind-9.
- 9.10 was just released: internalized geodns support (used by
FreeBSD.org). Plans in place for 9.11. Anything missing in BIND:
plosh will be here all week and happy to answer questions.
- Stub resolver in libc: who manages it? Draft ietf spec for
clientID support. Helps clients to connect to the nearest akami
(etc) server. DNS Cookies -- ISC position is to lobby OS vendors
to provide an opt-out. This is a layer of anonymisation that is
going away: should be control over any addition information
releases.
- draft-edns0-client-subnet
- This should be part of a future policy.
- Local unbound won't do this.
Michael
- getDNS API
- was asked to talk about this last night, but hasn't done anywork
on it himself. Colleagues have.
- replacement for getaddrinfo. Allows your stub resolver to get
validation information right down at the client level.
- is in ports
- Requires libxml, ldns, unbound to compile
- Turns out doing validation is non-trivial. Just about everything
that exposes validation status to users is a wrapper around
libunbound. Wasn't meant to be that way.
- Separation of policy and mechanism. "Secure do-what-I-mean"
function.
- Application programmers shouldn't be worrying about this: should
be a system policy. "Casper: open me a /thing/, please" should be
about the limit of it.
- Providing a higher level API should be within the purview of the OS.
- App should not drive the validation mechanism. Should be able to
ask for mechanism after the fact.
- alternate APIs for validation. At least 2^H8. What is still in
the standards process? libval ?
- we don't currently use what's in libc -- we bypass through
nsswitch stack. OpenSSH does direct DNS call for somethings,
nsswitch for others. Causes problems when different routes
generate different results.
- Only two Host -> IP lookup mechanisms in popular use: /etc/hosts
and DNS. (NIS is gone, and most people don't put this stuff in
LDAP). Should rip this stuff out of nsswitch ?
- is there anything more than /etc/hosts and DNS that we need?
- passing validation info through nsswitch is going to be a lot of
work
- Competing alternatives to getDNS? libval?
- BZ: ideally want to get to point where app says 'get me the socket to
the hostname' and all the DNS etc. is hidden. Agnostic about the
precise mechanism.
- libval is nice and simple; getDNS is more complex -- handles
multithreading etc.
- don't want arbitrary resolver code linked to your application if
it is at all sensitive. Need socket interface (to casper)
- JA: Does the application need to decide things or the system?
Both. either layer is a good place to impose additional
restrictions on what will be accepted.
- Like an init replacement. "I want to talk to this service"
shouldn't matter if local or on network
- Start to think about caching again. If casper is handling all the
lookups, it's relatively simple.
- Many steps to validate connection. Factor into high level service.
- Docco on getDNS looks nicer than libval. Look and feel of getDNS
API is different. libval very much like what we had before.
- We need a new API in base, and what we adopt will have some
influence on the rest of the world. Do we care about ease of
conversion of exist apps.
- What will linux do? And what will they do the following week?
- "Show me your work" -- don't need another language to describe how
to validate a lookup, just decide whether you approve of what was
done.
- mostly NL Net behind getDNS
- DNSSEC-tools people are behine libval
Aims for FreeBSD 11.0-Release:
- Need wider conversation about do we want to shoot nsswitch in the
head (or at least the bits related to host resolution)
- JA: "I think that sounds great"
- Hostname resolution will have a single path through the stack. (PW)
- NSS cache module currently gets rid of all the validation info.
Why keep 50k of /stuff/ on the off chance that it will need to be
revalidated.
- Survey applications to work out what API capabilities they need.
- Does casper need to do this, or can it run through unbound behind
the scenes.
- capsicumize unbound ?
- can we push patches upstream to unbound ?
- Think of casper as a rendezvouz service. Doesn't necessarily
eliminate the need to have an unbound service.
----
CategoryHistorical