Resolving problems

Mark_Andrews at isc.org Mark_Andrews at isc.org
Thu Apr 4 07:11:07 UTC 2002


> 
> > 
> > We observe similar problems trying to resolve mx-records for
> > mma-architects.co.uk (involving same authoritative name servers as
> > were mentioned in this thread already).
> > Strangely enough (for me) bind version 8.2.3 deals ok with that
> > map?.dns.gxn.net servers.
> > 
> > Simon Waters <Simon at wretched.demon.co.uk> wrote in message news:<a6sq8m$dc
> u@
> > pub3.rc.vix.com>...
> > > Re: Problems e-mailing anchorvans.co.uk
> > > 
> > > Nate Campi wrote:
> > >  
> > > > It doesn't look like corrupted cache, but BIND tossing the oversized
> > > > response entirely:
> > > 
> > > I was guessing as he said it worked first time, then failed.
> > >  
> > > >  $ dig  @map1.dns.gxn.net anchorvans.co.uk any
> > > > 
> > > >  ; <<>> DiG 8.3 <<>> @map1.dns.gxn.net anchorvans.co.uk any
> > > 
> > > The problem I saw with "dig" showing a packet dump is fixed in
> > > 9.2.1rc1.
> > > 
> > > Now it spits an error saying the truncated packet looks suspect,
> > > and succeeds in retrieving the packet using TCP. This is
> > > consistent with the changelog for BIND 9.2.1rc1.
> > > 
> > > Didn't Dan comment on the format of the truncation not being
> > > well defined in the standards.
> > > 
> > > > It would appear that an MTA doing ANY queries to get the MX info for
> > > > anchorvans.co.uk would be out of luck. Since this is standard for MTAs
> ,
> > > > I'd say anchorvans.co.uk is missing out on a lot of mail.
> > > 
> > > Hmm, well it can't be helping the reliability of their e-mail,
> > > especially given the number of people who mistakenly block TCP
> > > on port 53.
> > 
> > --
> > Andrey Alekseyev.  Zenon N.S.P., Moscow, Russian Federation
> > Senior Unix systems administrator
> > 
> 
> 	It really would help if the server didn't *lie* when it gets
> 	a EDNS style query.  The answer below says that there are
> 	no MX records for mma-architects.co.uk.
> 
> 	Mark
> 
> ; <<>> DiG 9.2.1rc2 <<>> mx mma-architects.co.uk @map4.dns.gxn.net +bufsize=
> 2049
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 666
> ;; flags: qr aa rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; Query time: 366 msec
> ;; SERVER: 195.224.255.34#53(map4.dns.gxn.net)
> ;; WHEN: Thu Apr  4 16:06:35 2002
> ;; MSG SIZE  rcvd: 12

	It would be better still if the ID in the response matched the query
	instead of being fixed at 666.  At least that way the servers wouldn't
	have to timeout.  I suppose there is a saving grace that the id is
	wrong.  The caching servers will treat it as a late response to a
	previous query and not cache it (provided they didn't use 666 in the
	original query).

	Mark

; <<>> DiG 9.2.1rc2 <<>> mx mma-architects.co.uk @map4.dns.gxn.net +bufsize=512 +qr
;; global options:  printcmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34430
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mma-architects.co.uk.		IN	MX

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 666
;; flags: qr aa rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; Query time: 401 msec
;; SERVER: 195.224.255.34#53(map4.dns.gxn.net)
;; WHEN: Thu Apr  4 17:00:13 2002
;; MSG SIZE  rcvd: 12

> 
> --
> Mark Andrews, Internet Software Consortium
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org
--
Mark Andrews, Internet Software Consortium
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