resolv.conf and first nameserver lookup failures
in [Linux Networking]
|
From: Alessandro on 11 Dec 2009 10:58 -------- Original Message -------- Subject: Re: resolv.conf and first nameserver lookup failures From: Alessandro <faglia(a)gmail.com> To: Date: Wed Dec 09 2009 09:39:19 GMT+0100 (ora Solare Europa Occidentale) >> 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... ;) > > 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. > I tried to employ glue records but BIND get angry with my zone data. This the head of db.domain1.loc1 file (under /var/cache/bind): $ORIGIN . $TTL 86400 ; 1 day domain1.loc1 IN SOA box1.domain1.loc1. root.domain1.it. ( 20081136 ; serial 28800 ; refresh (8 hours) 14400 ; retry (4 hours) 2419200 ; expire (4 weeks) 604800 ; minimum (1 week) ) NS box1.domain1.loc1. MX 10 box1.domain1.loc1. ; glue records domain2.loc2. NS box2.domain2.loc2. box2.domain2.loc2. A 192.168.50.6 $ORIGIN domain1.loc1. box1 A 192.168.7.1 [remaining of the zone] When I restart the service BIND says (in syslog): ignoring out-of-zone data (domain2.loc2) ignoring out-of-zone data (box2.domain2.loc2) I fear that glue records cannot be employed if domain2.loc2 is not a subdomain of domain1.loc1 for which I am defining glue record. Is this true? -- AF
From: Moe Trin on 12 Dec 2009 22:30 On Fri, 11 Dec 2009, in the Usenet newsgroup comp.os.linux.networking, in article <hftq6a$uce$1(a)nnrp.linuxfan.it>, Alessandro wrote: >>> 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. >>> 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. >I tried to employ glue records but BIND get angry with my zone data. >$ORIGIN . >$TTL 86400 ; 1 day >domain1.loc1 IN SOA box1.domain1.loc1. root.domain1.it. ( > NS box1.domain1.loc1. > glue records >domain2.loc2. NS box2.domain2.loc2. >box2.domain2.loc2. A 192.168.50.6 Yes, there is some confusion here. Last Saturday, you wrote: >>Bear in mind that "domain1" and "domain2" are local domains, for >>instance "mydomain1.loc" and "mydomain2.loc". and I understood that meant that they were in a common domain 'loc'. The idea is that you would run a local server authoritative for this common domain - even if it doesn't answer for requests about that domain to anyone because it has no hosts at that level. It's merely a place-holder holding the two sub-domains. Your clients ask about `host.domain1.loc`, and the name server sees that the request is not for the 'loc' domain, but a sub-domain within that domain. >When I restart the service BIND says (in syslog): >ignoring out-of-zone data (domain2.loc2) >ignoring out-of-zone data (box2.domain2.loc2) Yes >I fear that glue records cannot be employed if domain2.loc2 is not a >subdomain of domain1.loc1 for which I am defining glue record. Is >this true? Yes - you have to be authoritative for the domain above both remotes. Old guy
From: Alessandro on 18 Dec 2009 12:00
David Brown wrote: > Chris Davies wrote: >> David Brown <david.brown(a)hesbynett.removethisbit.no> wrote: >>> Windows also seems to track DNS settings for each interface >>> individually, and it's possible that it will try the (primary) DNS >>> servers for each interface if it is getting NXDOMAIN. >> >> Empirically, I would tend to agree with you. I'm not sure about the >> NXDOMAIN, though: I'm pretty sure that Windows uses a particular DNS >> server for any given connection/domain. >> > > I'm not sure of the details of how Windows picks which DNS server to > use, but that sounds likely to me. I tried to sniff packets on my windows box while connected to several branches via OpenVPN and doing several pings to different hosts. What I found is that windows's ping tries for every VPN interface (it's a tap-like device for every connection I fire up) all DNS servers it can (a kind of union of all DNS server you have from "ipconfig /all") and if all this fails it tries WINS. The advantage over Linux (for what I can understand) is that it seeks for an answer even if previous servers says NXDOMAIN (as it happens by issueing nslookup). I think now the picture is clearer in that Linux (as said before) behaves "politely" but fails while windos plays dirty (by using WINS) but manages to have an answer. Thanks for all your input. -- AF |