7 65.64/ ( 16 msec 20 msec 20 msec

Oops, indeed; you'd better upgrade your resolver library to understand
classless in-addr per RFC 2317:

% dig -x ptr

; <<>> DiG 8.3 <<>> -x ptr
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
;;, type = PTR, class = IN

;; ANSWER SECTION: 23h59m47s IN CNAME 65.64/
65.64/ 1D IN PTR bbr01-g3-0.okbr01.exodus.net.

64/ 23h57m10s IN NS bengi-w.exodus.net.
64/ 23h57m10s IN NS bengi-e.exodus.net.

bengi-w.exodus.net. 12m10s IN A
bengi-e.exodus.net. 12m10s IN A

;; Total query time: 3 msec
;; [...]


_MY_ resolver library is fine. That's how a customers new cisco reported

Cisco Internetwork Operating System Software
IOS (tm) C2600 Software (C2600-I-M), Version 12.1(3a), RELEASE SOFTWARE
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Thu 27-Jul-00 01:06 by cmong
Image text-base: 0x80008088, data-base: 0x807DA180

This is not an "oops".

Look at the RFC. It's a really simple yet ugly hack of DNS to allocate space
smaller then a /24.

Who cares if the Cisco resolver gives back the first CNAME record rather then
the following PTR?

Could anyone on NANOG really care less?!

indeed I see that right up to 12.1(5) which is the latest release I'm
running.. someone tell cisco :slight_smile:

Chris - its not a hack, its a proper way of doing things, the RFC merely
gives instructions on how to use this useful feature. the problem is that
cisco's reslover doesnt like CNAMES when it is looking up PTRs which is a
legal result.


case B110815 opened on feb 11th, but no DDTS opened yet ...