Server not resolving a domain...
Brad Knowles
brad.knowles at skynet.be
Wed Aug 8 13:19:12 UTC 2001
At 5:49 AM -0700 8/8/01, Ali Eghtessadi wrote:
> I am running bind 8.2.2P5 on a solaris 8 server.
You need to upgrade. This version of BIND is vulnerable to a
root compromise that can allow attackers to have full access to your
machine in just seconds. Indeed, the "li0n" worm a while back was
based on exploiting precisely this vulnerability.
> For some
> reason it can not resolve addresses for one of the domains
> "ny.babcockbrown.com".
This record does not exist anywhere in the DNS. Witness:
% dig ny.babcockbrown.com. any
; <<>> DiG 9.1.2 <<>> ny.babcockbrown.com. any
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 17481
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ny.babcockbrown.com. IN ANY
;; AUTHORITY SECTION:
babcockbrown.com. 600 IN SOA
alcatraz.babcockbrown.com. hostmaster.babcockbrown.com. 2001060600
900 300 604800 600
;; Query time: 77 msec
;; WHEN: Wed Aug 8 09:01:14 2001
;; MSG SIZE rcvd: 93
% dig @alcatraz.babcockbrown.com. ny.babcockbrown.com. any
; <<>> DiG 9.1.2 <<>> @alcatraz.babcockbrown.com. ny.babcockbrown.com. any
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22903
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ny.babcockbrown.com. IN ANY
;; AUTHORITY SECTION:
babcockbrown.com. 600 IN SOA
alcatraz.babcockbrown.com. hostmaster.babcockbrown.com. 2001060600
900 300 604800 600
;; Query time: 77 msec
;; SERVER: 208.1.254.2#53(alcatraz.babcockbrown.com.)
;; WHEN: Wed Aug 8 09:04:03 2001
;; MSG SIZE rcvd: 93
Since I suspect errors with your domain, I'll run some DNS
debugging tools against it. First up, we have the latest version of
"doc":
% doc -d babcockbrown.com
Doc-2.2.3: doc -d babcockbrown.com
Doc-2.2.3: Starting test of babcockbrown.com. parent is com.
Doc-2.2.3: Test date - Wed Aug 8 09:04:27 EDT 2001
DEBUG: digging @a.gtld-servers.net. for soa of com.
soa @a.gtld-servers.net. for com. has serial: 2001080701
DEBUG: digging @b.gtld-servers.net. for soa of com.
soa @b.gtld-servers.net. for com. has serial: 2001080701
DEBUG: digging @c.gtld-servers.net. for soa of com.
soa @c.gtld-servers.net. for com. has serial: 2001080701
DEBUG: digging @d.gtld-servers.net. for soa of com.
soa @d.gtld-servers.net. for com. has serial: 2001080701
DEBUG: digging @e.gtld-servers.net. for soa of com.
soa @e.gtld-servers.net. for com. has serial: 2001080701
DEBUG: digging @f.gtld-servers.net. for soa of com.
soa @f.gtld-servers.net. for com. has serial: 2001080701
DEBUG: digging @g.gtld-servers.net. for soa of com.
soa @g.gtld-servers.net. for com. has serial: 2001080701
DEBUG: digging @h.gtld-servers.net. for soa of com.
soa @h.gtld-servers.net. for com. has serial: 2001080701
DEBUG: digging @i.gtld-servers.net. for soa of com.
soa @i.gtld-servers.net. for com. has serial: 2001080701
DEBUG: digging @j.gtld-servers.net. for soa of com.
soa @j.gtld-servers.net. for com. has serial: 2001080701
DEBUG: digging @k.gtld-servers.net. for soa of com.
soa @k.gtld-servers.net. for com. has serial: 2001080701
DEBUG: digging @l.gtld-servers.net. for soa of com.
soa @l.gtld-servers.net. for com. has serial: 2001080701
DEBUG: digging @m.gtld-servers.net. for soa of com.
soa @m.gtld-servers.net. for com. has serial: 2001080701
SOA serial #'s agree for com. domain
Found 2 NS and 2 glue records for babcockbrown.com.
@a.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for babcockbrown.com.
@b.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for babcockbrown.com.
@c.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for babcockbrown.com.
@d.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for babcockbrown.com.
@e.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for babcockbrown.com.
@f.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for babcockbrown.com.
@g.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for babcockbrown.com.
@h.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for babcockbrown.com.
@i.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for babcockbrown.com.
@j.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for babcockbrown.com.
@k.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for babcockbrown.com.
@l.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for babcockbrown.com.
@m.gtld-servers.net. (non-AUTH)
DNServers for com.
=== 0 were also authoritatve for babcockbrown.com.
=== 13 were non-authoritative for babcockbrown.com.
Servers for com. (not also authoritative for babcockbrown.com.)
=== agree on NS records for babcockbrown.com.
DEBUG: domserv = alcatraz.babcockbrown.com. ns1-auth.sprintlink.net.
NS list summary for babcockbrown.com. from parent (com.) servers
== alcatraz.babcockbrown.com. ns1-auth.sprintlink.net.
digging @alcatraz.babcockbrown.com. for soa of babcockbrown.com.
soa @alcatraz.babcockbrown.com. for babcockbrown.com. serial: 2001060600
digging @ns1-auth.sprintlink.net. for soa of babcockbrown.com.
soa @ns1-auth.sprintlink.net. for babcockbrown.com. serial: 2001060600
SOA serial #'s agree for babcockbrown.com.
Authoritative domain (babcockbrown.com.) servers agree on NS for
babcockbrown.com.
ERROR: NS list from babcockbrown.com. authoritative servers does not
=== match NS list from parent (com.) servers
NS list summary for babcockbrown.com. from authoritative servers
== alcatraz.babcockbrown.com. ns1-auth.sprintlink.net.
ns2-auth.sprintlink.net.
Checking 1 potential addresses for hosts at babcockbrown.com.
== 208.1.254.2
in-addr PTR record found for 208.1.254.2
Summary:
ERRORS found for babcockbrown.com. (count: 1)
Done testing babcockbrown.com. Wed Aug 8 09:04:33 EDT 2001
Hmm. It would seem that you have what I would call an "orphan"
delegation here to ns2-auth.sprintlink.net (it is listed as an
authoritative nameserver by the nameservers that are officially
delegated from the .com gTLD nameservers, but is not itself delegated
to by those nameservers).
Now, let's take a look at DNS Expert Professional 1.6 from Men &
Mice (see <http://www.menandmice.com/2000/2100_dns_expert.html>):
DNS Expert
Detailed Report for babcockbrown.com.
8/8/01, 3:07 PM, using the analysis setting "Everything"
======================================================================
Information
----------------------------------------------------------------------
Serial number: 2001060600
Primary name server: alcatraz.babcockbrown.com.
Primary mail server: alcatraz.babcockbrown.com.
Number of records: N/A
Errors
----------------------------------------------------------------------
o The name server "ns2-auth.sprintlink.net." is not listed in
delegation data
The server "ns2-auth.sprintlink.net." is listed as being
authoritative for the zone according to the zone data, but there
is no NS record for that server in the delegation data.
Delegation data and zone data should always match.
o Unable to contact "alcatraz.babcockbrown.com."
It was not possible to establish a connection with the server
"alcatraz.babcockbrown.com.". This server will not be used to
check information about the zone.
Warnings
----------------------------------------------------------------------
o The name server "ns1-auth.sprintlink.net." does not permit zone
transfers
The name server "ns1-auth.sprintlink.net." has been configured to
reject unauthorized zone transfers and the application will not
be able to use data from this server while analyzing the zone.
o The name server "ns2-auth.sprintlink.net." does not permit zone
transfers
The name server "ns2-auth.sprintlink.net." has been configured to
reject unauthorized zone transfers and the application will not
be able to use data from this server while analyzing the zone.
o Zone transfer from authoritative servers not possible
It was not possible to perform a zone transfer from any of the
authoritative name servers for the zone. This will limit the
range of tests performed for the zone.
o The Refresh field in the SOA record contains an unusually low value
The value 900 of the Refresh field in the SOA record is unusually
low. The value for this field should be within the range 3600 -
86400.
o The Minimum TTL field in the SOA record contains an unusually low
value
The value 600 of the Minimum field in the SOA record is unusually
low. The value for this field should be within the range 3600 -
172800.
o The zone contains more than one MX record with the highest
preference
The zone contains more than one MX record for "babcockbrown.com."
(referring to "lombard.babcockbrown.com." and
"alcatraz.babcockbrown.com.") with the highest preference
(preference value 100).
----------------------------------------------------------------------
end of report
From what I can tell, it is not possible to contact
alcatraz.babcockbrown.com via TCP to port 53, which is likely to
cause unexplained DNS problems, as TCP is used for more than just
zone transfers. By the rules laid out by the RFCs, if a UDP query
results in more data than will fit in a UDP response, then as much
data as can be fit in will be transmitted and the "Truncated" bit
will be set. When that happens, the client is supposed to re-try
that query using TCP.
Therefore, blocking all TCP to port 53 is just plain stupid. If
you want to restrict zone transfers from unauthorized parties, you
should control this within the nameserver configuration, and not by
blocking all TCP packets to port 53.
Fortunately for you, the nameservers being operated by Sprint
*do* allow TCP packets to be transmitted to port 53, and they have
been configured so as to refuse zone transfers from unauthorized
parties. You should take a cue from Sprint and set up the security
on your nameserver the same way.
Overall, I suspect that your problem is one of delegation. You
have all this data privately in-house, but this information is not
available on a server that the rest of the world knows about, and
therefore any changes you make to these zones simply don't show up.
--
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