Re: host versus nslookup
On Thu, Oct 13, 2011 at 1:05 PM, listmail wrote: > On Thu, 13 Oct 2011 03:33:30 +0700, Fajar A. Nugraha wrote >> If you're concern about what address programs gets when they resolve >> host names, then getent is a better choice as it also respects >> nsswitch.conf and hosts file. >> > According to the (almost useless) manpage for getent, Yes, it can be improved :) > all it does is lookups > in local files, not name resolution. > > I can see how this would be useful if you were not using DNS, but > If your purpose is to diagnose "can the DNS server used as resolver for my server resolve a particular FQDN", then either host or nslookup will usually suffice, with "dig" giving more detailed output. However, if your concern is "can my program find the IP address for a particular FQDN", then getent will give more accurate info as it also takes into consideration the content of nsswitch.conf and the sources listed on that file. So getent might search for local files, DNS, NIS, or whatever source listed for "hosts" database in nsswitch.conf. > What am I missing here? >From the man page: " The getent program gathers entries from the specified administrative database using the specified search keys. Where database is one of passwd, group, hosts, services, protocols, or networks. " In this particular case we're only interested in hosts. I found more detailed explanation in a Solaris reference, which basically say getent asks the database source in order specified in /etc/nsswitch.conf. So for example if your /etc/nsswitch.conf has something like this: hosts: files dns and your /etc/hosts has this entry 111.90.255.252 archive.ubuntu.com then getent and host will give different results for archive.ubuntu.com, since getent will search /etc/hosts first. $ host archive.ubuntu.com archive.ubuntu.com has address 91.189.92.180 archive.ubuntu.com has address 91.189.92.181 archive.ubuntu.com has address 91.189.92.182 archive.ubuntu.com has address 91.189.92.183 archive.ubuntu.com has address 91.189.92.184 archive.ubuntu.com has address 91.189.92.188 archive.ubuntu.com has address 91.189.92.190 archive.ubuntu.com has address 91.189.92.169 archive.ubuntu.com has address 91.189.92.170 archive.ubuntu.com has address 91.189.92.171 archive.ubuntu.com has address 91.189.92.176 archive.ubuntu.com has address 91.189.92.177 archive.ubuntu.com has address 91.189.92.179 $ getent hosts archive.ubuntu.com 111.90.255.252 archive.ubuntu.com on the other hand both will give same result for google.com (which is not in /etc/hosts) www.google.com is an alias for www.l.google.com. www.l.google.com has address 209.85.175.99 www.l.google.com has address 209.85.175.104 www.l.google.com has address 209.85.175.105 www.l.google.com has address 209.85.175.103 www.l.google.com has address 209.85.175.106 www.l.google.com has address 209.85.175.147 $ getent hosts www.google.com 209.85.175.99 www.l.google.com www.google.com 209.85.175.104 www.l.google.com www.google.com 209.85.175.105 www.l.google.com www.google.com 209.85.175.103 www.l.google.com www.google.com 209.85.175.106 www.l.google.com www.google.com 209.85.175.147 www.l.google.com www.google.com -- Fajar ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: host versus nslookup
On 10/13/2011 07:05 AM, listmail wrote: On Thu, 13 Oct 2011 03:33:30 +0700, Fajar A. Nugraha wrote If you're concern about what address programs gets when they resolve host names, then getent is a better choice as it also respects nsswitch.conf and hosts file. According to the (almost useless) manpage for getent, all it does is lookups in local files, not name resolution. It uses whatever "hosts" database plugins for nsswitch are enabled. In most cases, this is: hosts: files dns At least under recent versions of glibc, there are actually several modes you can use it in: getent hosts - list all static hosts entries getent hosts key - calls gethostbyname2(key) getent ahosts key - calls getaddrinfo(AF_UNSPEC, key) getent ahostsv4 key - calls getaddrinfo(AF_INET, key) getent ahostsv6 key - calls getaddrinfo(AF_INET6, key) There's no question in my mind that "getent hosts key" or "getent ahosts key" are the appropriate tools to duplicate "normal" app name resolution, because the utility mirrors the API most apps will call. But you usually need to run "dig" to compare raw DNS and find the different. nslookup should be taken out into the woods and left there... it's a horrible program. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: host versus nslookup
> host is four characters shorter. Use `dig' and save 25% ;-) `nslookup' must die. (Until a few years ago, it printed a deprecation notice which, unfortunately, has since been removed.) -JP ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Experience with DDNS (RFC 2136)
> I'm looking for success (or failure) stories to back up my statement :) Thank you all for replies, on and off-list. If you are interested in a summary, I've posted it at [1]. Regards, -JP [1] http://dnssexy.net/538 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: fallback to forwarder if master zone does not have requested record
On Oct 13, 2011, at 7:57 AM, Moser, Stefan (SIDB) wrote: > in customer migrations, when we shift customers from an old DNS environment > to a new DNS environment, there are sometimes situations where we have to > keep the same domain (let’s say “example.com”) both on the old DNS-server and > on the new DNS-server. E.g., there was an A record “mail.example.com” on the > old DNS-server “dns-old”, and an A record “sap.example.com” on the new > DNS-Server “dns-new”. It would be beneficial, if DNS-clients of “dns-new” > could resolve both “mail.example.com” and “sap.example.com”, across both > DNS-servers. One could do this by having "dns-old" switch to being a slave of the zone from "dns-new". Or remove any trace of configuration of "example.com" zone from "dns-old", and clients talking to "dns-old" will have it perform recursive resolution of the domain which will get data from "dns-new", just as it would for any other random domain. > I can’t think of a meaningful BIND configuration to “mix” both zones, because > of the inherent zone / authoritative model that DNS and BIND have and that > makes forwarders, masters and slaves mutually exclusive. What would be needed > was some kind of “fallback forwarder” that would forward requests it cannot > find in a zone that it is authoritative for. Um, yeah. If you configure a nameserver to be authoritative for a zone, then that zone needs to have every valid record. If an authoritative nameserver doesn't have all valid records, someone is doing it wrong. Regards, -- -Chuck ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Experience with DDNS (RFC 2136)
At 11 Oct 2011 13:57:38 +0100, Chris Thompson wrote: > >> Maybe an off topic in this thread, but out of curiosity, is there any > >> specific reason you don't use the database as the direct source of the > >> zone with BIND 9's dlz or PowerDNS? In general it will be slower, and > > > >I can't speak for Chris but here, we rejected DLZ and similar because: > > > > 1. DNSSEC > > 2. Speed > > 3. Impedance mismatch between database schema and DNS > > 4. Perceived second-class status of DLZ > > 5. Loss of various things that are automatic if using zones (IXFR) > > 6. Too-tight coupling between the SQL DB and DNS [...] > I have kept an eye on DLZ developments over the years, and thought quite > seriously about using it for the re-implementation of the hidden master > for our "managed zone service" (for vanity domains, although that's not > how we describe them to the punters), but even there it didn't work out, > primarily for Phil's reasons #5 and #6. I see, thanks. I think #6 is the most critical reason - other things can be solved via development/release engineering improvements, but this one seems to be about the system design policy, which wouldn't (easily) be changed due to a feature set or the quality of implementation. Since there appears to be a class of operators who prefer the "coupling" of DNS server and the database (from the fact that there are a non negligible number of users of DLZ and PowerDNS(+ database backend), this is probably a matter of operational philosophy. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: fallback to forwarder if master zone does not have requested record
On 10/13/2011 08:51, Chuck Swiger wrote: > Um, yeah. If you configure a nameserver to be authoritative for a zone, then > that zone needs to have every valid record. If an authoritative nameserver > doesn't have all valid records, someone is doing it wrong. Big +1. Having the same zone be different on old and new name servers is just asking for trouble. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
