In message <[email protected]>, Masataka Ohta writes:
> Mark Andrews wrote:
>
> > The data stored at www.example.net is usually very different to the
> > data stored at example.net. For www.example.net you often don't
> > care about anything other than A and AAAA. The same can not be
> > said for example.net even after you remove SOA, NS and DNSKEY from
> > the evaluation.
>
> Are you saying to have:
>
> www.example.net. SOA ...
> NS ...
> CNAME example.net.
I am saying that many zones have more than A/AAAA/SOA/NS/DNSKEY/RRSIG at
the apex and adding allowing CNAME/SOA/NS/DNSKEY/RRSIG to all co-exist
doesn't help much as you end up with
example.net SOA
example.net NS
example.net CNAME example.net.hoster.net
example.net.hoster.net A
example.net.hoster.net AAAA
example.net.hoster.net TXT
example.net.hoster.net MX
...
Which kind of forces them to deploy GLB technology even if they
don't need to do for availability reasons to isolate the address
changes from the other changes.
When what is really wanted by the hoster is
example.net.hoster.net CNAME serverX.hoster.net
serverX.hoster.net A
serverX.hoster.net AAAA
which allows for the server's address to change and
the hosting machine to be able to be changed with minimal
DNS changes and is what they do for www.example.net.
www.example.net doesn't have the other baggage associated
with it.
> What's wrong with:
>
> _http._tcp.example.net. SRV ... www.example.net.
Nothing.
> >> The update is never rely on cached CNAME for SOA or NS query.
> >>
> >> Thus, even without the update, most people won't notice lack
> >> of the update.
> >
> > Most != all.
>
> Those who notice are those who can update their servers if
> they think it necessary (I think it is not).
>
> Masataka Ohta
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
