Brad Knowles brad.knowles at
Wed Oct 3 08:02:20 UTC 2001

At 1:19 PM -0700 10/2/01, Unix Admin wrote:

>  We are having problems with 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
> ( more interested in those that don't )

	Ahh, okay.  The 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 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 
<> 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 

	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. any +norec

; <<>> DiG 9.2.0rc3 <<>> @REDGATE.YELLOWPAGES.CO.UK. 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

;         IN      ANY

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.

A.GTLD-SERVERS.NET.     442013  IN      A
G.GTLD-SERVERS.NET.     442013  IN      A
H.GTLD-SERVERS.NET.     442013  IN      A
C.GTLD-SERVERS.NET.     442013  IN      A
I.GTLD-SERVERS.NET.     442013  IN      A
B.GTLD-SERVERS.NET.     442013  IN      A
D.GTLD-SERVERS.NET.     442013  IN      A
L.GTLD-SERVERS.NET.     442013  IN      A
F.GTLD-SERVERS.NET.     442013  IN      A
J.GTLD-SERVERS.NET.     442013  IN      A
K.GTLD-SERVERS.NET.     442013  IN      A
E.GTLD-SERVERS.NET.     442013  IN      A
M.GTLD-SERVERS.NET.     442013  IN      A

;; Query time: 118 msec
;; WHEN: Wed Oct  3 03:49:26 2001
;; MSG SIZE  rcvd: 474


; <<>> DiG 9.2.0rc3 <<>> @REDGATE.YELLOWPAGES.CO.UK. 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

;         IN      ANY

;; ANSWER SECTION:  3600    IN      A

;; AUTHORITY SECTION:      28800   IN      NS      28800   IN      NS      28800   IN      NS

;; ADDITIONAL SECTION:             3600    IN      A            3600    IN      A            3600    IN      A

;; Query time: 242 msec
;; WHEN: Wed Oct  3 03:49:32 2001
;; MSG SIZE  rcvd: 163


; <<>> DiG 9.2.0rc3 <<>> @REDGATE.YELLOWPAGES.CO.UK. 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

;         IN      ANY

;; ANSWER SECTION:  3594    IN      A

;; AUTHORITY SECTION:      172794  IN      NS      NS.HIS.COM.      172794  IN      NS      NS2.HIS.COM.      172794  IN      NS      NS3.HIS.COM.

NS.HIS.COM.             106805  IN      A
NS2.HIS.COM.            98165   IN      A
NS3.HIS.COM.            98165   IN      A

;; Query time: 116 msec
;; 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>


More information about the bind-users mailing list