Subject: [dnsext] Another CNAME question

From: John Levine <[email-masked]>
Date: 15 Feb 2010 04:10:43 -0000

Let's say I have a resource which is referred to via some CNAME
records:

a.b  IN A     10.2.3.4
c.d  IN CNAME a.b
e.f  IN CNAME c.d

I'd like to publish some annotations about the resource on a subdomain
of the resource's name:

_stuff.a.b IN TXT "plugh"

But that doesn't help the people who call it c.d and e.f.

Is there any technical reason I couldn't write client code that looks
at result of the A query, and if there is a CNAME chain, picks out the
name of the A record, and adds the prefix to that to form the name for
the second lookup?

I can imagine a variety of problems, such as resolver libraries that
don't let you see the CNAMEs, or caches that don't return quite the
set of records they're supposed to.  Is this likely to be workable in
practice, or is it too much of a kludge?

R's,
John

PS: I realize that in a more perfect world, the sensible approach would be
to use a new RRTYPE:

a.b IN ANNOTATE "plugh"

But that's not going to happen, mostly because it's so painful to add
new RRTYPEs to provisioning systems.

---

From: Matthew Dempsky <[email-masked]>
Date: Sun, 14 Feb 2010 20:42:16 -0800

> e.f  IN CNAME c.d

A query for e.f to a recursive resolver should return all three of
these records, from which a stub resolver could then pick out the
terminal name a.b, and construct an appropriate query (if that's the
convention your protocol has standardized on).

A lot of DNS client libraries just don't expose that information
though.  Most often they're dumbed down to just returning a set of
IPv4 addresses and maybe a few other basic record types if you're
lucky.

Better libraries provide access to all of the response resource record
sets and/or the raw response packet, but that's less common in my
experience.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 15 Feb 2010 09:22:24 -0500

> new RRTYPEs to provisioning systems.

We hear this so often it's like a broken record.

Every time I ask about it, I get a slightly different answer.

What makes that so hard?  Why do you think it's like that?  And what
would need to change for you to feel that it was no longer the case?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 15 Feb 2010 16:30:05 +0000

> Date: Sun, 14 Feb 2010 20:42:16 -0800
> From: Matthew Dempsky <[email-masked]>
> 
> A lot of DNS client libraries just don't expose that information though.
> Most often they're dumbed down to just returning a set of IPv4 addresses
> and maybe a few other basic record types if you're lucky.

The gethostbyname() shipped in BSD 4.4 and possibly 4.3-Tahoe was derived
from BIND 4.9 which returned the whole CNAME chain as aliases.  To wit:

+---
| [nsa:amd64] ./gethost www.microsoft.com
| {www.microsoft.com}
| name: lb1.www.ms.akadns.net
| aliases: www.microsoft.com toggle.www.ms.akadns.net g.www.ms.akadns.net
| addresses: 64.4.31.252 207.46.19.190 207.46.19.254
+---

All versions of FreeBSD/NetBSD/OpenBSD and BSD/OS have had this logic, and
all versions of HP-UX, AIX, Solaris, and Apple Darwin/MacOSX published
since 1996 have had this logic.  I'm less knowledgeable about what GNU
GLibC does in this case, but that would determine what all versions of
Linux do in this case.  Likewise I do not know what Win32 (Microsoft) does,
or what APR (Apache Portable Runtime) or MPR (Mozilla Portable Runtime) do.

Further historical note:

Many/most of these systems also return multiple aliases if there's more than
one PTR RR in a gethostbyaddr(), which was called experimental but shipped
enabled by default.  This is more controversial since RFC 1034/1035 calls
the target of a PTR "the canonical name" of which by definition there could
be only one.  However, we needed this to make multi-homing work.  As in many
controversial innovations in BIND of that era, no RFC was written to describe
the behaviour, and it may have fallen out of some codebases as a result.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 15 Feb 2010 22:34:45 +0100

* Andrew Sullivan:

[unusual record types]

> What makes that so hard?

You can't use gethostbyname or getaddrinfo anymore, and the
alternative interfaces are typically not very well documented and do
not give the appearance of being thread-safe.  You also have to use
something like dn_expand, which is counter-intuitive and somewhat
difficult to use.

At least that's why I briefly compressed data into A records a few
years ago.  Perhaps the situation on Windows is different, but I doubt
it.

It's not a very compelling observatioon because it also applies to
TXT, which turned out quite popular.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Feb 2010 09:11:50 +1100

> something like dn_expand, which is counter-intuitive and somewhat

By that reasoning there would MTA's using MX records or Kerbros
code using SRV records or ....

While dn_expand() and frieds may be low level they can cope with
any new record type that comes out.

If you don't like the documentation submit updates.  It is FOSS.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 15 Feb 2010 17:20:17 -0500

> TXT, which turned out quite popular.

Until I got here, I was muttering "but what about TXT?".  So yes.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: John Levine <[email-masked]>
Date: 16 Feb 2010 08:37:02 -0000

>What makes that so hard?

The biggest problem is crudware web provisioning systems that only
know about specific record types.  I can shove anything into my own
DNS server, but I can't explain to a thousand people using random
provisioning systems provided by their web host or domain registrar
how to add a new record type.

> Why do you think it's like that?

Sad experience.

> And what would need to change for you to feel that it was no longer the case?

Rewrite a very large amount of user facing software.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Feb 2010 22:58:07 -0700

> how to add a new record type.

I can totally relate.   But this seems like a really lousy reason not to add a new RRtype.   How is this problem ever going to get fixed if it doesn't cause anyone any obvious pain?   People will notice if they need to add a new RRtype and their admin system doesn't support it, but they will not notice if you don't add any new RRtypes to the standard.   So to me this is an argument in favor of adding new RRtypes.   I wouldn't propose adding new RRtypes just to get people to update their antiquated provisioning systems, but if you've got a new RRtype, this is an additional service it can perform.