"can't find bounty.org: Non-existent host/domain"

Brad Knowles brad.knowles at skynet.be
Thu Oct 4 22:13:15 UTC 2001


At 1:29 PM -0700 10/4/01, Petro wrote:

>  	If one does a lookup for "www.bounty.org", one gets the appropriate
>  ip (it's a cname to lists.bounty.org). If one is sending mail to
>  petro at bounty.org, it gets delivered (indicating to me that the MX
>  record is working properly). However if one just does a lookup on
>  "bounty.org" using (the now deprecated, I understand) nslookup one
>  gets "can't find bounty.org: Non-existent host/domain". If one uses
>  dig, you get:

	With both nslookup and dig, if you don't specify the query type, 
I believe that they will default to trying to look up the IP address. 
Since you don't have an IP address defined for bounty.org itself, you 
get the results you have described.

	However, this is not necessarily a configuration error -- as you 
point out, web access to www.bounty.org is working fine, and mail to 
user at bounty.org is working fine.


	You should only bother to add an IP address for the domain if you 
feel it's necessary, and if you want URLs like <http://bounty.org/> 
to work (assuming that you use the same IP address as you have for 
lists.bounty.org).

>  @               in      soa     bounty.org. petro.bounty.org. (
>                                  2001100303      ;serial
>                                  3600            ;refresh
>                                  1800            ;retry
>                                  604800          ;expiration
>                                  3600 )          ;minimum

	Generally speaking, you want your refresh to be at least three to 
four times as large as your retry.

>                          in      ns              blackhole.bounty.org.
>                          in      ns              nameserver.concentric.net.
>                          in      ns              namserver3.concentric.net.

	If you're going to be a truly "hidden master" for this zone, then 
you need to remove the NS record pointing to blackhole.bounty.org. 
Just leave it with the other two and it will still answer 
authoritatively to anyone who knows to query it, but should otherwise 
remain unmolested.

	Note that namserver3.concentric.net. doesn't exist -- this would 
appear to be a typo.  You probably meant 
"nameserver3.concentric.net".  Also, both of these nameservers may be 
on the same network.  You may want to arrange to have secondary/slave 
DNS provided by a third party, such as secondary.com.



>                  1w      in      MX      10      lists.bounty.org.

	You may want to consider arranging to have backup MX services with someone.

>  lists           1w      in      a               208.176.30.19
>  loki            1w      in      a               208.176.30.22
>  blackhole       1w      in      a               208.176.30.19
>  death           1w      in      a               208.176.30.21
>  www             1w      CNAME                   lists
>  bounty.org.     1w      cname                   lists

	Uhh, no.  You can't CNAME the entire domain.  This would have the 
CNAME record coexisting with the SOA and MX records, which is not 
allowed.  However, you can assign an IP address to the domain, if you 
like -- just use the same one as you have on "lists" today.

	Looking at what you have out there now for bounty.org, using DNS 
debugging tools, I see:

% doc -v bounty.org
Doc-2.2.3: doc -v bounty.org
Doc-2.2.3: Starting test of bounty.org.   parent is org.
Doc-2.2.3: Test date - Thu Oct  4 18:06:13 EDT 2001
soa @a.gtld-servers.net. for org. has serial: 2001100400
soa @b.gtld-servers.net. for org. has serial: 2001100400
soa @c.gtld-servers.net. for org. has serial: 2001100400
soa @d.gtld-servers.net. for org. has serial: 2001100400
DIGERR (NOT_AUTHORIZED): dig @e.gtld-servers.net. for SOA of parent 
(org.) failed
soa @f.gtld-servers.net. for org. has serial: 2001100400
soa @g.gtld-servers.net. for org. has serial: 2001100400
soa @h.gtld-servers.net. for org. has serial: 2001100400
soa @i.gtld-servers.net. for org. has serial: 2001100400
soa @j.gtld-servers.net. for org. has serial: 2001100400
soa @k.gtld-servers.net. for org. has serial: 2001100400
soa @l.gtld-servers.net. for org. has serial: 2001100400
soa @m.gtld-servers.net. for org. has serial: 2001100400
SOA serial #'s agree for org. domain
Found 2 NS and 2 glue records for bounty.org. @a.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for bounty.org. @b.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for bounty.org. @c.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for bounty.org. @d.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for bounty.org. @f.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for bounty.org. @g.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for bounty.org. @h.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for bounty.org. @i.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for bounty.org. @j.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for bounty.org. @k.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for bounty.org. @l.gtld-servers.net. (non-AUTH)
Found 2 NS and 2 glue records for bounty.org. @m.gtld-servers.net. (non-AUTH)
DNServers for org.
    === 0 were also authoritatve for bounty.org.
    === 12 were non-authoritative for bounty.org.
Servers for org. (not also authoritative for bounty.org.)
    === agree on NS records for bounty.org.
NS list summary for bounty.org. from parent (org.) servers
   == nameserver.concentric.net. nameserver3.concentric.net.
soa @nameserver.concentric.net. for bounty.org. serial: 2000121501
soa @nameserver3.concentric.net. for bounty.org. serial: 234
ERROR: non-authoritative SOA for bounty.org. from nameserver3.concentric.net.
ERROR: NS list from bounty.org. authoritative servers does not
   === match NS list from parent (org.) servers
NS list summary for bounty.org. from authoritative servers
   == loki.bounty.org. nameserver.concentric.net. namserver3.concentric.net.
Checking 1 potential addresses for hosts at bounty.org.
   == 208.176.30.22
in-addr PTR record found for 208.176.30.22
Summary:
    ERRORS found for bounty.org. (count: 2)
Done testing bounty.org.  Thu Oct  4 18:06:30 EDT 2001


	Note that nameserver3.concentric.net is a lame delegation (and 
their SOA serial number is wrong), and that you have mis-matched 
delegation information between the parent .org gTLD zone (which lists 
only nameserver.concentric.net and nameserver3.concentric.net) versus 
the authoritative servers themselves (which also list 
loki.bounty.org).  You want to make sure that the lists of 
authoritative servers match in both places, and that all the 
authoritative servers are properly configured and actually answering 
authoritatively for your zone.

	For another view of the same zone, here's the report from DNS 
Expert Professional 1.6:

                               DNS Expert
                    Detailed Report for bounty.org.
       10/5/01, 12:12 AM, using the analysis setting "Everything"
======================================================================

Information
----------------------------------------------------------------------
Serial number:           2000121501
Primary name server:     bounty.org.
Primary mail server:     lists.bounty.org.
Number of records:       N/A


Errors
----------------------------------------------------------------------
o Non-authoritative data received from the server
   "nameserver3.concentric.net."
     The server "nameserver3.concentric.net." is listed as being
     authoritative for the domain, but it does not contain
     authoritative data for it.

o Non-authoritative data received from the server "loki.bounty.org."
     The server "loki.bounty.org." is listed as being authoritative
     for the domain, but it does not contain authoritative data for it.

o Unable to check the name server "namserver3.concentric.net."
     It was not possible to check the name server
     "namserver3.concentric.net.", because its address could not be
     resolved.

o Only one of your name servers has autoritative data for the zone.
     The server "nameserver.concentric.net." is the only server that
     has authoritaive data for the zone.  If this server becomes
     unavailable, your domain will become inacessible.


Warnings
----------------------------------------------------------------------
o Problems determining primary server
     There was not enough data available to determine which server is
     the primary server for the zone. The zone data from the server
     "nameserver.concentric.net." will be used when analyzing the zone.

o The name server "nameserver.concentric.net." does not permit zone
   transfers
     The name server "nameserver.concentric.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 value in the SOA record is too close to the retry value
     The value of the Refresh field in the SOA record (currently 3600)
     should be at least three times bigger than the value of the Retry
     field (currently 1800).

o The TTL value 604800, in the A record "loki.bounty.org." is rather
   high
     The TTL value 604800, used in the A record "loki.bounty.org.", is
     unusually high.  The TTL value should be within the range 3600 -
     172800.

o The TTL value 604800, in the A record "lists.bounty.org." is rather
   high
     The TTL value 604800, used in the A record "lists.bounty.org.",
     is unusually high.  The TTL value should be within the range 3600
     - 172800.

o The TTL value 604800, in the MX record "bounty.org." is rather high
     The TTL value 604800, used in the MX record "bounty.org.", is
     unusually high.  The TTL value should be within the range 3600 -
     172800.

o There is only one MX record in the zone
     The zone contains only one MX record.  This will cause mail
     delivery problems if the primary mail server becomes unavailable.
      For safety purposes, there should be two or more mail servers
     for every zone, the extra mail servers being used as backup
     (secondary) servers for the primary server.


----------------------------------------------------------------------
end of report

-- 
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