Timothe Litt litt at acm.org
Fri Jul 1 17:03:53 UTC 2011

Yes, all my zones are (or will be) signed.  And all are dynamic update;
tricks like pointing all zones to the same zone files don't work.

So the bottom line is that either way I would somehow need to get my
registrar(s) to put special records  (DNAME or BNAME if it escapes the
politics) into the TLDs (.US, .INFO)?

Considering how hard it is just to get DNSSEC records installed, that
doesn't sound like a fun time.  I haven't seen a DNAME option in the GUI for
any of the registrars that I use.  And if I got a record in, I wonder (a) if
it would stay in and (b) if I could get it changed (or removed) when
circumstances change.  Does anyone have a real experience with this?
Especially someone who isn't a megacorp :-)?

Does the BNAME proposal address the MX/"CNAME" issues with DNAME?

Either way, having to put a record in the parent zone is no big deal -
except when registrars / TLDs are involved.

It seems to me that there's a more manageable approach than that described
for BNAME - that is solely under the control of named.

Given that my BIND servers are authoritative for the real (.net) and aliased
(.us, .info) zones (and, for the external views, properly delegated from the
TLDs), wouldn't it be more practical to have a named solution?  E.g. a
mechanism to tell named to respond authoritatively to all queries to aliased
zones (in my current case, .US, .INFO) as though it was resolving DNAME in
the parent zone?  Put another way: the aliased server is authoritative for
the aliased zone.  Where it gets the zone data from is a private matter.
Normally, it's a zone file.  But for an alias, it could simply query some
other "real" zone (it might even also be authoritative for that), substitute
the alias name for the "real" zone names, and serve the data as
authoritative.  (Signing as necessary.)

That would avoid doing anything in the TLD (parent in the general case), and
it would also make it easy to do more subtle things.  For example, put some
records in the aliased zone, and only go to the "real" zone if no record
matches a query.  Pretty much required for DNSSEC keys, so might as well
look for any record here first. That would seem very flexible.  And, since
it wouldn't need a new record type, no IETF politics!

It might look like
	zone example.us {
	type master;
	alias-of example.net; # Zone to mirror, meaning reflect queries for
example.us to example.net; verify any signatures, then edit reply's
example.us strings => example.us, re-sign and respond as authoritative
	file "example.us.exceptions.db"; # Required to contain (minimally)
.us DNSSEC keys
						   # Optionally, look here
before the alias zone when resolving.
Of course, the synthesized data can be cached per the usual rules; think of
the alias-of zone as serving "misses" from the zone file.

I know I'm not the only user with this problem - many corporations get
theirname.{everything posible) and then try to make them look like
theirname.com.  Usually with http redirects - but that doesn't address all
the other services.

But I conclude that as of today, this is wishful thinking - there is no
practical approach.  Sigh.

This communication may not represent my employer's views,
if any, on the matters discussed. 
-----Original Message-----
From: Mark Andrews [mailto:marka at isc.org] 
Sent: Thursday, June 30, 2011 20:58
To: Jon F.
Cc: Timothe Litt; bind-users at isc.org
Subject: Re: DNAME?

In message <BANLkTim=MAAu1y+XH7yziBMRZNvx30zzFQ at mail.gmail.com>, "Jon F."
> I have a similar set up to that and it works. Have you checked the 
> logs to make sure the zone properly loaded? I'm assuming the zone data 
> you posted below is from the example.us zone but your first question 
> makes it sound like you put it in a seperate zone. That would explain 
> the SERVFAIL if the zone data never loaded but the server was 
> authoritative. It does need to be in the .us.
> example.com.           60      IN      DNAME   example.net.
> test.example.com.     60      IN      CNAME   test.example.net.
> test.example.net.       60      IN      A
> And that's with zone data like this:
> example.com.  IN NS ns1.example.net.
> example.com.   IN NS ns2.example.net.
> example.com.  IN A
> example.com. IN DNAME example.net.
> Truthfully I haven't looked at DNAME's in a long time so I'm unsure 
> how to do it fully for a domain without adding an A record as well. 
> But what your doing works, it's just not very pretty. Someone may have a
better way.

There is an outstanding proposals for BNAME.  This would be added to the
parent zone instead of NS records and would synthesis CNAMEs records for the
domain and its children.

This has got bogged down in IETF politics over how to fix idn rather that be
allowed to stand on its own merits.

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

More information about the bind-users mailing list