0

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?

Improve this question
1
  • "which NS servers they will query as part of the recursive name resolution." Like any nameserver they do top down resolution and try all nameservers until getting a reply (positive or negative) while retaining statistical data (Round trip time) so that next time they slightly favor the nameserver replying faster.
    – Patrick Mevzek
    Jan 31, 2020 at 15:48

1 Answer 1

Reset to default
0

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

Improve this answer
5
  • This does not address the question of how NS servers are selected.
    – cnst
    Feb 10, 2012 at 4:35
  • Which NS for which task? Be more specific, I don't know how deep RTFM you requested
    – Lazy Badger
    Feb 10, 2012 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, 2012 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, 2012 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, 2012 at 5:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .