Thus said "AJ ONeal (Home)" on Mon, 16 Mar 2015 12:37:06 -0600: > I don't understand what *in-bailiwick* means.
Bailiwick is the thing over which you are steward (e.g. your DNS zone that has been delegated to you); or in other contexts, the thing for which you are an authority, or an expert. When you use NS records that are not part of your bailiwick (e.g. if your zone is coolaj86.com, then ns.coolaj86.com is in-bailiwick, and ns1.redirect-www.org is not), then DNS resolvers have to do extra work to resolve your domain. For example, a DNS resolver receives the NS delegation for your domain it cannot trust the glue records that it may receive received, and must start another round of querying, just to resolve the NS records that were obtained. For example: $ dnsq a coolaj86.com d.gtld-servers.net 1 coolaj86.com: 82 bytes, 1+0+2+0 records, response, noerror query: 1 coolaj86.com authority: coolaj86.com 172800 NS ns1.redirect-www.org authority: coolaj86.com 172800 NS ns2.redirect-www.org In this case, no glue was actually served with the record, but at any rate, now the DNS resolver, before it can continue to get an A record for coolaj86.com, must now resolve ns1.redirect-www.org to an A record to find out where your NS server is. If, instead, with your registrar, you had registered in-bailiwick NS records, no further queries would need to be made. E.g. if when this same query was made, I instead got NS ns1.coolaj86.com with an A glue record of 192.241.238.7, the next query that my DNS resolver would have to make is directly against 192.241.238.7. Instead, it has to go through numerous other delegations and lookups before it can eventually find that IP address to ask your authoritative DNS server for the answer. > This raises another question: > dig ns1.google.com @ns1.google.com > dig google.com @ns1.google.com > > How is it that google.com claims authority for itself? Because it must, otherwise, this would be considered a lame delgation (e.g. the gtld servers delegate google.com to ns1.google.com, but if ns1.google.com didn't answer authoritatively, and instead tried to delegate the domain to yet another server, this would be called a ``lame delegation'') and google.com would cease to exist on the Internet. The gtld servers have delegated google.com to ns1.google.com, so ns1.google.com must be an authoritative DNS server for google.com. So it answers accordingly. > Could I host the records for ns1.hellabit.com on hellabit.com? Absolutely. This is called in-bailiwick. And in fact, the NS records you give out, should try to match those that your parent delegates to you, though it isn't exactly required. > On name.com (my registrar) I don't seem to have the option of putting > in an IP address. It looks like I *must* use ns1.hellabit.com - but > that would mean that I couldn't serve the record for ns1.hellabit.com > from ns1.hellabit.com. Typically you have to ``register'' a glue record. Some registrars call it by that very name, others hide the terminology. They put up warnings to the effect that, ``be sure you know what you're doing, this will not help you resolve www.hellabit.com'' because presumably some people thought that you could put www.hellabit.com with an IP address to make their website resolve. What that really does is create an NS record named www.hellabit.com with an A glue record of the IP address for the NS. But I don't know of any DNS resolver that will be able to resolve this because what the DNS resolver will get is a NS record delegation that forwards to the IP where the webserver is. Unless the webserver is also running DNS for that domain, things would cease to resolve for that domain. > Is this a limitation of name.com? Or am I supposed to seed out > ns1.hellabit.com using name.com's nameservers and then switch my > nameserver for my nameserver to be itself after it has propagated? You may simply be looking at the wrong interface in name.com's DNS tools interface. > Sounds like bad-news-bears all the way around. It sounds like if I > could do what google does and be my own authority, this problem would > go away, yes? You don't necessarily have a problem, just a potential problem. Andy -- TAI64 timestamp: 4000000055078f54 /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
