|
|
|
|
|
|
| Author |
Message |
jpd
*nix forums Guru
Joined: 22 Feb 2005
Posts: 877
|
 Posted: Thu Jul 06, 2006 7:45 pm Post subject:
Re: major DNS hiccup
|
|
|
Begin <Olcrg.15392$Xp3.9815@newsfe4-gui.ntli.net>
On 2006-07-06, Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
| Quote: | Today, I suddenly found that DNS responses from the net often look
wrong.
|
Are those responses from other servers on the 'net to your bind, or do
they come from your bind as it passes the responses on? You might want
to compare the difference between those.
--
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 |
|
 |
neutron*star
*nix forums Guru
Joined: 21 Feb 2005
Posts: 2039
|
| Posted: Thu Jul 06, 2006 10:22 pm Post subject:
Re: major DNS hiccup
|
|
|
May want to consider any network security configurations with respect to
edns0 and path mtu discaovery. |
|
| Back to top |
|
|
Mike Scott
*nix forums Guru Wannabe
Joined: 25 Feb 2005
Posts: 138
|
| Posted: Fri Jul 07, 2006 9:03 am Post subject:
Re: major DNS hiccup
|
|
|
jpd wrote:
| Quote: | Begin <Olcrg.15392$Xp3.9815@newsfe4-gui.ntli.net
On 2006-07-06, Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
Today, I suddenly found that DNS responses from the net often look
wrong.
Are those responses from other servers on the 'net to your bind, or do
they come from your bind as it passes the responses on? You might want
to compare the difference between those.
|
I'd kind of hoped this problem would just go away overnight, but it
hasn't :-(
I've been running ethereal monitoring the NIC connected to the cable
modem, so these are queries and responses to and from other servers on
the net.
I did wonder about h/ware issues - as these are udp and don't seem to
have a checksum, I wondered if packets were being truncated somewhere.
If so, it's probably not on my hardware, as I've changed the NIC:
although this doesn't rule out the mode and ntl's network of course 
OTOH if there were hardware problems /anywhere/ I'd expect eg downloads
to suffer badly, which they don't - if I can get the ip address, the
rest works fine. And as I said earlier, if I don't use my own named, but
point resolv.conf at ntl's servers instead of 127.0.0.1, all works fine.
Also, the sets of names that will or won't resolve seem remarkably
consistent, although as the packets below show, different results can be
obtained from the same outside server when retrying.
In case someone can shed more light, I've appended an ethereal analysis
of 4 consecutive packets. Two identical questions with different
results. These are the end of a series of retries with various failure
modes. I'm very suspicious of packet #24, which says "questions: 0".
The only thing I can come up with is something truncating outgoing
requests (could help explain packet #24). But that seems just so unlikely.
====
No. Time Source Destination Protocol
Info
23 7.184019 86.22.67.158 202.147.2.2 DNS
Standard query A www.tfl.gov.uk.edgekey.net
Frame 23 (97 bytes on wire, 97 bytes captured)
Ethernet II, Src: 00:02:44:73:22:c3 (00:02:44:73:22:c3), Dst:
00:12:da:28:1c:01 (00:12:da:28:1c:01)
Internet Protocol, Src: 86.22.67.158 (86.22.67.158), Dst: 202.147.2.2
(202.147.2.2)
User Datagram Protocol, Src Port: 64217 (64217), Dst Port: domain (53)
Domain Name System (query)
Transaction ID: 0x6975
Flags: 0x0000 (Standard query)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
www.tfl.gov.uk.edgekey.net: type A, class IN
Name: www.tfl.gov.uk.edgekey.net
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
24 7.457769 202.147.2.2 86.22.67.158 DNS
Standard query response, Format error
Frame 24 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:12:da:28:1c:01 (00:12:da:28:1c:01), Dst:
00:02:44:73:22:c3 (00:02:44:73:22:c3)
Internet Protocol, Src: 202.147.2.2 (202.147.2.2), Dst: 86.22.67.158
(86.22.67.158)
User Datagram Protocol, Src Port: domain (53), Dst Port: 64217 (64217)
Domain Name System (response)
Transaction ID: 0x6975
Flags: 0x8001 (Standard query response, Format error)
Questions: 0
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
No. Time Source Destination Protocol
Info
25 7.459391 86.22.67.158 202.147.2.2 DNS
Standard query A www.tfl.gov.uk.edgekey.net
Frame 25 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 00:02:44:73:22:c3 (00:02:44:73:22:c3), Dst:
00:12:da:28:1c:01 (00:12:da:28:1c:01)
Internet Protocol, Src: 86.22.67.158 (86.22.67.158), Dst: 202.147.2.2
(202.147.2.2)
User Datagram Protocol, Src Port: 64217 (64217), Dst Port: domain (53)
Domain Name System (query)
Transaction ID: 0xae73
Flags: 0x0000 (Standard query)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
www.tfl.gov.uk.edgekey.net: type A, class IN
Name: www.tfl.gov.uk.edgekey.net
Type: A (Host address)
Class: IN (0x0001)
No. Time Source Destination Protocol
Info
26 7.730623 202.147.2.2 86.22.67.158 DNS
Standard query response CNAME e499.r.akamaiedge.net
Frame 26 (379 bytes on wire, 379 bytes captured)
Ethernet II, Src: 00:12:da:28:1c:01 (00:12:da:28:1c:01), Dst:
00:02:44:73:22:c3 (00:02:44:73:22:c3)
Internet Protocol, Src: 202.147.2.2 (202.147.2.2), Dst: 86.22.67.158
(86.22.67.158)
User Datagram Protocol, Src Port: domain (53), Dst Port: 64217 (64217)
Domain Name System (response)
Transaction ID: 0xae73
Flags: 0x8400 (Standard query response, No error)
Questions: 1
Answer RRs: 1
Authority RRs: 8
Additional RRs: 8
Queries
www.tfl.gov.uk.edgekey.net: type A, class IN
Name: www.tfl.gov.uk.edgekey.net
Type: A (Host address)
Class: IN (0x0001)
Answers
www.tfl.gov.uk.edgekey.net: type CNAME, class IN, cname
e499.r.akamaiedge.net
Name: www.tfl.gov.uk.edgekey.net
Type: CNAME (Canonical name for an alias)
Class: IN (0x0001)
Time to live: 6 hours
Data length: 20
Primary name: e499.r.akamaiedge.net
Authoritative nameservers
<Root>: type NS, class IN, ns K.ROOT-SERVERS.net
Name: <Root>
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 16 minutes, 40 seconds
Data length: 17
Name server: K.ROOT-SERVERS.net
....snip similar...
Additional records
K.ROOT-SERVERS.net: type A, class IN, addr 193.0.14.129
Name: K.ROOT-SERVERS.net
Type: A (Host address)
Class: IN (0x0001)
Time to live: 16 minutes, 40 seconds
Data length: 4
Addr: 193.0.14.129
....snip similar...
--
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: Fri Jul 07, 2006 10:15 am Post subject:
Re: major DNS hiccup
|
|
|
Dom wrote:
| Quote: | May want to consider any network security configurations with respect to
edns0 and path mtu discaovery.
I can't see that either of these would be the issue. Certainly not mtu - |
nothing's changed in that area. edns0 I wasn't aware of; but again, as
it was working, there'd be no reason to suddenly stop. But I did try
setting edns-udp-size to 512, which has introduced a new failure mode.
I think I'll set up named on a different machine and see what happens.
--
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: Fri Jul 07, 2006 11:54 am Post subject:
Re: major DNS hiccup
|
|
|
Mike Scott wrote:
....
| Quote: | I think I'll set up named on a different machine and see what happens.
After complete surgery - replacing the machine connected to the cable |
modem with another running named on 6.1, the problem persists.
Therefore I suppose it must be the modem or something upstream from
that. How on earth can I troubleshoot this further??
What kind of silver bullet could knock out my name server yet seemingly
leave others unaffected?
--
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: Fri Jul 07, 2006 6:37 pm Post subject:
Re: major DNS hiccup
|
|
|
Begin <drprg.73093$lQ.50977@newsfe3-gui.ntli.net>
On 2006-07-07, Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
| Quote: | I've been running ethereal monitoring the NIC connected to the cable
modem, so these are queries and responses to and from other servers on
the net.
|
Right. So it probably isn't in the answers your bind gives as long as
it is given correct input to work with. Let's see what the possibilities
are. I can think of right now:
a) Your bind suddenly generates wrong queries
b) Your cable modem or anything on the path from your bind to the other side
suddenly flips random bits in the traffic
c) The nameserver you're asking thinks the queries are wrong for some
other reason.
I'm not too versed in ethereal's output format, so ICBW, but I see no
reason to assume a). c) is pretty hard to detect so let's not worry
about it yet. That leaves b).
Implications here are that software upgrades and even hardware swaps on
your local machine are not likely to fix the problem.[1]
| Quote: | I did wonder about h/ware issues - as these are udp and don't seem to
have a checksum, I wondered if packets were being truncated somewhere.
|
I didn't see anything about checksums in the messages you pasted, but
I could have overlooked them. UDP is often enough sent out without a
checksum. For FreeBSD it is a sysctl whether to do that, I'd turn it on,
and it should be on by default.
Truncated packets should show up as such: IP keeps a length and the NIC
does as well. Also, ethernet frames have a checksum on the entire frame.
| Quote: | If so, it's probably not on my hardware, as I've changed the NIC:
although this doesn't rule out the mode and ntl's network of course
|
Right. It's not impossible that a dodgy linecard does this, but then I'd
expect more trouble. Most of that won't show up other than a few dropped
tcp packets that get re-sent automatically, but it isn't impossible to
device some testing to try and see whether this happens.
| Quote: | OTOH if there were hardware problems /anywhere/ I'd expect eg downloads
to suffer badly, which they don't - if I can get the ip address, the
rest works fine. And as I said earlier, if I don't use my own named, but
point resolv.conf at ntl's servers instead of 127.0.0.1, all works fine.
|
You'll have to investigate that a bit more.
| Quote: | Also, the sets of names that will or won't resolve seem remarkably
consistent, although as the packets below show, different results can be
obtained from the same outside server when retrying.
|
And what if you use dig(1) to poke around at various nameservers?
Can you narrow it down to one offending server?
| Quote: | The only thing I can come up with is something truncating outgoing
requests (could help explain packet #24). But that seems just so unlikely.
|
Flipping a bit or swapping a byte or two could do it too. It's obscure,
but without checksums it's not impossible. Do it on a level 3 (or higher,
transparant proxies anyone?) device and it'll survive the stripping off
and recalculating of various checksums.
[1] If you want to pursue that anyway, the PSU is a candidate, as is
generally cleaning the box, re-seating the components and making sure
its environment is cool enough. In reverse order.
--
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 |
|
|
jpd
*nix forums Guru
Joined: 22 Feb 2005
Posts: 877
|
| Posted: Fri Jul 07, 2006 6:41 pm Post subject:
Re: major DNS hiccup
|
|
|
Begin <DXrrg.4533$wR4.1262@newsfe1-gui.ntli.net>
On 2006-07-07, Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
| Quote: | After complete surgery - replacing the machine connected to the cable
modem with another running named on 6.1, the problem persists.
Therefore I suppose it must be the modem or something upstream from
that. How on earth can I troubleshoot this further??
|
If you can't replace the modem, and software tools (dig, ping, ttcp,
etc.) don't help, it's time to try and get a tech (level 2,3,4...) from
your ISP on the case.
It helps if you can narrow down exactly what the circumstances are
that trigger this, of course.
--
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 |
|
|
Mike Scott
*nix forums Guru Wannabe
Joined: 25 Feb 2005
Posts: 138
|
| Posted: Fri Jul 07, 2006 7:48 pm Post subject:
Re: major DNS hiccup
|
|
|
Thanks for the thoughts.
jpd wrote:
....
| Quote: |
a) Your bind suddenly generates wrong queries
|
Hardly :-)
| Quote: | b) Your cable modem or anything on the path from your bind to the other side
suddenly flips random bits in the traffic
|
Would screw up other things too.
| Quote: | c) The nameserver you're asking thinks the queries are wrong for some
other reason.
|
The /several/ nameservers - this problem seems to affect a number of
apparently unconnected domains.
....
| Quote: | I did wonder about h/ware issues - as these are udp and don't seem to
have a checksum, I wondered if packets were being truncated somewhere.
|
Me too.
| Quote: |
I didn't see anything about checksums in the messages you pasted, but
I could have overlooked them. UDP is often enough sent out without a
checksum. For FreeBSD it is a sysctl whether to do that, I'd turn it on,
and it should be on by default.
|
I wasn't aware of that - but it would presumably depend on the other end
playing ball too. I'll try it later though.
....
| Quote: | Right. It's not impossible that a dodgy linecard does this, but then I'd
|
In fact, I swapped out the entire machine - lock, stock and cpu.
Skeletal firewall (allow outbound and matching inbound) just in case.
/Exactly/ the same problem. Although I did copy over the bind database
files and config - but this hadn't been changed for a year or more.
| Quote: | Also, the sets of names that will or won't resolve seem remarkably
consistent, although as the packets below show, different results can be
obtained from the same outside server when retrying.
And what if you use dig(1) to poke around at various nameservers?
Can you narrow it down to one offending server?
|
Interesting point. Given the wide selection of failing addresses, I
assumed they'd have different servers - but that /is/ an assumption. Job
for tomorrow.
| Quote: |
[1] If you want to pursue that anyway, the PSU is a candidate, as is
generally cleaning the box, re-seating the components and making sure
its environment is cool enough. In reverse order.
|
well, as I said, I swapped the whole caboodle out, so unlikely
Since posting, I've tried another experiment. Pick a "known failing"
address (www.yell.co.uk) and run nslookup with local server while
monitoring the cm NIC with ethereal. Then look at that failing output
and see which server is being contacted; finally rerun nslookup
specifying that server. In the one case I've tried, that second request
works:
| Quote: | server localhost
Default server: localhost |
Address: 127.0.0.1#53
| Quote: | www.yell.co.uk
Server: localhost |
Address: 127.0.0.1#53
** server can't find www.yell.co.uk: SERVFAIL
| Quote: | server 194.74.151.200 <<== picked out from ethereal log
Default server: 194.74.151.200 |
Address: 194.74.151.200#53
| Quote: | www.yell.co.uk
Server: 194.74.151.200 |
Address: 194.74.151.200#53
Non-authoritative answer:
Name: www.yell.co.uk
Address: 194.72.108.2
And dig says much the same:
%dig www.yell.co.uk
; <<>> DiG 9.3.2 <<>> www.yell.co.uk
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5158
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.yell.co.uk. IN A
;; Query time: 132 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jul 7 20:43:46 2006
;; MSG SIZE rcvd: 32
%
%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: 14608
;; 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. 86400 IN A 194.72.108.2
;; Query time: 41 msec
;; SERVER: 194.74.151.200#53(194.74.151.200)
;; WHEN: Fri Jul 7 20:44:08 2006
;; MSG SIZE rcvd: 48
And now I'm going to sleep on it.
--
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 |
|
|
Michel Talon
*nix forums Guru
Joined: 21 Feb 2005
Posts: 557
|
| Posted: Fri Jul 07, 2006 8:19 pm Post subject:
Re: major DNS hiccup
|
|
|
Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
| Quote: |
This one seems to fall heavily into the "can't happen" category, and I'm
stuck for ideas: would /very/ much appreciate pointers about where to look.
Thanks in advance.
|
Could it be that you have somewhat firewalled TCP and leaved only UDP?
Some DNS queries are done via UDP, others via TCP, so firewalling TCP is
not a good idea.
--
Michel TALON |
|
| Back to top |
|
|
jpd
*nix forums Guru
Joined: 22 Feb 2005
Posts: 877
|
| Posted: Fri Jul 07, 2006 9:24 pm Post subject:
Re: major DNS hiccup
|
|
|
Begin <wUyrg.15604$Xp3.4019@newsfe4-gui.ntli.net>
On 2006-07-07, Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
| Quote: | It's not impossible that a dodgy linecard does this, [...]
In fact, I swapped out the entire machine - lock, stock and cpu.
|
I ment the linecard on the ISP's side, or possibly the modem, or anything
on that path. That's out of your control (unless you have a spare cable
modem to swap in), so you need to contact a tech at your ISP.
--
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 |
|
|
Mike Scott
*nix forums Guru Wannabe
Joined: 25 Feb 2005
Posts: 138
|
| Posted: Mon Jul 10, 2006 10:47 am Post subject:
Re: major DNS hiccup
|
|
|
Michel Talon wrote:
| Quote: | Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
This one seems to fall heavily into the "can't happen" category, and I'm
stuck for ideas: would /very/ much appreciate pointers about where to look.
Thanks in advance.
Could it be that you have somewhat firewalled TCP and leaved only UDP?
Some DNS queries are done via UDP, others via TCP, so firewalling TCP is
not a good idea.
|
I'm 99.9999% sure it's not firewall-related. If it were, I would think
either all or no traffic would pass at all; and I've tried a different
machine (with a very liberal firewall config). I see traffic passing
both ways (all udp, no tcp, incidentally), and all with correct
checksums (another contributor to this thread suggested checking this),
and nothing being blocked. Oh, and I've just tried removing pf's 'scrub'
rule - an act of desperation that made no difference at all :-(
What I get is nameserver reply packets from assorted unrelated servers
(even the root servers) with defects in them - either no answer record
but with the question returned to me (as seems normal), or no answer
/and/ no question (the latter being flagged in the reply as 'format error').
It seems that this is occurring even when the lookup is (at application
level) successful - and that duplicate replies from different servers
often provide the missing information.
I've now dropped back to using my ISP's name servers plus hosts files
for the LAN addresses, which works but is not really satisfactory and
only plasters over the problem - which started suddenly last thursday if
I recall.
Maybe I've just not fed the Gremlins enough last week?
--
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 10, 2006 10:52 am Post subject:
Re: major DNS hiccup
|
|
|
jpd wrote:
| Quote: | Begin <DXrrg.4533$wR4.1262@newsfe1-gui.ntli.net
On 2006-07-07, Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
After complete surgery - replacing the machine connected to the cable
modem with another running named on 6.1, the problem persists.
Therefore I suppose it must be the modem or something upstream from
that. How on earth can I troubleshoot this further??
If you can't replace the modem, and software tools (dig, ping, ttcp,
etc.) don't help, it's time to try and get a tech (level 2,3,4...) from
your ISP on the case.
|
Tried asking. As expected: "we can't support your system"; they did
however claim there were no network changes last week that might affect
DNS. But given their reputation, that assurance is probably worth the
paper the email was written on :-)
And if it were the modem or other upstream h/w, there'd most surely be
other major problems. And anyway, to answer another's question, the UDP
checksums are all correct in both directions, so the modem is at least
giving me uncorrupted data. Bar an acceptably few dropped tcp packets,
and the DNS problem, everything is working just fine.
| Quote: |
It helps if you can narrow down exactly what the circumstances are
that trigger this, of course.
|
I know. But I've failed so far to spot anything in common in the groups
of "working" and "failing" requests.
--
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 10, 2006 1:37 pm Post subject:
Re: major DNS hiccup
|
|
|
Begin <7kqsg.79971$lQ.52678@newsfe3-gui.ntli.net>
On 2006-07-10, Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
| Quote: | If you can't replace the modem, and software tools (dig, ping, ttcp,
etc.) don't help, it's time to try and get a tech (level 2,3,4...) from
your ISP on the case.
Tried asking. As expected: "we can't support your system";
|
``That's fine,'' you reply, ``as I do that myself.'' That doesn't mean
they don't have their network to take care of. I usually can (eventually)
get through to someone who can order a linecheck/cardcheck/whatevercheck.
Their above answer is NOT good enough; not because you expect them to
support your system, but because you do need them to support their own
network. Of course, you need to have done your part and be able to back
that claim with evidence.
| Quote: | they did however claim there were no network changes last week that
might affect DNS. But given their reputation, that assurance is
probably worth the paper the email was written on
|
A device that is failing intermittendly or on the verge of failing is
not a planned change and thus nothing they'd know about. It's still
their job to find the problem and fix it. It's up to you to demonstrate
that it is a problem and that it isn't in your system.
--
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 10, 2006 1:38 pm Post subject:
Re: major DNS hiccup
|
|
|
In article <drprg.73093$lQ.50977@newsfe3-gui.ntli.net> Mike Scott
<usenet.10@spam.stopper.scottsonline.org.uk> writes:
| Quote: |
In case someone can shed more light, I've appended an ethereal analysis
of 4 consecutive packets. Two identical questions with different
results. These are the end of a series of retries with various failure
modes.
|
But the queries aren't identical - the first one uses EDNS0 to send an
OPT RR - the server responds to this with FORMERR (Format Error), which
can be expected from a server that doesn't understand EDNS0. The second
query is a retry without the EDSN0 part, and it succeeds, getting a
proper response. I.e. there's no indication of anything wrong here, all
is by the spec (RFC 2671).
| Quote: | I'm very suspicious of packet #24, which says "questions: 0".
|
This is also normal AFAIK - the server couldn't understand the query,
i.e. effectively it didn't see any question in it.
Unfortunately this doesn't really help resolve your problem I guess, but
at least it should eliminate one of the "this looks wrong" parts. Of
course the problem could still be EDNS0-related, maybe some *other*
queries go to a server that goes bonkers when it receives an EDNS0
query, and doesn't reply correctly even on the retry (or perhaps it
gives a garbage response to the EDNS0 query).
If you have forwarders specified in your named.conf, you might want to
try changing/removing them. Also, BIND allows for turning off the EDSN0
attempt, but as far as I can see only on a per-destination-server basis
- i.e. this won't be useful unless you can identify servers that behave
brokenly.
--Per Hedeland
per@hedeland.org |
|
| Back to top |
|
|
Mike Scott
*nix forums Guru Wannabe
Joined: 25 Feb 2005
Posts: 138
|
| Posted: Mon Jul 10, 2006 3:48 pm Post subject:
Re: major DNS hiccup
|
|
|
jpd wrote:
| Quote: | Begin <7kqsg.79971$lQ.52678@newsfe3-gui.ntli.net
On 2006-07-10, Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
If you can't replace the modem, and software tools (dig, ping, ttcp,
etc.) don't help, it's time to try and get a tech (level 2,3,4...) from
your ISP on the case.
Tried asking. As expected: "we can't support your system";
``That's fine,'' you reply, ``as I do that myself.'' That doesn't mean
they don't have their network to take care of. I usually can (eventually)
get through to someone who can order a linecheck/cardcheck/whatevercheck.
|
I know the theory. But most UK ISPs have reputations of maximising
income and minimising their own work. Which means the front-line people
will use any excuse to do nothing, not helped by their being
script-merchants with orders (it usually seems) not to disturb any real
techies. So unless I can put the finger on exactly where in their system
any fault may be, I'll get no joy. And I have to admit, there's about
as much proof it's /not/ ntl as there is that it's not my own system:
all the UDP packets carry correct checksums, and none appear to have
been dropped.
I think I may have to let this rest. From a practical pov, I've a backup
system running that works even if less satisfactory. But I still really
would like to know what's going on - maybe watch and wait, I don't know.
--
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 |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sat Nov 22, 2008 4:29 am | All times are GMT
|
|
Debt Consolidation | Mortgage Calculator | Mobile Phones | Charity | Personal Loans
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
