Cannot get ip address of mx record kienhwa.hk

[Mark Andrews]

> First, if you can avoid it, don't use nslookup. It's misleading and  
> silly. Use dig instead - if you want dig for windows, download the  
> BIND for Windows binary package. (If you don't want to use the  
> installer, just drag the executable to a handy location. You'll also  
> need a library; when you try to run it, it will tell you which  
> library is missing.)
> 
> In this case, the two name servers for kienhwa.hk have different  
> copies of the zone. The name servers appear to be load balancers,  
> rather than something full-featured like BIND. fpdns.pl can't  
> identify them, at least not from my location.
> 
> The relevant records are as follows:
> 
> kienhwa.hk.             0       IN      MX      10 kienhwa.hk.
> kienhwa.hk.             0       IN      A       202.134.124.67
> kienhwa.hk.             0       IN      A       202.134.124.67
> 
> Each name server reports a different A record, and neither puts the A  
> record in the Additional section of the response. This, along with  
> the 0 TTL's, may be what's tripping up your BIND server - it gets the  
> MX record, looks up the A record, and then no longer has the MX  
> record. Or something like that. I know very old versions of BIND had  
> trouble with 0 TTL's, but I know that was at least largely fixed a  
> long time ago.
> 
> BIND 9 should have no trouble with this, though. So the solution is  
> probably going to be to upgrade BIND. This may not be a trivial  
> undertaking, depending on your situation, but it's pretty important  
> for a variety of reasons. BIND 8 should no longer be used for most  
> purposes.
> 
> Chris Buxton
> Men & Mice

	Well as Peter pointed out.  Lying in answers to any queries
	doesn't help.  Note "aa" is set.  This response says that
	there are NO records at the name which is clearly incorrect.

	The correct response should have had SOA, NS, MX and A
	records in the answer section as we can see these in the
	various responses it returns for other queries.

	RFC are written so that software will interoperate correctly.
	Failure to follow the RFCs leads to all sorts of problems.
	In this case the nameservers are clearly not RFC compliant
	and the original poster should just give up trying to talk
	to this site as it is well and truly broken.

	Bcc: barry at ouser.com (so he will see there is a problem with
	the nameservers but not need the followups).

	Barry. FIX YOUR NAMESERVERS!!!!!!!!

	Mark

; <<>> DiG 9.3.2 <<>> any kienhwa.hk @NS1.OGDNS.COM
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8971
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;kienhwa.hk.			IN	ANY

;; AUTHORITY SECTION:
kienhwa.hk.		1800	IN	SOA	NS1.OGDNS.COM. NS1.OGDNS.COM. 1 10800 3600 86400 0

;; Query time: 411 msec
;; SERVER: 202.134.124.66#53(202.134.124.66)
;; WHEN: Wed Aug  9 09:56:30 2006
;; MSG SIZE  rcvd: 90

> On Aug 7, 2006, at 9:49 PM, Alex Tang wrote:
> 
> > Hi All
> >
> > Sometimes my user cannot send email to kienhwa.hk. I find out that  
> > the dns server cannot get the ip address of the mx record at the  
> > same time.
> >
> >> set q=mx
> >> kienhwa.hk
> > Server:         dns
> > Address:
> >
> > kienhwa.hk      mail exchanger = 10 kienhwa.hk.
> >
> > but I can get the ip address of the mx by enter the host name only
> >
> >> set q=a
> >> kienhwa.hk
> > Server:         dns
> > Address:
> >
> > Name:   kienhwa.hk
> > Address: 202.134.124.67
> >
> > also the ttl of the domain is 0
> >
> >> set q=soa
> >         origin = NS1.OGDNS.COM
> >         mail addr = NS1.OGDNS.COM
> >         serial = 1
> >         refresh = 10800
> >         retry = 3600
> >         expire = 86400
> >         minimum = 0
> >
> > What cause the problem ?
> > My bind version is 8.3.7
> >
> > Help Help
> >
> > Thx
> >
> >
> >
> 
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org