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
- [DNSOP] New usage for TXT RR type on radar: Kerbe… Petr Spacek
- Re: [DNSOP] New usage for TXT RR type on radar: K… John Levine
- Re: [DNSOP] New usage for TXT RR type on radar: K… Patrik Fältström
- Re: [DNSOP] New usage for TXT RR type on radar: K… John R Levine
- Re: [DNSOP] New usage for TXT RR type on radar: K… Nicholas Weaver
- Re: [DNSOP] New usage for TXT RR type on radar: K… Patrik Fältström
- Re: [DNSOP] New usage for TXT RR type on radar: K… Mark Andrews
- Re: [DNSOP] New usage for TXT RR type on radar: K… Paul Wouters