• DevSummit
• 201405
• 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

Break 10:30 - 11:00

Part two 11:00-12:00

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 general developer summit page).

Attending

In order to attend you need register for the developer summit as well as by email for the session and be confirmed by the working group organizer. Follow the guidelines described on the main page or what you received by email. For questions or if in doubt ask the session chairs.

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