cname quick question
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.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.nominum.com and
ns.rfc1035.com are identical. NSI wouldn't let me have NS records
called ns.rfc1035.com in the com zone if the glue records for them
had the same IP addresses as the A records for gns.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> 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> ;; 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> ;; ->>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