cname quick question

Jim Reid jim at rfc1035.com
Thu Mar 8 21:47:26 UTC 2001


>>>>> "Brad" == Brad Knowles <brad.knowles at skynet.be> writes:

    Brad> 	Strangely, it also seems that gns1.nominum.com and
    Brad> gns2.nominum.com are lame delegations -- they appear in the
    Brad> list from the parent servers, but not in the list from the
    Brad> authoritative servers:

Nope, they are not lame delegations. gns[12].nominum.com are answering
authoritatively for rfc1035.org. They always have done. The NS record
targets in the actual rfc1035.org zone just have different names for
the same hosts. The IP addresses for gns[12].nominum.com and
ns[12].rfc1035.com are identical. NSI wouldn't let me have NS records
called ns[12].rfc1035.com in the com zone if the glue records for them
had the same IP addresses as the A records for gns[12].nominum.com
that were already in the com zone. Sigh.

    Brad> I also find it interesting that the Nominum GNS servers don't 
    Brad> appear to be capable of understanding DNAME records, either:

    Brad> dig @gns1.nominum.com. rfc1035.org. any
    Brad> ; <<>> DiG 8.1 <<>> @gns1.nominum.com. rfc1035.org. any
    Brad> .....
    Brad> rfc1035.org.            1D IN 39        \#(    ; unknown RR type
         07 72 66 63 31 30 33 35 03 63 6f 6d 00 )        ; .rfc1035.com.

Well that would be interesting if it were true. However it's the
version of dig you're running that doesn't understand the DNAME, not
the GNS name servers:

	% dig @gns1.nominum.com rfc1035.org any

	; <<>> DiG 9.1.1rc3 <<>> @gns1.nominum.com rfc1035.org any
	....
	rfc1035.org.            86400   IN      DNAME   rfc1035.com.

Note the dig version number in the output!

    Brad> 	Hmm, you also don't seem to have updated this machine
    Brad> to BIND 9.1.1:

    Brad> $ dig @ns0.rfc1035.com. version.bind. txt chaos
    Brad> ....
    Brad> ;; ANSWER SECTION: version.bind.  0S CHAOS TXT "9.1.0"

The server could be lying... It sometimes says it runs 4.8.3. :-)

    Brad> And the GNS servers don't seem to respond to this query at all:

    Brad> $ dig @gns1.nominum.com. version.bind. txt chaos
    Brad> ....
    Brad> ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 10

They do respond. With a REFUSED error code. There's nothing wrong with
that. It means the server has been configured not to answer that query.
FWIW the Microsoft name server returns a NOTIMP - not implemented -
error code to those version queries.


More information about the bind-users mailing list