[dns-operations] register nameservers in different TLD's NS
Hello, My domain name, say nsbeta.info, has registered the nameservers in info's servers. So, the domain nsbeta.info can use the nameservers of itself as its auth servers. But, a domain in other TLD, say example.com, can't use the nameservers of nsbeta.info as its auth servers. How can I register a info nameserver in a com's NS? Thank you. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] register nameservers in different TLD's NS
I think what he means is that the other TLD ( ie .com ) does not yet have a glue record in place for the .info nameserver - thus it will not allow domains to be delegated to it. He needs a registrar to create the glue recs - and it doesn't need to be the parent registrar of the .info domain If you ( sorry, didn't get original posters name ) email me the exact hostname you need setup offlist we'll get it added to the global registries for you - mark Sent from my iPhone On 2012-07-16, at 10:12 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Mon, Jul 16, 2012 at 09:45:34PM +0800, ?? m...@nsbeta.info wrote a message of 17 lines which said: But, a domain in other TLD, say example.com, can't use the nameservers of nsbeta.info as its auth servers. Why? It should work. For instance, the name servers of linux.com are under .org. How can I register a info nameserver in a com's NS? You cannot, the DNS is a tree, .com cannot have information about .info machines (a long time ago, it did, but it was a bad idea and, anyway, it is over now). ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] register nameservers in different TLD's NS
On Mon, Jul 16, 2012 at 10:27:07AM -0400, Mark Jeftovic mar...@easydns.com wrote a message of 40 lines which said: I think what he means is that the other TLD ( ie .com ) does not yet have a glue record in place for the .info nameserver Of course. There is no need for glue since the name server's names are not in the same domain (not even in the same TLD). thus it will not allow domains to be delegated to it. easydns.com is delegated and it has a .info name server and the .com name servers do not have glue (and for good reasons): % dig +short @a.gtld-servers.net DNS4.EASYDNS.INFO % ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] register nameservers in different TLD's NS
On 2012-07-16, at 11:21, Mark Jeftovic wrote: Sorry, I mispoke when I said glue record. It's not a glue record that needs to exist, BUT there does need to be a nameserver defined for that hostname at the registry before you can delegate a .com or .net domain to it. For even more clarity, it's perhaps worth mentioning that in gTLDs this is mainly an artifact of the EPP data model (which itself inherited aspects from earlier data models). Registries (e.g. ccTLD registries) which take other approaches might not need the registration of a host object (or equivalent, in their model). Joe ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] register nameservers in different TLD's NS
On 16 jul 2012, at 21:37, Joe Abley wrote: On 2012-07-16, at 11:21, Mark Jeftovic wrote: Sorry, I mispoke when I said glue record. It's not a glue record that needs to exist, BUT there does need to be a nameserver defined for that hostname at the registry before you can delegate a .com or .net domain to it. For even more clarity, it's perhaps worth mentioning that in gTLDs this is mainly an artifact of the EPP data model (which itself inherited aspects from earlier data models). Registries (e.g. ccTLD registries) which take other approaches might not need the registration of a host object (or equivalent, in their model). Well, I think the policy in any epp based registry should be able to be such: - It is for a registrar to add a domain object, and link that domain object to a named host object - A host object has as a sponsoring registrar the registrar that is sponsor of the to the name of the host object inferior domain object - A named host object can be created by anyone, but glue can only be added to the host object by the for the host object sponsoring registrar An alternative is to allow domain objects to be created with hostnames that are host objects only in the case that the explicit glue is needed (that the host has a domain name in the delegated domain). Sure, it might create problems if you have cross-referenced glue, but I have at the moment a case where a registrant due to policy in the registry can not get a domain name of NS to what they want because the domain name of the NS has a different sponsoring registrar than the sponsoring registrar of the delegated domain. I.e. we have example1.com with a name server that is for example ns.example2.com. Now, example1.com and example2.com have different registrars, and the registrar for example1.com is not allowed to create the host object ns.example2.com that is needed for the domain example1.com. If only example2.com did use ns.example2.com as name server, then the host object would exist in the registry database, and the example1.com domain object could reference it. But as it is now, nope. I have no problems with registries providing rope that the registrant can hang themselves in, but having registries having policies that prohibit the registrant to do the right thing, that makes me irritated. Patrik ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs