cname quick question

[Brad Knowles]

At 9:47 PM +0000 3/8/01, Jim Reid wrote:

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

	Weird.  I have to say that this is the first time I recall seeing 
differing names used in the delegations and within the zone itself, 
but where the servers themselves were actually correctly configured 
and properly answering authoritatively.

	To me, this has all the smells of a lame delegation, but as you 
point out, is not.  So, I guess the real question is -- how would you 
programatically detect a true lame delegation, and not have your 
detector set off by this false positive?  Maybe you only do it by IP 
address and not by the host/domain label?

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

	Ahh, right.  Well, I don't have any BINDv9 installations, so I 
can't use a BINDv9 dig to test this out.  Even if I did, I wouldn't 
then have a BIND 8 server I could use my BINDv9 client against, to 
see how the server handles DNAMEs in comparison to the client.

	Sorry about that.  It hadn't occurred to me that there might be a 
client issue here as well.

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

	Indeed, I just added checking of version.bind to my private copy 
of "doc", and noticed that this had already changed.

	Hmm.  I guess someone is going to have to write a paper on DNS 
nameserver fingerprinting, starting with the sort of work previously 
done on OS fingerprinting using TCP/IP.

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

	Oops, I missed that.  Speaking of unusual return codes, what is 
"VRSN1" in the return codes for this query on all of the 
*.gtld-servers.net machines?

--
Brad Knowles, <brad.knowles at skynet.be>

#!/usr/bin/perl -w
# 531-byte qrpff-fast, Keith Winstein and Marc Horowitz <sipb-iap-dvd at mit.edu>
# MPEG 2 PS VOB file on stdin -> descrambled output on stdout
# arguments: title key bytes in least to most-significant order
# Usage:
# qrpff 153 2 8 105 225 /mnt/dvd/VOB_FILE_NAME | extract_mpeg2 | mpeg2_dec -
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map{$_%16or$t^=$c^=(
$m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t^=(72, at z=(64,72,$a^=12*($_%16
-2?0:$m&17)),$b^=$_%64?12:0, at z)[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h
=5;$_=unxb24,join"", at b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$
d=unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d>>12^$d>>4^
$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9,$_=$t[$_]^
(($h>>=8)+=$f+(~$g&$t))for at a[128..$#a]}print+x"C*", at a}';s/x/pack+/g;eval