Returned mail: User unknown
postoffice at isc.org
postoffice at isc.org
Tue Apr 2 00:56:56 UTC 2013
The original message was received at 2004-06-16 09:14:35 +0800
from postoffice. [10.0.0.1]
----- The following addresses had permanent fatal errors -----
<leungwai at pacific.net.hk>
-----Transcript of session follows -----
... while talking to postoffice..:
>>> RCPT To:<leungwai at pacific.net.hk>
<<< 550 5.1.1 unknown or illegal alias: leungwai at pacific.net.hk
550 <leungwai at pacific.net.hk>... User unknown
-- Attached file included as plaintext by Ecartis --
Reporting-MTA: dns; postoffice.
Received-From-MTA: DNS; postoffice.
Arrival-Date: 2004-06-16 09:14:35 +0800
Final-Recipient: RFC822; leungwai at pacific.net.hk
Action: failed
Status: 5.1.1
Remote-MTA: DNS; postoffice.
Diagnostic-Code: SMTP;550 5.1.1 unknown or illegal alias: leungwai at pacific.net.hk
Last-Attempt-Date: 2004-06-16 09:14:35 +0800
-- Attached file included as plaintext by Ecartis --
Return-Path: <bind-users-bounce at isc.org>
Received: from tko.pacific.net.hk ([202.64.33.138])
by mxrelay1.pacific.net.hk with ESMTP
id <20040615075202.QOOZ6016.mxrelay1.pacific.net.hk at tko.pacific.net.hk>
for <leungwai at pacific.net.hk>; Tue, 15 Jun 2004 15:52:02 +0800
Received: from tko.pacific.net.hk (localhost [127.0.0.1])
by tko.pacific.net.hk with ESMTP
id i5F7q1is012650 for <leungwai at pacific.net.hk>; Tue, 15 Jun 2004 15:52:01 +0800 (CST)
Received: from antispam2.pacific.net.hk (antispam2.pacific.net.hk [202.14.67.107])
by tko.pacific.net.hk with ESMTP
id i5F7q1l9012645 for <leungwai at pacific.net.hk>; Tue, 15 Jun 2004 15:52:01 +0800 (CST)
Received: from mx-2.isc.org (mx-2.isc.org [204.152.184.170])
by antispam2.pacific.net.hk with ESMTP
id i5F7prmJ032029 for <leungwai at pacific.net.hk>; Tue, 15 Jun 2004 15:51:58 +0800
Received: from rc3.isc.org (rc3.isc.org [IPv6:2001:4f8:3:bb:209:5bff:fe05:1b9c])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
by mx-2.isc.org (Postfix) with ESMTP
id 2FFA28D776; Tue, 15 Jun 2004 07:51:26 +0000 (UTC)
(envelope-from bind-users-bounce at isc.org)
Received: from rc3.isc.org (rc3.isc.org [204.152.187.25])
by rc3.isc.org (Postfix) with ESMTP id AA3875C8E2;
Tue, 15 Jun 2004 07:50:59 +0000 (UTC)
(envelope-from bind-users-bounce at isc.org)
Received: with ECARTIS (v1.0.0; list bind-users); Tue, 15 Jun 2004 07:50:00 +0000 (UTC)
Date: Tue, 15 Jun 2004 07:50:00 +0000 (UTC)
From: BIND Users Mailing List <bind-users at isc.org>
To: bind-users digest users <ecartis at isc.org>
Subject: bind-users Digest V6 #153
Precedence: bulk
List-unsubscribe: <mailto:bind-users-request at isc.org?Subject=unsubscribe>
List-Id: <bind-users.isc.org>
X-List-ID: <bind-users.isc.org>
Message-Id: <20040615075059.AA3875C8E2 at rc3.isc.org>
bind-users Digest Mon, 14 Jun 2004 Volume: 06 Issue: 153
In This Issue:
Re: Re: Any problems with gcc 3 and bind 9?
Re: Dnsbl / bind in harmony
Re: Non-local DNS resolution question
Re: Still Having Intermittent Issues Resovling External Doma
Looking for DNS reverse lookup service
Event Id 5774
recursive-clients, what value ?
Re: Newbie needs help - non-authoritative lookup, reverse zo
batch reverse dns lookup
Looking for DNS reverse lookup service
RE: batch reverse dns lookup
Re: Newbie needs help - non-authoritative lookup, reverse zo
Re: batch reverse dns lookup
RE: batch reverse dns lookup
dynamic DNS issues - invalid TSIG key
Re: batch reverse dns lookup
RE: batch reverse dns lookup
Re: dynamic DNS issues - invalid TSIG key
rndc reload / rndc reconfig do not add new zones from includ
Re: Event Id 5774
Re: Event Id 5774
Re: 'dig -t any ...' question
Re: recursive-clients, what value ?
Re: batch reverse dns lookup
Re: Looking for DNS reverse lookup service
Re: Non-local DNS resolution question
RE: recursive-clients, what value ?
Re: 'dig -t any ...' question
TCP vs. UDP in query responses?
Re: Non-local DNS resolution question
Re: 'dig -t any ...' question
RE: TCP vs. UDP in query responses?
Re: TCP vs. UDP in query responses?
Re: TCP vs. UDP in query responses?
Re: 'dig -t any ...' question
Re: Looking for DNS reverse lookup service
OT: yahoo dns
Re: TCP vs. UDP in query responses?
Re: bind9-users Digest V5 #155
Re: recursive-clients, what value ?
Re: [PATCH] resolv.conf addition for mobile users
Re: 'dig -t any ...' question
Re: OT: yahoo dns
Re: Non-local DNS resolution question
redundant web servers
Re: recursive-clients, what value ?
RE: recursive-clients, what value ?
auth-nxdomain yes
Re: recursive-clients, what value ?
Re: bind9-users Digest V5 #155
----------------------------------------------------------------------
Date: Mon, 14 Jun 2004 11:34:44 +0400
From: Ladislav Vobr <lvobr at ies.etisalat.ae>
Subject: Re: Re: Any problems with gcc 3 and bind 9?
> Using libgcc.so.3.0 ??
not sure I used 'out of the box' gcc 3.3.0, packaged with FreeBSD 5.2.1
distribution.
Ladislav
------------------------------
Subject: Re: Dnsbl / bind in harmony
From: wrolf.courtney at donovandata.com
Date: Mon, 14 Jun 2004 11:29:51 -0400
Simple with BIND 9. Have BIND listend on 53, but forward queries for your
DNSBL to djbdns on another port:
zone "your.zone.com" IN {
type forward;
forward first;
forwarders {
127.0.0.1 port 650;
};
};
See http://www.surbl.org/rbldnsd-bind-freebsd.html for more details.
Wrolf Courtney
bind9-users-bounce at isc.org wrote on 06/07/2004 01:42:13 PM:
> Hello,
>
> I'd like to configure a nameserver machine to perform both bind style
zone
> transfers and also djbdns rbldns . Has anyone done this? I don't like
the
> idea of using tinydns to do the zone transfers since ixfr isn't
supported.
> The purpose of this is to run both spamcop rsync rblddns style and maps
zone
> file based transfers.
>
> Thanks
> Dan Durrer
>
>
------------------------------
Date: Mon, 14 Jun 2004 11:25:11 -0500
From: Robert Lowe <Robert.H.Lowe at lawrence.edu>
Subject: Re: Non-local DNS resolution question
Jim Reid wrote:
>>>>>>"Robert" == Robert Lowe <Robert.H.Lowe at lawrence.edu> writes:
>
>
> >> Having scanned the archives, it appears I put:
> >>
> >> digitalriver.com NS fc-2kdc-01.fireclick.com.
> >> digitalriver.com NS fc-2kdc-02.fireclick.com.
> >> fc-2kdc-01.fireclick.com. A 192.168.254.26
> >> fc-2kdc-02.fireclick.com. A 192.168.254.27
>
> >> in the root zone file.
>
> Robert> No, don't do this. Use a forward zone in your named.conf files
>
> No! Don't do this either. A DNS "solution" that involves forwarding is
> almost certainly broken. Configure your local name server(s) as slaves
> for the digitalriver.com zone. These servers don't have to be listed
> in the NS records for digitalriver.com. This way your local name
> servers will be less dependent on the existing digitalriver.com
> servers and your overall DNS infrastructure will therefore be more
> robust and stable.
Late getting back to this... if he has the option of acting as a slave,
and both parties are willing to do the work (and it might be trivial,
but if there are lots of zones, it may not be), then I'll agree. If not,
there is nothing inherently "broken" about using a forward zone (and yes,
Bob, one entry will cover all subdomains). Interacting with private partner
networks is what it's there for, and while some may misuse the feature, and
others just don't like it, that's not to say it should be avoided at all
costs.
-Robert
------------------------------
Date: Mon, 14 Jun 2004 12:42:37 -0400
From: Joel M Nimety <jnimety at cybergnostic.com>
Subject: Re: Still Having Intermittent Issues Resovling External Domains
Hello all -- Just thought I'd give an update on this issue. We recently
replaced our Alteon 708 core with a new Riverstone. After this
migration our dns problems have been solved.
Specifically two devices were removed from the dns->internet path:
Old:
Crossbeam->alteon180e_external->alteon708->alteon180e_internal->dns_server_farm
New:
Crossbeam->Riverstone->alteon180e_internal->dns_server_farm
We still don't know whether the 180e_external or 708 was causing the
problem.
Thanks everyone for you help. -- Joel
Joel M Nimety wrote:
> We are still experiencing problems:
>
> > We're experiencing intermittent issues resolving domain names. Often
> > these domains are microsoft.com, cnn.com, etc. We are running 3
> > identical servers and sometime they can go a week or two without any
> > trouble (othertimes only hours), then without warning one server will
> > be unable to perform a recursive lookup for a few domains.
> >
> > rndc flush has no effect, restarting bind fixes any problems.
>
> Someone suggested that it may be a firewall issue. We have contacted
> our fw vendor and made changes to allow all dns traffic through. This
> didn't fix the problem.
>
> Next, I installed bind 9.3beta4 on one of the machines and forced edns
> size to 512. About an hour later this box failed.
>
> We are getting desperate. I can provide tcpdumps and configs if
> necessary.
>
> Many thanks to anyone who can help.
>
> --
> Joel Nimety
>
>
>
--
Joel Nimety
------------------------------
From: "Dave Humes" <david.humes at jhuapl.edu>
Subject: Looking for DNS reverse lookup service
Date: Mon, 14 Jun 2004 12:53:34 -0400
A few weeks ago I stumbled accross a for-fee service that claimed to provide
all the names associated with an IP address rather than just the single name
that you get with a typical nslookup reverse lookup. Unfortunately, I
forgot to bookmark the site and have now googled through about 20 pages
without success. Can anyone provide a referal for this service?
Thanks.
--Dave
------------------------------
From: "Jim Carver" <jcarver at carverscomputer.com>
Subject: Event Id 5774
Date: Mon, 14 Jun 2004 09:23:46 -0700
Recently I setup Windows Server 2000, the DNS Server. I
keep getting the same error I don't how to fix it. The error is
Event Type: Error
Event Source: NETLOGON
Event Category: None
Event ID: 5774
Date: 6/12/2004
Time: 6:58:53 PM
User: N/A
Computer: WOLF
Description:
Registration of the DNS
record '_kpasswd._udp.carverscomputer.com. 600 IN SRV 0
100 464 wolf.carverscomputer.com.' failed with the
following error:
DNS server unable to interpret format.
Data:
0000: 29 23 00 00 )#..
How do you fix it?
Thank you
------------------------------
Date: Mon, 14 Jun 2004 15:09:31 +0200
From: Mikael <pub.nospam at grizzli.org>
Subject: recursive-clients, what value ?
Hello,
I'm working on bind 9.2 on linux mandrake and I had lots of logs
containing :
Jun 14 09:23:30 hostname named[1045]: client: client 127.0.0.1#34559: no
more recursive clients: quota reached
Jun 14 09:25:22 hostname named[1045]: client: client 127.0.0.1#34565: no
more recursive clients: quota reached
I read that increasing "recursive-clients" could help. I'm going to set
it to 2000 but is there a way to know what would be a good value ?
Is there a way to monitor in real time the number of simultaneous clients ?
Thanks in advance,
Mikael
------------------------------
From: kalahari875 at netscape.net (Arthur Penn)
Subject: Re: Newbie needs help - non-authoritative lookup, reverse zone
Date: 13 Jun 2004 14:23:32 -0700
Thanks for your reply. I found a very good article that helped me get
things straightened out
(http://www.linuxgazette.com/issue44/pollman/dns.html). This cleared
up some of the significant confusion I had about setting up DNS with
BIND 9.
Regarding keeping the Mandrake DHCP daemon from overwriting
/etc/resolv.conf, the following seems to have done the trick:
> To override that action edit /etc/sysconfig/network-scripts/ifcfg-eth0
> (1,2 etc) and add the line
>
> PEERDNS=no
What is the significance of the line "$TTL 1d" that appears at the
start of named.local? In the example article above, the zone files did
not have this, and BIND doesn't seem to mind--it messages about
assuming a value. Should I set this, and what does it mean?
Also, where do I place the "allow update" text to allow DNS to update
the zone files (or did I misunderstand what that does)?
The zone files I ended up with follow:
[named.local]
@ IN SOA pest.supergnat.org. root.supergnat.org. (
1997022700 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS localhost.
1 IN PTR localhost.
[named.supergnat]
@ IN SOA pest.supergnat.org root.supergnat.org (
1;
10800;
3600;
604800;
86400 );
IN NS pest.supergnat.org.
pest IN A 192.168.71.1
localhost IN A 127.0.0.1
computer1 IN A 192.168.71.2
computer2 IN A 192.168.71.3
computer3 IN A 192.168.71.4
[named.192-168-71]
@ IN SOA pest.supergnat.org. root.supergnat.org. (
1;
10800;
3600;
604800;
86400 );
IN NS pest
1 IN PTR pest
2 IN PTR computer1
3 IN PTR computer2
4 IN PTR computer3
/dev/rob0 <rob0 at gmx.co.uk> wrote in message news:<c9o5ou$5c6$1 at sf1.isc.org>...
> On Wednesday 02 June 2004 09:51, Arthur Penn wrote:
> > How can I fix this? (Conf files follow below)
>
> Log output might have helped more. In your logs it probably says which
> RR's dhcpd is trying to change and what errors result.
>
> > 2) I set up a reverse lookup zone to try to resolve names of machines
> > on the local net. Since most of the local machines have their IP
> > addresses set by DHCP from the router, how can I get the entries for
> > these machine names to show up automatically in the zone file?
>
> named.conf might have helped too. This router (running dhcpd) is also
> the nameserver? Show your zone declarations for supergnat.org and
> 71.168.192.in-addr.arpa. Did you "allow-update localhost;" in each?
>
> > 3) I had changed /etc/resolv.conf before to remove the nameservers of
> > my ISP that DHCP placed there and use my local DNS, but sometime
> > today something overwrote /etc/resolv.conf and put the ISP's DNSes
> > back in there. How can I stop this?
>
> Change your DHCP client such that it does not overwrite resolv.conf. If
> you're using dhcpcd(8), it's the -R option. If you're using something
> else you'll have to look it up. If none of that makes any sense to you
> at all, ask this question on a Mandrake forum (and take all the advice
> you receive with a grain of salt. :)
>
> > [/var/named/192-168-71.zone]
> > NS pest.supergnat. ; naneserver address
>
> Not "pest.supergnat.org."? Where's the "org."? Why no "A" records? Is
> this supposed to be the forward zone or the reverse?
>
> > [/var/named/named.local]
> > @ IN SOA pest.supergnat. root.supergnat. (
>
> Again no "org."
>
> > IN NS pest.supergnat.
> >
> > 1 IN PTR localhost.
>
> This looks like a reverse zone. The name makes it sound like a forward
> zone. Why do you want 192.168.71.1 to resolve to "localhost."? You're
> giving out incorrect information. Say, if you're on 192.168.71.2,
> assuming it's a different machine, then 1.71.168.192.in-addr.arpa. is
> NOT "localhost".
>
> Have you looked at the BIND 9 ARM? You have it in HTML, probably in
> /usr/share/doc/bind-$VERSION.
------------------------------
From: "Andy Peters" <abuse at 127.0.0.1>
Subject: batch reverse dns lookup
Date: Sat, 12 Jun 2004 17:36:44 +0100
Hi i don't know if this is quite the group to ask this in (you are the dns
guru's ?) so feel free to offer alternative group suggestions
here's the problem, i have a list of domains (26,000+) in plain text format
(its a hosts file to be exact) and i would like to seperate the domains that
resolve to an ip from the ones that don't (to clean up the list and remove
invalid and dead entries)
any idea how i might achieve it ? i would of thought a quick bash or batch
script could do this but not having any experience in shell scripts i dont
know how i could do this
any help or pointers would be appreciated (i have access to
suse/knoppix/win*/)
cheers folks
Andy P
------------------------------
From: "Humes, David G." <David.Humes at jhuapl.edu>
Subject: Looking for DNS reverse lookup service
Date: Mon, 14 Jun 2004 13:31:21 -0400
A few weeks ago I ran accross a for-fee service that claimed to provide all
the names associated with an IP address rather than just the single name
that you get with a typical nslookup reverse lookup. Unfortunately, I
forgot to bookmark the site and have now googled through about 20 pages
without success. Can anyone provide a referal for this service?
Thanks.
--Dave
------------------------------
From: Richard Peiper <rpeiper at waca.com>
Subject: RE: batch reverse dns lookup
Date: Mon, 14 Jun 2004 13:42:57 -0400
I am sure someone can do this off the top of their head. I can do
one for you in Perl5 if you have access to that in probably 15 mins. In the
middle of a cleanup of some issues right now so I wouldn't have it done
until the end of the week. Let me know if you still need it and I can write
a quick loop thru the file, ping each one and generate 2 lists.
Richard
-----Original Message-----
From: Andy Peters [mailto:abuse at 127.0.0.1]
Sent: Saturday, June 12, 2004 12:37 PM
To: comp-protocols-dns-bind at isc.org
Subject: batch reverse dns lookup
Hi i don't know if this is quite the group to ask this in (you are the dns
guru's ?) so feel free to offer alternative group suggestions
here's the problem, i have a list of domains (26,000+) in plain text format
(its a hosts file to be exact) and i would like to seperate the domains that
resolve to an ip from the ones that don't (to clean up the list and remove
invalid and dead entries)
any idea how i might achieve it ? i would of thought a quick bash or batch
script could do this but not having any experience in shell scripts i dont
know how i could do this
any help or pointers would be appreciated (i have access to
suse/knoppix/win*/)
cheers folks
Andy P
------------------------------
From: Barry Margolin <barmar at alum.mit.edu>
Subject: Re: Newbie needs help - non-authoritative lookup, reverse zone
Date: Mon, 14 Jun 2004 14:04:15 -0400
In article <caknap$14ud$1 at sf1.isc.org>,
kalahari875 at netscape.net (Arthur Penn) wrote:
> Thanks for your reply. I found a very good article that helped me get
> things straightened out
> (http://www.linuxgazette.com/issue44/pollman/dns.html). This cleared
> up some of the significant confusion I had about setting up DNS with
> BIND 9.
>
> Regarding keeping the Mandrake DHCP daemon from overwriting
> /etc/resolv.conf, the following seems to have done the trick:
> > To override that action edit /etc/sysconfig/network-scripts/ifcfg-eth0
> > (1,2 etc) and add the line
> >
> > PEERDNS=no
>
> What is the significance of the line "$TTL 1d" that appears at the
> start of named.local? In the example article above, the zone files did
> not have this, and BIND doesn't seem to mind--it messages about
> assuming a value. Should I set this, and what does it mean?\
$TTL specifies the default TTL to use for records that don't have an
explicit TTL. Earlier versions of BIND uses the Minimum field from the
SOA record for this; that gets used as a fallback for backward
compatibility if you leave out $TTL.
You really should get the DNS & BIND book....
>
> Also, where do I place the "allow update" text to allow DNS to update
> the zone files (or did I misunderstand what that does)?
You only need this if you're making use of dynamic update (e.g. a DHCP
server adding/deleting entries as it assigns addresses).
If you need it, it goes in named.conf.
--
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
------------------------------
From: "Masood Ahmad Shah" <masood at nexlinx.net.pk>
Subject: Re: batch reverse dns lookup
Date: Mon, 14 Jun 2004 23:21:36 +0500
I will suggest better to write script in perl or shell ........that will
check valid dns record instead ping. Coz many service provider has been
blocked icmp :)
Best Regds,
Masood Ahmad Shah
Nexlinx
http://nexlinx.net.pk
----- Original Message -----
From: "Richard Peiper" <rpeiper at waca.com>
To: "'Andy Peters'" <abuse at 127.0.0.1>; <comp-protocols-dns-bind at isc.org>
Sent: Monday, June 14, 2004 10:42 PM
Subject: RE: batch reverse dns lookup
>
> I am sure someone can do this off the top of their head. I can do
> one for you in Perl5 if you have access to that in probably 15 mins. In
the
> middle of a cleanup of some issues right now so I wouldn't have it done
> until the end of the week. Let me know if you still need it and I can
write
> a quick loop thru the file, ping each one and generate 2 lists.
>
> Richard
>
>
> -----Original Message-----
> From: Andy Peters [mailto:abuse at 127.0.0.1]
> Sent: Saturday, June 12, 2004 12:37 PM
> To: comp-protocols-dns-bind at isc.org
> Subject: batch reverse dns lookup
>
>
> Hi i don't know if this is quite the group to ask this in (you are the dns
> guru's ?) so feel free to offer alternative group suggestions
>
> here's the problem, i have a list of domains (26,000+) in plain text
format
> (its a hosts file to be exact) and i would like to seperate the domains
that
> resolve to an ip from the ones that don't (to clean up the list and remove
> invalid and dead entries)
> any idea how i might achieve it ? i would of thought a quick bash or batch
> script could do this but not having any experience in shell scripts i dont
> know how i could do this
> any help or pointers would be appreciated (i have access to
> suse/knoppix/win*/)
>
> cheers folks
>
> Andy P
>
>
>
>
------------------------------
From: Richard Peiper <rpeiper at waca.com>
Subject: RE: batch reverse dns lookup
Date: Mon, 14 Jun 2004 15:41:20 -0400
Actually that is a really good idea except how do you distinguish a
valid A record entry from a stale A record entry?
Richard
-----Original Message-----
From: Masood Ahmad Shah [mailto:masood at nexlinx.net.pk]
Sent: Monday, June 14, 2004 2:22 PM
To: Richard Peiper; 'Andy Peters'; comp-protocols-dns-bind at isc.org
Subject: Re: batch reverse dns lookup
I will suggest better to write script in perl or shell ........that will
check valid dns record instead ping. Coz many service provider has been
blocked icmp :)
Best Regds,
Masood Ahmad Shah
Nexlinx
http://nexlinx.net.pk
----- Original Message -----
From: "Richard Peiper" <rpeiper at waca.com>
To: "'Andy Peters'" <abuse at 127.0.0.1>; <comp-protocols-dns-bind at isc.org>
Sent: Monday, June 14, 2004 10:42 PM
Subject: RE: batch reverse dns lookup
>
> I am sure someone can do this off the top of their head. I can do
> one for you in Perl5 if you have access to that in probably 15 mins. In
the
> middle of a cleanup of some issues right now so I wouldn't have it done
> until the end of the week. Let me know if you still need it and I can
write
> a quick loop thru the file, ping each one and generate 2 lists.
>
> Richard
>
>
> -----Original Message-----
> From: Andy Peters [mailto:abuse at 127.0.0.1]
> Sent: Saturday, June 12, 2004 12:37 PM
> To: comp-protocols-dns-bind at isc.org
> Subject: batch reverse dns lookup
>
>
> Hi i don't know if this is quite the group to ask this in (you are the dns
> guru's ?) so feel free to offer alternative group suggestions
>
> here's the problem, i have a list of domains (26,000+) in plain text
format
> (its a hosts file to be exact) and i would like to seperate the domains
that
> resolve to an ip from the ones that don't (to clean up the list and remove
> invalid and dead entries)
> any idea how i might achieve it ? i would of thought a quick bash or batch
> script could do this but not having any experience in shell scripts i dont
> know how i could do this
> any help or pointers would be appreciated (i have access to
> suse/knoppix/win*/)
>
> cheers folks
>
> Andy P
>
>
>
>
------------------------------
From: "Noah" <admin2 at enabled.com>
Subject: dynamic DNS issues - invalid TSIG key
Date: Mon, 14 Jun 2004 12:37:57 -0800
FreeBSD-4.9-STABLE on server side
bind-9.2.3
okay I am trying to set up dynamic DNS to bind on a FreeBSD box. I have admin
on both client and server side. the client is a redhat-8.0 machine with ISC
DHCP installed.
I verified the spelling of the keyname on both the client and server config
files. and re-cut and pasted the key in both the client and server
configuration files.
right now the client side is complaining of an invalid TSIG key. The keys are
cut and Pasted and fomatted properly in each configuration file. so I am at a
loss as to what to check next.
I have attached the error message. I changed the hostnames and IP addresses
to protect the inocent - <> are added to clarify what I did.
--- snip ---
Jun 12 14:45:44 <hostname> dhclient: if IN A <hostname.domain.com>. rrset
doesn't exist add 3600 IN A <hostname.domain.com>. <10.2.1.1> add 3600 IN TXT
<hostname.domain.com>. "<key_stuff>": invalid TSIG key.
--- snip ---
I am following the forwarding tutorial at:
http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html#forward
so the configuration on the client side looks like this -
--- /etc/dhclient-eth0.conf ----
send fqdn.fqdn "<hostname.domain.com>.";
send fqdn.encoded on;
send fqdn.server-update off;
key <hostname.domain.com>. {
algorithm HMAC-MD5;
secret "<key>";
}
zone <domain.com> {
key "<hostname.domain.com>.";
}
interface "eth0" {
send host-name "<hostname>";
send dhcp-client-identifier <mac_address>;
send dhcp-lease-time 3600;
prepend domain-name-servers 127.0.0.1;
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, host-name;
require subnet-mask, domain-name-servers;
script "/sbin/dhclient-script";
}
--- /etc/dhclient-eth0.conf ----
and here are the modfifications on the server side. just the snippets that
are relevant to this configuration. the file is fairly large.
--- /etc/namedb/named.conf ----
key <hostname.domain.com>. {
algorithm HMAC-MD5;
secret "<key>";
};
...
zone "<domain.com>" in {
type master;
file "zones/<domain.com>";
allow-transfer { <10.2.2.1>; <10.2.2.2>; };
allow-query { any; };
allow-update { none; };
notify yes;
update-policy {
grant <hostname.domain.com>. name <hostname.domain.com>. A TXT;
grant <hostname.domain.com>. name <hostname2.domain.com>. A TXT;
grant * self * A TXT;
};
};
--- /etc/namedb/named.conf ---
clues please?
cheers,
Noah
------------------------------
From: Barry Margolin <barmar at alum.mit.edu>
Subject: Re: batch reverse dns lookup
Date: Mon, 14 Jun 2004 17:07:53 -0400
In article <cal086$1pka$1 at sf1.isc.org>,
Richard Peiper <rpeiper at waca.com> wrote:
> Actually that is a really good idea except how do you distinguish a
> valid A record entry from a stale A record entry?
What do you mean by "stale A record entry"? Unless your caching server
retains records beyond their TTLs, there's no such thing.
--
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
------------------------------
From: Richard Peiper <rpeiper at waca.com>
Subject: RE: batch reverse dns lookup
Date: Mon, 14 Jun 2004 17:27:25 -0400
Say I have an entry in my DNS which points to a machine which no
longer exists. And I don't take it out because I am lazy and can't manage my
DNS properly? In theory you could make a much more complex system of
nslookup with reverse mapping and then a ping test to generate a status for
each entry... Hmm... considering the state of the DNS server I inherited I
might just have to look into that one.
Richard
-----Original Message-----
From: Barry Margolin [mailto:barmar at alum.mit.edu]
Sent: Monday, June 14, 2004 5:08 PM
To: comp-protocols-dns-bind at isc.org
Subject: Re: batch reverse dns lookup
In article <cal086$1pka$1 at sf1.isc.org>,
Richard Peiper <rpeiper at waca.com> wrote:
> Actually that is a really good idea except how do you distinguish a
> valid A record entry from a stale A record entry?
What do you mean by "stale A record entry"? Unless your caching server
retains records beyond their TTLs, there's no such thing.
--
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
------------------------------
From: Daniel Roesen <dr at bofh.de>
Subject: Re: dynamic DNS issues - invalid TSIG key
Date: Mon, 14 Jun 2004 21:30:21 +0000 (UTC)
* Noah <admin2 at enabled.com>:
> I verified the spelling of the keyname on both the client and server
> config files.
OK, this is popular reason #1. :-)
> right now the client side is complaining of an invalid TSIG key.
Are system clocks NTP-synched? TSIG requires system clocks to be within
a certain window of synchronicity.
> --- /etc/namedb/named.conf ----
>
> key <hostname.domain.com>. {
> algorithm HMAC-MD5;
> secret "<key>";
> };
>
> ...
>
> zone "<domain.com>" in {
> type master;
> file "zones/<domain.com>";
> allow-transfer { <10.2.2.1>; <10.2.2.2>; };
> allow-query { any; };
> allow-update { none; };
> notify yes;
> update-policy {
> grant <hostname.domain.com>. name <hostname.domain.com>. A TXT;
> grant <hostname.domain.com>. name <hostname2.domain.com>. A TXT;
> grant * self * A TXT;
> };
> };
Erm... how about
allow-update { key <hostname.domain.com>.; };
Regards,
Daniel
------------------------------
From: "John Fawcett" <no-spam at tiscali.it>
Subject: rndc reload / rndc reconfig do not add new zones from included files
Date: Mon, 14 Jun 2004 23:50:36 +0200
I am using bind 9, on Suse 9.0. I have an issue with "rndc reload" and "rndc
reconfig" which does not seem to read newly added zones where those zones
are in an include file.
I don't specify zones (other than "." "localhost" and "0.0.127.in-addr.arpa)
directly in named.conf but instead use the following include statement:
include "/etc/named.conf.include";
The /etc/named.conf.include is a Suse generated file which contains various
other includes. In my case there is:
include "/etc/named.d/captured-zones.conf";
In captured-zones.conf I put the zone statements for domains (usually run by
spammers) to which I want to block access from the local network:
example:
zone "meds4sd.com" IN { type master; file "master/dummy-block.zone"; };
where the dummy-block.zone file just points to 127.0.0.1
Whenever I add a new zone definition to captured-zones.conf and then run
rndc reload, I get this log entry
Jun 14 23:34:12 turate named[24241]: loading configuration from
'/etc/named.conf'
but the zone is not loaded.
rndc reconfig doesn't load the new zone either.
I have to restart named to get the new zone loaded. Is there a short cut to
loading new zones without having to restart named?
John
------------------------------
Date: Mon, 14 Jun 2004 18:34:33 -0400
From: Danny Mayer <mayer at gis.net>
Subject: Re: Event Id 5774
At 12:23 PM 6/14/2004, Jim Carver wrote:
>Recently I setup Windows Server 2000, the DNS Server. I
>keep getting the same error I don't how to fix it. The error is
> Event Type: Error
>Event Source: NETLOGON
>Event Category: None
>Event ID: 5774
>Date: 6/12/2004
>Time: 6:58:53 PM
>User: N/A
>Computer: WOLF
>Description:
>Registration of the DNS
>record '_kpasswd._udp.carverscomputer.com. 600 IN SRV 0
>100 464 wolf.carverscomputer.com.' failed with the
>following error:
>DNS server unable to interpret format.
>Data:
>0000: 29 23 00 00 )#..
>
>How do you fix it?
>Thank you
You ask in the right newsgroup. This is a Windows DNS server. This newsgroup
is for BIND.
Danny
------------------------------
From: "Michael Barber" <mikeb at comcity.com>
Subject: Re: Event Id 5774
Date: Mon, 14 Jun 2004 15:45:18 -0700
It looks like a typo in the zone file for carverscomputer.com near )#
....is my guess.
----- Original Message -----
From: "Danny Mayer" <mayer at gis.net>
To: "Jim Carver" <jcarver at carverscomputer.com>;
<comp-protocols-dns-bind at isc.org>
Sent: Monday, June 14, 2004 3:34 PM
Subject: Re: Event Id 5774
> At 12:23 PM 6/14/2004, Jim Carver wrote:
> >Recently I setup Windows Server 2000, the DNS Server. I
> >keep getting the same error I don't how to fix it. The error is
> > Event Type: Error
> >Event Source: NETLOGON
> >Event Category: None
> >Event ID: 5774
> >Date: 6/12/2004
> >Time: 6:58:53 PM
> >User: N/A
> >Computer: WOLF
> >Description:
> >Registration of the DNS
> >record '_kpasswd._udp.carverscomputer.com. 600 IN SRV 0
> >100 464 wolf.carverscomputer.com.' failed with the
> >following error:
> >DNS server unable to interpret format.
> >Data:
> >0000: 29 23 00 00 )#..
> >
> >How do you fix it?
> >Thank you
>
> You ask in the right newsgroup. This is a Windows DNS server. This
newsgroup
> is for BIND.
>
> Danny
>
>
------------------------------
Date: Mon, 14 Jun 2004 18:38:06 -0400
From: Kevin Darcy <kcd at daimlerchrysler.com>
Subject: Re: 'dig -t any ...' question
Jim Reid wrote:
>>>>>>"Ladislav" == Ladislav Vobr <lvobr at ies.etisalat.ae> writes:
>>>>>>
>>>>>>
>
> Ladislav> what's so special about ANY?
>
>Nothing. You just don't seem to understand what it means. A QYTPE of
>ANY means "give me whatever RRs you have for this name". That's all.
>See my earlier posting for more info.
>
> Ladislav> Why any recursive servers don't do it's best to satisfy
> Ladislav> the recursive client with the reply from the authoritative
> Ladislav> server, that's why we call it recursive right?
>
>Wrong. We call it recursive because the server is able to recursively
>make iterative queries to resolve a query on behalf of some client.
>It doesn't mean the server does that: it can answer from its cache
>which might or might not have been populated with data returned from
>earlier queries to authoritative servers. No assumptions can or should
>be made about how a recursive server provides answers. It should of
>course interrogate authoritative servers when nothing has been
>cached. But that cannot be guaranteed. And even if it does query
>authoritative servers, the answer might not be correct. The DNS is
>loosely coupled remember. It can take time for a zone's authoritative
>servers to converge on the same copy of the zone data after the zone
>gets updated. They don't all update the zone simultaneously.
>
>You seem to think that an ANY QTYPE means a server must retrieve every
>RR for the name. That's not the case. In fact this is impossible. The
>master server could change the RRs immediately after answering your
>hypothetical EVERY query before that reply gets back to the client.
>It's not even the case that a server must query an authoritative
>server in order to respond to an ANY query.
>
>Remember too that one of the key strengths of the DNS is caching. In
>some sense this means that recursive servers are lazy. They'll answer
>from cache every time unless there's nothing relevant in the cache and
>they're forced to resolve something. This is why people need to think
>carefully about TTL values. How many times have we seen postings here
>where there's been a long-lived TTL for a web or mail server that then
>gets renumbered and the poster whines that traffic still goes to the
>old address even though they've updated the zone?
>
That's fine and dandy. We all understand that DNS is "loosely coupled",
and that caching requires all sorts of tradeoffs and compromises. But I
think personally QTYPE=* has been compromised to the point of almost
being unusable for its originally-intended purpose. What if instead of
defining a valid, complete QTYPE=* response from cache as "whatever you
happen to have in your cache", which as Ladislav rightly points out
makes a mockery of the RA flag, we define it as
"RRsets for all record types that were seen in the most recent
QTYPE=* response, if none of them have expired"
?? Certainly we don't expect recursive servers to recurse *every*
QTYPE=* query, on the offchance that maybe some RRset has changed, but
certainly if all of the RRsets for all of the record types previously
seen in a QTYPE=* response are still present in the cache, regardless of
whether those RRsets were from the original QTYPE=* query, or from other
queries, or combination of the two, why not synthesize a response from
them? That seems perfectly reasonable to me, and not unduly burdensome
to recursing servers. Note that if the recursing server happens to
notice that it is missing exactly *one* of the RRsets (a fairly common
occurrence, I would expect, since A records tend to have smaller TTLs
than anything else), then it could make a choice between recursing the
whole QTYPE=* query, or just fetching the missing RRset. The alternative
is for the client to make the A-record query itself, along with queries
for whatever other record types in which it is interested, so from the
recursive-server's standpoint, this can only be a win.
I can understand that this definition could raise a concern about
"record-type lock", where the recursive server might assume, in
perpetuity (or at least until the next restart/reboot), that only
certain record types exist for a given name, and thus keep synthesizing
QTYPE=* responses from the same set of record types even after one or
more types have been deleted from or added to the name. Deleted types
aren't really a problem, since according to the above definition the
answer is not valid and/or complete if any of the individual RRsets have
expired, so eventually the deleted RRset will expire and the recursive
server will be forced to fetch a new QTYPE=* answer. This "staleness"
problem is thus no worse than if the client was using type-specific
queries instead of QTYPE=*. Added types are a bit more problematic --
how can a recursive server know that records with a given type have been
added to a name, unless it's actually querying that name & type (or
QTYPE=*) from its upstream sources? This problem can be solved at the
protocol level with a very minor clarification/extension of Negative
Caching, but in the interim, some more-or-less arbitrary limit could be
set in BIND, such that a fresh QTYPE=* query is forced every so often,
in order to prevent "record-type lock". This could be just a fixed
amount of time, such as was implemented before Negative Caching was
properly specified, and like BIND 9 currently implements for "lame
server TTL"s, or it could be based on the TTLs of the various RRsets
associated with the name, either an average, the minimum, the maximum,
or the result of some sort of multivariable formula...
- Kevin
------------------------------
From: ksp at att.com (Kevin Pickard)
Subject: Re: recursive-clients, what value ?
Date: 14 Jun 2004 16:20:17 -0700
Mikael <pub.nospam at grizzli.org> wrote in message news:<caknas$1500$1 at sf1.isc.org>...
> Hello,
>
> I'm working on bind 9.2 on linux mandrake and I had lots of logs
> containing :
>
> Jun 14 09:23:30 hostname named[1045]: client: client 127.0.0.1#34559: no
> more recursive clients: quota reached
> Jun 14 09:25:22 hostname named[1045]: client: client 127.0.0.1#34565: no
> more recursive clients: quota reached
>
> I read that increasing "recursive-clients" could help. I'm going to set
> it to 2000 but is there a way to know what would be a good value ?
> Is there a way to monitor in real time the number of simultaneous clients ?
>
> Thanks in advance,
>
> Mikael
Determining a good value for the "recursive-clients" option depends on
your environment. From the logs you included, it looks like you're
just barely peaking over the default 1000 simultaneous recursive
queries every now and then, (because you only had two entries, and
they were a couple mins apart). I'd guess that, unless you expect
significantly more recursive queries in the future, that bumping
"recursive-clients" to 1100 should probably suffice. If you find that
you're still generating "quota reached" logs like above, bump it up a
little more until the messages subside.
Setting it at 2000, as you mentioned, is probably more than you need
-- theoretically a doubling of your current simultaneous recursive
query capacity.
Lastly, keep in mind that, as the Bv9ARM mentions, "each recursing
client uses a fair bit of memory, on the order of 20 kilobytes". Your
amount of physical memory ultimately dictates how high this value can
go. We have many servers in production which have this value set
above 3000, but they have the RAM to back it up.
Best Regards,
ksp
------------------------------
From: Barry Margolin <barmar at alum.mit.edu>
Subject: Re: batch reverse dns lookup
Date: Mon, 14 Jun 2004 19:27:02 -0400
In article <cal692$2cgs$1 at sf1.isc.org>,
Richard Peiper <rpeiper at waca.com> wrote:
> Say I have an entry in my DNS which points to a machine which no
> longer exists. And I don't take it out because I am lazy and can't manage my
> DNS properly? In theory you could make a much more complex system of
> nslookup with reverse mapping and then a ping test to generate a status for
> each entry... Hmm... considering the state of the DNS server I inherited I
> might just have to look into that one.
It seem like this attempt is likely to have many false negatives, due to
machines that are shut down or disconnected from the network at the time
you run the script.
--
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
------------------------------
Date: Mon, 14 Jun 2004 19:32:26 -0400
From: Kevin Darcy <kcd at daimlerchrysler.com>
Subject: Re: Looking for DNS reverse lookup service
Dave Humes wrote:
>A few weeks ago I stumbled accross a for-fee service that claimed to provide
>all the names associated with an IP address rather than just the single name
>that you get with a typical nslookup reverse lookup.
>
Oh, really? That's a rather extravagant claim. Can they find A records,
pointing to Internet addresses, that I add to my *internal*,
firewalled-off, unroutable DNS too? Even if the claim is limited to "DNS
visible from the Internet", that's an awful lot of data to go through
periodically, and the data would tend to get stale almost as soon as it
was added to the database. Also, some folks use A records with encrypted
or hashed names for various reasons, and don't allow zone transfers of
their zones. How would this service find one of those, if the A record
happened to point to the address of interest?
>Unfortunately, I
>forgot to bookmark the site and have now googled through about 20 pages
>without success. Can anyone provide a referal for this service?
>
I seriously doubt this service is worth your time or money...
- Kevin
------------------------------
Date: Mon, 14 Jun 2004 20:03:24 -0400
From: Kevin Darcy <kcd at daimlerchrysler.com>
Subject: Re: Non-local DNS resolution question
Robert Lowe wrote:
>Jim Reid wrote:
>
>
>
>>>>>>>"Robert" == Robert Lowe <Robert.H.Lowe at lawrence.edu> writes:
>>>>>>>
>>>>>>>
>> >> Having scanned the archives, it appears I put:
>> >>
>> >> digitalriver.com NS fc-2kdc-01.fireclick.com.
>> >> digitalriver.com NS fc-2kdc-02.fireclick.com.
>> >> fc-2kdc-01.fireclick.com. A 192.168.254.26
>> >> fc-2kdc-02.fireclick.com. A 192.168.254.27
>>
>> >> in the root zone file.
>>
>> Robert> No, don't do this. Use a forward zone in your named.conf files
>>
>>No! Don't do this either. A DNS "solution" that involves forwarding is
>>almost certainly broken. Configure your local name server(s) as slaves
>>for the digitalriver.com zone. These servers don't have to be listed
>>in the NS records for digitalriver.com. This way your local name
>>servers will be less dependent on the existing digitalriver.com
>>servers and your overall DNS infrastructure will therefore be more
>>robust and stable.
>>
>>
>
>Late getting back to this... if he has the option of acting as a slave,
>and both parties are willing to do the work (and it might be trivial,
>but if there are lots of zones, it may not be), then I'll agree. If not,
>there is nothing inherently "broken" about using a forward zone (and yes,
>Bob, one entry will cover all subdomains). Interacting with private partner
>networks is what it's there for, and while some may misuse the feature, and
>others just don't like it, that's not to say it should be avoided at all
>costs.
>
I think what you're forgetting (or overlooking) is the "stub" option.
This gives most of the benefits of slaving without the zone-transfer
overhead, and most of the benefits of forwarding without as much
fragility (or, as Cricket would say, "brittleness") or scalability
problems (since forwarding basically shifts the name-resolution workload
from the local nameservers to the forwarder(s)). "stub"s are especially
efficient at deeply-delegated hiearchies, since they cache referral
information for the relevant nameservers all of the way down the chain
and can therefore "shortcut" future queries. The only thing that
seriously trips up "stub"s are what I call "iceberg" hierarchies, where
the authoritative servers for the apex zone (or perhaps a few levels
below) are directly queriable, but the authoritative servers for the
various descendant zones are not. Improper delegation often compounds
the problems I have with such hierarchies. In those cases, forwarding
must be used. In fact, I would say generally that forwarding should not
be used except where there are connectivity issues ("forward only" mode)
or there is a demonstrated performance benefit ("forward first" mode).
- Kevin
------------------------------
From: "Richard Maynard" <ephur at corp.earthlink.net>
Subject: RE: recursive-clients, what value ?
Date: Mon, 14 Jun 2004 17:18:11 -0700
> I read that increasing "recursive-clients" could help. I'm
> going to set
> it to 2000 but is there a way to know what would be a good value ?
As Kevin already pointed out, this is a question that can vary widely
depending on your environment. Firstly, I would advise against doubling the
limit, if you eventually want to get there that's okay, but you may want to
do it in smaller incremental steps. The recursive-clients limitations are
not only memory related, but you also have to factor in extra machine load,
not just in managing the additional queries, but also all the extra
connections it will have to keep track of. Doubling the amount of queries
will also increase network traffic, if you are on a network that is even
lightly congested then increases in queries could cause a greater number of
queries to fail than would previously.
The other part of what you put in your logs, is that localhost is the one
triggering these failures. If it's a caching only name server that serves
services on that machine only you could also investigate other items such as
increasing the cache time, or caching invalid responses, which I believe by
default is off. Caching negative responses can GREATLY reduce the
recursive-clients problem. If DNS for a high traffic domain is failing, and
you're recursive clients are all hitting their timeouts waiting for a
response when one won't be coming back then you'll end up again, seeing
errors like the ones you saw.
> Is there a way to monitor in real time the number of
> simultaneous clients ?
You could probably get this from turning up debugging/query logging and
parsing the data, but outside of that I'm not sure of any immediate way to
get the number of simultaneous clients. I would suggest keeping track of
your stats daily and looking at your long term trends, and be sure to look
at your cache hit rate, it gives a good idea of what other things you can
start tuning. While, most decent hardware running on a good network will
have no problems with an extra thousand recursive clients, it may not be the
ultimate answer, by increasing the recursive clients you could end up
masking a different issue.
-- Richard Maynard
------------------------------
From: Barry Margolin <barmar at alum.mit.edu>
Subject: Re: 'dig -t any ...' question
Date: Mon, 14 Jun 2004 20:25:38 -0400
In article <calb87$2osn$1 at sf1.isc.org>,
Kevin Darcy <kcd at daimlerchrysler.com> wrote:
> That's fine and dandy. We all understand that DNS is "loosely coupled",
> and that caching requires all sorts of tradeoffs and compromises. But I
> think personally QTYPE=* has been compromised to the point of almost
> being unusable for its originally-intended purpose.
Just what *is* that purpose? I don't see any indication in RFC 1034; no
real justification is given for its existence.
Note also that the OP has made a big deal about whether it should return
records with cred=GLUE, but the DNS specification makes no mention of
credibility levels for cached information. All it says, in section
5.3.3 (the resolver algorithm, which is used by a server when processing
a query that has RD set) is: "Step 1 searches the cache for the desired
data. If the data is in the cache, it is assumed to be good enough for
normal use."
--
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
------------------------------
Date: Mon, 14 Jun 2004 17:34:33 -0700
From: Chris De Young <chd at arizona.edu>
Subject: TCP vs. UDP in query responses?
Hi,
My understanding is that DNS queries and responses by default use UDP,
but will switch to TCP if the response record set is large (and TCP is
used for zone transfers). Am I correct?
If so, what determines when TCP is used vs. UDP? I have some
recollection that TCP will be used if the response record set is larger
than 512 bytes, but I don't remember where I got that from so I don't
have any confidence that it's right. :-)
Is this threshold fixed, or will it depend on other factors?
I have a remote user (in Norway, I think) having intermittent problems
resolving a particular name (www.math.arizona.edu, not a large RR
set), and it *seems* tentatively to be the result of firewall rules
that permit DNS over UDP but not TCP -- but I can't prove it yet, and
it doesn't seem intuitive unless there are other factors that I don't
know about determining the use of TCP vs. UDP.
Thanks,
-Chris
------------------------------
From: Barry Margolin <barmar at alum.mit.edu>
Subject: Re: Non-local DNS resolution question
Date: Mon, 14 Jun 2004 20:41:42 -0400
In article <caletq$r9$1 at sf1.isc.org>,
Kevin Darcy <kcd at daimlerchrysler.com> wrote:
> I think what you're forgetting (or overlooking) is the "stub" option.
> This gives most of the benefits of slaving without the zone-transfer
> overhead
Has the implementation of stub zones changed? When I first looked at it
(back in BIND 4 days), it performed a zone transfer, but ignored
everything but the SOA and NS records. So the zone-transfer overhead
was the same. I'm also not sure that it looked at nested NS records
within the zone; I thought it only cared about the ones at the zone apex.
--
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
------------------------------
Date: Mon, 14 Jun 2004 20:45:31 -0400
From: Kevin Darcy <kcd at daimlerchrysler.com>
Subject: Re: 'dig -t any ...' question
Barry Margolin wrote:
>In article <calb87$2osn$1 at sf1.isc.org>,
> Kevin Darcy <kcd at daimlerchrysler.com> wrote:
>
>
>
>>That's fine and dandy. We all understand that DNS is "loosely coupled",
>>and that caching requires all sorts of tradeoffs and compromises. But I
>>think personally QTYPE=* has been compromised to the point of almost
>>being unusable for its originally-intended purpose.
>>
>>
>
>Just what *is* that purpose? I don't see any indication in RFC 1034; no
>real justification is given for its existence.
>
RFCs are specification documents, they don't necessarily justify the
existence of every aspect of what they specify. But it seems rather
obvious to me that the purpose of QTYPE=* is to efficiently retrieve all
relevant RRsets owned by a particular DNS name, as opposed to querying
all of those RRsets individually. The way QTYPE=* has been implemented,
however, has rendered it so untrustworthy that very few apps that could
benefit from this efficiency even bother to issue QTYPE=* queries any
more. This is a pity, all the more so because it would be a rather
elegant way to retrieve both A and AAAA records for a given name, and
thus ease the migration to IPv6.
>Note also that the OP has made a big deal about whether it should return
>records with cred=GLUE, but the DNS specification makes no mention of
>credibility levels for cached information. All it says, in section
>5.3.3 (the resolver algorithm, which is used by a server when processing
>a query that has RD set) is: "Step 1 searches the cache for the desired
>data. If the data is in the cache, it is assumed to be good enough for
>normal use."
>
RFC 2181 states "... data from the additional data section, and data
from the authority section of a non-authoritative answer, should not be
cached in such a way that they would ever be returned as answers to a
received query." This applies to QTYPE=* queries just as much as any
other query type.
- Kevin
------------------------------
From: "Richard Maynard" <ephur at corp.earthlink.net>
Subject: RE: TCP vs. UDP in query responses?
Date: Mon, 14 Jun 2004 17:50:20 -0700
> My understanding is that DNS queries and responses by default use UDP,
> but will switch to TCP if the response record set is large (and TCP is
> used for zone transfers). Am I correct?
I don't think there is an internal 'switch'. Some programs may be designed
to work that way, but according to the RFC the data size of the UDP packet
can only hit 512bytes. Bind truncates anything over than when responding.
That's why looking at UDP packets coming back, the maximum size is usually
around 517-520bytes, data + overhead. It may also be smaller than the 512
byte limit, but partial records will not be returned.
> If so, what determines when TCP is used vs. UDP? I have some
> recollection that TCP will be used if the response record set
> is larger
> than 512 bytes, but I don't remember where I got that from so I don't
> have any confidence that it's right. :-)
I'm pretty sure each application determines for itself. Most common
unix/windows resolver libraries just use UDP for DNS queries, and retry on
failures. Some libraries will try UDP then TCP. You can force your name
server to always do it's recursive lookups one way over the other, but
that's irrelevant to what the client sees.
> Is this threshold fixed, or will it depend on other factors?
512 bytes is fixed, based on the RFC. There may be software out there that
doesn't behave in accordance with the RFC but in this case bind does exactly
what it needs to. This is, and should be considered a hard limit. Even if
the server was to answer with a larger data set there is no telling what the
client will do with the extra data.
> I have a remote user (in Norway, I think) having intermittent problems
> resolving a particular name (www.math.arizona.edu, not a large RR
> set), and it *seems* tentatively to be the result of firewall rules
> that permit DNS over UDP but not TCP -- but I can't prove it yet, and
> it doesn't seem intuitive unless there are other factors that I don't
> know about determining the use of TCP vs. UDP.
Again, this really depends on what is doing the lookup. It's possible that
this application first tries a UDP lookup, and on failure will try a slower,
larger, but more reliable TCP query. That could cause failures like you
describe. It could just be an issue of packet loss from point a to point b
given the international connection that the UDP packets may get dropped on a
more than ideal basis. I'm not sure what your situation is, but the remote
user could go with a local caching server that could be forced into UDP
queries only and may be more successful, and aggressive, retrying the
original query before failing.
-- Richard Maynard
------------------------------
From: Barry Margolin <barmar at alum.mit.edu>
Subject: Re: TCP vs. UDP in query responses?
Date: Mon, 14 Jun 2004 20:57:04 -0400
In article <calgj5$4n5$1 at sf1.isc.org>, Chris De Young <chd at arizona.edu>
wrote:
> Hi,
>
> My understanding is that DNS queries and responses by default use UDP,
> but will switch to TCP if the response record set is large (and TCP is
> used for zone transfers). Am I correct?
>
> If so, what determines when TCP is used vs. UDP? I have some
> recollection that TCP will be used if the response record set is larger
> than 512 bytes, but I don't remember where I got that from so I don't
> have any confidence that it's right. :-)
>
> Is this threshold fixed, or will it depend on other factors?
That was the original specification. However, an extension mechanism
called EDNS0 allows the client to specify the maximum size datagram it
can accept. If the client and server support this mechanism, larger
responses can be sent without switching to TCP.
> I have a remote user (in Norway, I think) having intermittent problems
> resolving a particular name (www.math.arizona.edu, not a large RR
> set), and it *seems* tentatively to be the result of firewall rules
> that permit DNS over UDP but not TCP -- but I can't prove it yet, and
> it doesn't seem intuitive unless there are other factors that I don't
> know about determining the use of TCP vs. UDP.
I don't see any reason why this lookup would ever need to use TCP. What
evidence suggests that this firewall rule is the problem?
--
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
------------------------------
Date: Tue, 15 Jun 2004 09:57:32 +0900
From: Hyo-Jeong Shin <shinhj at hana.ne.kr>
Subject: Re: TCP vs. UDP in query responses?
Q: DNS quereis use UDP by default.
A: No. MS Exchange Server and Bagle Worm use TCP by default.
Usually, DNS queries UDP datagram.
If answer of UDS query is larger than 512 bytes, server answers with
TC(message truncated)=1 of DNS header.
That incurs following TCP query.
You can generate TCP query by option "set=vc" in "nslookup".
When I query www.math.arizona.edu, the answer was ok.
Chris De Young wrote:
>Hi,
>
>My understanding is that DNS queries and responses by default use UDP,
>but will switch to TCP if the response record set is large (and TCP is
>used for zone transfers). Am I correct?
>
>If so, what determines when TCP is used vs. UDP? I have some
>recollection that TCP will be used if the response record set is larger
>than 512 bytes, but I don't remember where I got that from so I don't
>have any confidence that it's right. :-)
>
>Is this threshold fixed, or will it depend on other factors?
>
>I have a remote user (in Norway, I think) having intermittent problems
>resolving a particular name (www.math.arizona.edu, not a large RR
>set), and it *seems* tentatively to be the result of firewall rules
>that permit DNS over UDP but not TCP -- but I can't prove it yet, and
>it doesn't seem intuitive unless there are other factors that I don't
>know about determining the use of TCP vs. UDP.
>
>Thanks,
>-Chris
>
>
--
Hyo-jeong Shin
Internet Networking Team
KT Corporation, Technology Lab.
463-1 Jeonmin-dong, Yuseong-gu, Daejeon 305-811, KOREA
Office:042-870-8194(or 0502-393-2228) Fax:042-870-8339
------------------------------
From: Barry Margolin <barmar at alum.mit.edu>
Subject: Re: 'dig -t any ...' question
Date: Mon, 14 Jun 2004 21:05:56 -0400
In article <calhbv$6ba$1 at sf1.isc.org>,
Kevin Darcy <kcd at daimlerchrysler.com> wrote:
> Barry Margolin wrote:
>
> >In article <calb87$2osn$1 at sf1.isc.org>,
> > Kevin Darcy <kcd at daimlerchrysler.com> wrote:
> >
> >
> >
> >>That's fine and dandy. We all understand that DNS is "loosely coupled",
> >>and that caching requires all sorts of tradeoffs and compromises. But I
> >>think personally QTYPE=* has been compromised to the point of almost
> >>being unusable for its originally-intended purpose.
> >>
> >>
> >
> >Just what *is* that purpose? I don't see any indication in RFC 1034; no
> >real justification is given for its existence.
> >
> RFCs are specification documents, they don't necessarily justify the
> existence of every aspect of what they specify. But it seems rather
> obvious to me that the purpose of QTYPE=* is to efficiently retrieve all
> relevant RRsets owned by a particular DNS name, as opposed to querying
> all of those RRsets individually. The way QTYPE=* has been implemented,
> however, has rendered it so untrustworthy that very few apps that could
> benefit from this efficiency even bother to issue QTYPE=* queries any
> more. This is a pity, all the more so because it would be a rather
> elegant way to retrieve both A and AAAA records for a given name, and
> thus ease the migration to IPv6.
But RFC 1034 included an example of QTYPE=* being sent to caching
servers, showing that different servers will return different records
based on what they happened to have cached at the time. So the problem
is in the original design, not BIND's implementation.
>
> >Note also that the OP has made a big deal about whether it should return
> >records with cred=GLUE, but the DNS specification makes no mention of
> >credibility levels for cached information. All it says, in section
> >5.3.3 (the resolver algorithm, which is used by a server when processing
> >a query that has RD set) is: "Step 1 searches the cache for the desired
> >data. If the data is in the cache, it is assumed to be good enough for
> >normal use."
> >
> RFC 2181 states "... data from the additional data section, and data
> from the authority section of a non-authoritative answer, should not be
> cached in such a way that they would ever be returned as answers to a
> received query." This applies to QTYPE=* queries just as much as any
> other query type.
I did notice a change related to that when we upgraded our caching
servers from BIND 8 to 9. Prior to that, if I asked for the A record of
a nameserver, I would often get the address from the glue in the parent
zone. After the upgrade, it seemed to go to the authoritative server
for this -- if all of the zone's servers were down, the query would hang
and eventually return a SERVFAIL error. The only way to get the cached
glue record was to query without the RD flag set.
However, I think ANY queries would still return whatever happened to be
in the cache, no matter how it was learned.
--
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
------------------------------
Date: Mon, 14 Jun 2004 21:20:53 -0400
From: Alan Shackelford <ashackel at jhmi.edu>
Subject: Re: Looking for DNS reverse lookup service
I don't really think this is possible unless you have access to the
files representing the zone data on the primary master DNS. Even then
there is nothing to say there is not a name from a totally separate DNS
pointing to the IP address. So if you saw such a thing it was either a
false claim or a scam. I can't see how one could possibly guarantee
accuracy in the moving, changeable Internet (I have enough trouble
within JHU and JHMI).
Alan
Humes, David G. wrote:
>A few weeks ago I ran accross a for-fee service that claimed to provide all
>the names associated with an IP address rather than just the single name
>that you get with a typical nslookup reverse lookup. Unfortunately, I
>forgot to bookmark the site and have now googled through about 20 pages
>without success. Can anyone provide a referal for this service?
>
>Thanks.
>
>--Dave
>
>
>
------------------------------
From: "dave" <dmehler26 at woh.rr.com>
Subject: OT: yahoo dns
Date: Mon, 14 Jun 2004 21:24:07 -0400
Hello,
I realize this is not a bind related topic, but i am unsure as to where
else to post this. Please respond privately with any input.
I've got a situation where a cable user on a static IP is using yahoo
for dns to resolve two web sites, let's call them www.example1.com and
www.example2.com. The sites themselves are hosted on a FreeBSD 5.2.1 box
that is running apache2, behind an ipfilter firewall. The firewall is set to
forward port80 trafic to the web server which it does just fine, pull up
www.example1.com and you get the first site. Now if you pull up either
example* site from within the network you get each site, however external,
that is requests from internet users, going to www.example2.comm end up on
the first site. I don't think this is a virtual host issue with apache2 as
internally they both work. Also, external requests to either site give the
public IP address vs. the site name in the address bar. My only theory is it
has something to do with the way yahoo handles there dns. If anyone has any
input i'd appreciate it.
Thanks.
Dave.
------------------------------
Date: Mon, 14 Jun 2004 18:39:16 -0700
From: Chris De Young <chd at arizona.edu>
Subject: Re: TCP vs. UDP in query responses?
> I don't see any reason why this lookup would ever need to use TCP.
I didn't either, but...
>What evidence suggests that this firewall rule is the problem?
The firewall logged TCP traffic on port 53 as well, and changing the
rule set from "allow UDP 53" to "allow UDP and TCP 53" appears to have
solved the problem. So, although I don't understand *why* the remote
resolver is doing this, it does appear to be using UDP sometimes and
TCP other times. The firewall rule can stay that way; I'm now just
trying to understand the behavior.
Richard Maynard said that some libraries will try UDP and then TCP; my
only guess at this point is that this is one of them, and that some
minor packet loss between the resolver and here is causing the UDP
query to occasionally be lost, so we might be seeing TCP retries.
I can't prove it, but I can't think of anything better.
Thanks to all!
Cheers,
-Chris
------------------------------
Date: Mon, 14 Jun 2004 19:20:47 -0700
Subject: Re: bind9-users Digest V5 #155
From: Jean Tourrilhes <jt at bougret.hpl.hp.com>
On Sat, Jun 12, 2004 at 07:51:39AM +0000, ISC Mailing List Manager wrote:
> Date: Sat, 12 Jun 2004 03:57:45 +0200
> From: Sten Carlsen <ccc2716 at vip.cybercity.dk>
> Subject: Re: [PATCH] resolv.conf addition for mobile users
>
> One question (for me at least) is:
> If we have more than one connection to the outside, will we catch every
> change of the default route by monitoring only PPP and DHCP? Will
> somebody have a function that will switch the default route based on
> e.g. response times?
> If PPP and DHCP are both up, will you always use the last one to come up
> as the route? If that is blocked will you not switch to the other that
> is up? In that case we may be using the wrong nameserver. If you don't
> switch when the default route fails to answer, then why do you keep two
> connections up at the same time?
> Trying all nameservers to see which will respond may not be adequate in
> case the correct one uses views to give us an internal view that is not
> accessable from the others.
>
> Basically I fear we may miss some changes by not looking at the route
> table. On the other hand we only have to look at it when it changes.
This is even more messy than that. A casual look at the
routing table can't tell you if a given nameserver is going to work or
not.
Just to give you a *real* example. This is my route table :
----------------------------
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
15.4.88.0 0.0.0.0 255.255.248.0 U 0 0 0 eth4
0.0.0.0 15.4.88.1 0.0.0.0 UG 0 0 0 eth4
----------------------------
The appropriate nameserver are :
-----------------
search hpl.hp.com
nameserver 15.0.48.4
nameserver 15.0.152.4
nameserver 15.255.168.31
-----------------
In this case, the proper route is "0.0.0.0". But, 0.0.0.0
could point to anywhere else, so testing the presence of the 0.0.0.0
route is not enough. In other case, you would use the subnet route,
and that works differently. And you have no idea what kind of route is
going to be configured, I may use a specific host route just for the
nameserver.
But, remember that I'm behind a application level
firewall. Therefore, I can access some part of 15.X, and some part of
15.X is not accessible (on the other side). So, I can't access the
nameserver on the external HP network (but you can). There is no way
I'm going to know that from the routing table.
If you want to do a perfect job, the only way to know is to
try it, i.e. to send the request over the network. But, that's exactly
what I'm trying to avoid for performance reason. And also because all
resolver only allow for 3 nameserver, which is totally inadequate for
such scenario.
So, what do I want to acheive. The point is not to get the
perfect solution, that's impossible, but to get something that works
in most cases and give the user enough hooks so that he can make the
system works for him.
Now, back to your example. My assumption is that, if DHCP or
PPP setup goes far enough to get some DNS info, it means that there
was network connectivity one node on the subnet (PPP/DHCP
server). Most connectivity problems happen at the link level, which
means at that point, except rare messup of subnet config, you are good
to go. Similarly, when link connectivity goes down, PPP and DHCP will
exit and cleanup.
If both are up at the same time, you just hope that either the
nameserver are on the local subnet (most case - would work ok), or
that the user knows what he is doing and fix the resolver
configuration accordingly. Because the config is now split in multiple
files, one per interface, it's easy for the user script to just rename
the file of the interface it's not using to something else. The
difference with what we have today, is that today we have an anonymous
config in /etc/resolv.conf, whereas my proposal allows to strongly
associate config to interface, making it easy to know which is which.
Note that in the case of most mobile device, for battery sake,
you really want to "down" the interfaces that you are not using. And
it's far easier to just down an interface than to play elaborate
tricks with the routing table.
> > Please report ;-) Note that Win32 also seems to get it right,
> >but I don't expect to know how they do it :-(
> >
> >
> >
> As far as I can tell the Apple source code is available at:
> http://www.opendarwin.org/downloads/
>
> I have not looked into the sources, I assume you could get the picture
> much quicker than me.
I'm not familiar with *BSD code, and I've never used OS-X, so
you would know much faster than me. Just check the content of
resolv.conf on a live system and how it evolves.
> Best regards
>
> Sten Carlsen
Have fun...
Jean
------------------------------
Date: Tue, 15 Jun 2004 07:23:21 +0400
From: Ladislav Vobr <lvobr at ies.etisalat.ae>
Subject: Re: recursive-clients, what value ?
>
> I read that increasing "recursive-clients" could help. I'm going to set
> it to 2000 but is there a way to know what would be a good value ?
> Is there a way to monitor in real time the number of simultaneous clients ?
hmm, that would be nice to see, what kind of stuff and how much full is
the internal recursive queue. I don't know anything which can do this
and miss it too.
I have the value 2000, but regularly getting the similiar messages, bind
sometimes keeps retrying in hundereds of queries in background and
nobody is aware about it, and it uses up whole queue without logging any
thing else that that the queue is full.
My traffic is around 3000/sec on a caching 9.2.3, I asked some time back
here, what should be the number or how I can calculate it roughly, what
number would fit this kind of traffic, but no recommedation :-(
Ladislav
------------------------------
From: "Delpy" <delpy at sover.net>
Subject:
Date: Mon, 14 Jun 2004 23:33:42 -0400
help
------------------------------
Date: Mon, 14 Jun 2004 23:48:38 -0400
From: Danny Mayer <mayer at gis.net>
Subject: Re: [PATCH] resolv.conf addition for mobile users
At 05:51 PM 6/11/2004, Jean Tourrilhes wrote:
> Please report ;-) Note that Win32 also seems to get it right,
>but I don't expect to know how they do it :-(
What exactly did they get right?
Danny
------------------------------
Date: Tue, 15 Jun 2004 08:00:49 +0400
From: Ladislav Vobr <lvobr at ies.etisalat.ae>
Subject: Re: 'dig -t any ...' question
> I did notice a change related to that when we upgraded our caching
> servers from BIND 8 to 9. Prior to that, if I asked for the A record of
> a nameserver, I would often get the address from the glue in the parent
> zone. After the upgrade, it seemed to go to the authoritative server
> for this -- if all of the zone's servers were down, the query would hang
> and eventually return a SERVFAIL error. The only way to get the cached
> glue record was to query without the RD flag set.
>
barry, the change is there between 8.3.4 and 8.4.1, 8.4.1 returns is the
same way as 9 and higher, 8.3.4 returns it as a *answer*, I think this
will be very important to distinguish once it comes to dnssec. What is
glue and what is not, since the glue is not signed.
> However, I think ANY queries would still return whatever happened to be
> in the cache, no matter how it was learned.
if it is cached with *glue* credibility it will not return it to ra
clients. This behavious as you describe is nightmare, it keeps retrying
to all nameservers if all unreachable causing incredible traffic to
remote servers and the network as well, I am sometimes seeing
nameservers querying me with 1000(one thousand)req/s with the same
request, this can really spoil lot's of things, why would ever caching
nameserver has to do such a thing, does it really help to do it this
way....?
how can we say it is perfectly fine to answer the recursive client with
non-authoritative data, when nothing was cached before this request? I
feel recursion means, if it is not available, recurse up to the source
(auth servers) and get it, not from . or 2ndlevel or 3level or 4level,
we can not stop randomly somelevel just because some binds think it was
enough steps(parent 8.3.4 thinks it is enough, parent 8.4.1 thinks try
to go to next level... it seems really very consistent:-), we always
should go up to the source *provided it was not cached before*. How will
this work in dnssec, we just answer to ra client with *glue* and tell
him be happy for it:-)?
Ladislav
------------------------------
From: Barry Margolin <barmar at alum.mit.edu>
Subject: Re: OT: yahoo dns
Date: Tue, 15 Jun 2004 00:34:09 -0400
In article <calkb8$csi$1 at sf1.isc.org>, "dave" <dmehler26 at woh.rr.com>
wrote:
> Hello,
> I realize this is not a bind related topic, but i am unsure as to where
> else to post this. Please respond privately with any input.
comp.protocols.tcp-ip.domains is the place for general DNS questions.
> I've got a situation where a cable user on a static IP is using yahoo
> for dns to resolve two web sites, let's call them www.example1.com and
> www.example2.com. The sites themselves are hosted on a FreeBSD 5.2.1 box
> that is running apache2, behind an ipfilter firewall. The firewall is set to
> forward port80 trafic to the web server which it does just fine, pull up
> www.example1.com and you get the first site. Now if you pull up either
> example* site from within the network you get each site, however external,
> that is requests from internet users, going to www.example2.comm end up on
> the first site. I don't think this is a virtual host issue with apache2 as
> internally they both work. Also, external requests to either site give the
> public IP address vs. the site name in the address bar. My only theory is it
> has something to do with the way yahoo handles there dns. If anyone has any
> input i'd appreciate it.
I don't know what you mean by "using yahoo for dns to resolve two web
sites". Do you mean Yahoo is operating the authoritative DNS servers
for the domains, or Yahoo is operating the caching server that the
servers' resolvers are using?
Anyway, you haven't really given us enough information to tell what's
going on. In particular, you have to tell us the real domains that are
involved.
--
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
------------------------------
Date: Tue, 15 Jun 2004 08:50:19 +0400
From: Ladislav Vobr <lvobr at ies.etisalat.ae>
Subject: Re: Non-local DNS resolution question
> Has the implementation of stub zones changed? When I first looked at it
> (back in BIND 4 days), it performed a zone transfer, but ignored
> everything but the SOA and NS records. So the zone-transfer overhead
> was the same. I'm also not sure that it looked at nested NS records
> within the zone; I thought it only cared about the ones at the zone apex.
In bind 8,9 it queries only for normal SOA record and than for NS
records, it uses TCP to query for NS records, while UDP for SOA records,
but it doesn't do a zone transfer, in fact I am using it with
tranfer-allowed { none; };
Ladislav
------------------------------
Date: Mon, 14 Jun 2004 22:09:55 -0600
From: RYAN vAN GINNEKEN <rmvg at shaw.ca>
Subject: redundant web servers
Just wondering what is the best way to setup redundant web servers that
span across multiple ISP's any ideas or docs would be appreciated.
THANK YOU
------------------------------
Date: Tue, 15 Jun 2004 08:46:56 +0400
From: Ladislav Vobr <lvobr at ies.etisalat.ae>
Subject: Re: recursive-clients, what value ?
> default is off. Caching negative responses can GREATLY reduce the
> recursive-clients problem. If DNS for a high traffic domain is failing, and
> you're recursive clients are all hitting their timeouts waiting for a
> response when one won't be coming back then you'll end up again, seeing
> errors like the ones you saw.
it is by default in bind9 (3hours) and (10min for lame servers) only
nxdomain, nxrrset are cached, servfail is not, time-outs are not, if
*all* nameservers for high traffic domain are down, bind will keep
flooding it sometimes with incredible rate depends purely on your
clients, bind doesn't control it in any way,just amplify (by retries)
you clients' flood and sends it to those "pure victim servers", same for
servfail.
>
>>Is there a way to monitor in real time the number of
>>simultaneous clients ?
> You could probably get this from turning up debugging/query logging and
> parsing the data, but outside of that I'm not sure of any immediate way to
> get the number of simultaneous clients. I would suggest keeping track of
> your stats daily and looking at your long term trends, and be sure to look
> at your cache hit rate, it gives a good idea of what other things you can
> start tuning.
Richard, how can I plot cache hit rate? Do you mean rndc stats, there is
only # of recursive requests.
Ladislav
------------------------------
From: "Richard Maynard" <ephur at corp.earthlink.net>
Subject: RE: recursive-clients, what value ?
Date: Mon, 14 Jun 2004 22:25:30 -0700
> it is by default in bind9 (3hours) and (10min for lame servers) only
> nxdomain, nxrrset are cached, servfail is not, time-outs are not, if
> *all* nameservers for high traffic domain are down, bind will keep
> flooding it sometimes with incredible rate depends purely on your
> clients, bind doesn't control it in any way,just amplify (by retries)
> you clients' flood and sends it to those "pure victim
> servers", same for
> servfail.
Ahhh! That's good to know, I didn't realize the ServFail's weren't cached.
Thanks for the info, I sure wish servfails were cached, as it stands, it's
not hard to start a short lived DOS against a DNS farm that will recurse for
you with bad servers and one bad domain.
> Richard, how can I plot cache hit rate? Do you mean rndc
> stats, there is
> only # of recursive requests.
You can look at the # of recursive requests and the number of total requests
to get the % of your requests that are answered from Cache. I found this to
be amongst the most useful datasets when correlating machine performance
with different configurations. It's not uncommon to see 75% of the queries
on my farm answered out of cache during peak usage hours. I don't know or
have exact numbers on how much longer a cached vs a non-cached query will
take right now, but I do have direct performance differences.
Getting my cache hit rate up from ~50% to ~65% yeilded more than a 15%
performance improvement, with only minimal changes to our configurations.
-- Richard Maynard
------------------------------
Date: Tue, 15 Jun 2004 09:25:49 +0400
From: Ladislav Vobr <lvobr at ies.etisalat.ae>
Subject: auth-nxdomain yes
when does this option help? does it help only in case somebody's bind is
forwarding to my caching server? Can altering this option decrease
number of nxdomain normal cachings server gets.
How does the client (not bind server) treats nxdomain with and without
aa bit?
Ladislav
------------------------------
Date: Tue, 15 Jun 2004 09:43:26 +0400
From: Ladislav Vobr <lvobr at ies.etisalat.ae>
Subject: Re: recursive-clients, what value ?
> Ahhh! That's good to know, I didn't realize the ServFail's weren't cached.
> Thanks for the info, I sure wish servfails were cached, as it stands, it's
> not hard to start a short lived DOS against a DNS farm that will recurse for
> you with bad servers and one bad domain.
yes :-) I guess we all lernead it hard way :-)
>
>>Richard, how can I plot cache hit rate? Do you mean rndc
>>stats, there is
>>only # of recursive requests.
>
> You can look at the # of recursive requests and the number of total requests
> to get the % of your requests that are answered from Cache. I found this to
> be amongst the most useful datasets when correlating machine performance
> with different configurations. It's not uncommon to see 75% of the queries
> on my farm answered out of cache during peak usage hours. I don't know or
> have exact numbers on how much longer a cached vs a non-cached query will
> take right now, but I do have direct performance differences.
>
> Getting my cache hit rate up from ~50% to ~65% yeilded more than a 15%
> performance improvement, with only minimal changes to our configurations.
hmm, I thought there might be a relation, but seemed to me more
complicated, what about the failures don't they initiate a query before
they fail, is this failed query counted as well in recursion? and what
is it recursion actually, when I dump stats I see recursion, imho
caching server initiate on behalf of recursive clients non-recursive
queries (unless it is forwarding), so if it counts how many
non-recursive queries had to be done, because it was not cached, it
should not be called recursion, but i might be wrong here:-), I think
definitelly it is very good idea, to plot this. We are using rrdtool
here but use to plot only basic stats, we'll try this parametr as well.
Thanks for your support
Ladislav
------------------------------
Date: Tue, 15 Jun 2004 09:46:41 +0200
From: Sten Carlsen <ccc2716 at vip.cybercity.dk>
Subject: Re: bind9-users Digest V5 #155
Jean Tourrilhes wrote:
>
> This is even more messy than that. A casual look at the
>routing table can't tell you if a given nameserver is going to work or
>not.
> Just to give you a *real* example. This is my route table :
>----------------------------
>Kernel IP routing table
>Destination Gateway Genmask Flags Metric Ref Use Iface
>15.4.88.0 0.0.0.0 255.255.248.0 U 0 0 0 eth4
>0.0.0.0 15.4.88.1 0.0.0.0 UG 0 0 0 eth4
>----------------------------
> The appropriate nameserver are :
>-----------------
>search hpl.hp.com
>nameserver 15.0.48.4
>nameserver 15.0.152.4
>nameserver 15.255.168.31
>-----------------
> In this case, the proper route is "0.0.0.0". But, 0.0.0.0
>could point to anywhere else, so testing the presence of the 0.0.0.0
>route is not enough. In other case, you would use the subnet route,
>and that works differently. And you have no idea what kind of route is
>going to be configured, I may use a specific host route just for the
>nameserver.
> But, remember that I'm behind a application level
>firewall. Therefore, I can access some part of 15.X, and some part of
>15.X is not accessible (on the other side). So, I can't access the
>nameserver on the external HP network (but you can). There is no way
>I'm going to know that from the routing table.
> If you want to do a perfect job, the only way to know is to
>try it, i.e. to send the request over the network. But, that's exactly
>what I'm trying to avoid for performance reason. And also because all
>resolver only allow for 3 nameserver, which is totally inadequate for
>such scenario.
>
> So, what do I want to acheive. The point is not to get the
>perfect solution, that's impossible, but to get something that works
>in most cases and give the user enough hooks so that he can make the
>system works for him.
> Now, back to your example. My assumption is that, if DHCP or
>PPP setup goes far enough to get some DNS info, it means that there
>was network connectivity one node on the subnet (PPP/DHCP
>server). Most connectivity problems happen at the link level, which
>means at that point, except rare messup of subnet config, you are good
>to go. Similarly, when link connectivity goes down, PPP and DHCP will
>exit and cleanup.
> If both are up at the same time, you just hope that either the
>nameserver are on the local subnet (most case - would work ok), or
>that the user knows what he is doing and fix the resolver
>configuration accordingly. Because the config is now split in multiple
>files, one per interface, it's easy for the user script to just rename
>the file of the interface it's not using to something else. The
>difference with what we have today, is that today we have an anonymous
>config in /etc/resolv.conf, whereas my proposal allows to strongly
>associate config to interface, making it easy to know which is which.
> Note that in the case of most mobile device, for battery sake,
>you really want to "down" the interfaces that you are not using. And
>it's far easier to just down an interface than to play elaborate
>tricks with the routing table.
>
>
>
Yes for mobile and even portable (battery operated) devices all
interfaces not needed will be not just down, they will be "power off".
This leaves the question of switching sequence: current if goes down
(off line) before next is started. Or opposite? I believe in the first.
A user will always(?) use the cheapest way to connect and only when that
fails switch to the next option (if any). If this is true, clean up is
much easier and only the code for each if going up or down needs to be
involved. This is pretty much current situation, where this gets messy
is when you also have fixed (static) setups involved, and when DHCP or
PPP will not provide the needed details.
Routing tables from my MAC, I don't use IP6:
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default christina.s-carlse UGSc 2 0 en1
localhost localhost UH 10 29367 lo0
169.254 link#5 UCS 0 0 en1
192.168.14 link#5 UCS 1 0 en1
silver.s-carlsen.d localhost UHS 0 0 lo0
christina.s-carlse 0:2:96:1:3e:98 UHLW 5 354 en1 200
Internet6:
Destination Gateway Flags Netif Expire
UH lo0
fe80::%en0 link#4 UC en0
0:3:93:d3:c3:36 UHL lo0
fe80::%en1 link#5 UC en1
0:3:93:eb:7f:59 UHL lo0
ff01:: U lo0
ff02::%lo0 UC lo0
ff02::%en0 link#4 UC en0
ff02::%en1 link#5 UC en1
>>> Please report ;-) Note that Win32 also seems to get it right,
>>>but I don't expect to know how they do it :-(
>>>
>>>
>>>
>>>
>>>
>>As far as I can tell the Apple source code is available at:
>>http://www.opendarwin.org/downloads/
>>
>>I have not looked into the sources, I assume you could get the picture
>>much quicker than me.
>>
>>
>
> I'm not familiar with *BSD code, and I've never used OS-X, so
>you would know much faster than me. Just check the content of
>resolv.conf on a live system and how it evolves.
>
>
>
>
Fresh from the system (behind a NAT. All details given by DHCP):
silver:~>cd /etc
silver:/etc>ls re*
resolv.conf
resolver:
254.169.in-addr.arpa local
silver:/etc>cat resolv.conf
domain s-carlsen.dk
nameserver 192.168.14.254
silver:/etc>cd resolver/
silver:/etc/resolver>ls
254.169.in-addr.arpa local
silver:/etc/resolver>cat local
nameserver 224.0.0.251
port 5353
timeout 1
silver:/etc/resolver>cat 254.169.in-addr.arpa
nameserver 224.0.0.251
port 5353
timeout 1
silver:/etc/resolver>
All the resolver/* stuff is for "Rendevouz" = multicast DNS , even that
works together with windows on a separate isolated network.
> Have fun...
>
> Jean
>
>
--
Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
------------------------------
End of bind-users Digest V6 #153
********************************
More information about the bind-users
mailing list