Your email message was blocked
mailmarshall at mailgate.linney.co.uk
mailmarshall at mailgate.linney.co.uk
Wed Jul 30 07:08:36 UTC 2003
MailMarshal (an automated content monitoring gateway) has
stopped the following email for the following reason:
It believes it may contain unacceptable language, or inappropriate material.
Message: BB00041560.00000001.mml
From: bind-users at isc.org
To: drees at groupwise.linney.com
Subject: bind-users Digest V5 #199
Please remove any inappropriate language and send it again.
The blocked email will be automatically deleted after 5 days.
MailMarshal Rule: Inbound Messages : Block Unacceptable Language
Script Offensive Language (Basic) Triggered in Body
Expression: bullshit Triggered 1 times weighting 5
Email security by MailMarshal from Marshal Software.
-- Attached file included as plaintext by Ecartis --
-- File: BB00041560.00000001.eml
Received: from elgar.linney.co.uk (Not Verified[195.182.180.2]) by mailgate2.linney.co.uk with MailMarshal (v5,0,3,91)
id <BB00041560>; Wed, 30 Jul 2003 08:08:36 +0100
Received: from mailgate.linney.co.uk [195.182.180.245] by elgar.linney.co.uk with ESMTP
Received: from minardi.isc.org (Not Verified[204.152.189.14]) by mailgate.linney.co.uk with MailMarshal (v5,0,3,91)
id <BA0004f571>; Sat, 26 Jul 2003 08:51:51 +0100
Received: from rc3.isc.org (rc3.isc.org [204.152.187.25])
by minardi.isc.org (Postfix) with ESMTP
id E838E35E6; Sat, 26 Jul 2003 07:50:00 +0000 (UTC)
(envelope-from bind-users-bounce at isc.org)
Received: with ECARTIS (v1.0.0; list bind-users); Sat, 26 Jul 2003 07:50:00 +0000 (UTC)
Date: Sat, 26 Jul 2003 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 V5 #199
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: <~BA0004f571.00052c76.mml.4252458519 at minardi.isc.org>
bind-users Digest Fri, 25 Jul 2003 Volume: 05 Issue: 199
In This Issue:
RE: Reverse mapping on a non-octet boundary
nsupdate on MS Windows
Re: Details of Propagation
Re: DNS anomaly
Re: DNS anomaly
dispatch: error:
Re: DNS anomaly
Re: This hostmaster should be PUNISHED
Re: This hostmaster should be PUNISHED
Re: This hostmaster should be PUNISHED
DNS Forwarders from Windows to Linux
Re: DNS Forwarders from Windows to Linux
Re: Details of Propagation
Re: Queries fail first time round
----------------------------------------------------------------------
From: Sam Pointer <sam.pointer at hpdsoftware.com>
Subject: RE: Reverse mapping on a non-octet boundary
Date: Fri, 25 Jul 2003 11:05:08 +0100
Thanks for your help! I now see that my provider *has* followed the RFC2317
method that I have used before with my other ISP.
I think my confusion came from thinking about it too hard! I now see, as you
say, that I will have to maintain 3 files for the various ranges.
Again, many thanks for your help. This list and its population has been a
wonderful resource to me.
>No, not in this case ( unless your provider makes adjustments )
>
>What your provider delegated is 3 zones :
>0-31.246.167.195.in-addr.arpa.
>32-39.246.167.195.in-addr.arpa.
>40-43.246.167.195.in-addr.arpa.
>
>You will setup 3 zonefiles, ( zone "0-31.246.167.195.in-addr.arpa" { ... )
>with contents exactly as if you owned the 246.167.195.in-addr.arpa :
>@ IN SOA ( ...
> IN NS xxx
> IN NS yyy
>1 IN PTR firsthost.domain.tld.
>2 IN PTR secondhost.domain.tld.
>etc
>If you could convince your provider to delegate all three ranges as :
>hpdsc IN NS ns1.hpdsc.com.
>hpdsc IN NS ns2.hpdsc.com.
>and in their CNAME replace "[0-31|32-39|40-43]" with "hpdsc"
>you would of course be autorative for "hpdsc.246.167.195.in-addr.arpa."
>and could have all your PTR in this file.
This email and any attachments are strictly confidential and are intended
solely for the addressee. If you are not the intended recipient you must
not disclose, forward, copy or take any action in reliance on this message
or its attachments. If you have received this email in error please notify
the sender as soon as possible and delete it from your computer systems.
Any views or opinions presented are solely those of the author and do not
necessarily reflect those of HPD Software Limited or its affiliates.
At present the integrity of email across the internet cannot be guaranteed
and messages sent via this medium are potentially at risk. All liability
is excluded to the extent permitted by law for any claims arising as a re-
sult of the use of this medium to transmit information by or to
HPD Software Limited or its affiliates.
------------------------------
From: "Cinense, Mark" <macinen at sandia.gov>
Subject: nsupdate on MS Windows
Date: Fri, 25 Jul 2003 07:33:04 -0600
I am running nsupdate on a Windows 2000 server, and updating a Bind 9.2.2
server. Does anyone know why I might be having problems with the nsupdate
utility. The problem is that it hangs sometimes, and on some days a lot and
on other days not at all. I guess nsupdate uses udp, is this correct? Just
about everyone in the server group thinks it is the network switch, and of
course the network group thinks it is our servers. The nsupdate utility is
the one from ISC's website, and it is compiled for Win32.
Please help.
Mark
------------------------------
Date: Fri, 25 Jul 2003 08:26:15 -0700
From: Jeff Lasman <jblists at nobaloney.net>
Subject: Re: Details of Propagation
Whizkid25468 wrote:
> I am, com, I meant to write com's servers (that was a, uhh, keyboard error,
> yeah, keyboard), but knowing about the root servers can't hurt /;-)<<. So
> when are com's servers supposed to be updated?
I, too, keep hearing 5am and 5pm, and I'm certainly no expert, but I
have seen that when I change a nameserver's IP# or add a nameserver at
some point in the afternoon (I'm in California, PDT, currently -0700),
it's usually in the TLD servers by the next morning. So 5am/5pm is
definitely a possibility (as uncertain as that sounds).
> > > Finally, I've been *unreliably* informed that propagation time from the
> > > point of view of using your ISP's nameserver can depend on the size of
> your
> > > ISP, the type of nameserver you're on, and how often it's *set to
> update*.
> > > Isn't propagation (once the root servers update) purely dependant on the
> > > TTLs of the affected records? The size of the ISP shouldn't matter!
> >
> > True.
>
> Oh good, my entire understanding of the DNS isn't completly off the mark
> then /:-)<<.
Again, I'm no expert, but it's been my experience (and I've heard from
others) that aol seems to ignore TTL and has their own agenda for
updating. Some people add that they only do it if the TTL is
"unreasonably" short, but no one seems to know what "unreasonably" means
<frown>.
> Unless you use Dynamic DNS /:-\<<. A component of that is to turn the TTL
> down really low on your records, isn't it?
That depends on how badly you want your systems to be found <smile>. In
general yes, but you shouldn't be using Dynamic DNS for systems visible
on the 'net, and for local DNS, it doesn't really matter.
And in case you haven't noticed, there's still a lot of mystery in what
is without a doubt the most important service on the Internet.
Jeff
--
Jeff Lasman, nobaloney.net, P. O. Box 52672, Riverside, CA 92517 US
Internet & Unix/Linux/Sun/Cobalt Consulting +1 909 324-9706
Our jblists address used on lists is for list email only
To contact us offlist: "http://www.nobaloney.net/contactus.html"
------------------------------
From: Jonathan de Boyne Pollard <J.deBoynePollard at tesco.net>
Subject: Re: DNS anomaly
Date: Fri, 25 Jul 2003 15:34:12 +0100
RK> There seems to be a problem with the Telstra DNS servers [...]
No, there isn't. There is nothing wrong with either 139.134.5.51 or
139.134.2.190. Neither of those servers are "ninthave.net." content
DNS servers. (The "ninthave.net." content DNS servers are
212.100.225.215, 194.153.169.31, 194.153.169.15, and 212.13.198.12.)
You sent them queries with the RD bit set to 0 in your tests, and
they replied with whatever data they happened to have cached at the
time. The lack of "glue" resource records in the reply is not an
error. They simply didn't have the glue cached. Right now, they
don't have _anything_ about "ninthave.net." in their caches at all.
Moreover: The fact that an apparently entirely randomly selected IP
address, 61.9.208.24, doesn't provide DNS service to the world is not
a problem, either.
Furthermore: I don't know from whence you get the idea that
RK> "Counsel.com.au." also has an IN A address at
RK> "ns7.zoneedit.com."
but this (with the obvious error of "IN A address" for "IN NS name"
corrected) is not supported by any DNS data that are being published
by either the "counsel.com.au." or the "com.au." content DNS servers,
or by any of the test results that you show.
There _is_ a problem with "counsel.com.au.", but it is nothing to do
with ZoneEdit, with Telstra, or with your randomly selected IP
address. Because of the choice of intermediate domain names in the
delegation information, the domain is effectively glueless.
"[a-d].ns.bytemark.co.uk." are not subdomains of "com.au.".
------------------------------
From: Jonathan de Boyne Pollard <J.deBoynePollard at tesco.net>
Subject: Re: DNS anomaly
Date: Fri, 25 Jul 2003 15:25:25 +0100
BM> Telstra's DNS servers don't seem to be running BIND, [...]
The DNS servers that he is referring to as "Telstra's DNS servers" here are
139.134.2.190 and 139.134.5.51, both of which advertise that they are BIND
version 8.2.4.
------------------------------
From: "bizbox" <bizbox at yahoo.com>
Subject: dispatch: error:
Date: Fri, 25 Jul 2003 09:32:52 +0800
hi,
i have been seeing the following in the log
Jul 25 09:33:01.770 dispatch: error: dispatch 0x9bd0168: shutting down due
to TCP receive error: connection reset
Jul 25 09:33:02.644 dispatch: error: dispatch 0x9bd0168: shutting down due
to TCP receive error: connection reset
Jul 25 09:33:03.697 dispatch: error: dispatch 0x9bd0168: shutting down due
to TCP receive error: connection reset
Jul 25 09:33:07.415 dispatch: error: dispatch 0x9bd0168: shutting down due
to TCP receive error: connection reset
any idea wat is it going on??
------------------------------
Date: Fri, 25 Jul 2003 12:36:14 +1000
From: Roger Keays <r.keays at ninthave.net>
Subject: Re: DNS anomaly
> Glue records are A records for the subdomain nameservers that are in the
> *parent* zone. They only exist when the domain is delegated to nameservers
> that are in the domain they serve. Since ninthave.net is delegated to
> servers in the bytemark.co.uk domain, there are no glue records.
>
Thanks for that correction.
>
>>I'm doubly confused as the problem only seems to occur on Telstra DNS
>
>
> Telstra's DNS servers don't seem to be running BIND, so they may deal with
> this anomaly differently than most other servers.
>
>
>>servers, and triply confused because the domain counsel.com.au which has
>>almost identical configuration and the same nameservers works fine (even
>>with Telstra servers).
>
>
> Maybe this is because Telstra hosts one of the authoritative servers for
> the com.au domain.
>
The problem fixed itself when the NS record for ninthave.net expired
from the offending DNS server. When these records were reloaded, the
corresponding A records for my nameservers were found.... can't
understand why they weren't found previously, but it appears to be
specific to the .net domain.
I get the impression that when the DNS server first loaded ninthave.net
it couldn't find an A record for the nameservers (perhaps a network
outage, or wasn't supplied with one from the .net nameservers), and it
never tried again to find these records.
...OR... it *was* trying to find these records but was querying
ns.ninthave.net (for the address a.ns.ninthave.net)..
... nope, that doesn't make sense either... still confused ...
Thanks for your help
Roger
--
------------------------------------------------------------------------
ninth ave p: +61 7 3870 8494
Web Hosting m: +61 405 048 371
Web Design w: http://www.ninthave.net
Programming e: r.keays at ninthave.net
------------------------------------------------------------------------
------------------------------
From: Nico Kadel-Garcia <nkadel at verizon.net>
Subject: Re: This hostmaster should be PUNISHED
Date: Fri, 25 Jul 2003 02:19:45 GMT
Joseph S D Yao wrote:
> On Wed, Jul 23, 2003 at 09:32:37PM -0500, Jeff Stevens wrote:
>
>>On 7/23/2003 2:57 PM, Joseph S D Yao wrote:
>>
>>>>;; ADDITIONAL SECTION:
>>>>mx2.netpussies.com. 8h57m49s IN A 127.0.0.1
>>>>mx1.netpussies.com. 8h57m42s IN A 127.0.0.1
>>
>>What exactly happens with this configuration? Any attempt to email to
>>this domain simply loops back to yourself. Am I missing something?
>>--
>>Jeffrey Stevens
>
>
> All you're missing is that this is a nasty-spam site, and they knew
> everyone would want to complain. So they made it so you couldn't.
Yeah, this sort of bullshit is illegal in some states that require ads
to carry legitimate return addresses. But take a look at their SOA record:
# dig -t mx mx2.netpussies.com
; <<>> DiG 9.2.1 <<>> -t mx mx2.netpussies.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49240
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;mx2.netpussies.com. IN MX
;; AUTHORITY SECTION:
netpussies.com. 10800 IN SOA ns1.techhosting.net.
dns.techhosting.net. 2001011100 43200 7200 604800 43200
So we see, they're being hosted by ns1.techhosting.net. That's where to
go to get these folks cut off, at least in the short term.
------------------------------
From: Jonathan de Boyne Pollard <J.deBoynePollard at tesco.net>
Subject: Re: This hostmaster should be PUNISHED
Date: Fri, 25 Jul 2003 04:26:18 +0100
JS> What exactly happens with this configuration?
An invocation of the procedure outlined in the final
paragraph of section 5 of RFC 2821.
------------------------------
From: Jonathan de Boyne Pollard <J.deBoynePollard at tesco.net>
Subject: Re: This hostmaster should be PUNISHED
Date: Fri, 25 Jul 2003 04:38:20 +0100
I submit that the hostmaster of "aereolineas.com.ar." is a _far_ better
candidate.
------------------------------
From: laurence at kashya.com (Laurence Mayer)
Subject: DNS Forwarders from Windows to Linux
Date: 25 Jul 2003 01:13:05 -0700
Hi,
I have a Windows DNS with doaminname.com for our Windows environment,
and a Linux (RH 8.0) DNS with domainname.com for our linux
environment, each with the same domain names.
I have enabled forwarders on the Windows 2k server, to point to the
Linux DNS Server, so that users in the Windows environment can get to
machines in the Linux environment, BUT when doing a dns lookup from
the Windows environment for a host on the linux DNS it does not
resolve.
Is this because they have the same domain names?
Is this workable?
Any suggestions?
Thanks
Laurence
------------------------------
From: Barry Margolin <barry.margolin at level3.com>
Subject: Re: DNS Forwarders from Windows to Linux
Date: Fri, 25 Jul 2003 19:02:37 GMT
In article <bfrtbl$s0c$1 at sf1.isc.org>,
Laurence Mayer <laurence at kashya.com> wrote:
>Hi,
>I have a Windows DNS with doaminname.com for our Windows environment,
>and a Linux (RH 8.0) DNS with domainname.com for our linux
>environment, each with the same domain names.
>
>I have enabled forwarders on the Windows 2k server, to point to the
>Linux DNS Server, so that users in the Windows environment can get to
>machines in the Linux environment, BUT when doing a dns lookup from
>the Windows environment for a host on the linux DNS it does not
>resolve.
>
>Is this because they have the same domain names?
Yes. A server won't forward if it's authoritative for the domain.
>Any suggestions?
Do all the administration on one server, and configure the other one as a
slave. Or use separate domain names.
Note that having both of them forwarding to each other can result in a loop
if someone tries to look up something that's not in either of their
domains. I'm not sure if BIND checks for the case of forwarding back to
the same address it received the query from.
--
Barry Margolin, barry.margolin at level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
------------------------------
From: "Whizkid25468" <whizkidxxxxx at oceanfree.net>
Subject: Re: Details of Propagation
Date: Fri, 25 Jul 2003 21:17:20 +0100
"Jeff Lasman" <jblists at nobaloney.net> wrote in message
news:bfrihb$jf0$1 at sf1.isc.org...
> Whizkid25468 wrote:
>
> > I am, com, I meant to write com's servers (that was a, uhh, keyboard
error,
> > yeah, keyboard), but knowing about the root servers can't hurt /;-)<<.
So
> > when are com's servers supposed to be updated?
>
> I, too, keep hearing 5am and 5pm, and I'm certainly no expert, but I
> have seen that when I change a nameserver's IP# or add a nameserver at
> some point in the afternoon (I'm in California, PDT, currently -0700),
> it's usually in the TLD servers by the next morning. So 5am/5pm is
> definitely a possibility (as uncertain as that sounds).
Well, further agreement (no matter how uncertain) is nice. /:-)<<
>
> > > > Finally, I've been *unreliably* informed that propagation time from
the
> > > > point of view of using your ISP's nameserver can depend on the size
of
> > your
> > > > ISP, the type of nameserver you're on, and how often it's *set to
> > update*.
> > > > Isn't propagation (once the root servers update) purely dependant on
the
> > > > TTLs of the affected records? The size of the ISP shouldn't matter!
> > >
> > > True.
> >
> > Oh good, my entire understanding of the DNS isn't completly off the mark
> > then /:-)<<.
>
> Again, I'm no expert, but it's been my experience (and I've heard from
> others) that aol seems to ignore TTL and has their own agenda for
> updating. Some people add that they only do it if the TTL is
> "unreasonably" short, but no one seems to know what "unreasonably" means
> <frown>.
Hmm, I don't like people who don't follow standards. If everyone follows one
standard, and you know it, you know how an awful lot of people do things. If
people do things differently there are more variables involved. But AOL
overriding TTLs isn't really a major worry, who cares if a few AOLers can't
see a website or two?
>
> > Unless you use Dynamic DNS /:-\<<. A component of that is to turn the
TTL
> > down really low on your records, isn't it?
>
> That depends on how badly you want your systems to be found <smile>. In
> general yes, but you shouldn't be using Dynamic DNS for systems visible
> on the 'net, and for local DNS, it doesn't really matter.
It's a funny idea, turning down the TTL. The whole 'take the load off
individual systems' thing kinda gets lost somewhere.
>
> And in case you haven't noticed, there's still a lot of mystery in what
> is without a doubt the most important service on the Internet.
Yeah, noticed that. Oh well. /;-)<<
>
> Jeff
> --
> Jeff Lasman, nobaloney.net, P. O. Box 52672, Riverside, CA 92517 US
> Internet & Unix/Linux/Sun/Cobalt Consulting +1 909 324-9706
> Our jblists address used on lists is for list email only
> To contact us offlist: "http://www.nobaloney.net/contactus.html"
>
------------------------------
Date: Fri, 25 Jul 2003 19:36:32 -0400
From: Kevin Darcy <kcd at daimlerchrysler.com>
Subject: Re: Queries fail first time round
Simon Hobson wrote:
> I have a longstanding issue with our BIND setup. If a domain has not
> been queried for some time, a query for a host in it often fails the
> first time, but then repeating the request results in a successful
> lookup. The lookup failures happen with a wide range of domains, so
> I'm pretty certain it's going to be something internal.
>
> I have two internal servers :
> 1 - BIND 9.2.1 on RedHat 6.2
> 2 - BIND 8.2.2-P7 on SCO OpenServer 5.0.6a
>
> 1 is the master for all my internal zones, 2 is the secondary. Both
> are configured to go out to the root servers for everything else.
>
> Nothing is ever logged by either server when a lookup fails. I don't
> know whether to blame my DNS servers or my clients - I have a
> suspicion that it might be my clients (I've personally only noticed
> this effect with Mac clients, but then I avoid windoze as much as I
> can) being too demanding and refusing to wait for an answer. Our
> connection is with Demon Internet at 64k over ISDN (which is up
> almost all the time these days).
>
> Does anyone have any clues how to track this one down ?
Well, BIND 8 doesn't have "query restart", so in certain circumstances
it will get only part way towards an answer and then rely on the client
retrying its query in order to finish resolution of the name. BIND 9
doesn't have this problem, though, so it doesn't really explain the
symptoms you're seeing.
I haven't worked much with ISDN -- is there any possibility that
sometimes your ISDN connection goes "idle" and then needs to "wake
up" when it gets a DNS query, thus introducing an excessive amount of
latency from time to time? My experience has been that DNS tends to be
like the canary in the coal mine -- it's often the first thing to fail
whenever you have any kind of latency or packet-loss problems.
When all speculation fails, of course, it's probably time to roll up
your sleeves, fire up the old sniffer (which could be a piece of fancy
standalone hardware, or just something like "tcpdump") and look what's
happening at the packet level.
- Kevin
------------------------------
End of bind-users Digest V5 #199
********************************
More information about the bind-users
mailing list