|
|
|
|
|
|
| Author |
Message |
Mark Andrews
*nix forums beginner
Joined: 02 Mar 2005
Posts: 25
|
 Posted: Wed Jul 19, 2006 4:17 am Post subject:
Re: major DNS hiccup
|
|
|
| Quote: | 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
|
Actually it didn't work and it proves my supposition in
the other messages. If you were actually talking to the
authoritative servers then you would see "aa" in the
flags. You are in fact talking to a cache.
This is what you should be seeing. Note "aa" is set and
"ra" is not set. In addition you get the NS RRset and
associated glue.
Mark
; <<>> 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: 4659
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;www.yell.co.uk. IN A
;; ANSWER SECTION:
www.yell.co.uk. 86400 IN A 194.72.108.2
;; AUTHORITY SECTION:
yell.co.uk. 86400 IN NS redgate.yellowpages.co.uk.
yell.co.uk. 86400 IN NS redgate2.yellowpages.co.uk.
;; ADDITIONAL SECTION:
redgate.yellowpages.co.uk. 86400 IN A 194.74.151.200
redgate2.yellowpages.co.uk. 86400 IN A 194.74.151.194
;; Query time: 307 msec
;; SERVER: 194.74.151.194#53(194.74.151.194)
;; WHEN: Wed Jul 19 14:12:16 2006
;; MSG SIZE rcvd: 137
| Quote: | 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 |
|
 |
Mike Scott
*nix forums Guru Wannabe
Joined: 25 Feb 2005
Posts: 138
|
| Posted: Wed Jul 19, 2006 9:47 am Post subject:
Re: major DNS hiccup
|
|
|
Mark Andrews wrote:
....
| Quote: | 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.
|
OK, I take your point. (I am, btw, headed well out of my depth here;
nameservers are something I've used and accepted as "just working" in
the past, without worrying to much about the nitty gritty.)
| Quote: |
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.
|
OK, so what happens when named thinks it's talking to an authoritative
server, and it's actually something different?
Checking a handful of queries that actually do work using my nameserver,
I find they all have "flags: qr rd ra", none with aa.
Whatever the details, this /has/ to be something on the network - all
was well until July 6th when caching nameservers seem to have started
failing for various people on the same segment of ntl's network. I've
logged a second fault call with ntl, requesting very firmly that the
issue be escalated past front-line support to the relevant group.
Hopefully, they'll have some sort of change record, and will realise
from that at least what's going on.
===
Incidentally, as a result of all this, I'm wondering about the relative
fragility of protocols that work only on a defined port number (DNS,
SMTP particularly) - these can all be broken or hijacked very readily by
some central authority: contrast with http, where any destination port
is possible (so, eg, when ntl's /web/ proxies break, it's quite easy to
bypass them). I guess this isn't the right group for such musings - but
I'd hope anyway I'm not the only one to think about 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 |
|
|
jpd
*nix forums Guru
Joined: 22 Feb 2005
Posts: 877
|
| Posted: Wed Jul 19, 2006 11:04 am Post subject:
Re: major DNS hiccup
|
|
|
Begin <o23vg.15527$EK1.13934@newsfe4-gui.ntli.net>
On 2006-07-18, Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
| Quote: | 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.
|
Don't charge the first line.
First line support is very good at keeping people at bay, calming irate
customers, filtering out the user error problems, and so on. That's what
they're there for. They're not there to fix anything.
At this point you really just want to pass their firewall and talk to
someone else. Someone started with saying literally that, and after
a long conversation (he can be quite persistent and can keep that up
for hours) said ``well, I said I wanted to talk to someone else at the
start, didn't I?'' when he finally got passed off to the second line.
That isn't particularly effective: The first line isn't allowed to pass
you off just because you want to talk to someone else.
Tell them exactly what you're seeing until their heads explode so they
pass you onto someone more knowledgeable. Mix in strong hints that you
checked and doublechecked your stuff and that you don't need handholding
while you support your own system, thank you, but carefully.
Describe your problem, not as if it's their fault, but as if you're
seeing an anomaly and need it investigated. Make them conclude that it
really must be their fault in their network on their side and that you
have proof. Lather, rinse, repeat until you talk to someone with actual
DNS clue. Get a trouble ticket written (get the number) with a promise
to call you back, then follow up on that after a day or two.
Be honest, have the proof ready, and don't act all superior. Just walk
them through your problems and your evidence. Give them a crash course
network monitoring and packet inspecting in that manner if you have to.
If that fails, take it to paper (fax or letter, not email). Keep track
of the names of everybody you talk to, and the times, and maybe the
names of their direct superiors, too. Also, re-read contracts and SLA
documents to see exactly what hoops you need to jump through so you can
put their noses to the grindstone.
Understandably, they'll be miffed you're expecting them to live up to
their SLA for a residential contract, but you do pay them a little for
that low service level so them being miffed really is their problem.
Your problem is to make clear they have a problem in their network and
that they're not living up to their SLA and that you've done your part
to notify them of that. In writing, if necessairy.
If you encounter particularly helpful and clueful people, keep track
of that too, and after the problem is fixed, send a thank you note
with a commendation about those people to their bosses.
--
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: Wed Jul 19, 2006 11:11 am Post subject:
Re: major DNS hiccup
|
|
|
Begin <ucnvg.16276$EK1.6129@newsfe4-gui.ntli.net>
On 2006-07-19, Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
| Quote: | Incidentally, as a result of all this, I'm wondering about the relative
fragility of protocols that work only on a defined port number (DNS,
SMTP particularly) - these can all be broken or hijacked very readily by
some central authority: contrast with http, where any destination port
is possible (so, eg, when ntl's /web/ proxies break, it's quite easy to
bypass them).
|
No, it isn't. You still need to find somewhere off-site that will proxy
your requests from your alternative destination port to port 80 again,
if only because of the millions of webservers that expect you to use
port 80.
Likewise, it isn't exactly hard to run an smptd or a dns server on a
port other than their well known ones. It's just that nobody ever does
so, whereas too many companies had firewalls blocking just port 80 so
many people implemented all sorts of workarounds. The difference is
historic, not technical.
--
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: Wed Jul 19, 2006 11:16 am Post subject:
Re: major DNS hiccup
|
|
|
jpd wrote:
| Quote: | Begin <o23vg.15527$EK1.13934@newsfe4-gui.ntli.net
On 2006-07-18, Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
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.
Don't charge the first line.
....
If you encounter particularly helpful and clueful people, keep track
of that too, and after the problem is fixed, send a thank you note
with a commendation about those people to their bosses.
|
Thanks for the tips - a followup problem report is already with them --
firm but saccharine sweet I hope in its politeness, and asking for the
problem to be escalated to the appropriate group.
Actually, thinking of helpful people, there may be a 'back door' into
support. I'll check!
--
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 19, 2006 6:17 pm Post subject:
Re: major DNS hiccup
|
|
|
Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
| Quote: | Mark Andrews wrote:
...
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.
OK, I take your point. (I am, btw, headed well out of my depth here;
nameservers are something I've used and accepted as "just working" in
the past, without worrying to much about the nitty gritty.)
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.
OK, so what happens when named thinks it's talking to an authoritative
server, and it's actually something different?
Checking a handful of queries that actually do work using my nameserver,
I find they all have "flags: qr rd ra", none with aa.
Whatever the details, this /has/ to be something on the network - all
was well until July 6th when caching nameservers seem to have started
failing for various people on the same segment of ntl's network. I've
logged a second fault call with ntl, requesting very firmly that the
issue be escalated past front-line support to the relevant group.
Hopefully, they'll have some sort of change record, and will realise
from that at least what's going on.
|
I'll be interested to see how you get on.
I take it this is now of academic interest only, and you have a fully
working named when you set your forwarders to NTL's nameservers?
Andrew |
|
| Back to top |
|
|
Mike Scott
*nix forums Guru Wannabe
Joined: 25 Feb 2005
Posts: 138
|
| Posted: Thu Jul 20, 2006 9:49 am Post subject:
Re: major DNS hiccup
|
|
|
Andrew Haley wrote:
....
| Quote: | Whatever the details, this /has/ to be something on the network - all
was well until July 6th when caching nameservers seem to have started
failing for various people on the same segment of ntl's network. I've
logged a second fault call with ntl, requesting very firmly that the
issue be escalated past front-line support to the relevant group.
Hopefully, they'll have some sort of change record, and will realise
from that at least what's going on.
I'll be interested to see how you get on.
I take it this is now of academic interest only, and you have a fully
working named when you set your forwarders to NTL's nameservers?
|
The original reason for running my own nameserver was (a)
self-instruction, and (b) the reputation of ntl's servers' reliability.
In fact, even using their servers, I've had the odd transient glitch
that looks awfully like the same problem (web access failed; nslookup
returned a server failure message; - but then it all cleared again with
seconds).
So not /quite/ academic interest, but I guess the urgency (if it was
ever there) has gone.
No response yet, btw, to the second formal fault report. I'm also
trying to raise the topic on chetnet (seems to be a back-door into ntl
support) but haven't managed to get a posting accepted yet. Problems on
top of problems  And all I was trying to do was get some music
transposed......
--
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: Thu Jul 20, 2006 1:22 pm Post subject:
Re: major DNS hiccup
|
|
|
Mike Scott <usenet.10@spam.stopper.scottsonline.org.uk> wrote:
| Quote: | Andrew Haley wrote:
...
Whatever the details, this /has/ to be something on the network - all
was well until July 6th when caching nameservers seem to have started
failing for various people on the same segment of ntl's network. I've
logged a second fault call with ntl, requesting very firmly that the
issue be escalated past front-line support to the relevant group.
Hopefully, they'll have some sort of change record, and will realise
from that at least what's going on.
I'll be interested to see how you get on.
I take it this is now of academic interest only, and you have a
fully working named when you set your forwarders to NTL's
nameservers?
The original reason for running my own nameserver was (a)
self-instruction, and (b) the reputation of ntl's servers' reliability.
In fact, even using their servers, I've had the odd transient glitch
that looks awfully like the same problem (web access failed; nslookup
returned a server failure message; - but then it all cleared again with
seconds).
|
Now, that is all very interesting to know. I was just about to go
back to using my NTL connection becasue it's so much faster than the
Demon ADSL connection, but maybe I shouldn't. I'll think on it.
| Quote: | So not /quite/ academic interest, but I guess the urgency (if it was
ever there) has gone.
No response yet, btw, to the second formal fault report. I'm also
trying to raise the topic on chetnet (seems to be a back-door into
ntl support) but haven't managed to get a posting accepted
yet. Problems on top of problems And all I was trying to do was
get some music transposed......
|
Good luck.
Andrew. |
|
| Back to top |
|
|
Mike Scott
*nix forums Guru Wannabe
Joined: 25 Feb 2005
Posts: 138
|
| Posted: Thu Jul 20, 2006 2:07 pm Post subject:
Re: major DNS hiccup
|
|
|
Andrew Haley wrote:
....
I wish it wasn't needed! Have you noticed how computer books in the
library are shelved next to the "unexplained and supernatural phenomena"
section? At least, they are round here. I'm beginning to wonder if they
know something I ought to :-)
But thanks! I'll return when I've heard something new.
--
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 7:49 am | All times are GMT
|
|
Personal Loans | Web Design | Books | Mortgage Calculator | Free Ringtones
|
|
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
