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

From: Petr Spacek <[email-masked]>
Date: Tue, 31 May 2016 09:08:44 +0200

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?

I do not like TXT but I'm not in position to judge validity of these arguments.

Thank you for your time.

-- 
Petr Spacek  @  Red Hat

---

From: "John Levine" <[email-masked]>
Date: 31 May 2016 14:52:08 -0000

>Could someone validate these assumptions?

They are all correct except for the bit about not being able to
standardize TXT records.  There are plenty of standards track RFCs
that use TXT records with _prefix names, notably DKIM, RFC 6376.

You may be thinking about the kerfuffle about SPF and RFC 4408, but
SPF for reasons that made some sense a decade ago uses TXT records
with unprefixed names.  Don't do that.

R's,
John

---

From: "Patrik Fältström" <[email-masked]>
Date: Tue, 31 May 2016 20:50:56 +0200

It is a big failure and problem for the Internet that there is no support for unknown resource record types.

See RFC 3597 (from 2003) and followers.

   Patrik -- that because of this will continue to object to use of TXT, as we all have our windmills

---

From: "John R Levine" <[email-masked]>
Date: 31 May 2016 15:13:13 -0400

> It is a big failure and problem for the Internet that there is no support for unknown resource record types.

No kidding. The problem isn't with DNS server software like BIND and NSD, 
which are updated regularly.  The problem is the Web Crudware(tm) that 
most people use to manage their zones.

See https://datatracker.ietf.org/doc/draft-levine-dnsextlang/

I think I have funding to revise and implement this, by the way.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 31 May 2016 12:14:51 -0700

> On May 31, 2016, at 12:13 PM, John R Levine <[email-masked]> wrote:
> 
> No kidding. The problem isn't with DNS server software like BIND and NSD, which are updated regularly.  The problem is the Web Crudware(tm) that most people use to manage their zones.
> 

Overall, its the crud ware for configuration not the path.  Unknown record types seem to be well supported from a transport viewpoint.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: "Patrik Fältström" <[email-masked]>
Date: Tue, 31 May 2016 21:20:10 +0200

On 31 May 2016, at 21:13, John R Levine wrote:

> No kidding. The problem isn't with DNS server software like BIND and NSD, which are updated regularly.

Correct!

> The problem is the Web Crudware(tm) that most people use to manage their zones.
>

Excellent! Me like!

   paf

---

From: Mark Andrews <[email-masked]>
Date: Wed, 01 Jun 2016 07:49:55 +1000

In message <[email-masked]>, Petr Spacek write
> 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

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 31 May 2016 18:44:11 -0400 (EDT)

>>> deployable option for individuals and small organizations

What is missing in this discussion is that a URI allows for a weight, so
you can have clear primary and fallback sites configured through the URI
RRTYPE. That is starting become a little hack-ish when using TXT.

> always host your own servers if you have to.

+1

This is for a security mechanism. I'd hope you would pick a DNS hoster
that frequently updates their stuff if you are going to populate your
zone with DNS security information hosted by them.

The URI seems like an excellent fit for this draft.

Paul