[dns-operations] Adding CNAME for the root domain issue

Mark Jeftovic markjr at easydns.com
Wed Apr 27 21:55:39 UTC 2016


Somebody already said it in this thread (Mark Andrews I think)

SRV records already fix this.

Actually they don't "fix" it, you just don't need to do anything else if
you just put in your SRV recs:

$ORIGIN example.com.
	IN 	SOA....
	IN	NS blah.blah.blah.

	IN	MX mail.example.com.

 _http._tcp.example.com. 86400 IN SRV 0 5 80 example.com.cdns-r-us.dom.


But browsers don't support SRV

(Sorry for the following, I really don't mean to be "talking up my
book", I took great pains not to ask a lot of questions on this list
while I was writing it, but anyway...)

In the book... there  is a sidebar... that sidebar has the title:

In a better world, browsers would support SRV records.

- mark

On 2016-04-27 5:31 PM, Dave Warren wrote:
> On 2016-04-27 13:16, Fred Morris wrote:
>> I've been biting my tongue, but ok I give up. Not your fault specifically
>> Mark...
>>
>> On Wed, 27 Apr 2016, Mark Jeftovic wrote:
>>> I refer to apex aliasing in the book (almost done) as "the big kahuna of
>>> protocol violations"
>> What toxic landscape gives rise to this unwanted denizen? If something
>> demands a CNAME at the apex, it's hardly a zone at all: how can we do NS
>> records?
>>
>> Just CNAME it. There I said it: CNAME it in the parent zone, because it's
>> not a zone at all.
>>
>> But that will never happen because rules exist against that sort of
>> thing.
> 
> It's not just about rules against this configuration, even if we
> eliminated those rules, it wouldn't solve the problem for the user who
> wants this:
> 
> example.com. CNAME cdn.someservice.example.
> mail.example.com. A 192.24.0.5
> 
> Or more likely:
> 
> example.com. CNAME cdn.someservice.example.
> example.com. MX 0 mail.example.com.
> mail.example.com. A 192.24.0.5
> 
> A new RR that would be"return defined record if it exists, otherwise
> alias to..." might solve all of the problems by simply allowing aliases
> and other records to coexist, but frankly, SRV records are a better
> solution in a number of ways (and SRV records already exist, we just
> need to get browser manufacturers to implement them)
> 
> If we were redesigning DNS completely, we might instead allow any RR
> type other than SOA and NS to return a "Alias to..." response instead of
> an actual response, but this would be impossible to implement in a
> backward compatible way.
> 

-- 
Mark Jeftovic, Founder & CEO, easyDNS Technologies Inc.
Company Website: http://easydns.com
Read my blog: http://markable.com
+1-416-535-8672 ext 225



More information about the dns-operations mailing list