Bind unable to get MX reocrd from Parrent name server

Fri Jul 5 14:11:53 UTC 2013

The other DNS server software is working around or ignoring
the issues.  Server software varies in how much it ignores or
works around bad domain setups.  Also, in some situations,
configuration problems result in symptoms that come and go.

One reason DNS software is picky about correct setups is security:
ignoring some configuration issues increases the chance
of passing along bad, possibly malicious answers.  Bind is
apparently pickier than some other DNS server software.
I have to believe some public resolvers have considerable extra
logic to try to "partially validate" and use domains that
are incorrectly set up.

The ideal way to fix the issue is to get the owner of
the domain to fix it.

John
Cornell University IT

On Jul 5, 2013, at 7:59 AM, Fosiul Alam wrote:

> Hi
> thanks for reply,
> I am not the domain admin for "rbcaa.co.za"
> I can see they have issue with their domain setup .
> but what I want to know is :
> when all Dns server can resolved their mx record example ,
> mxtoolbox,introdns,google .. (Despite they have issue with their dns
> setup for that domain (as you said) ) then why we cant ??
>
> Thanks for looking into it .
>
> On Fri, Jul 5, 2013 at 12:45 PM, Steven Carr <sjcarr at gmail.com> wrote:
>> Your glue is broken. You need to update the glue NS records in the
>> parent to reflect the actual nameservers that are authoritative for
>> the zone.
>>
>> It also looks like you could have some data mismatch between zones
>> hosted on (ns1.yithosting.co.za + ns2.yithosting.co.za) and
>> (demeter.is.co.za + babylon.mitsol.co.za). Check that the zone data  
>> is
>> consistent across the nameservers.
>>
>> Steve
>>
>> On 5 July 2013 12:35, Fosiul Alam <fosiul at gmail.com> wrote:
>>> Hi
>>> Occasionally we see customer is complainning that we are not able to
>>> resolve mx record when mxtoolbox or other website can resolve  
>>> their mx
>>> record .
>>> If i do a trace on the domain, i get bellow .
>>>
>>> now the problem is :
>>> demeter.is.co.za. and babylon.mitsol.co.za does not know anything
>>> about MX record of that domain. but if i query by using  parent name
>>> server ns1.yithosting.co.za. and ns2.yithosting.co.za , it returns  
>>> the
>>> mx record .
>>>
>>> but mxtoolbox, introdns can resolve the mx record although they
>>> complain the same that
>>>
>>> """"
>>> The following nameservers are listed at your nameservers as
>>> nameservers for your domain, but are not listed at the parent
>>> nameservers (see RFC2181 5.4.1). You need to make sure that these
>>> nameservers are working.If they are not working ok, you may have
>>> problems!
>>> demeter.is.co.za
>>> babylon.mitsol.co.za
>>>
>>> ERROR: One or more of the nameservers listed at the parent servers  
>>> are
>>> not listed as NS records at your nameservers. The problem NS records
>>> are:
>>> ns1.yithosting.co.za
>>> ns2.yithosting.co.za
>>> This is listed as an ERROR because there are some cases where nasty
>>> problems can occur (if the TTLs vary from the NS records at the root
>>> servers and the NS records point to your own domain, for example).
>>> ""
>>>
>>> then why our bind is unable to resolve mx record ???
>>> Thanks for the  help
>>>
>>>
>>> [root at za-ns-8 ~]# dig  rbcaa.co.za +trace
>>>
>>> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> rbcaa.co.za  
>>> +trace
>>> ;; global options: +cmd
>>> . 447499 IN NS a.root-servers.net.
>>> . 447499 IN NS j.root-servers.net.
>>> . 447499 IN NS l.root-servers.net.
>>> . 447499 IN NS d.root-servers.net.
>>> . 447499 IN NS k.root-servers.net.
>>> . 447499 IN NS g.root-servers.net.
>>> . 447499 IN NS i.root-servers.net.
>>> . 447499 IN NS h.root-servers.net.
>>> . 447499 IN NS m.root-servers.net.
>>> . 447499 IN NS c.root-servers.net.
>>> . 447499 IN NS f.root-servers.net.
>>> . 447499 IN NS e.root-servers.net.
>>> . 447499 IN NS b.root-servers.net.
>>> ;; Received 508 bytes from 10.33.91.35#53(10.33.91.35) in 14 ms
>>>
>>> za. 172800 IN NS za1.dnsnode.net.
>>> za. 172800 IN NS disa.tenet.ac.za.
>>> za. 172800 IN NS nsza.is.co.za.
>>> za. 172800 IN NS za-ns.anycast.pch.net.
>>> za. 172800 IN NS sns-pb.isc.org.
>>> ;; Received 360 bytes from 199.7.83.42#53(199.7.83.42) in 346 ms
>>>
>>> co.za. 86400 IN NS ns0.plig.net.
>>> co.za. 86400 IN NS ns.coza.net.za.
>>> co.za. 86400 IN NS ns0.neotel.co.za.
>>> co.za. 86400 IN NS ns1.coza.net.za.
>>> co.za. 86400 IN NS coza1.dnsnode.net.
>>> co.za. 86400 IN NS ns0.is.co.za.
>>> co.za. 86400 IN NS ns4.iafrica.com.
>>> ;; Received 266 bytes from 196.4.160.27#53(196.4.160.27) in 285 ms
>>>
>>> rbcaa.co.za. 86400 IN NS ns1.yithosting.co.za.
>>> rbcaa.co.za. 86400 IN NS ns2.yithosting.co.za.
>>> ;; Received 108 bytes from 196.4.160.17#53(196.4.160.17) in 81 ms
>>>
>>> rbcaa.co.za. 14400 IN A 41.203.1.156
>>> rbcaa.co.za. 86400 IN NS demeter.is.co.za.
>>> rbcaa.co.za. 86400 IN NS babylon.mitsol.co.za.
>>> ;; Received 99 bytes from 41.203.1.158#53(41.203.1.158) in 41 ms
>>> _______________________________________________
>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to  
>>> unsubscribe from this list
>>>
>>> bind-users mailing list
>>> bind-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
> -- 
> Regards
> Fosiul Alam
> 07877100621
> http://www.fosiul.co.uk
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to  
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>