Re: Query on ignoring additional section returned in replies

2015-11-18 Thread Mike Hoskins (michoski)
On 11/18/15, 1:19 PM, "bind-users-boun...@lists.isc.org on behalf of Carl Byington" wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >On Wed, 2015-11-18 at 10:47 -0500, Barry Margolin wrote: >> While that's the pedantically correct answer, in practice it doesn't >> work well when your us

Re: Query on ignoring additional section returned in replies

2015-11-18 Thread Barry Margolin
In article , Reindl Harald wrote: > Am 18.11.2015 um 16:47 schrieb Barry Margolin: > > In article , > > Reindl Harald wrote: > > > >> when a result looks like below it needs to be fixed and "Are there any > >> BIND specific workarounds?" is the wrong question becaus even if - the > >> domain

Re: Query on ignoring additional section returned in replies

2015-11-18 Thread Carl Byington
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 2015-11-18 at 10:47 -0500, Barry Margolin wrote: > While that's the pedantically correct answer, in practice it doesn't > work well when your users complain "Google DNS deals with it, why > don't you?" Your users don't care what happens to peop

Re: Query on ignoring additional section returned in replies

2015-11-18 Thread Mike Hoskins (michoski)
On 11/18/15, 10:47 AM, "bind-users-boun...@lists.isc.org on behalf of Barry Margolin" wrote: >In article , > Reindl Harald wrote: > >> when a result looks like below it needs to be fixed and "Are there any >> BIND specific workarounds?" is the wrong question becaus even if - the >> domain owner

Re: Query on ignoring additional section returned in replies

2015-11-18 Thread Reindl Harald
Am 18.11.2015 um 16:47 schrieb Barry Margolin: In article , Reindl Harald wrote: when a result looks like below it needs to be fixed and "Are there any BIND specific workarounds?" is the wrong question becaus even if - the domain owner is not in the position to place workarounds somewhere

Re: Query on ignoring additional section returned in replies

2015-11-18 Thread Barry Margolin
In article , Reindl Harald wrote: > when a result looks like below it needs to be fixed and "Are there any > BIND specific workarounds?" is the wrong question becaus even if - the > domain owner is not in the position to place workarounds somewhere else While that's the pedantically correct a

Re: Query on ignoring additional section returned in replies

2015-11-18 Thread Reindl Harald
Am 18.11.2015 um 12:34 schrieb Mark Andrews: In message <5b818b25da9e40ebbff0e3d6dfec1...@pvsvrexc06.ad.tmres.my>, Elias Ahm ed Kamal writes: Even with a broken delegation its like always resolvable with Google DNS or= even Open DNS. Are there any BIND specific workarounds? The other name

Re: Query on ignoring additional section returned in replies

2015-11-18 Thread Mark Andrews
: bind-users@lists.isc.org > Subject: Re: Query on ignoring additional section returned in replies > > > In message <659dec986e9347369634488991f6e...@pvsvrexc06.ad.tmres.my>, Elias= > Ahm ed Kamal writes: > > Hi guys, > > > > I'm having issues resolving

RE: Query on ignoring additional section returned in replies

2015-11-18 Thread Bob McDonald
Is this hosted on some sort of load-balancer? Add a +norecurse to your dig and see how that changes things. Regards, Bob ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-use

RE: Query on ignoring additional section returned in replies

2015-11-18 Thread Elias Ahmed Kamal
Subject: Re: Query on ignoring additional section returned in replies In message <659dec986e9347369634488991f6e...@pvsvrexc06.ad.tmres.my>, Elias Ahm ed Kamal writes: > Hi guys, > > I'm having issues resolving www.fis.com.my. I'm trying to tell > fis.com.my tha t it

Re: Query on ignoring additional section returned in replies

2015-11-18 Thread Mark Andrews
In message <659dec986e9347369634488991f6e...@pvsvrexc06.ad.tmres.my>, Elias Ahm ed Kamal writes: > Hi guys, > > I'm having issues resolving www.fis.com.my. I'm trying to tell fis.com.my tha > t its an issue at their end, but when checking against 8.8.8.8 it resolves fi > neso it MUST be a pro