|
|
|
|
|
|
| Author |
Message |
Mike Scott
*nix forums Guru Wannabe
Joined: 25 Feb 2005
Posts: 138
|
 Posted: Tue Jul 11, 2006 5:20 pm Post subject:
Re: major DNS hiccup
|
|
|
Andrew Haley wrote:
....
| Quote: | But thanks for the ideas. Somehow I get the most horrible feeling this
will all be down to something incredibly obvious that I've just been
missing totally.....
FWIW, my failures began at 11:03:54 on Jul 6.
Mike, can you have a look at your named logs, and see when it started?
Andrew.
Jul 6 11:03:54 mammoth named[2671]: lame server resolving 'gmail.com' (in 'gmail.com'?): 216.239.34.10#53
|
Hate to disappoint, but I don't get any logged errors or other useful
messages, just the start and stop messages. However, I know this all
started sometime thursday, that would be 6th, probably morning.
If it's ntl (I'm Cambridge too, btw - Harlow) I can't imagine what
they're doing. I see reply packets with correct checksums and no
noticeable missing packets - so they'd have to be intercepting DNS
packets, garbaging and retransmitting them: somehow I doubt ntl could
manage that quite so successfully :-)
I assume your messages listed are lookup failures? FWIW I /can/ resolve
backmx.iol.cz as 194.228.41.113, also I get
;; ANSWER SECTION:
gmail.com. 60 IN A 64.233.161.83
gmail.com. 60 IN A 64.233.171.83
gmail.com. 60 IN A 216.239.57.83
so it looks as though we have different failures (maybe you could check
www.yell.co.uk please?)
I suppose I /could/ resurrect my old dial-up account - but as that's
tesconet, it's not likely to be any different at all!
--
Please use the corrected version of the address below for replies.
Replies to the header address will be junked, as will mail from
various domains listed at www.scottsonline.org.uk
Mike Scott Harlow Essex England.(unet -a-t- scottsonline.org.uk) |
|
| Back to top |
|
 |
Andrew Haley
*nix forums beginner
Joined: 11 Jul 2006
Posts: 7
|
| Posted: Tue Jul 11, 2006 5:46 pm Post subject:
Re: major DNS hiccup
|
|
|
Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
| Quote: | Andrew Haley wrote:
...
But thanks for the ideas. Somehow I get the most horrible feeling this
will all be down to something incredibly obvious that I've just been
missing totally.....
FWIW, my failures began at 11:03:54 on Jul 6.
Mike, can you have a look at your named logs, and see when it started?
Jul 6 11:03:54 mammoth named[2671]: lame server resolving 'gmail.com' (in 'gmail.com'?): 216.239.34.10#53
Hate to disappoint, but I don't get any logged errors or other useful
messages, just the start and stop messages. However, I know this all
started sometime thursday, that would be 6th, probably morning.
If it's ntl (I'm Cambridge too, btw - Harlow) I can't imagine what
they're doing. I see reply packets with correct checksums and no
noticeable missing packets - so they'd have to be intercepting DNS
packets, garbaging and retransmitting them: somehow I doubt ntl
could manage that quite so successfully 
|
I suppose if the UDP checksums are alright, it couldn't be MTU
problems.
Couldn't they be trying to cache DNS queries? They have their famous
"transparent" web proxy, after all, so we know they definitely are
stupid enough.
We have some real solid evidence here: it _can't_ be the local named
configuration because the exact same named works when I simply change
the network connection. Something (either that NTL are doing or all
those name servers that send packets to NTL are doing) is garbling DNS
responses. I suppose to prove it for sure I could try it again by
plugging in the NTL connection.
| Quote: | I assume your messages listed are lookup failures? FWIW I /can/ resolve
backmx.iol.cz as 194.228.41.113, also I get
;; ANSWER SECTION:
gmail.com. 60 IN A 64.233.161.83
gmail.com. 60 IN A 64.233.171.83
gmail.com. 60 IN A 216.239.57.83
|
It comes and goes. Yes, they came back as lookup failures; sometimes
it worked, sometimes not.
| Quote: | so it looks as though we have different failures (maybe you could check
www.yell.co.uk please?)
|
Well, I'd have to disconnect from Demon and reconnect to NTL.
Andrew. |
|
| Back to top |
|
|
Per Hedeland
*nix forums Guru Wannabe
Joined: 20 Feb 2005
Posts: 182
|
| Posted: Tue Jul 11, 2006 5:55 pm Post subject:
Re: major DNS hiccup
|
|
|
In article <E5Rsg.96337$uP.82275@newsfe2-gui.ntli.net> Mike Scott
<usenet.10@spam.stopper.scottsonline.org.uk> writes:
| Quote: |
If it's ntl (I'm Cambridge too, btw - Harlow) I can't imagine what
they're doing. I see reply packets with correct checksums and no
noticeable missing packets - so they'd have to be intercepting DNS
packets, garbaging and retransmitting them: somehow I doubt ntl could
manage that quite so successfully
|
You still haven't posted any traces from failed lookups - if you do,
maybe someone could figure out just what is wrong with them...
--Per Hedeland
per@hedeland.org |
|
| Back to top |
|
|
Mike Scott
*nix forums Guru Wannabe
Joined: 25 Feb 2005
Posts: 138
|
| Posted: Wed Jul 12, 2006 8:06 am Post subject:
Re: major DNS hiccup
|
|
|
Per Hedeland wrote:
| Quote: | In article <E5Rsg.96337$uP.82275@newsfe2-gui.ntli.net> Mike Scott
usenet.10@spam.stopper.scottsonline.org.uk> writes:
If it's ntl (I'm Cambridge too, btw - Harlow) I can't imagine what
they're doing. I see reply packets with correct checksums and no
noticeable missing packets - so they'd have to be intercepting DNS
packets, garbaging and retransmitting them: somehow I doubt ntl could
manage that quite so successfully :-)
You still haven't posted any traces from failed lookups - if you do,
maybe someone could figure out just what is wrong with them...
--Per Hedeland
per@hedeland.org
|
I thought I had  I must be getting muddled about what I've posted
and what not; sorry.
Anyway, I'm going to check out dnstracer (thanks Chronos) as well again
today or tomorrow - the output made my head spin last night - and I'll
get back hopefully with detailed info from a definitive failure.
(Thanks to all for the patient help being given here!)
--
Please use the corrected version of the address below for replies.
Replies to the header address will be junked, as will mail from
various domains listed at www.scottsonline.org.uk
Mike Scott Harlow Essex England.(unet -a-t- scottsonline.org.uk) |
|
| Back to top |
|
|
Andrew Haley
*nix forums beginner
Joined: 11 Jul 2006
Posts: 7
|
| Posted: Wed Jul 12, 2006 8:49 am Post subject:
Re: major DNS hiccup
|
|
|
Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
| Quote: | Per Hedeland wrote:
In article <E5Rsg.96337$uP.82275@newsfe2-gui.ntli.net> Mike Scott
usenet.10@spam.stopper.scottsonline.org.uk> writes:
If it's ntl (I'm Cambridge too, btw - Harlow) I can't imagine what
they're doing. I see reply packets with correct checksums and no
noticeable missing packets - so they'd have to be intercepting DNS
packets, garbaging and retransmitting them: somehow I doubt ntl could
manage that quite so successfully :-)
You still haven't posted any traces from failed lookups - if you do,
maybe someone could figure out just what is wrong with them...
--Per Hedeland
per@hedeland.org
I thought I had I must be getting muddled about what I've posted
and what not; sorry.
Anyway, I'm going to check out dnstracer (thanks Chronos) as well again
today or tomorrow - the output made my head spin last night - and I'll
get back hopefully with detailed info from a definitive failure.
|
That'd be good. I'd like to go back to NTL if that's at all possible:
my Demon connection is a good deal slower than my NTL one.
So, if there are any experiment I can do, I will. It's just a matter
of hooking up the NTL connection again, and that should only take a
few minutes.
Andrew. |
|
| Back to top |
|
|
Andrew Haley
*nix forums beginner
Joined: 11 Jul 2006
Posts: 7
|
| Posted: Fri Jul 14, 2006 6:26 pm Post subject:
Re: major DNS hiccup
|
|
|
Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
| Quote: | Per Hedeland wrote:
In article <E5Rsg.96337$uP.82275@newsfe2-gui.ntli.net> Mike Scott
usenet.10@spam.stopper.scottsonline.org.uk> writes:
If it's ntl (I'm Cambridge too, btw - Harlow) I can't imagine what
they're doing. I see reply packets with correct checksums and no
noticeable missing packets - so they'd have to be intercepting DNS
packets, garbaging and retransmitting them: somehow I doubt ntl could
manage that quite so successfully :-)
You still haven't posted any traces from failed lookups - if you do,
maybe someone could figure out just what is wrong with them...
--Per Hedeland
per@hedeland.org
I thought I had I must be getting muddled about what I've posted
and what not; sorry.
Anyway, I'm going to check out dnstracer (thanks Chronos) as well again
today or tomorrow - the output made my head spin last night - and I'll
get back hopefully with detailed info from a definitive failure.
|
As a postscript to all of this, I have now spoken with several NTL
customers in Cambridge, and they all have experienced the same DNS
problems. It seems that the fix is to point your DNS forwarder at
NTL's own name servers, rather than using using the roots.
I find it hard to imagine what the cause of this might be. Maybe NTL
are even doing this deliberately to reduce their own DNS traffic? Or
maybe it's an attempt at filtering:
http://technology.guardian.co.uk/weekly/story/0,,1807757,00.html
Andrew. |
|
| Back to top |
|
|
Mike Scott
*nix forums Guru Wannabe
Joined: 25 Feb 2005
Posts: 138
|
| Posted: Sat Jul 15, 2006 6:28 pm Post subject:
Re: major DNS hiccup
|
|
|
Andrew Haley wrote:
| Quote: | Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
Per Hedeland wrote:
In article <E5Rsg.96337$uP.82275@newsfe2-gui.ntli.net> Mike Scott
usenet.10@spam.stopper.scottsonline.org.uk> writes:
If it's ntl (I'm Cambridge too, btw - Harlow) I can't imagine what
they're doing. I see reply packets with correct checksums and no
noticeable missing packets - so they'd have to be intercepting DNS
packets, garbaging and retransmitting them: somehow I doubt ntl could
manage that quite so successfully
You still haven't posted any traces from failed lookups - if you do,
maybe someone could figure out just what is wrong with them...
--Per Hedeland
per@hedeland.org
I thought I had I must be getting muddled about what I've posted
and what not; sorry.
Anyway, I'm going to check out dnstracer (thanks Chronos) as well again
today or tomorrow - the output made my head spin last night - and I'll
get back hopefully with detailed info from a definitive failure.
As a postscript to all of this, I have now spoken with several NTL
customers in Cambridge, and they all have experienced the same DNS
problems. It seems that the fix is to point your DNS forwarder at
NTL's own name servers, rather than using using the roots.
I find it hard to imagine what the cause of this might be. Maybe NTL
are even doing this deliberately to reduce their own DNS traffic? Or
maybe it's an attempt at filtering:
http://technology.guardian.co.uk/weekly/story/0,,1807757,00.html
Andrew.
|
Hmm. That's all about making UK ISPs filter child-p0rn web sites. The UK
government is forcing UK broadband users to cover the cost of probably
useless filtering, which may have got ntl to break DNS on the way.
Wonderful.
In light of Andrew's comments, I'm not sure there's much point in
further 'unaimed' checking of the problems I'm seeing. However, the only
thing I can think of that ntl might have done to cause this is install
transparent DNS proxies -- although I've never heard of such a thing,
I'd assume the idea's at least plausible. Can anyone think of a way of
testing this hypothesis?
I guess this isn't strictly a c.u.b.f.misc topic any more. Maybe it
should move to a more appropriate group??? Suggestions?
--
Please use the corrected version of the address below for replies.
Replies to the header address will be junked, as will mail from
various domains listed at www.scottsonline.org.uk
Mike Scott Harlow Essex England.(unet -a-t- scottsonline.org.uk) |
|
| Back to top |
|
|
Mike Scott
*nix forums Guru Wannabe
Joined: 25 Feb 2005
Posts: 138
|
| Posted: Mon Jul 17, 2006 10:48 am Post subject:
Re: major DNS hiccup
|
|
|
Per Hedeland wrote:
| Quote: | In article <E5Rsg.96337$uP.82275@newsfe2-gui.ntli.net> Mike Scott
usenet.10@spam.stopper.scottsonline.org.uk> writes:
If it's ntl (I'm Cambridge too, btw - Harlow) I can't imagine what
they're doing. I see reply packets with correct checksums and no
noticeable missing packets - so they'd have to be intercepting DNS
packets, garbaging and retransmitting them: somehow I doubt ntl could
manage that quite so successfully :-)
You still haven't posted any traces from failed lookups - if you do,
maybe someone could figure out just what is wrong with them...
--Per Hedeland
per@hedeland.org
|
OK, I've come back to this at last. Hoping it might have gone away as
suddenly as it arrived; but no such luck :-(
I ran 'dig' to look up the address of one of the always-failing names.
'dig' output plus ethereal diagnosis follow. named running as caching
nameserver on localhost.
If this really is due to ntl (my ISP) messing up, I'd appreciate some
advice on how to prove that really is the case.
(more at end)
data# dig @localhost www.yell.co.uk
; <<>> DiG 9.3.2 <<>> @localhost www.yell.co.uk
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 59976
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.yell.co.uk. IN A
;; Query time: 1339 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jul 17 11:32:48 2006
;; MSG SIZE rcvd: 32
=======
ethereal stuff......
No. Time Source Destination
Protocol Info
3 11:32:48.292602 86.22.67.158 194.74.151.194 DNS
Standard query A www.yell.co.uk
Frame 3 (85 bytes on wire, 85 bytes captured)
Ethernet II, Src: SurecomT_73:22:c3 (00:02:44:73:22:c3), Dst:
Cisco_28:1c:01 (00:12:da:28:1c:01)
Internet Protocol, Src: 86.22.67.158 (86.22.67.158), Dst: 194.74.151.194
(194.74.151.194)
User Datagram Protocol, Src Port: 60882 (60882), Dst Port: domain (53)
Source port: 60882 (60882)
Destination port: domain (53)
Length: 51
Checksum: 0x6acc [correct]
Domain Name System (query)
Transaction ID: 0x67a3
Flags: 0x0000 (Standard query)
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data OK:
Non-authenticated data is unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
www.yell.co.uk: type A, class IN
Name: www.yell.co.uk
Type: A (Host address)
Class: IN (0x0001)
Additional records
No. Time Source Destination
Protocol Info
4 11:32:48.300886 194.74.151.194 86.22.67.158 DNS
Standard query response, Format error
Frame 4 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Cisco_28:1c:01 (00:12:da:28:1c:01), Dst:
SurecomT_73:22:c3 (00:02:44:73:22:c3)
Internet Protocol, Src: 194.74.151.194 (194.74.151.194), Dst:
86.22.67.158 (86.22.67.158)
User Datagram Protocol, Src Port: domain (53), Dst Port: 60882 (60882)
Source port: domain (53)
Destination port: 60882 (60882)
Length: 20
Checksum: 0x35d8 [correct]
Domain Name System (response)
Transaction ID: 0x67a3
Flags: 0x8081 (Standard query response, Format error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority
for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... 1... .... = Recursion available: Server can do
recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority
portion was not authenticated by the server
.... .... .... 0001 = Reply code: Format error (1)
Questions: 0
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
No. Time Source Destination
Protocol Info
5 11:32:48.347740 86.22.67.158 194.74.151.194 DNS
Standard query A www.yell.co.uk
Frame 5 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: SurecomT_73:22:c3 (00:02:44:73:22:c3), Dst:
Cisco_28:1c:01 (00:12:da:28:1c:01)
Internet Protocol, Src: 86.22.67.158 (86.22.67.158), Dst: 194.74.151.194
(194.74.151.194)
User Datagram Protocol, Src Port: 60882 (60882), Dst Port: domain (53)
Source port: 60882 (60882)
Destination port: domain (53)
Length: 40
Checksum: 0xe247 [correct]
Domain Name System (query)
Transaction ID: 0x19cf
Flags: 0x0000 (Standard query)
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data OK:
Non-authenticated data is unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
www.yell.co.uk: type A, class IN
Name: www.yell.co.uk
Type: A (Host address)
Class: IN (0x0001)
No. Time Source Destination
Protocol Info
6 11:32:48.355006 194.74.151.194 86.22.67.158 DNS
Standard query response
Frame 6 (131 bytes on wire, 131 bytes captured)
Ethernet II, Src: Cisco_28:1c:01 (00:12:da:28:1c:01), Dst:
SurecomT_73:22:c3 (00:02:44:73:22:c3)
Internet Protocol, Src: 194.74.151.194 (194.74.151.194), Dst:
86.22.67.158 (86.22.67.158)
User Datagram Protocol, Src Port: domain (53), Dst Port: 60882 (60882)
Source port: domain (53)
Destination port: 60882 (60882)
Length: 97
Checksum: 0x2991 [correct]
Domain Name System (response)
Transaction ID: 0x19cf
Flags: 0x8080 (Standard query response, No error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority
for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... 1... .... = Recursion available: Server can do
recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority
portion was not authenticated by the server
.... .... .... 0000 = Reply code: No error (0)
Questions: 1
Answer RRs: 0
Authority RRs: 2
Additional RRs: 0
Queries
www.yell.co.uk: type A, class IN
Name: www.yell.co.uk
Type: A (Host address)
Class: IN (0x0001)
Authoritative nameservers
No. Time Source Destination
Protocol Info
7 11:32:48.640550 86.22.67.158 194.74.151.200 DNS
Standard query A www.yell.co.uk
Frame 7 (85 bytes on wire, 85 bytes captured)
Ethernet II, Src: SurecomT_73:22:c3 (00:02:44:73:22:c3), Dst:
Cisco_28:1c:01 (00:12:da:28:1c:01)
Internet Protocol, Src: 86.22.67.158 (86.22.67.158), Dst: 194.74.151.200
(194.74.151.200)
User Datagram Protocol, Src Port: 55234 (55234), Dst Port: domain (53)
Source port: 55234 (55234)
Destination port: domain (53)
Length: 51
Checksum: 0x025f [correct]
Domain Name System (query)
Transaction ID: 0xe61a
Flags: 0x0000 (Standard query)
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data OK:
Non-authenticated data is unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
www.yell.co.uk: type A, class IN
Name: www.yell.co.uk
Type: A (Host address)
Class: IN (0x0001)
Additional records
No. Time Source Destination
Protocol Info
8 11:32:48.649341 194.74.151.200 86.22.67.158 DNS
Standard query response, Format error
Frame 8 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Cisco_28:1c:01 (00:12:da:28:1c:01), Dst:
SurecomT_73:22:c3 (00:02:44:73:22:c3)
Internet Protocol, Src: 194.74.151.200 (194.74.151.200), Dst:
86.22.67.158 (86.22.67.158)
User Datagram Protocol, Src Port: domain (53), Dst Port: 55234 (55234)
Source port: domain (53)
Destination port: 55234 (55234)
Length: 20
Checksum: 0xcd6a [correct]
Domain Name System (response)
Transaction ID: 0xe61a
Flags: 0x8081 (Standard query response, Format error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority
for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... 1... .... = Recursion available: Server can do
recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority
portion was not authenticated by the server
.... .... .... 0001 = Reply code: Format error (1)
Questions: 0
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
No. Time Source Destination
Protocol Info
9 11:32:48.649846 86.22.67.158 194.74.151.200 DNS
Standard query A www.yell.co.uk
Frame 9 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: SurecomT_73:22:c3 (00:02:44:73:22:c3), Dst:
Cisco_28:1c:01 (00:12:da:28:1c:01)
Internet Protocol, Src: 86.22.67.158 (86.22.67.158), Dst: 194.74.151.200
(194.74.151.200)
User Datagram Protocol, Src Port: 55234 (55234), Dst Port: domain (53)
Source port: 55234 (55234)
Destination port: domain (53)
Length: 40
Checksum: 0x1877 [correct]
Domain Name System (query)
Transaction ID: 0xf9a9
Flags: 0x0000 (Standard query)
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data OK:
Non-authenticated data is unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
www.yell.co.uk: type A, class IN
Name: www.yell.co.uk
Type: A (Host address)
Class: IN (0x0001)
No. Time Source Destination
Protocol Info
10 11:32:48.657166 194.74.151.200 86.22.67.158 DNS
Standard query response
Frame 10 (131 bytes on wire, 131 bytes captured)
Ethernet II, Src: Cisco_28:1c:01 (00:12:da:28:1c:01), Dst:
SurecomT_73:22:c3 (00:02:44:73:22:c3)
Internet Protocol, Src: 194.74.151.200 (194.74.151.200), Dst:
86.22.67.158 (86.22.67.158)
User Datagram Protocol, Src Port: domain (53), Dst Port: 55234 (55234)
Source port: domain (53)
Destination port: 55234 (55234)
Length: 97
Checksum: 0x5fc0 [correct]
Domain Name System (response)
Transaction ID: 0xf9a9
Flags: 0x8080 (Standard query response, No error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority
for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... 1... .... = Recursion available: Server can do
recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority
portion was not authenticated by the server
.... .... .... 0000 = Reply code: No error (0)
Questions: 1
Answer RRs: 0
Authority RRs: 2
Additional RRs: 0
Queries
www.yell.co.uk: type A, class IN
Name: www.yell.co.uk
Type: A (Host address)
Class: IN (0x0001)
Authoritative nameservers
====
Incidentally, I also tried accessing the two nameservers shown in those
packets directly. That seems to work for dig:
data# dig @194.74.151.194 www.yell.co.uk
; <<>> DiG 9.3.2 <<>> @194.74.151.194 www.yell.co.uk
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7427
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.yell.co.uk. IN A
;; ANSWER SECTION:
www.yell.co.uk. 85376 IN A 194.72.108.2
;; Query time: 18 msec
;; SERVER: 194.74.151.194#53(194.74.151.194)
;; WHEN: Mon Jul 17 11:47:47 2006
;; MSG SIZE rcvd: 48
Also
data# dig @194.74.151.200 www.yell.co.uk
; <<>> DiG 9.3.2 <<>> @194.74.151.200 www.yell.co.uk
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17678
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.yell.co.uk. IN A
;; ANSWER SECTION:
www.yell.co.uk. 85190 IN A 194.72.108.2
;; Query time: 9 msec
;; SERVER: 194.74.151.200#53(194.74.151.200)
;; WHEN: Mon Jul 17 11:50:52 2006
;; MSG SIZE rcvd: 48
I don't know what that proves though.
--
Please use the corrected version of the address below for replies.
Replies to the header address will be junked, as will mail from
various domains listed at www.scottsonline.org.uk
Mike Scott Harlow Essex England.(unet -a-t- scottsonline.org.uk) |
|
| Back to top |
|
|
Per Hedeland
*nix forums Guru Wannabe
Joined: 20 Feb 2005
Posts: 182
|
| Posted: Mon Jul 17, 2006 1:56 pm Post subject:
Re: major DNS hiccup
|
|
|
In article <8WJug.7561$i32.3378@newsfe2-gui.ntli.net> Mike Scott
<usenet.10@spam.stopper.scottsonline.org.uk> writes:
| Quote: |
OK, I've come back to this at last. Hoping it might have gone away as
suddenly as it arrived; but no such luck :-(
I ran 'dig' to look up the address of one of the always-failing names.
'dig' output plus ethereal diagnosis follow. named running as caching
nameserver on localhost.
|
"Interesting" stuff - IMHO it's quite clear that your ISP is messing
things up with some sort of "transparent" filter/proxy/cache/firewall -
it might be specifically b0rken where EDNS0 is concerned, while their
"normal" name servers can deal with that one way or another (as they
should) - but it's not really conclusive that this is the trigger.
Unfortunately your ethereal output was missing some parts, notably
details of the "additional records", but they can be guessed...
| Quote: | No. Time Source Destination
Protocol Info
3 11:32:48.292602 86.22.67.158 194.74.151.194 DNS
Standard query A www.yell.co.uk
Frame 3 (85 bytes on wire, 85 bytes captured)
|
This is named's "normal" first query, including the EDSN0 OPT RR (which
isn't shown) - it gets a FORMERR reply:
| Quote: | No. Time Source Destination
Protocol Info
4 11:32:48.300886 194.74.151.194 86.22.67.158 DNS
Standard query response, Format error
Flags: 0x8081 (Standard query response, Format error)
|
As previously mentioned, this is OK per se (but see below), and named
retries without the EDNS0 stuff (note shorter packet and no additional
records):
| Quote: | No. Time Source Destination
Protocol Info
5 11:32:48.347740 86.22.67.158 194.74.151.194 DNS
Standard query A www.yell.co.uk
Frame 5 (74 bytes on wire, 74 bytes captured)
|
But here comes the real brokenness - the reply to this query is
non-authoritative, has no error but no answers either, but has authority
records:
| Quote: | No. Time Source Destination
Protocol Info
6 11:32:48.355006 194.74.151.194 86.22.67.158 DNS
Standard query response
Flags: 0x8080 (Standard query response, No error)
Questions: 1
Answer RRs: 0
Authority RRs: 2
|
The authority records weren't shown, but a fair guess is that they were
the two "proper" NS records, one of which is for the very server
purportedly sending this response. This is the signature of a "lame
delegation", and named would normally log that (but it can be turned off
IIRC).
The remaining packets are just an exact repeat with the other server
(.200), after which named is out of options and has to deliver the
SERVFAIL back to 'dig'.
| Quote: | If this really is due to ntl (my ISP) messing up, I'd appreciate some
advice on how to prove that really is the case.
|
Well, the above doesn't prove anything like that per se - it could just
be two badly broken and/or misconfigured name servers (but of course
lots of people would have problems with that domain if so, and you said
it happened to other domains too).
However when I try the exact same thing myself, there is no problem (see
below). The query from named happens to go to the .200 server - only,
since it is successful. And that server is perfectly capable of handling
the EDSN0 stuff - no FORMERR, but instead the correct reply at first
try, and it even sends an EDNS0 OPT RR itself. I bet I would get the
same result from .194.
So it would seem that your ISP's supposedly-transparent stuff either
generates the FORMERR itself, or mangles the request such that it really
has a format error when it arrives at the server. And then it enters
some strange "state" that causes it to generate the lame-delegation-
style response (I can't really think of a way for it to mangle the
request such that the actual server sends that response). Hm, actually,
you *would* get such a response if your query was forwarded to a
(different) server that didn't do recursion, which might be a clue (or
not).
Why it works for some domains remains unknown, but it may not be
possible to figure out from your end - e.g. their "transparent" stuff
could be load-balancing across some set of local caching servers, only
some of which are b0rken.
Anyway, for me this clearly proves that your ISP is at fault - whether
it is proof enough for them I have no idea. They could e.g. claim that
your named sends some broken stuff while mine doesn't - but then there
was the other poster here that had success with the exact same setup
that failed with your ISP when he switched to another ISP.
If all else fails, you could perhaps hack named to not use EDSN0 at all
- I didn't find any such setting, but at least in the code I have here,
in /usr/src/contrib/bind9/lib/dns/resolver.c the function
resquery_send() checks the per-server setting that I mentioned:
if ((query->addrinfo->flags & DNS_FETCHOPT_NOEDNS0) == 0 &&
peer != NULL &&
dns_peer_getsupportedns(peer, &useedns) == ISC_R_SUCCESS &&
!useedns)
{
query->options |= DNS_FETCHOPT_NOEDNS0;
dns_adb_changeflags(fctx->adb,
query->addrinfo,
DNS_FETCHOPT_NOEDNS0,
DNS_FETCHOPT_NOEDNS0);
}
Changing that to
if (1)
{
query->options |= DNS_FETCHOPT_NOEDNS0;
...
would probably do the trick... - again assuming that EDNS0 really *is*
the trigger.
--Per Hedeland
per@hedeland.org
Ethereal output:
No. Time Source Destination Protocol Info
13 38.820669 10.1.1.1 194.74.151.200 DNS Standard query A www.yell.co.uk
Frame 13 (85 bytes on wire, 85 bytes captured)
Ethernet II, Src: Intel_83:4c:d3 (00:d0:b7:83:4c:d3), Dst: Cisco_28:34:00 (00:02:17:28:34:00)
Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 194.74.151.200 (194.74.151.200)
User Datagram Protocol, Src Port: 61490 (61490), Dst Port: domain (53)
Source port: 61490 (61490)
Destination port: domain (53)
Length: 51
Checksum: 0x1ac1 [correct]
Domain Name System (query)
Transaction ID: 0xa82b
Flags: 0x0000 (Standard query)
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
www.yell.co.uk: type A, class IN
Name: www.yell.co.uk
Type: A (Host address)
Class: IN (0x0001)
Additional records
<Root>: type OPT
Name: <Root>
Type: OPT (EDNS0 option)
UDP payload size: 4096
Higher bits in extended RCODE: 0x0
EDNS0 version: 0
Z: 0x8000
Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs)
Bits 1-15: 0x0 (reserved)
Data length: 0
No. Time Source Destination Protocol Info
14 38.884347 194.74.151.200 10.1.1.1 DNS Standard query response A 194.72.108.2
Frame 14 (190 bytes on wire, 190 bytes captured)
Ethernet II, Src: Cisco_28:34:00 (00:02:17:28:34:00), Dst: Intel_83:4c:d3 (00:d0:b7:83:4c:d3)
Internet Protocol, Src: 194.74.151.200 (194.74.151.200), Dst: 10.1.1.1 (10.1.1.1)
User Datagram Protocol, Src Port: domain (53), Dst Port: 61490 (61490)
Source port: domain (53)
Destination port: 61490 (61490)
Length: 156
Checksum: 0x5e59 [correct]
Domain Name System (response)
Transaction ID: 0xa82b
Flags: 0x8400 (Standard query response, No error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .1.. .... .... = Authoritative: Server is an authority for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... 0... .... = Recursion available: Server can't do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
.... .... .... 0000 = Reply code: No error (0)
Questions: 1
Answer RRs: 1
Authority RRs: 2
Additional RRs: 3
Queries
www.yell.co.uk: type A, class IN
Name: www.yell.co.uk
Type: A (Host address)
Class: IN (0x0001)
Answers
www.yell.co.uk: type A, class IN, addr 194.72.108.2
Name: www.yell.co.uk
Type: A (Host address)
Class: IN (0x0001)
Time to live: 1 day
Data length: 4
Addr: 194.72.108.2
Authoritative nameservers
yell.co.uk: type NS, class IN, ns redgate2.yellowpages.co.uk
Name: yell.co.uk
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 day
Data length: 23
Name server: redgate2.yellowpages.co.uk
yell.co.uk: type NS, class IN, ns redgate.yellowpages.co.uk
Name: yell.co.uk
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 day
Data length: 10
Name server: redgate.yellowpages.co.uk
Additional records
redgate.yellowpages.co.uk: type A, class IN, addr 194.74.151.200
Name: redgate.yellowpages.co.uk
Type: A (Host address)
Class: IN (0x0001)
Time to live: 1 day
Data length: 4
Addr: 194.74.151.200
redgate2.yellowpages.co.uk: type A, class IN, addr 194.74.151.194
Name: redgate2.yellowpages.co.uk
Type: A (Host address)
Class: IN (0x0001)
Time to live: 1 day
Data length: 4
Addr: 194.74.151.194
<Root>: type OPT
Name: <Root>
Type: OPT (EDNS0 option)
UDP payload size: 4096
Higher bits in extended RCODE: 0x0
EDNS0 version: 0
Z: 0x8000
Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs)
Bits 1-15: 0x0 (reserved)
Data length: 0 |
|
| Back to top |
|
|
Mike Scott
*nix forums Guru Wannabe
Joined: 25 Feb 2005
Posts: 138
|
| Posted: Mon Jul 17, 2006 3:35 pm Post subject:
Re: major DNS hiccup
|
|
|
Thanks for the diagnosis. I've put some notes on the missing bits (only
missing because the trace seemed too long anyway) from the binary dump file.
Per Hedeland wrote:
| Quote: | In article <8WJug.7561$i32.3378@newsfe2-gui.ntli.net> Mike Scott
usenet.10@spam.stopper.scottsonline.org.uk> writes:
OK, I've come back to this at last. Hoping it might have gone away as
suddenly as it arrived; but no such luck :-(
I ran 'dig' to look up the address of one of the always-failing names.
'dig' output plus ethereal diagnosis follow. named running as caching
nameserver on localhost.
"Interesting" stuff - IMHO it's quite clear that your ISP is messing
things up with some sort of "transparent" filter/proxy/cache/firewall -
it might be specifically b0rken where EDNS0 is concerned, while their
"normal" name servers can deal with that one way or another (as they
should) - but it's not really conclusive that this is the trigger.
Unfortunately your ethereal output was missing some parts, notably
details of the "additional records", but they can be guessed...
|
The 'additional record' in the query (sorry, should have been included)
was specifying the EDNS0 option, also had a DNSSEC bit set.
....
| Quote: | But here comes the real brokenness - the reply to this query is
non-authoritative, has no error but no answers either, but has authority
records:
No. Time Source Destination
Protocol Info
6 11:32:48.355006 194.74.151.194 86.22.67.158 DNS
Standard query response
Flags: 0x8080 (Standard query response, No error)
Questions: 1
Answer RRs: 0
Authority RRs: 2
The authority records weren't shown, but a fair guess is that they were
the two "proper" NS records, one of which is for the very server
purportedly sending this response. This is the signature of a "lame
delegation", and named would normally log that (but it can be turned off
IIRC).
|
They named the two 'yell' nameservers, redgate and
redgate2.yellowpages.co.uk, as you surmise.
Odd about the logging - I currently only get minimal logging, using the
default logging configuration.
....
| Quote: | Anyway, for me this clearly proves that your ISP is at fault - whether
|
I'm not sure whether that's good news or bad :-)
| Quote: | it is proof enough for them I have no idea. They could e.g. claim that
your named sends some broken stuff while mine doesn't - but then there
was the other poster here that had success with the exact same setup
that failed with your ISP when he switched to another ISP.
|
Out of curiosity, I tried traceroute -p 53 to one of the root
nameservers. The hypothesis was that if ntl have put some sort of
transparent cache into place, this /ought/ not to reach the root server
- maybe! In fact, it did eventually, but only after some very long
delays; I'm not sure a one-off proves much anyway - perhaps some further
thought along those lines might give an indicator (eg craft a
traceroute-like thing that sends a genuine dns query, and sees where it
reaches. Maybe I could hack the traceroute sources).
Thanks for the patch. I'm not sure it'll help though - I'm almost sure
the other nameserver I tried from the ports (the name /still/ escapes
me, and the PC is turned off right now) explicitly does not support EDNS
- and that returns the same symptoms as BIND does. But I'll give it
another look.
One 'evil' thought might be to contact the operators of the failing
domains and tell them (some) ntl users can't get through and why.....
--
Please use the corrected version of the address below for replies.
Replies to the header address will be junked, as will mail from
various domains listed at www.scottsonline.org.uk
Mike Scott Harlow Essex England.(unet -a-t- scottsonline.org.uk) |
|
| Back to top |
|
|
jpd
*nix forums Guru
Joined: 22 Feb 2005
Posts: 877
|
| Posted: Mon Jul 17, 2006 3:43 pm Post subject:
Re: major DNS hiccup
|
|
|
Begin <e9g4th$o7f$1@hedeland.org>
On 2006-07-17, Per Hedeland <per@hedeland.org> wrote:
| Quote: | If all else fails, you could perhaps hack named to not use EDSN0 at all
- I didn't find any such setting,
|
IIRC from last time I looked that there is a global setting that regulates
the maximum value to ever advertise. Setting it to 512 might cause bind
to never include EDNS0 options, or at least reduce the probability that
packets get truncated.
--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law. |
|
| Back to top |
|
|
Per Hedeland
*nix forums Guru Wannabe
Joined: 20 Feb 2005
Posts: 182
|
| Posted: Mon Jul 17, 2006 9:02 pm Post subject:
Re: major DNS hiccup
|
|
|
In article <X6Oug.14695$EK1.11536@newsfe4-gui.ntli.net> Mike Scott
<usenet.10@spam.stopper.scottsonline.org.uk> writes:
| Quote: |
Out of curiosity, I tried traceroute -p 53 to one of the root
nameservers. The hypothesis was that if ntl have put some sort of
transparent cache into place, this /ought/ not to reach the root server
- maybe!
|
That won't work - traceroute always uses multiple ports (increments by
one for each probe), -p just gives the "base" one. I.e. by the time the
probes reach the "interesting" place, the port won't be 53 anymore.
| Quote: | In fact, it did eventually, but only after some very long
delays; I'm not sure a one-off proves much anyway - perhaps some further
thought along those lines might give an indicator (eg craft a
traceroute-like thing that sends a genuine dns query, and sees where it
reaches. Maybe I could hack the traceroute sources).
|
Yes - there is a 'tcptraceroute' that really does the same thing as a
TCP connection attempt would, and which can tell you "interesting"
things (like proceeding across a DNAT/"port forwarding" firewall and
mapping out the network behind it:-) - but I haven't heard of a
'udptraceroute' along those lines. It might be enough just to keep the
port fixed for traceroute - you won't get the "final hit" line which is
based on receiveing an ICMP "port unreachable", but you would see where
the intermediate responses (from ICMP "time exceeded") stop coming back.
But I really don't think that your ISP would deny that they are doing
some sort of "intercept" of the DNS traffic (assuming that you can get
hold of someone there that even understands what you're talking about) -
"proving" (to their satisfaction) that they are doing it incorrectly may
be harder.
| Quote: | Thanks for the patch. I'm not sure it'll help though - I'm almost sure
the other nameserver I tried from the ports (the name /still/ escapes
me, and the PC is turned off right now) explicitly does not support EDNS
- and that returns the same symptoms as BIND does. But I'll give it
another look.
|
Right, I had forgotten about that - and of course the fact that some
queries succeed indicates that EDNS0 can't really be fatal, since BIND
will do it on all queries by default. The thing that did point to EDNS0
was that 'dig' queries succeeded, but there is another difference
between BIND's and dig's queries, that may be the significant one given
what your trace showed: BIND (or any "real" name server) will not ask
for recursion, while dig will. You could try dig with +norecurse (this
should work when querying the authoritative servers, or a server that
happens to have the data in its cache, but not otherwise - works fine
with both the servers in this case from here, as expected).
| Quote: | One 'evil' thought might be to contact the operators of the failing
domains and tell them (some) ntl users can't get through and why.....
|
Well, I don't know any specifics in your case, but my general impression
is that if getting an ISP to fix things is possible at all, it is only
by request from its paying customers (unless the brokenness is downright
harmful to the rest of the network). Inquiries from third parties would
probably at most result in them (and you) being told that "it works fine
when using the DNS servers we provide for our customers".
--Per Hedeland
per@hedeland.org |
|
| Back to top |
|
|
Per Hedeland
*nix forums Guru Wannabe
Joined: 20 Feb 2005
Posts: 182
|
| Posted: Mon Jul 17, 2006 9:09 pm Post subject:
Re: major DNS hiccup
|
|
|
In article <4i1phlF1ogn2U1@individual.net> jpd
<read_the_sig@do.not.spam.it.invalid> writes:
| Quote: | Begin <e9g4th$o7f$1@hedeland.org
On 2006-07-17, Per Hedeland <per@hedeland.org> wrote:
If all else fails, you could perhaps hack named to not use EDSN0 at all
- I didn't find any such setting,
IIRC from last time I looked that there is a global setting that regulates
the maximum value to ever advertise. Setting it to 512 might cause bind
to never include EDNS0 options, or at least reduce the probability that
packets get truncated.
|
There is such a setting, but I believe Mike already tried setting it to
512 w/o improvement - and IIRC BIND will send the EDNS0 option anyway,
just with the value specified. Also, the response in the example he
posted is "small", it doesn't actually use the offer of sending bigger
packets.
--Per Hedeland
per@hedeland.org |
|
| Back to top |
|
|
Mike Scott
*nix forums Guru Wannabe
Joined: 25 Feb 2005
Posts: 138
|
| Posted: Tue Jul 18, 2006 10:51 am Post subject:
Re: major DNS hiccup
|
|
|
Per Hedeland wrote:
| Quote: | In article <X6Oug.14695$EK1.11536@newsfe4-gui.ntli.net> Mike Scott
usenet.10@spam.stopper.scottsonline.org.uk> writes:
Out of curiosity, I tried traceroute -p 53 to one of the root
nameservers. The hypothesis was that if ntl have put some sort of
transparent cache into place, this /ought/ not to reach the root server
- maybe!
That won't work - traceroute always uses multiple ports (increments by
one for each probe), -p just gives the "base" one. I.e. by the time the
probes reach the "interesting" place, the port won't be 53 anymore.
|
Yes, thanks; I figured that out the hard way after posting (maybe I
should start reading man pages ).
And I didn't know that it uses the remote port number to encode the
attempt identification, icmp replies apparently not including enough
data to match them to the particular sent packets. So it's not quite
straightforward to send DNS probes in the same way. I'll keep it on the
back burner - if ntl are intercepting DNS packets, there has to be a way
to prove it!
....
| Quote: | But I really don't think that your ISP would deny that they are doing
some sort of "intercept" of the DNS traffic (assuming that you can get
|
The front line support have already denied any network changes affecting
DNS. I've no idea at all how to get things like this escalated - front
line seems to take the view that rebooting cures almost everything,
otherwise they call an engineer to come and look at the modem The
very concept of networking problems seems foreign to them.
Thanks again for your help, and of course to the others who've put time
into this!
--
Please use the corrected version of the address below for replies.
Replies to the header address will be junked, as will mail from
various domains listed at www.scottsonline.org.uk
Mike Scott Harlow Essex England.(unet -a-t- scottsonline.org.uk) |
|
| Back to top |
|
|
Mark Andrews
*nix forums beginner
Joined: 02 Mar 2005
Posts: 25
|
| Posted: Wed Jul 19, 2006 4:03 am Post subject:
Re: major DNS hiccup
|
|
|
In article <12b7gv9jth8jdaa@news.supernews.com>,
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
| Quote: | Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
Chronos wrote:
After replacing Mike Scott with a small shell script on Tuesday 11 Jul
2006 09:06, the following appeared on stdout:
Thanks, but as it's only DNS that's not working
And then only if you're doing fully recursive lookups. Is your hints
file up to date?
Yes.
Have you tried an alternate root such as ORSN?
I have now. Same problem (sample of 2 failure, 1 working).
But thanks for the ideas. Somehow I get the most horrible feeling this
will all be down to something incredibly obvious that I've just been
missing totally.....
FWIW, my failures began at 11:03:54 on Jul 6.
Mike, can you have a look at your named logs, and see when it started?
Andrew.
Jul 6 11:03:54 mammoth named[2671]: lame server resolving 'gmail.com'
(in 'gmail.com'?): 216.239.34.10#53
Jul 6 11:03:54 mammoth named[2671]: lame server resolving
'174.176.132.209.sbl-xbl.spamhaus.org' (in 'sbl-xbl.spamhaus.org'?):
193.70.192.64#53
Jul 6 11:03:54 mammoth named[2671]: lame server resolving
'190.182.233.64.sbl-xbl.spamhaus.org' (in 'sbl-xbl.spamhaus.org'?):
193.70.192.64#53
Jul 6 11:03:54 mammoth named[2671]: lame server resolving
'rbldns4.sorbs.net' (in 'sorbs.NET'?): 213.155.150.206#53
Jul 6 11:03:54 mammoth named[2671]: lame server resolving
'rbldns4.sorbs.net' (in 'sorbs.NET'?): 63.209.15.211#53
Jul 6 11:03:54 mammoth named[2671]: lame server resolving
'190.182.233.64.sa-other.bondedsender.org' (in
'sa-other.bondedsender.org'?): 64.92.165.122#5
3
Jul 6 11:03:54 mammoth named[2671]: lame server resolving
'174.176.132.209.sa-trusted.bondedsender.org' (in
'sa-trusted.bondedsender.org'?): 64.92.165.
122#53
Jul 6 11:03:54 mammoth named[2671]: lame server resolving
'rbldns4.sorbs.net' (in 'sorbs.NET'?): 217.70.177.40#53
Jul 6 11:03:54 mammoth named[2671]: lame server resolving
'rbldns4.sorbs.net' (in 'sorbs.NET'?): 209.97.199.116#53
Jul 6 11:07:21 mammoth named[2671]: lame server resolving
'backmx.iol.cz' (in 'iol.cz'?): 194.228.2.1#53
Jul 6 11:07:21 mammoth named[2671]: lame server resolving
'backmx.iol.cz' (in 'iol.cz'?): 194.228.2.61#53
Jul 6 11:07:21 mammoth named[2671]: lame server resolving
'backmx.iol.cz' (in 'iol.cz'?): 194.228.2.1#53
Jul 6 11:07:21 mammoth named[2671]: lame server resolving
'backmx.iol.cz' (in 'iol.cz'?): 194.228.2.61#53
Jul 6 11:07:21 mammoth named[2671]: lame server resolving
'backmx.iol.cz' (in 'iol.cz'?): 194.228.2.61#53
Jul 6 11:07:21 mammoth named[2671]: lame server resolving
'backmx.iol.cz' (in 'iol.cz'?): 194.228.2.1#53
Jul 6 11:07:21 mammoth named[2671]: lame server resolving
'backmx.iol.cz' (in 'iol.cz'?): 194.228.2.1#53
Jul 6 11:07:21 mammoth named[2671]: lame server resolving
'backmx.iol.cz' (in 'iol.cz'?): 194.228.2.61#53
Jul 6 11:07:21 mammoth named[2671]: lame server resolving
'backmx.iol.cz' (in 'iol.cz'?): 194.228.2.61#53
...
|
I suspect that they have installed a "transparent DNS cache".
Nameservers require authoritative answers (aa flag set)
from authoritative servers. A "transparent DNS cache" will
result in non-authoritative answers. Lack of "aa" is a
indication that the zone is not loaded or partially loaded
on the authoritative server.
A "transparent DNS cache" will not be visible to a stub
resolver which is expecting to get answers from a cache.
A interative resolver (which named is) exects to get
authoritative answers or referrals.
When named is taking to a forwarder it is expecting to
get non-authoritative answers from the forwarder which
is why things work when you configure forwarders.
"dig backmx.iol.cz @194.228.2.61" should return something
like this. Note "aa" is set in flags. If you are getting
a answer without "aa" being set then you should complain.
Mark
; <<>> DiG 9.3.2 <<>> backmx.iol.cz @194.228.2.61
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37692
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;backmx.iol.cz. IN A
;; ANSWER SECTION:
backmx.iol.cz. 3600 IN A 194.228.41.112
;; AUTHORITY SECTION:
iol.cz. 3600 IN NS dns-polvezni.iol.cz.
iol.cz. 3600 IN NS dns.iol.cz.
iol.cz. 3600 IN NS ns2.tel.cz.
;; ADDITIONAL SECTION:
dns.iol.cz. 3600 IN A 194.228.2.61
ns2.tel.cz. 86400 IN A 194.228.2.1
dns-polvezni.iol.cz. 3600 IN A 194.228.41.113
;; Query time: 330 msec
;; SERVER: 194.228.2.61#53(194.228.2.61)
;; WHEN: Wed Jul 19 14:01:58 2006
;; MSG SIZE rcvd: 162 |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sat Nov 22, 2008 6:09 am | All times are GMT
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
