Yell.com
Brad Knowles
brad.knowles at skynet.be
Wed Oct 3 08:02:20 UTC 2001
At 1:19 PM -0700 10/2/01, Unix Admin wrote:
> We are having problems with Yell.com that certain ISP can't get to the
> site.
>
> Our DNS looks OK apart from our secondary DNS server is offline at the
> moment ( fixed soon). Our main DNS is proxied behind some Foundry kit
> for Global Site Load Balancing reasons and has a 10sec TTL. We do have
> reslience though as we have 2 servers under the proxy address.
>
> If anyone has a spare moment - take a look and let me know if you get
> Yell.com ( more interested in those that don't )
Ahh, okay. The yell.com folks. You should already have copies
of some analysis that I've done on this domain so far.
One thing that I'd suggest is that you turn on the ability for
arbitrary people outside your network to do zone transfers. This is
how I found out about your previous problems, which I posted about on
this mailing list (and which I believe someone sent you a copy of,
which you then used to fix your problems).
From my part, looking at your machines, it seems to me that
you're running BIND 8.1.2, which should most certainly be replaced --
preferably with 9.1.3-REL or 9.2.0rc5, but if you are wedded to the
BIND 8 platform, then at the very least you should upgrade to version
8.2.5-REL. This may or may not fix the problem, but it should
certainly help eliminate some potentially confusing factors
(including such things as your servers inappropriately providing
out-of-zone glue, especially cached glue).
As you already know, the TTLs in your domain are excessively low
-- 3600 seconds for everything is way too low for normal records.
Moreover, if you really do need to set your TTLs low so that your
GSLB stuff can work correctly, then 3600 seconds is probably way too
high. Either way, I'd say that this is very clearly broken.
If you need to provide low TTLs for your IP addresses for your
GSLB to work correctly, you could safely do that while providing much
more reasonable TTLs for the NS records, SOA record, MX records,
etc.... The names would stick around for a while, although people
would have to more frequently query for their associated IP addresses.
Oh, and you really should get reverse DNS set up correctly --
either have the folks at BT.net delegate the zone to you, so that you
can run it correctly on your local machines, or they should have it
correctly set up on their end.
If your zone is as important as you lead us to believe, then you
should most certainly have an off-site secondary/slave with another
company. I recommend that you talk to the folks at Nominum about
setting you up as a customer of their Global Name Service (GNS). See
<http://www.nominum.com/> for more info. They could probably also do
some consulting for you to help you fix all your various and sundry
DNS problems.
You could even go so far as to completely outsource the
management of your DNS to another company. Here, I'd recommend that
you talk to the company that Cricket Liu (co-author of the book _DNS
and BIND_) now works for, namely Men & Mice (see
<http://www.menandmice.com/>).
Finally, probably one of your most serious problems is that your
nameservers are acting as public caching/recursive resolvers, in
addition to their authoritative role. This means that they are much
more subject to cache poisoning attacks, and older versions of BIND
(such as 8.1.2, which is what you appear to be running) are
particularly vulnerable to this.
Since cache poisoning attacks are a frequent prelude to having
machines on your network taken over, you're really leaving yourself
wide open to having some or all of your machines compromised if you
do not upgrade the version of BIND that you are running, and you do
not turn off recursion.
Here's an example of the kind of query that should *not* work
against your servers:
% dig @REDGATE.YELLOWPAGES.CO.UK. www.shub-internet.org. any +norec
; <<>> DiG 9.2.0rc3 <<>> @REDGATE.YELLOWPAGES.CO.UK.
www.shub-internet.org. any +norec
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10278
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 13
;; QUESTION SECTION:
;www.shub-internet.org. IN ANY
;; AUTHORITY SECTION:
org. 343398 IN NS A.GTLD-SERVERS.NET.
org. 343398 IN NS G.GTLD-SERVERS.NET.
org. 343398 IN NS H.GTLD-SERVERS.NET.
org. 343398 IN NS C.GTLD-SERVERS.NET.
org. 343398 IN NS I.GTLD-SERVERS.NET.
org. 343398 IN NS B.GTLD-SERVERS.NET.
org. 343398 IN NS D.GTLD-SERVERS.NET.
org. 343398 IN NS L.GTLD-SERVERS.NET.
org. 343398 IN NS F.GTLD-SERVERS.NET.
org. 343398 IN NS J.GTLD-SERVERS.NET.
org. 343398 IN NS K.GTLD-SERVERS.NET.
org. 343398 IN NS E.GTLD-SERVERS.NET.
org. 343398 IN NS M.GTLD-SERVERS.NET.
;; ADDITIONAL SECTION:
A.GTLD-SERVERS.NET. 442013 IN A 192.5.6.30
G.GTLD-SERVERS.NET. 442013 IN A 192.42.93.30
H.GTLD-SERVERS.NET. 442013 IN A 192.54.112.30
C.GTLD-SERVERS.NET. 442013 IN A 192.26.92.30
I.GTLD-SERVERS.NET. 442013 IN A 192.36.144.133
B.GTLD-SERVERS.NET. 442013 IN A 192.33.14.30
D.GTLD-SERVERS.NET. 442013 IN A 192.31.80.30
L.GTLD-SERVERS.NET. 442013 IN A 192.41.162.30
F.GTLD-SERVERS.NET. 442013 IN A 192.35.51.30
J.GTLD-SERVERS.NET. 442013 IN A 210.132.100.101
K.GTLD-SERVERS.NET. 442013 IN A 213.177.194.5
E.GTLD-SERVERS.NET. 442013 IN A 192.12.94.30
M.GTLD-SERVERS.NET. 442013 IN A 202.153.114.101
;; Query time: 118 msec
;; SERVER: 194.74.151.200#53(REDGATE.YELLOWPAGES.CO.UK.)
;; WHEN: Wed Oct 3 03:49:26 2001
;; MSG SIZE rcvd: 474
% dig @REDGATE.YELLOWPAGES.CO.UK. www.shub-internet.org. any
; <<>> DiG 9.2.0rc3 <<>> @REDGATE.YELLOWPAGES.CO.UK. www.shub-internet.org. any
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65450
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;www.shub-internet.org. IN ANY
;; ANSWER SECTION:
www.shub-internet.org. 3600 IN A 216.200.80.85
;; AUTHORITY SECTION:
shub-internet.org. 28800 IN NS ns.his.com.
shub-internet.org. 28800 IN NS ns2.his.com.
shub-internet.org. 28800 IN NS ns3.his.com.
;; ADDITIONAL SECTION:
ns.his.com. 3600 IN A 209.67.207.6
ns2.his.com. 3600 IN A 216.200.68.6
ns3.his.com. 3600 IN A 216.194.192.8
;; Query time: 242 msec
;; SERVER: 194.74.151.200#53(REDGATE.YELLOWPAGES.CO.UK.)
;; WHEN: Wed Oct 3 03:49:32 2001
;; MSG SIZE rcvd: 163
% dig @REDGATE.YELLOWPAGES.CO.UK. www.shub-internet.org. any
; <<>> DiG 9.2.0rc3 <<>> @REDGATE.YELLOWPAGES.CO.UK. www.shub-internet.org. any
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43574
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;www.shub-internet.org. IN ANY
;; ANSWER SECTION:
www.shub-internet.org. 3594 IN A 216.200.80.85
;; AUTHORITY SECTION:
shub-internet.org. 172794 IN NS NS.HIS.COM.
shub-internet.org. 172794 IN NS NS2.HIS.COM.
shub-internet.org. 172794 IN NS NS3.HIS.COM.
;; ADDITIONAL SECTION:
NS.HIS.COM. 106805 IN A 209.67.207.6
NS2.HIS.COM. 98165 IN A 216.200.68.6
NS3.HIS.COM. 98165 IN A 216.194.192.8
;; Query time: 116 msec
;; SERVER: 194.74.151.200#53(REDGATE.YELLOWPAGES.CO.UK.)
;; WHEN: Wed Oct 3 03:49:38 2001
;; MSG SIZE rcvd: 180
If your nameservers were properly secured, we would have gotten
the same response on the last two queries as we did on the first one.
Anyway, this is everything I can think of, without being able to
do a full transfer of your entire zone. I'm sure that if I was able
to get that information, I could probably provide some additional
information that might also be helpful.
--
Brad Knowles, <brad.knowles at skynet.be>
H4sICIFgXzsCA2RtYS1zaWcAPVHLbsMwDDvXX0H0kkvbfxiwVw8FCmzAzqqj1F4dy7CdBfn7
Kc6wmyGRFEnvvxiWQoCvqI7RSWTcfGXQNqCUAnfIU+AT8OZ/GCNjRVlH0bKpguJkxiITZqes
MxwpSucyDJzXxQEUe/ihgXqJXUXwD9ajB6NHonLmNrUSK9nacHQnH097szO74xFXqtlbT3il
wMsBz5cnfCR5cEmci0Rj9u/jqBbPeES1I4PeFBXPUIT1XDSOuutFXylzrQvGyboWstCoQZyP
dxX4dLx0eauFe1x9puhoi0Ao1omEJo+BZ6XLVNaVpWiKekxN0VK2VMpmAy+Bk7ZV4SO+p1L/
uErNRS/qH2iFU+iNOtbcmVt9N16lfF7tLv9FXNj8AiyNcOi1AQAA
More information about the bind-users
mailing list