Okay, the consensus on dns-ops is that this is broken and shouldn't work.
Specifically, a construct of the following form is invalid:
www.example.com. SOA blah blah blah
www.example.com. NS ns1.example.com.
www.example.com. DNAME elsewhere.example.net.
The problem is that DNAME is intended to apply to *child* names of the
LHS name ("record owner"). It should *not* apply to the owner name itself.
This is made explict in the next draft of the DNAME specification, which
states: "a DNAME RR redirects DNS names subordinate to its owner name; *the
owner name* of a DNAME is *not redirected* itself" (emphasis added).
(draft-ietf-dnsext-rfc2672bis-dname-25,
section
2.3<http://tools.ietf.org/html/draft-ietf-dnsext-rfc2672bis-dname-25#section-2.3>
)
So, while you're of course free to do this anyway, it may cause demons to
fly out of your nose <http://catb.org/jargon/html/N/nasal-demons.html>.
More likely, some future hotfix or Service Pack may take it away. That's
especially likely if the proposed client-side support for DNAME ever makes
it out of committee.
You Have Been Warned(TM). :-)
-- Ben
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
---
To manage subscriptions click here:
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to [email protected]
with the body: unsubscribe ntsysadmin
