resolv.conf and first nameserver lookup failures
in [Linux Networking]
|
From: Stefan Monnier on 9 Dec 2009 10:51 > But there is overlap. In that case, network A has one view of '.' and > network B has another view of '.'. The root domain is just much a > domain as any other domain. But that overlap has an obvious resolution. So while technically you can view it as an overlap, it does not generate ambiguities. So it should be technically possible to provide both views at the same time (e.g. by settgin up a local name-server that tries the two views and returns whichever view doesn't return a failure). Stefan
From: Moe Trin on 9 Dec 2009 14:57 On Wed, 09 Dec 2009, in the Usenet newsgroup comp.os.linux.networking, in article <hfnnnn$brn$1(a)nnrp.linuxfan.it>, Alessandro wrote: >ibuprofin(a)painkiller.example.tld (Moe Trin) >> No - you don't understand what glue records are. Glue records are >> pointers to the IP of the name server that is authoritative for a >> range. If your name servers have dynamic IP addresses and like to >> hide from everyone, the idiot who set up the networks needs to be >> shot. Repeatedly. >Uhuh I feel sick... ;) Someone in another newsgroup has a .sig that fits that situation: "Some people are alive only because it is illegal to kill them." I have seen some of the most bone-headed networking setups, and yet the people who set them up can't see anything wrong other than the fact that the networks don't work the way they imagine they should. Really need to add more chlorine to the gene pool. ;-) >> The glue records tell the name server to ask a different >> (authoritative) name server for answer, so that it can respond to >> the resolver making the original query. It's not the job of the >> resolver to figure out which name server to ask or to ask every >> name server it can find. >You are right, I didn't understand this concept. I'll have a deeper >look to this concept. It's a fairly common problem, especially with domains that have more than one facility - perhaps even in different countries. Trying to get all of the sub-domains to feed all of the latest changes to the poor admin who's _trying_ to keep the main name server up to date is a loosing battle. That's why child domains or sub-domains were created. >I am reading "DNS and BIND 5th edition" by O'Reilly and probably my >mind was absent when I was at page 211. ;-) That's a _great_ book, and probably has more appropriate details than the ISC BIND manual. My wife hates it when I get near a book store that's selling O'Reilly books, because I _always_ find yet another book I've got to have. >Thanks for helping me in getting deeper sight of this awesome world. Happy to be able to help! Old guy
From: Stefan Monnier on 9 Dec 2009 16:28 >> > But there is overlap. In that case, network A has one view of '.' and >> > network B has another view of '.'. The root domain is just much a >> > domain as any other domain. >> But that overlap has an obvious resolution. > It has many obvious resolutions. Only if you warp your mind. If you're a normal user, there's only one. >> �So while technically you can view it as an overlap, it does not >> generate ambiguities. �So it should be technically possible to >> provide both views at the same time (e.g. by settgin up a local >> name-server that tries the two views and returns whichever view >> doesn't return a failure). > But neither returned a failure in this case. NXDOMAIN is not a > failure, it is a definitive success condition. If you're a name-lookup-function, indeed. If you're a normal user, it's a failure (which normal users usually describe more precisely as "my thing doesn't work"). Stefan
From: David Schwartz on 10 Dec 2009 00:08 On Dec 9, 1:28 pm, Stefan Monnier <monn...(a)iro.umontreal.ca> wrote: > >> > But there is overlap. In that case, network A has one view of '.' and > >> > network B has another view of '.'. The root domain is just much a > >> > domain as any other domain. > >> But that overlap has an obvious resolution. > > It has many obvious resolutions. > Only if you warp your mind. If you're a normal user, there's only one. That's why normal users don't get to design networks. ;) > >> So while technically you can view it as an overlap, it does not > >> generate ambiguities. So it should be technically possible to > >> provide both views at the same time (e.g. by settgin up a local > >> name-server that tries the two views and returns whichever view > >> doesn't return a failure). > > But neither returned a failure in this case. NXDOMAIN is not a > > failure, it is a definitive success condition. > If you're a name-lookup-function, indeed. If you're a normal user, > it's a failure (which normal users usually describe more precisely as > "my thing doesn't work"). Right, but the point is that there's a good reason it doesn't work that needs to be addressed in a non-trivial way. You either need to flip a switch between networks or you need to design a consistent "synthesis view" of the two networks and implement that view somehow. There is no magic way to "just make it work" that won't break in horrible ways in situations just slightly more complex than this one. DS
From: Alessandro on 10 Dec 2009 03:23
-------- Original Message -------- Subject: Re: resolv.conf and first nameserver lookup failures From: ibuprofin(a)painkiller.example.tld (Moe Trin) To: Date: Wed Dec 09 2009 20:57:08 GMT+0100 (ora Solare Europa Occidentale) > On Wed, 09 Dec 2009, in the Usenet newsgroup comp.os.linux.networking, in > article <hfnnnn$brn$1(a)nnrp.linuxfan.it>, Alessandro wrote: > >> ibuprofin(a)painkiller.example.tld (Moe Trin) > > ;-) That's a _great_ book, and probably has more appropriate details > than the ISC BIND manual. My wife hates it when I get near a book > store that's selling O'Reilly books, because I _always_ find yet > another book I've got to have. Ahah my wife too. The difference is that I buy them at Amazon. I think we are all in the same boat (as a saying in my country states). -- AF |