In message <4a00c706.5060...@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_andr...@isc.org
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
