headers
Paul Jarc | 1 Mar 2004 07:20
Picon

Re: Various "lame" errors

"Robin Bowes" <robin-lists <at> robinbowes.com> wrote:
> I found that certain web sites and mail addresses are not resolving. Also,
> some addresses are resolving, but are shown as "lame".

This might happen if your ISP runs a transparent proxy for DNS
queries.  Ask them whether they do that.

> And here's the log for that:
>
> 2004-02-29 23:02:28.168904500 query 48 c0a80114:e4a8:d888 1 forums.gentoo.org.
> 2004-02-29 23:02:28.168913500 cached 1 forums.gentoo.org.
> 2004-02-29 23:02:28.168916500 sent 48 51

This wouldn't be useful, since it just says that the information wsa
found in the cache.  We would want to see the part thatshows when the
information was received from another server.  But before we worry
about that, check with your ISP about transparent proxying.

> If I change the dnscache to do forward only to my ISP name servers
> (194.168.4.100 and 194.168.8.100) then I see similar results.
>
> However, if I change /etc/resolv.conf to use the ISP servers directly then
> the domains resolve OK, e.g.:

There shouldn't be any difference between these two cases.  Are you
sure you set up forwarding mode correctly?  root/servers/ <at>  should
contain *only* your ISP's cache addresses, not the root servers as
well.  env/FORWARDONLY should be nonempty.  You have to restart
dnscache after making those changes.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gerrit Pape | 1 Mar 2004 08:58

fyi: tinydyndns-0.4.0 available

Hi, for your information.  A new test package of tinydyndns is available

 http://innominate.org/projects/tinydyndns/

With this version the tinydyndns programs can adjust time-to-live and
timestamp (time-to-die or starting time) when creating or updating type
A DNS records, and optionally work on records specified for a special
client location.  The documentation is updated slightly.

Regards, Gerrit.
--

-- 
Open projects at http://smarden.org/pape/.
Permalink | Reply | 0 comments |
headers
Jonathan de Boyne Pollard | 1 Mar 2004 11:29

Re: Various "lame" errors

RB> 2004-02-29 23:00:40.057844500 tx 0 1 www.gentoo.org. gentoo.org. cc4a6501 cc45ea01 cc45ea01
RB> 2004-02-29 23:00:40.069923500 lame cc4a6501 gentoo.org. gentoo.org.
RB> 2004-02-29 23:00:40.069928500 tx 0 1 www.gentoo.org. gentoo.org. cc45ea01 cc45ea01
RB> 2004-02-29 23:00:40.080471500 lame cc45ea01 gentoo.org. gentoo.org.
RB> 2004-02-29 23:00:40.080476500 tx 0 1 www.gentoo.org. gentoo.org. cc45ea01
RB> 2004-02-29 23:00:40.092909500 lame cc45ea01 gentoo.org. gentoo.org.

It looks like the problem that you had in 2003-03, that went away
before you could run the tests that I gave you and thus determine
what it was and actually fix it, is back.  Now is your chance to
run the tests that I gave you then.
Permalink | Reply | 2 comments |
headers
Robin Bowes | 1 Mar 2004 13:37
Favicon

Re: Various "lame" errors

On Mon, March 1, 2004 10:29, Jonathan de Boyne Pollard said:
> RB> 2004-02-29 23:00:40.057844500 tx 0 1 www.gentoo.org. gentoo.org.
> cc4a6501 cc45ea01 cc45ea01
> RB> 2004-02-29 23:00:40.069923500 lame cc4a6501 gentoo.org. gentoo.org.
> RB> 2004-02-29 23:00:40.069928500 tx 0 1 www.gentoo.org. gentoo.org.
> cc45ea01 cc45ea01
> RB> 2004-02-29 23:00:40.080471500 lame cc45ea01 gentoo.org. gentoo.org.
> RB> 2004-02-29 23:00:40.080476500 tx 0 1 www.gentoo.org. gentoo.org.
> cc45ea01
> RB> 2004-02-29 23:00:40.092909500 lame cc45ea01 gentoo.org. gentoo.org.
>
> It looks like the problem that you had in 2003-03, that went away
> before you could run the tests that I gave you and thus determine
> what it was and actually fix it, is back.  Now is your chance to
> run the tests that I gave you then.

I thought the very same thing myself.

Unfortunately (fortunately?) the problem seemed to go away this morning
before I could run any more tests. I'll double check tonight, and if it is
still broken I'll dig out your proposed tests and run them.

I must say, I'm 99% sure it's an upstream issue, i.e. NTL have made
changes to their DNS/IP filter architecture which is impact me.

Cheers,

R.
--

-- 
http://robinbowes.com
(Continue reading)

Permalink | Reply | 1 comment |
headers
Power-Netz (Schwarz | 2 Mar 2004 14:35
Picon

endless loop in query.c


Hi,

"we" recently discovered another endless loop in dnscache 1.05 .

Our dnscaches listen to 127.0.0.1 only!

Problem:

Depending on other activities and cpu power dnscache
varies in TOP from 20-89% cpu usage:

6670 dnscache   9   0  5768 5728   368 S    89,4  0,2 335:44
/usr/local/bin/dnscache

Analysis:

Dnscache tries to get information for webspeed.dk

pls. see below for more information about webspeed.dk's zone

strace -p 6670 shows this loop:

write(2, "lame 00000000000000000000ffffc02"..., 64) = 64
write(2, "tx 0 1 ns.webspeed.dk. webspeed."..., 168) = 168
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 98
fcntl64(98, F_GETFL)                    = 0x2 (flags O_RDWR)
fcntl64(98, F_SETFL, O_RDWR|O_NONBLOCK) = 0
bind(98, {sin_family=AF_INET, sin_port=htons(40303),
sin_addr=inet_addr("0.0.0.0")}}, 16) = 0
(Continue reading)

Permalink | Reply | 573 comments |
headers
Stefaan A Eeckels | 2 Mar 2004 17:56
X-Face
Picon
Favicon

Re: endless loop in query.c

On Tue, 2 Mar 2004 14:35:11 +0100
"Power-Netz \(Schwarz\)" <schwarz <at> power-netz.de> wrote:

> "we" recently discovered another endless loop in dnscache 1.05 .
> 
> Our dnscaches listen to 127.0.0.1 only!
> 
> Problem:
> 
> Depending on other activities and cpu power dnscache
> varies in TOP from 20-89% cpu usage:
> 
> 134.169.10.20 is the named cache  <at>  tu-bs.de . It is not involved
> in the loop, just used to get the zone information dnscache can't give.
> 
> [root <at> d1 apache]# dig  <at> 134.169.10.20 any webspeed.dk
> 
> ; <<>> DiG 9.2.1 <<>>  <at> 134.169.10.20 any webspeed.dk
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49098
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
> 
> ;; QUESTION SECTION:
> ;webspeed.dk.                   IN      ANY
> 
> ;; ANSWER SECTION:
> webspeed.dk.            24791   IN      NS      ns1.webspeed.dk.
> webspeed.dk.            24791   IN      NS      ns2.webspeed.dk.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
mw-list-dns | 2 Mar 2004 18:41
Picon

Re: SPF is harmful. Adopt it.

On Sun, Feb 29, 2004 at 04:25:48AM +0000, Jonathan de Boyne Pollard wrote:
> JdeBP> 1. Set up the IM2000 services, and concomitant user account
> JdeBP> management procedures, for your customers to originate and 
> JdeBP> to recieve mail.
> 
> m> It is like your post about DHCP to the djbdns list: 
> 
> Ironically, it is; but not for the incorrect reason that you give.  
> 
> By the way: This _is_ the "djbdns" list.

Yupp, I messed up accidentally.

> m> you are referring to an unavailable implementation.  
> 
> Untrue.  We haven't been discussing hypotheticals.  

So then where is IM2000 available? 

Mate 

--

-- 
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis  
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
Permalink | Reply | 0 comments |
headers
Jonathan de Boyne Pollard | 2 Mar 2004 19:51

Re: endless loop in query.c

PNS> "we" recently discovered another endless loop in dnscache 1.05 .

No you haven't.  The trace that you show _does not contain a loop_.

If you are going to claim the existence of a loop, you could at least
show one.

PNS> additional: ns1.webspeed.dk 27547 A 0.0.0.0

<URL:http://homepages.tesco.net./~J.deBoynePollard/Softwares/djbdns/#dnscache-strict-forwardonly>

PNS> Solution & Fix :

That is a very badly thought out patch.  It makes unjustified 
assumptions about IP addresses and it changes the semantics of
responses.  Avoid it.
Permalink | Reply | 574 comments |
headers
Jonathan de Boyne Pollard | 2 Mar 2004 20:05

Re: Various "lame" errors

RB> I must say, I'm 99% sure it's an upstream issue, i.e. NTL have
RB> made changes to their DNS/IP filter architecture which is 
RB> impact me.

You still haven't eliminated your NAT machine as the cause of the problem,
because you still haven't run any of the tests without it interposed between
you and the rest of Internet.  

As I said on 2003-03-12, although NTL is boneheaded enough to run interception
proxy HTTP servers, it has not and does not, in my experience, run
interception proxy DNS servers.  (I wouldn't have been able to diagnose other
people's content DNS service problems over the past few years if it had.)
Permalink | Reply | 0 comments |
headers
Power-Netz (Schwarz | 3 Mar 2004 12:26
Picon

AW: endless loop in query.c

> ; <<>> DiG 9.2.1 <<>>  <at> 134.169.10.20 any webspeed.dk
> > ns1.webspeed.dk.        27547   IN      A       0.0.0.0
> > ns2.webspeed.dk.        27547   IN      A       194.239.10.182

> ; <<>> DiG 9.2.1 <<>>  <at> 134.169.10.20 any webspeed.dk
> ns2.webspeed.dk.	68340	IN	A	194.239.10.182

> No loop here. Or if this isn't where the "endless loop" manifests
> itself, please indicate the command you used to trigger it. Maybe
> the webspeed.dk people fixed their DNS?

I still get the 0.0.0.0 In A with the same DIG as you use.

maybe a libresolv error? 

Paul, what do you think?
Permalink | Reply | 1 comment |

Gmane