Subject: Re: [dnsop] strange response about ns.apnic.net from gtld servers

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Nov 2005 16:22:03 +1100

> (Sorry if this list is not the best place to ask this)
> 
> I've noticed a strange response from gtld servers when I asked an A
> RRset of "ns.apnic.net".  In summary,
> 
> - gtld servers returns an A RR whose IPv4 address is 203.37.255.97,
>   which is different from the authoritative data (according to
>   apnic.net's authoritative servers, it should be 202.12.29.25)
> - the response from the gtld servers does not have AA or RA bit.
> - but the TTL doesn't seem to decrease even if I repeatedly ask the
>   same name to the same server.  So, it doesn't seem to be a cached
>   RRset at least in a normal sense.
> (specific responses using dig are attached below)
> 
> What's happening?
> 
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center, Toshiba Corp.
> 					[email-masked]

	It's a glue record.  Contact APNIC to get it updated /
	removed depending upon whether it is a nameserver for a child
	of NET/COM or not.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Terry Manderson <[email-masked]>
Date: Tue, 22 Nov 2005 14:50:54 +1000

Hi Jinmei-san,

What you see is, I think, an issue of stale glue.

APNIC has previously and on several occasions asked for
glue records to be changed to reflect reality.

We do apologise if this inconsistency causes you concern
and we will of course try to get this updated as soon
as possible.

Cheers,
Terry

--
Terry Mnderson,  Snr Systems & Network Architect
    APNIC Secretariat        http://www.apnic.net
    [email-masked]          tel: +61 7 3858 3100

.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 22 Nov 2005 13:33:59 +0900

What's happening?

					JINMEI, Tatuya

% dig @a.gtld-servers.net ns.apnic.net +norec; sleep 5; dig @a.gtld-servers.net ns.apnic.net +norec

; <<>> DiG 9.4.0a2 <<>> @a.gtld-servers.net ns.apnic.net +norec
; (2 servers found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58115
;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5

;; QUESTION SECTION:
;ns.apnic.net.			IN	A

;; ANSWER SECTION:
ns.apnic.net.		172800	IN	A	203.37.255.97

;; AUTHORITY SECTION:
apnic.net.		172800	IN	NS	cumin.apnic.net.
apnic.net.		172800	IN	NS	ns-sec.ripe.net.
apnic.net.		172800	IN	NS	tinnie.apnic.net.
apnic.net.		172800	IN	NS	tinnie.arin.net.

;; ADDITIONAL SECTION:
cumin.apnic.net.	172800	IN	A	202.12.29.59
ns-sec.ripe.net.	172800	IN	A	193.0.0.196
ns-sec.ripe.net.	172800	IN	AAAA	2001:610:240:0:53::4
tinnie.apnic.net.	172800	IN	A	202.12.29.60
tinnie.arin.net.	172800	IN	A	69.25.34.195

;; Query time: 187 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Tue Nov 22 13:32:39 2005
;; MSG SIZE  rcvd: 231

; <<>> DiG 9.4.0a2 <<>> @a.gtld-servers.net ns.apnic.net +norec
; (2 servers found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57741
;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5

;; QUESTION SECTION:
;ns.apnic.net.			IN	A

;; ANSWER SECTION:
ns.apnic.net.		172800	IN	A	203.37.255.97

;; AUTHORITY SECTION:
apnic.net.		172800	IN	NS	cumin.apnic.net.
apnic.net.		172800	IN	NS	ns-sec.ripe.net.
apnic.net.		172800	IN	NS	tinnie.apnic.net.
apnic.net.		172800	IN	NS	tinnie.arin.net.

;; ADDITIONAL SECTION:
cumin.apnic.net.	172800	IN	A	202.12.29.59
ns-sec.ripe.net.	172800	IN	A	193.0.0.196
ns-sec.ripe.net.	172800	IN	AAAA	2001:610:240:0:53::4
tinnie.apnic.net.	172800	IN	A	202.12.29.60
tinnie.arin.net.	172800	IN	A	69.25.34.195

;; Query time: 189 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Tue Nov 22 13:32:45 2005
;; MSG SIZE  rcvd: 231

% dig @202.12.29.59 ns.apnic.net +norec

; <<>> DiG 9.4.0a2 <<>> @202.12.29.59 ns.apnic.net +norec
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24435
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ns.apnic.net.			IN	A

;; ANSWER SECTION:
ns.apnic.net.		3600	IN	A	202.12.29.25

;; Query time: 174 msec
;; SERVER: 202.12.29.59#53(202.12.29.59)
;; WHEN: Tue Nov 22 13:33:08 2005
;; MSG SIZE  rcvd: 46
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 22 Nov 2005 16:15:25 +0900

>>>>> On Tue, 22 Nov 2005 16:22:03 +1100,
>>>>> Mark Andrews <[email-masked]> said:

> 	It's a glue record.

Hmm, so the gtld server returns a glue record for which it does not
have the authority in the answer section.  While it does not
necessarily seem invalid according to RFC2181 (which prohibits an
authoritative server from returning an authoritative answer as
non-authoritative data, but doesn't say anything about the content of
the answer section), it's still annoying as we see now...

					JINMEI, Tatuya

---

From: Edward Lewis <[email-masked]>
Date: Tue, 22 Nov 2005 13:53:19 -0500

At 16:15 +0900 11/22/05, JINMEI Tatuya / 
>the answer section), it's still annoying as we see now...

This is something I've personally labelled a "hybrid answer" on the 
namedroppers list.  (Meaning it's my term, no group has vetted it.) 
The expected response in the situation is a referral - everything in 
the response you see but with a ANCOUNT=0 and no records in the 
ANSWER section.  The message is a hybrid referral-cache response.

There is a historical reason for this hybrid.  Smoothing over a ton 
of details, older resolvers were not capable of handling the number 
of "restarts" needed to look up a reverse map (for instance).  By 
slipping in the A record in the hybrid answer, these resolvers were 
able to do reverse map lookups.

There's nothing syntactically wrong with the response.  It is 
possible to see an answer that not authoritative (no AA) without the 
recursion available bit on (no RA).  The semantic is "I've learned 
this for some other reason and I'll tell you, but don't expect me to 
look it up for you otherwise."  In this case, the answer was obtained 
through the registration process.

I'm not surprised that this hybrid isn't covered by specifications, 
it came from an operational observation.  The situation spurring this 
kind of message was a weakness in a software design (not a bug per 
se).  The design weakness has been corrected in later versions of 
software, but, as usual, there's no accounting for some folks' 
failure to upgrade.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

3 months to the next trip.  I guess it's finally time to settle down and
find a grocery store.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Nov 2005 10:47:26 +1100

> able to do reverse map lookups.

	The reason was much simpler than that.  Named (4 and 8)
	only has one database internally to store rdata (both zone
	and cache).  If you had glue it was stored and returned in
	the answer section.  Originally this was with AA set later
	glue was returned with AA cleared.  Named (8) still does
	this if RD is set in the query.

	Atlas followed this model.