Re: resolver doesn't see resolv.conf changes
Hajimu UMEMOTO wrote: Hi, Oops, it should be: http://www.imasy.or.jp/~ume/FreeBSD/nss_resinit-20060408.tar.gz Very nice. I wonder though, why has resinit to come before files? Shouldn't it be files resinit dns? Anyway, after some limited testing, it seems to work fine. Thanks a bunch! I hope this does make it into FreeBSD some time. Ulrich Spoerlein -- PGP Key ID: 20FEE9DD Encrypted mail welcome! Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD Which is worse: ignorance or apathy? Don't know. Don't care. pgp0bTGU00xhg.pgp Description: PGP signature
Re: resolver doesn't see resolv.conf changes
Lowell Gilbert wrote: Lowell Gilbert [EMAIL PROTECTED] writes: Ulrich Spoerlein [EMAIL PROTECTED] writes: Lyndon Nerenberg wrote: The solution is to run a local caching nameserver instance. You should do this anyway, for performance reasons. Add 'named_enable=YES' to /etc/rc.conf, and modify your /etc/dhclient.conf as follows: Good idea, but this defeates the hierarchical purpose of DNS. Now my caching DNS is always querying the root DNS servers. I worked around that by having dhclient-script rewrite the named.conf (to add a forwarders clause), and restart the named. I don't have a laptop any more, and this doesn't seem to be one of the scripts I keep around in my web pages, but I could go back to old backups for it... Oh, look I found it. This was with the old (ISC) dhclient, but I think it should work with the current one also. [snip] It's a bit of a hack, but it lets you use the DHCP-supplied nameserver without any glitches when the address for that server changes under you. Great, I though about something equally myself, as a cacheing nameserver would surely be handy. I'll give it a shot, but perhaps I can live with the simple append/prepend stuff for split DNS. I'll see how it goes. Thanks to all for the various suggestions. Ulrich Spoerlein -- PGP Key ID: 20FEE9DD Encrypted mail welcome! Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD Which is worse: ignorance or apathy? Don't know. Don't care. pgpfQEK3DzFEK.pgp Description: PGP signature
Re: resolver doesn't see resolv.conf changes
Hi, On Sun, 9 Apr 2006 18:06:31 +0200 Ulrich Spoerlein [EMAIL PROTECTED] said: spoerlein Very nice. I wonder though, why has resinit to come before files? spoerlein Shouldn't it be files resinit dns? Yup, it is enough to put resinit just before dns, and it should work. However, our resolver calls res_init(3) for some resolver options even when looking up /etc/hosts. So, I prefer to put resinit at first. spoerlein Anyway, after some limited testing, it seems to work fine. Thanks a spoerlein bunch! I hope this does make it into FreeBSD some time. Thank you for testing. I've uploaded new tarball which includes a manpage, little while ago: http://www.imasy.or.jp/~ume/FreeBSD/nss_resinit-20060410.tar.gz I think there is no inevitability to commit it into our base tree. Perhaps, the ports is good place. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: resolver doesn't see resolv.conf changes
Dmitry Pryanishnikov wrote: Hello! On Sat, 8 Apr 2006, Ulrich Spoerlein wrote: Good idea, but this defeates the hierarchical purpose of DNS. Now my caching DNS is always querying the root DNS servers. Sorry, but what kind of hierarchy does it defeat? If client's query can't be satisfied from provider's DNS cache, and doesn't refer to domain which is hosted on ISP, then provider's DNS server will make first query to root DNS server, and then will walk down domain hierarchy (e.g. .ua - .dp.ua - atlantis.dp.ua). So setting client's DNS to directly query root servers defeats just the provider's DNS cache. Exactly. Since I have the honour to use a dialup connection regularly, I'd rather have a forwarding-only DNS server, since that will cut down the number of DNS packets on the dialup-link tremendously. The dhclient/named hacks are all very nice, but additionally I'll need the same in ppp.linkup. And there might be ISPs who disallow outgoing DNS connections to somewhere else than their own DNS servers. Not us ;) Lucky you, but I'd rather go the local route, since this should always work and be faster (provided the ISP's named is not overloaded) Ulrich Spoerlein -- PGP Key ID: 20FEE9DD Encrypted mail welcome! Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD Which is worse: ignorance or apathy? Don't know. Don't care. pgp8iQ5tP5kt2.pgp Description: PGP signature
Re: resolver doesn't see resolv.conf changes
Hajimu UMEMOTO wrote: [resinit patch] It seems working on my 7-CURRENT box and 6-STABLE box. However, it should be tested more. Thanks! I'll give it a try. Though it takes me a while to roam around, I'll report back! Ulrich Spoerlein -- PGP Key ID: 20FEE9DD Encrypted mail welcome! Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD Which is worse: ignorance or apathy? Don't know. Don't care. pgp0MdkBoGuuz.pgp Description: PGP signature
Re: resolver doesn't see resolv.conf changes
Lyndon Nerenberg wrote: The solution is to run a local caching nameserver instance. You should do this anyway, for performance reasons. Add 'named_enable=YES' to /etc/rc.conf, and modify your /etc/dhclient.conf as follows: Good idea, but this defeates the hierarchical purpose of DNS. Now my caching DNS is always querying the root DNS servers. And there might be ISPs who disallow outgoing DNS connections to somewhere else than their own DNS servers. Additionally, when jacking into someone else's LAN, I usually want to use their local DNS servers, to resolve local names. Ulrich Spoerlein -- PGP Key ID: 20FEE9DD Encrypted mail welcome! Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD Which is worse: ignorance or apathy? Don't know. Don't care. pgp68J1y3knIY.pgp Description: PGP signature
Re: resolver doesn't see resolv.conf changes
Ulrich Spoerlein [EMAIL PROTECTED] writes: Lyndon Nerenberg wrote: The solution is to run a local caching nameserver instance. You should do this anyway, for performance reasons. Add 'named_enable=YES' to /etc/rc.conf, and modify your /etc/dhclient.conf as follows: Good idea, but this defeates the hierarchical purpose of DNS. Now my caching DNS is always querying the root DNS servers. I worked around that by having dhclient-script rewrite the named.conf (to add a forwarders clause), and restart the named. I don't have a laptop any more, and this doesn't seem to be one of the scripts I keep around in my web pages, but I could go back to old backups for it... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: resolver doesn't see resolv.conf changes
Lowell Gilbert [EMAIL PROTECTED] writes:
Ulrich Spoerlein [EMAIL PROTECTED] writes:
Lyndon Nerenberg wrote:
The solution is to run a local caching nameserver instance. You should
do this anyway, for
performance reasons. Add 'named_enable=YES' to /etc/rc.conf, and modify
your
/etc/dhclient.conf as follows:
Good idea, but this defeates the hierarchical purpose of DNS. Now my
caching DNS is always querying the root DNS servers.
I worked around that by having dhclient-script rewrite the named.conf
(to add a forwarders clause), and restart the named. I don't have a
laptop any more, and this doesn't seem to be one of the scripts I keep
around in my web pages, but I could go back to old backups for it...
Oh, look I found it. This was with the old (ISC) dhclient, but I
think it should work with the current one also.
dhclient-enter-hooks looked like this:
#!/bin/sh
realfile=/etc/namedb/forwarders-list
tempfile=${realfile}-temp
if [ x$new_domain_name_servers != x ]; then
echo ' forwarders {' $realfile
for n in $new_domain_name_servers ; do
if [ ${n} != 127.0.0.1 ] ; then
echo ${n}; $realfile
fi
done
echo }; $realfile
else
cp $realfile $tempfile
fi
if ! diff $realfile $tempfile /dev/null ; then
cpp -P -C /etc/namedb/named.conf /etc/namedb/named.usable.conf
ndc reload
fi
where as you can probably tell I was using a dhclient.conf that
included
prepend domain-name-servers 127.0.0.1;
in order to get the standard resolv.conf rewriting to put the local
nameserver at the top preference.
named was configured to use named.usable.conf, which was built from a
named.conf that had '#include forwarders-list' in its top-level
options.
It's a bit of a hack, but it lets you use the DHCP-supplied nameserver
without any glitches when the address for that server changes under
you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: resolver doesn't see resolv.conf changes
Ulrich Spoerlein wrote: Lyndon Nerenberg wrote: The solution is to run a local caching nameserver instance. You should do this anyway, for performance reasons. Add 'named_enable=YES' to /etc/rc.conf, and modify your /etc/dhclient.conf as follows: Good idea, but this defeates the hierarchical purpose of DNS. Now my caching DNS is always querying the root DNS servers. Yes, and is actually sending valid queries driven by a human trying to do something useful. Serving legitimate traffic isn't a problem for the root nameservers, but you could always set up a forwarder line to use the local ISP's nameserver first. [ The root nameservers are seeing upwards of 90% bogus queries (ie, invalid queries, misplaced assertions from DNS servers claiming to be root nameservers themselves, Kaspersky-style DoS attacks, etc). ] And there might be ISPs who disallow outgoing DNS connections to somewhere else than their own DNS servers. There are people offering walled gardens which prevent normal Internet access but provide some limited services; such aren't really ISPs, though. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: resolver doesn't see resolv.conf changes
Hello! On Sat, 8 Apr 2006, Ulrich Spoerlein wrote: Good idea, but this defeates the hierarchical purpose of DNS. Now my caching DNS is always querying the root DNS servers. Sorry, but what kind of hierarchy does it defeat? If client's query can't be satisfied from provider's DNS cache, and doesn't refer to domain which is hosted on ISP, then provider's DNS server will make first query to root DNS server, and then will walk down domain hierarchy (e.g. .ua - .dp.ua - atlantis.dp.ua). So setting client's DNS to directly query root servers defeats just the provider's DNS cache. And there might be ISPs who disallow outgoing DNS connections to somewhere else than their own DNS servers. Not us ;) Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: [EMAIL PROTECTED] nic-hdl: LYNX-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: resolver doesn't see resolv.conf changes
On Sat, 8 Apr 2006, Dmitry Pryanishnikov wrote: DP Sorry, but what kind of hierarchy does it defeat? If client's query DP can't be satisfied from provider's DNS cache, and doesn't refer to DP domain which is hosted on ISP, then provider's DNS server will make DP first query to root DNS server, and then will walk down domain hierarchy DP (e.g. .ua - .dp.ua - atlantis.dp.ua). So setting client's DNS to directly DP query root servers defeats just the provider's DNS cache. Not in other ways delegated domains, i.e. XXX.local. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: resolver doesn't see resolv.conf changes
Hello! On Sat, 8 Apr 2006, Dmitry Morozovsky wrote: DP Sorry, but what kind of hierarchy does it defeat? If client's query DP can't be satisfied from provider's DNS cache, and doesn't refer to DP domain which is hosted on ISP, then provider's DNS server will make DP first query to root DNS server, and then will walk down domain hierarchy DP (e.g. .ua - .dp.ua - atlantis.dp.ua). So setting client's DNS to directly DP query root servers defeats just the provider's DNS cache. Not in other ways delegated domains, i.e. XXX.local. I think that we're talking about official domain hierarchy here, aren't we? And those XXX.local and YYY.homenet domains are outside this hierarchy. And, BTW, ISP clients are rarely interested in internal ISP's .local domains. They're interested in ISP servers (SMTP, POP3/IMAP, NNTP, WEB), and these servers usually have official names in public ISP domains, accessible via official hierarchy (down from root servers). Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: [EMAIL PROTECTED] nic-hdl: LYNX-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: resolver doesn't see resolv.conf changes
On Sat, 8 Apr 2006, Dmitry Pryanishnikov wrote: DP DP Sorry, but what kind of hierarchy does it defeat? If client's query DP DP can't be satisfied from provider's DNS cache, and doesn't refer to DP DP domain which is hosted on ISP, then provider's DNS server will make DP DP first query to root DNS server, and then will walk down domain DP hierarchy DP DP (e.g. .ua - .dp.ua - atlantis.dp.ua). So setting client's DNS to DP directly DP DP query root servers defeats just the provider's DNS cache. DP DP Not in other ways delegated domains, i.e. XXX.local. DP DP I think that we're talking about official domain hierarchy here, aren't we? DP And those XXX.local and YYY.homenet domains are outside this hierarchy. And, DP BTW, ISP clients are rarely interested in internal ISP's .local domains. DP They're interested in ISP servers (SMTP, POP3/IMAP, NNTP, WEB), and these DP servers usually have official names in public ISP domains, accessible via DP official hierarchy (down from root servers). Situations vary. There may be patterns where one laptop should be involved in corporate networks with .local (and somewhat restricted or even faschist-style outgoing firewalls; I *do* know some organizations where you can't even ssh out without organizational problems) and some possibly totally different public networks. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: resolver doesn't see resolv.conf changes
On Apr 8, 2006, at 1:39 AM, Ulrich Spoerlein wrote: Good idea, but this defeates the hierarchical purpose of DNS. Now my caching DNS is always querying the root DNS servers. That's how the DNS works. You query the root once for the TLD, then cache the NS records for the TLD's servers, point one level down, and repeat until you find the target. And there might be ISPs who disallow outgoing DNS connections to somewhere else than their own DNS servers. In my experience, these are few and far between. Additionally, when jacking into someone else's LAN, I usually want to use their local DNS servers, to resolve local names. And sites running split-DNS are also rare. But worry not: dhclient can deal with these, too. A quick perusal of dhclient.conf(5) turns up the prepend and append modifiers. Choose whichever best implements your preferred policy. The two scenarios you describe are rare enough that it's not worth writing glue to fudge up forwarders entries in named.conf and the associated headaches. Or, you could port nscd over from Solaris. --lyndon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: resolver doesn't see resolv.conf changes
Hi, On Wed, 5 Apr 2006 17:27:19 +0200 Ulrich Spoerlein [EMAIL PROTECTED] said: spoerlein Is the resolver supposed to periodically check for updates to the spoerlein resolv.conf, or are the applications somehow caching the IP of the DNS spoerlein server? Traditionally, the resolver doesn't reread resolv.conf. It is not useful for especially mobile environment. So, I wrote a patch to reread resolv.conf in past. Recently, I noticed that it could be implemented as a NSS plug-in, and made it just today. You can get it from: http://www.imasy.or.jp/FreeBSD/nss_resinit-20060408.tar.gz I don't write any documentation, yet. But, it should work by changing `hosts' entry in /etc/nsswitch.conf to the following line: hosts: resinit files dns It seems working on my 7-CURRENT box and 6-STABLE box. However, it should be tested more. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: resolver doesn't see resolv.conf changes
Hi, On Fri, 7 Apr 2006 12:15:54 -0400 Rong-En Fan [EMAIL PROTECTED] said: grafan The file is not there. I got 404. Oops, it should be: http://www.imasy.or.jp/~ume/FreeBSD/nss_resinit-20060408.tar.gz Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: resolver doesn't see resolv.conf changes
cite from=Hajimu UMEMOTO Hi, On Wed, 5 Apr 2006 17:27:19 +0200 Ulrich Spoerlein [EMAIL PROTECTED] said: spoerlein Is the resolver supposed to periodically check for updates to the spoerlein resolv.conf, or are the applications somehow caching the IP of the DNS spoerlein server? Traditionally, the resolver doesn't reread resolv.conf. It is not useful for especially mobile environment. So, I wrote a patch to reread resolv.conf in past. Recently, I noticed that it could be implemented as a NSS plug-in, and made it just today. You can get it from: http://www.imasy.or.jp/FreeBSD/nss_resinit-20060408.tar.gz I don't write any documentation, yet. But, it should work by changing `hosts' entry in /etc/nsswitch.conf to the following line: hosts: resinit files dns It seems working on my 7-CURRENT box and 6-STABLE box. However, it should be tested more. Alternatively, it is possible to use caching DSN server on local machine. In reslolv.conf you can write 'nameserver 127.0.0.1' and then reconfigure and restart bind than connecting to different networks. Applications still use 127.0.0.1 as nameserver. And no any patches. Works for me. May be not suitable for all situations. :) -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: resolver doesn't see resolv.conf changes
when switching my laptop from LAN to a dialup connection, applications started _before_ the switch will still try to send DNS queries to my local DNS server. This isn't ideal, and the only workaround I've found so far is to restart the application. Is the resolver supposed to periodically check for updates to the resolv.conf, or are the applications somehow caching the IP of the DNS server? If you're the author of the application you can periodically unset a RES_INIT bit mask option in _res.options. Next time your application will try to call res_send() it will call res_init() at first. This is according to a resolver(3) manual page. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: resolver doesn't see resolv.conf changes
Is the resolver supposed to periodically check for updates to the
resolv.conf, or are the applications somehow caching the IP of the DNS
server?
No, resolv.conf is only read once when the resolver routines initialize.
The solution is to run a local caching nameserver instance. You should do
this anyway, for performance reasons. Add 'named_enable=YES' to
/etc/rc.conf, and modify your /etc/dhclient.conf as follows:
interface ath0 {
supersede domain-name orthanc.ca;
supersede domain-name-servers 127.0.0.1;
}
interface bge0 {
supersede domain-name orthanc.ca;
supersede domain-name-servers 127.0.0.1;
}
Change the domain string to something more appropriate, and adjust the
interface names to match your laptop. You'll need to start named and
restart the dhclient instances (in that order) for the changes to take
effect.
--lyndon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
