In article <1515887413.808127.1234484296.080ba...@webmail.messagingengine.com> you write: >> > as soon as we add one RR through EPP, as James stated there is the >> > question about all others. >> >> Yes, and I clearly do not want to go into that: too complicated for >> me. > >Have you seen draft-ietf-dnsop-aname? > >Seems to be closely related in the sense that it could be as useful to have >DNAME as to have ANAME (of course the difference is that one already exists >the other not yet or never)
There's little reason to put an ANAME into a TLD zone file. Whatever you wanted to do with one, you can do equally well with an ANAME at the apex of a 2LD. For that matter, if you really really want to shoot yourself in the foot, you can get the same effect as a DNAME in a TLD right now by delegating the name and putting the DNAME at the apex of the 2LD, nothing new required. You could even have an ANAME and DNAME together, to sort of simulate the also non-existent BNAME. I continue to believe that allowing DNAMEs in TLDs is a bad idea, and so I see no reason to spend further effort on this extension. With respect to DNAMEs at the top level, someone else noted that the root zone isn't managed the same way as TLDs, so there's no obvious connection. Since you can get the effect of a DNAME in the root zone by putting a DNAME at the apex of a TLD as Taiwan has done, if people want more root-ish DNAMEs it might be more productive to consider how to invent a policy to allow a DNAME-only TLD if you're not a ccTLD. R's, John _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
