Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Apart from the source code, there seems to be virtually no public information on the web of how BIND and djbdns, amongst other recursive resolvers, select which NS servers they will query as part of the recursive name resolution.

Is it always best to provide your own glue records for your domain names, even if you're actually still using the DNS servers of your hoster (i.e. should you glue the IP-addresses of hoster's DNS under your own domain), or is it better to provide the actual NS names of your hoster, without trying to make them look like they're under your domain?

Does it help to have a mixture of records, e.g. if my hoster has 5 auth NS servers with glues from .com (and my domain name is a non-.com one), can I re-claim some of them under my own domain with my own non-.com glue records, and give out the rest straight through the hoster's own .com domain?

Also, I've noticed that in my simple tests with dig(1), it seems like the glue records are not actually given by some parent zones, even if they would in fact be served by the same auth server should they be explicitly requested (try dig @ns.ripn.net domenus.su and dig @ns.ripn.net domenus.ru, seeing that you get no glue on the original attempt; although dig @a.gtld-servers.net. theos.com does work as expected, giving out all .net and .com glue automatically); does it mean that if I have several domains within a certain zone like .ru/.su, it's still best for each such domain to have their own glue?

share|improve this question

1 Answer 1

Is it always best to provide your own glue records for your domain names, even if you're actually still using the DNS servers of your hoster

Doesn't matter

  • if DNS-servers are down (physically) - you didn't get answer from any name
  • if DNS-servers are in business - any name of NS will give same result

You can see small difference only if hoster's zone is in different state, than your

it seems like the glue records are not actually given by some parent zones

It was semi-broken tests, ns doesn't answer (me, now), but next attempt with ns9 gave me

Quering 194.85.252.62#53 for {domenus.ru.,ANY}
Received answer from 194.85.252.62#53
  Not authoritative

  Referral:
  -> domenus.ru. [NS] ns2.domenus.ru.
  -> domenus.ru. [NS] ns1.domenus.ru.

as expected

share|improve this answer
    
This does not address the question of how NS servers are selected. –  cnst Feb 10 '12 at 4:35
    
Which NS for which task? Be more specific, I don't know how deep RTFM you requested –  Lazy Badger Feb 10 '12 at 4:56
    
Cannot possibly be any more specific. Please read my question. For a specific example, please see the output of dig @a.gtld-servers.net. theos.com.. If I was named or dnscache, which NS server will I query next? –  cnst Feb 10 '12 at 5:16
    
@cnst - I done it. It seems for me that you don't want to get answer and work for it. AMF! –  Lazy Badger Feb 10 '12 at 5:20
    
If you would have read it, you would have noticed that I'm talking about recursive name resolution, and specifically asking how NS servers are selected. I really cannot be any more specific than this, sorry! Did you skip the bolded out part of the question? ;-) –  cnst Feb 10 '12 at 5:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.