DNS Resolution Failure - FORMERR

Mark Andrews Mark_Andrews at isc.org
Wed May 6 01:44:48 UTC 2009


In message <4A00C706.5060609 at chrysler.com>, Kevin Darcy writes:
> 
> Eric Swenson wrote:
> > I apologize for the multiple posts. I didn't think my post was making 
> > it to the list since I never received my own post, but have been 
> > receiving those of others.  And yes, I'm configured to see my own posts.
> >
> > A couple people have suggested I look at the trace output of bind to 
> > see what server is sending the bad response.  I provide some of the 
> > trace output below.  I certainly don't see anything amiss, and one of 
> > the servers that appears to provoke the FORMERR seems to have 
> > responded just fine.  Here is relevant output (with some stuff deleted 
> > due to verbosity):
> >
> > 05-May-2009 10:49:14.943 dispatch 0x8144b90 response 0x81476b8 
> > 192.228.79.201#53: attached to task 0x80ed240
> > 05-May-2009 10:49:14.945 resquery 0x8152c70 (fctx 
> > 0x812f170(imap.gmail.com/A) <http://imap.gmail.com/A%29>): sent
> > 05-May-2009 10:49:14.945 resquery 0x8152c70 (fctx 
> > 0x812f170(imap.gmail.com/A) <http://imap.gmail.com/A%29>): senddone
> > 05-May-2009 10:49:14.945 dispatch 0x8149a70: got packet: requests 0, 
> > buffers 2, recvs 1
> > 05-May-2009 10:49:14.945 dispatch 0x8149a70: shutting down; detaching 
> > from sock 0x81418f0, task 0x8141a20
> > 05-May-2009 10:49:14.965 socket 0x8141460 192.228.79.201#53: packet 
> > received correctly
> > 05-May-2009 10:49:14.966 dispatch 0x8144b90: got packet: requests 1, 
> > buffers 1, recvs 1
> > 05-May-2009 10:49:14.966 dispatch 0x8144b90: got valid DNS message 
> > header, /QR 1, id 47066
> > 05-May-2009 10:49:14.966 resquery 0x8152c70 (fctx 
> > 0x812f170(imap.gmail.com/A) <http://imap.gmail.com/A%29>): response
> > 05-May-2009 10:49:14.967 received packet:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  47066
> > ;; flags: qr rd ra ; QUESTION: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4
> > ;; QUESTION SECTION:
> > ;imap.gmail.com <http://imap.gmail.com>. IN A
> >
> > ;; ANSWER SECTION:
> > imap.gmail.com <http://imap.gmail.com>. 241 IN CNAME 
> > gmail-imap.l.google.com <http://gmail-imap.l.google.com>.
> > gmail-imap.l.google.com <http://gmail-imap.l.google.com>. 241 IN A 
> > 209.85.201.111
> > gmail-imap.l.google.com <http://gmail-imap.l.google.com>. 241 IN A 
> > 209.85.201.109
> >
> > ;; AUTHORITY SECTION:
> > gmail.com <http://gmail.com>. 76384 IN NS ns4.google.com 
> > <http://ns4.google.com>.
> > gmail.com <http://gmail.com>. 76384 IN NS ns1.google.com 
> > <http://ns1.google.com>.
> > gmail.com <http://gmail.com>. 76384 IN NS ns2.google.com 
> > <http://ns2.google.com>.
> > gmail.com <http://gmail.com>. 76384 IN NS ns3.google.com 
> > <http://ns3.google.com>.
> >
> > ;; ADDITIONAL SECTION:
> > ns4.google.com <http://ns4.google.com>. 77136 IN A 216.239.38.10
> > ns1.google.com <http://ns1.google.com>. 77136 IN A 216.239.32.10
> > ns2.google.com <http://ns2.google.com>. 77136 IN A 216.239.34.10
> > ns3.google.com <http://ns3.google.com>. 77136 IN A 216.239.36.10
> This is a little suspect. Usually when you have a CNAME and A records in 
> the Answer Section, the Authority Section contains NS records for the 
> zone containing the A record (in this case, gmail-imap.l.google.com). 
> Here, however, the Authority Section contains NS records for the zone 
> containing the CNAME itself (imap.gmail.com). Odd. When I query the 
> name, I get the l.google.com NS records in Authority.

	An iterative resolver will not work well with a "transparent"
	dns cache.  The answer above nominally came from 192.228.79.201
	(b.root-servers.net).  It should have been something like this.

bsdi# dig gmail-imap.l.google.com +norec @192.228.79.201

; <<>> DiG 8.3 <<>> gmail-imap.l.google.com +norec @192.228.79.201 
; (1 server found)
;; res options: init defnam dnsrch no-tld-query edns0
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44866
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 16
;; QUERY SECTION:
;;      gmail-imap.l.google.com, type = A, class = IN

;; AUTHORITY SECTION:
com.                    2D IN NS        K.GTLD-SERVERS.NET.
com.                    2D IN NS        L.GTLD-SERVERS.NET.
com.                    2D IN NS        M.GTLD-SERVERS.NET.
com.                    2D IN NS        A.GTLD-SERVERS.NET.
com.                    2D IN NS        B.GTLD-SERVERS.NET.
com.                    2D IN NS        C.GTLD-SERVERS.NET.
com.                    2D IN NS        D.GTLD-SERVERS.NET.
com.                    2D IN NS        E.GTLD-SERVERS.NET.
com.                    2D IN NS        F.GTLD-SERVERS.NET.
com.                    2D IN NS        G.GTLD-SERVERS.NET.
com.                    2D IN NS        H.GTLD-SERVERS.NET.
com.                    2D IN NS        I.GTLD-SERVERS.NET.
com.                    2D IN NS        J.GTLD-SERVERS.NET.

;; ADDITIONAL SECTION:
A.GTLD-SERVERS.NET.     2D IN A         192.5.6.30
B.GTLD-SERVERS.NET.     2D IN A         192.33.14.30
C.GTLD-SERVERS.NET.     2D IN A         192.26.92.30
D.GTLD-SERVERS.NET.     2D IN A         192.31.80.30
E.GTLD-SERVERS.NET.     2D IN A         192.12.94.30
F.GTLD-SERVERS.NET.     2D IN A         192.35.51.30
G.GTLD-SERVERS.NET.     2D IN A         192.42.93.30
H.GTLD-SERVERS.NET.     2D IN A         192.54.112.30
I.GTLD-SERVERS.NET.     2D IN A         192.43.172.30
J.GTLD-SERVERS.NET.     2D IN A         192.48.79.30
K.GTLD-SERVERS.NET.     2D IN A         192.52.178.30
L.GTLD-SERVERS.NET.     2D IN A         192.41.162.30
M.GTLD-SERVERS.NET.     2D IN A         192.55.83.30
A.GTLD-SERVERS.NET.     2D IN AAAA      2001:503:a83e::2:30
B.GTLD-SERVERS.NET.     2D IN AAAA      2001:503:231d::2:30
; EDNS: version: 0, udp=4096, flags=0000

;; Total query time: 192 msec
;; FROM: bsdi.dv.isc.org to SERVER: 192.228.79.201
;; WHEN: Wed May  6 11:38:02 2009
;; MSG SIZE  sent: 52  rcvd: 540

bsdi# 

> I'm not sure, however, that this anomaly alone is sufficient to cause 
> problems.

	It is sufficient as the answer is malformed.  Why to people
	sell DNS products without looking a the RFC's?

	You need to findout if the transparent cache is in your
	equipement or further out into then network and get it
	turned off.

	Mark

> > 05-May-2009 10:49:14.967 fctx 0x812f170(imap.gmail.com/A' 
> > <http://imap.gmail.com/A%27>): answer_response
> > 05-May-2009 10:49:14.968 fctx 0x812f170(imap.gmail.com/A' 
> > <http://imap.gmail.com/A%27>): noanswer_response
> > 05-May-2009 10:49:14.968 fctx 0x812f170(imap.gmail.com/A' 
> > <http://imap.gmail.com/A%27>): cancelquery
> > 05-May-2009 10:49:14.968 dispatch 0x8144b90 response 0x81476b8 
> > 192.228.79.201#53: detaching from task 0x80ed240
> > 05-May-2009 10:49:14.968 dispatch 0x8144b90: detach: refcount 0
> > 05-May-2009 10:49:14.968 fctx 0x812f170(imap.gmail.com/A' 
> > <http://imap.gmail.com/A%27>): add_bad
> > 05-May-2009 10:49:14.969 FORMERR resolving 'imap.gmail.com/A/IN 
> > <http://imap.gmail.com/A/IN>': 192.228.79.201#53
> >
> > Does this trace output suggest what is going wrong?  -- Eric
> >
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org



More information about the bind-users mailing list