Re: [DNSOP] New usage for TXT RR type on radar: Kerberos service discovery

Mark Andrews <marka@isc.org> Tue, 31 May 2016 21:50 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8383C12B049 for <dnsop@ietfa.amsl.com>; Tue, 31 May 2016 14:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.327
X-Spam-Level:
X-Spam-Status: No, score=-8.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_476jqixlfT for <dnsop@ietfa.amsl.com>; Tue, 31 May 2016 14:50:08 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E201712B040 for <dnsop@ietf.org>; Tue, 31 May 2016 14:50:07 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id E7DF91FCAE4; Tue, 31 May 2016 21:49:59 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B62CA1600B8; Tue, 31 May 2016 21:49:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A75F01600B7; Tue, 31 May 2016 21:49:58 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id a3HV9zHiUZ78; Tue, 31 May 2016 21:49:58 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 2913B160069; Tue, 31 May 2016 21:49:58 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B8F074A61AAE; Wed, 1 Jun 2016 07:49:55 +1000 (EST)
To: Petr Spacek <pspacek@redhat.com>
From: Mark Andrews <marka@isc.org>
References: <df9d8d34-6005-6b61-e9d1-397d915aa197@redhat.com>
In-reply-to: Your message of "Tue, 31 May 2016 09:08:44 +0200." <df9d8d34-6005-6b61-e9d1-397d915aa197@redhat.com>
Date: Wed, 01 Jun 2016 07:49:55 +1000
Message-Id: <20160531214955.B8F074A61AAE@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/oS92GBbBj3cc3lnos2RXevtX3-U>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] New usage for TXT RR type on radar: Kerberos service discovery
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 May 2016 21:50:09 -0000

In message <df9d8d34-6005-6b61-e9d1-397d915aa197@redhat.com>, Petr Spacek write
s:
> Hello,
> 
> I would like to draw attention of dnsop WG to discussion about new service
> discovery method for Kerberos:
> 
> Please see
> http://www.ietf.org/mail-archive/web/kitten/current/msg06044.html
> and its continuation
> http://mailman.mit.edu/pipermail/krbdev/2016-May/012588.html
> 
> 
> Main arguments for using TXT instead of URI RR type are:
> ...
> > We had been planning to use the URI record type, but after a recent
> > round of discussion, we don't think it's likely that popular DNS hosting
> > providers will allow customers to create URI records (since it seems
> > like no one else is using them).  Some middle-boxes would also block DNS
> > queries for URI records.  That problem would be even worse if we create
> > a new record type.  So, we are planning to use the TXT record type.  It
> > seems unlikely that we can standardize on a TXT record through the IETF
> > (except perhaps as an informational RFC), but it seems like the only
> > deployable option for individuals and small organizations
> ...
> 
> Could someone validate these assumptions?

Well you have idiots with firewalls that think that anything new
needs to be blocked be it types, flags, options or versions depite
none of that being a actual security threat.  The only way to fix
this is to force them to upgrade.  This is possible.  Just start
using a feature that is being block and it will be corrected.  That
being said dropping queries based on qtype is rare.

That said we are pushing ahead with deploy DNS COOKIES (RFC 7873)
by default.  There are more firewalls that block unknown EDNS options
than those that block based on type.  There are also plenty of
nameservers that do not implement EDNS correctly and fail to ignore
unknown EDNS options.  For the most part that just slows down
resolution but there are corner cases where things break. e.g. a
validating resolver trying to retrieve records from a signed zone
where the server doesn't implement EDNS correctly, misconfigured
loadbalancers where the backing zone is missing necessary fallback
records to handle the queries that fall through to it.

Yes, we have had bug reports over lookup failures due to DNS COOKIES
and when that is the issue we complain to the DNS operator.

Most modern nameservers handle new records types and unknown record
types.  There are a few that return NOTIMP rather than NOERROR to
unimplemented types.  Similarly there are a few that return REFUSED.
When you discover one contact the operator and complain.

The hardest part is DNS hosters that fail to update their web
interfaces to handle new types.  Deciding to not use a new type due
to this is a case of the tail wagging the dog.  We should not go
there.  You can alway open support tickets to get records added.

Adding new types is easy to do and should be something that is
expected to be done by all parts of the ecosystem.  It's not like
we haven't been adding new types every year for the last 20 odd
years.

We shouldn't be letting substandard operators be holding up DNS
developments.  There is absolutely nothing stopping anyone that
wants to deploy a new type from doing so other than FEAR.  You can
always host your own servers if you have to.

Mark

> I do not like TXT but I'm not in position to judge validity of these argument
> s.
> 
> Thank you for your time.
> 
> -- 
> Petr Spacek  @  Red Hat
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org