Re: Problem resolving a domain

Am 13.05.22 um 15:16 schrieb Rainer Duffner: Thanks for the hints! It does indeed work with these settings. The problem is also that google and quad9 and most of the rest of the internet seem to be able to resolve it the real problem is that they are working around it - if not the stupid

Re: Problem resolving a domain

> The problem is also that google and quad9 and most of the rest of the > internet seem to be able to resolve it. Yes, that’s **the problem**. There’s no pressure to get Barclays to fix this. If you are a customer, complain loudly. Advice your customers who are customers to complain loudly. Th

Re: Problem resolving a domain

Hi, Thanks for the hints! It does indeed work with these settings. The problem is also that google and quad9 and most of the rest of the internet seem to be able to resolve it. While I investigated this issue, I came around a posting from one or two years ago where similar problems with Ba

Re: Problem resolving a domain

; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> >>> +timeout +retries IN A myapplication.glbaa.barclays.com. @ >>> ns21.barclays.com. >>> ;; global options: +cmd >>> ;; connection timed out; no servers could be reached &

Re: Problem resolving a domain

bian10~1.gbpa71ef8-Debian <<>> +timeout >>> +retries IN A myapplication.glbaa.barclays.com. @ns21.barclays.com. >>> ;; global options: +cmd >>> ;; connection timed out; no servers could be reached >>> >>> >>> DNSVIZ gives the same

Re: Problem resolving a domain

m/dnssec/ >> >> • glbaa.barclays.com zone: The server(s) were not responsive to >> queries over UDP. (157.83.102.245, 157.83.102.246, 157.83.126.245, >> 157.83.126.246) >> >> Ondrej >> -- >> Ondřej Surý (He/Him) >> ond...@isc.org >> >

Re: Problem resolving a domain

245, > 157.83.126.246) > > Ondrej > -- > Ondřej Surý (He/Him) > ond...@isc.org > > My working hours and your working hours may be different. Please do not > feel obligated to reply outside your normal working hours. > > > On 13. 5. 2022, at 13:54, Rainer Duffner

Re: Problem resolving a domain

2022, at 13:54, Rainer Duffner wrote: > > Hi, > > at work, I have a problem resolving the following domain: > > myapplication.international.barclays.com > > > BIND 9.16.27, FreeBSD 12.3-P5. > 2022Q2 ports. > > > I copied the config to a VM at home - but

Problem resolving a domain

Hi, at work, I have a problem resolving the following domain: myapplication.international.barclays.com BIND 9.16.27, FreeBSD 12.3-P5. 2022Q2 ports. I copied the config to a VM at home - but it did not work there, either. I believe it must have happened on the update from BIND 9.16.26 to

Re: Problem resolving

Hi Danilo, there’s a misconfiguration on the verisigndns.com side (already reported to Verisign), where ftp.rs.verisigndns.com is delegated (e.g. there’s the zonecut), but the child servers are configured as authoritative for rs.verisigndns.com. If there was just a query for A record, it wouldn

Problem resolving

Hello, I recently stumbled upon a problem trying to update my root hints file from *ftp.rs.internic.net*. For some reason, one of my DNS servers running on Alpine Linux, can't resolve this name properly and always fails: # ping ftp.rs.internic.net ping: ftp.rs.internic.net: Try again nslookup s

Re: Problem resolving domain

Both servers are broken. One fails to implement DNS COOKIE (RFC 7873) correctly. Note that the "Client COOKIE mismatch" is reported. Named rejects the response because the client cookie does not match that sent to the server. The response looks like someone trying to spoof the response. The o

Re: Problem resolving domain

On Mon, Jan 27, 2020 at 10:27 AM Stephan von Krawczynski wrote: > > Hello all, > > I ran across a question I did not really expect. I am using bind 9.14.1 as > normal, standalone nameserver. When trying to resolve a certain domain I get a > SERVFAIL (with nslookup). Deeper inspection of the proble

Re: Problem resolving domain

On Mon, 27 Jan 2020 16:36:42 +0100 Anand Buddhdev wrote: > On 27/01/2020 16:26, Stephan von Krawczynski wrote: > > Hi Stephan, > > > I would have expected that bind finds the domain by using the working > > nameserver and ignoring the dead one. But obviously it does not. > > Did I misconfigure

Re: Problem resolving domain

In article , Stephan von Krawczynski wrote: > Hello all, > > I ran across a question I did not really expect. I am using bind 9.14.1 as > normal, standalone nameserver. When trying to resolve a certain domain I get a > SERVFAIL (with nslookup). Deeper inspection of the problem shows that the >

RE: Problem resolving domain

n letting it answer incorrectly. -Original Message- From: bind-users On Behalf Of Stephan von Krawczynski Sent: Monday, January 27, 2020 10:27 AM To: bind-us...@isc.org Subject: Problem resolving domain Hello all, I ran across a question I did not really expect. I am using bind 9.14.1 as

Re: Problem resolving domain

Am 27.01.20 um 16:26 schrieb Stephan von Krawczynski: > I ran across a question I did not really expect. I am using bind 9.14.1 as > normal, standalone nameserver. When trying to resolve a certain domain I get a > SERVFAIL (with nslookup). Deeper inspection of the problem shows that the > domain

Re: Problem resolving domain

On 27/01/2020 16:26, Stephan von Krawczynski wrote: Hi Stephan, > I would have expected that bind finds the domain by using the working > nameserver and ignoring the dead one. But obviously it does not. > Did I misconfigure something? I thought both nameservers should be questioned > and the firs

Problem resolving domain

Hello all, I ran across a question I did not really expect. I am using bind 9.14.1 as normal, standalone nameserver. When trying to resolve a certain domain I get a SERVFAIL (with nslookup). Deeper inspection of the problem shows that the domain uses 2 nameservers, where one works perfectly well,

Re: problem resolving ardownload.adobe.com

FWIW, I ran into this issue with www.elevationsbanking.com as well. The setup was very similar, the record resolved to a CNAME which in turn resolved to another CNAME. When the TTL expired on the CNAME the record would revert to NXDOMAIN. It wasn’t until the TTL expired for the SOA that things

Re: problem resolving ardownload.adobe.com

In article , Mark Andrews wrote: > > The adobe servers are just plain broken. > > Request a CNAME -> NXDOMAIN (Should return CNAME record) > Request a TXT -> NXDOMAIN (Should return CNAME record) > Request a NS -> NXDOMAIN (Should return CNAME record) > Add a EDNS optio

Re: problem resolving ardownload.adobe.com

The adobe servers are just plain broken. Request a CNAME -> NXDOMAIN (Should return CNAME record) Request a TXT -> NXDOMAIN (Should return CNAME record) Request a NS -> NXDOMAIN (Should return CNAME record) Add a EDNS option -> NXDOMAIN (Should return CNAME record)

Re: problem resolving ardownload.adobe.com

On Wed, Jul 2, 2014 at 2:51 PM, Carl Byington wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > version: 9.10.0-P2 > > dig ardownload.adobe.com. @localhost > > ;; ANSWER SECTION: > ardownload.adobe.com. 8743IN CNAME ardownload.wip4.adobe.com. > > What is the rest of the dig ou

Re: problem resolving ardownload.adobe.com --enable-sit harmful?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 2014-07-04 at 09:41 +1000, Mark Andrews wrote: > Until Adobe fix their broken servers you can use a server clause to > disable sending SIT requests to them. Obviously this does not scale. > server { request-sit no; }; Thanks. That

Re: problem resolving ardownload.adobe.com --enable-sit harmful?

I suggest that you log a complaint with Adobe requesting that they contact their nameserver vendor for a fix. This bug is similar in nature to that of http://www.kb.cert.org/vuls/id/714121 (NXDOMAIN incorrectly returned to a query). Unknown EDNS options are supposed to be ignored by the nam

Re: problem resolving ardownload.adobe.com --enable-sit harmful?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I re-ran the dig to localhost (running bind 9.10.0-P2), and grabbed the packets with tcpdump. dig ardownload.adobe.com. @localhost That sent a query to 192.150.19.247 with flags = 0, edns size = 512, and got an NXDOMAIN answer. So I tried to reproduc

problem resolving ardownload.adobe.com

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 version: 9.10.0-P2 dig ardownload.adobe.com. @localhost ;; ANSWER SECTION: ardownload.adobe.com. 8743IN CNAME ardownload.wip4.adobe.com. dig ardownload.adobe.com. @8.8.8.8 ;; ANSWER SECTION: ardownload.adobe.com. 4141IN CNAME ard

Re: Problem resolving my google country domain from certain servers

In article , Carlos R Laguna wrote: > I am facing some issue with all my dns cache, Bind version 9.7.3 the are > all behind a nat, and all seem to work fine except www.google.com.cu i > try to resolve using nslookup or dig http://paste.desdelinux.net/4883 > but got nothing out of it, any light o

Problem resolving my google country domain from certain servers

I am facing some issue with all my dns cache, Bind version 9.7.3 the are all behind a nat, and all seem to work fine except www.google.com.cu i try to resolve using nslookup or dig http://paste.desdelinux.net/4883 but got nothing out of it, any light over this will be really appreciated, i can send

Re: Problem resolving one particular domain

In message <4e2fea67.7080...@agenda.si>, Danilo Godec writes: > On 07/27/2011 10:31 AM, Stephane Bortzmeyer wrote: > > On Wed, Jul 27, 2011 at 09:59:32AM +0200, > > Danilo Godec wrote > > a message of 247 lines which said: > > > >> Weirdness number 2 - using dig directly with their servers wo

Re: Problem resolving one particular domain

On Wed, Jul 27, 2011 at 10:31:30AM +0200, Stephane Bortzmeyer wrote a message of 34 lines which said: > 1) It means you are vulnerable to Kaminsky-style cache poisoning. In > 2011, 'query-source port 53;' should have disappeared a long time > ago. For the record, there are still around 1 % of

Re: Problem resolving one particular domain

On 07/27/2011 10:31 AM, Stephane Bortzmeyer wrote: On Wed, Jul 27, 2011 at 09:59:32AM +0200, Danilo Godec wrote a message of 247 lines which said: Weirdness number 2 - using dig directly with their servers works: Nothing weird here: dig does not behave like the BIND resolver. It does not

Re: Problem resolving one particular domain

On Wed, Jul 27, 2011 at 09:59:32AM +0200, Danilo Godec wrote a message of 247 lines which said: > Weirdness number 2 - using dig directly with their servers works: Nothing weird here: dig does not behave like the BIND resolver. It does not use EDNS at all by default, it does not use the same

Problem resolving one particular domain

Hi, I'm running three DNS servers (1 master, 2 slaves) running bind 9.7.3, hosting about 150 domains, while also providing DNS service for my network. Recently a customer complained that they cannot send an email (they use my SMTP server) to a specific domain 'rabobank.com' - Postfix logged

Re: Problem resolving CNAME in BIND 9.8.0 and 9.8.0-P2

On 06/10/11 09:50, Per-Olof Axelsson wrote: When I run the following dig command below I sometimes get different answers, generally 20-30 minutes after restarting BIND. It doesn't matter if I run dig from a remote host or locally on the problematic DNS server. The two servers in question run on

Re: Problem resolving CNAME in BIND 9.8.0 and 9.8.0-P2

On 6/10/2011 8:36 AM, Phil Mayers wrote: It was fixed in 9.8.1, or you can apply the patch that the FreeBSD guys have: http://www.freebsd.org/cgi/cvsweb.cgi/ports/dns/bind98/files/patch-bin__named__query.c?rev=1.1 I can't take credit for that, it came from Mark. :) -- Nothin' ever do

Re: Problem resolving CNAME in BIND 9.8.0 and 9.8.0-P2

Phil Mayers wrote: > > This might be the problem resolving CNAMEs that was discussed on the list > recently: > > https://lists.isc.org/pipermail/bind-users/2011-May/thread.html#83714 > > "Bind 9.8.0 intermittent problem with non-recursive responses" > > It

Re: Problem resolving CNAME in BIND 9.8.0 and 9.8.0-P2

On 10/06/11 15:50, Per-Olof Axelsson wrote: When I run the following dig command below I sometimes get different answers, generally 20-30 minutes after restarting BIND. It doesn't This might be the problem resolving CNAMEs that was discussed on the list recently: https://lists.is

Problem resolving CNAME in BIND 9.8.0 and 9.8.0-P2

When I run the following dig command below I sometimes get different answers, generally 20-30 minutes after restarting BIND. It doesn't matter if I run dig from a remote host or locally on the problematic DNS server. The two servers in question run on entirely different hardware and operating sy

Re: Problem resolving domains with valid GLUE records but misconfigured NS records

Well, the zone is publishing NS records that all return REFUSED when I query them, so from my point of view the whole domain is broken. The *best* approach here is to contact the domain admin and get them to fix it. In the absence of that, how to circumvent it? ns1.ecb.int apparently doesn't

Re: Problem resolving domains with valid GLUE records but misconfigured NS records

In message <4b9fad0c.1090...@um.edu.mt>, Gilbert Cassar writes: > Hi, > > We have a recurring problem with recursive domain resolution using a > bind 9.6 caching server. An example of such a zone is ecb.eu. The > problem seems due to a misconfiguration on their side where all the > (supposedl

Problem resolving domains with valid GLUE records but misconfigured NS records

Hi, We have a recurring problem with recursive domain resolution using a bind 9.6 caching server. An example of such a zone is ecb.eu. The problem seems due to a misconfiguration on their side where all the (supposedly authorative) NS records listed in their zone file do not answer requests

Re: problem resolving domains with bind9.5.0-P2

Based on the answer size for the query you presented, I'd focus on looking for an upstream filter/device that is blocking answers that are > 512 bytes. On Wed, Sep 9, 2009 at 5:34 AM, Matthias Brehm wrote: > Dear all, > > > > we use bind9.5.0-P2 for the internet dns server. > > Sometimes we get

Re: problem resolving domains with bind9.5.0-P2

> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34869 While it doesn't help you with your 9.5.0-P2 version, BIND 9.6.1 and newer provide a new query-errors logging category that can be helpful by logging details about various errors. ___ bind-us

problem resolving domains with bind9.5.0-P2

Dear all, we use bind9.5.0-P2 for the internet dns server. Sometimes we get no response for some domains, like this: ; <<>> DiG 9.3.2 <<>> cluster3.eu.messagelabs.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34869 ;; flags: qr rd

Re: Problem resolving "www.lmsintl.com"

Apisa, Kathy (US - MABS) wrote: > I am running bind 9,4.2-P2 You'll want to upgrade that to 9.4.3-P1 for better security, performance, etc. > on windows and can resolve all external Domains names Really? You've tried them ALL? :) > with the exception of www.lmsintl.com

Re: Problem resolving "www.lmsintl.com"

Make sure your Windows client is not appending any additional suffix to your domain name by adding a . to the end of your domain name. So for example, your nslookup command should look something similar to this: nslookup www.lmsintl.com. What happens when you do "dig www.lmsintl.com. a"? Does it

Problem resolving "www.lmsintl.com"

I am running bind 9,4.2-P2 on windows and can resolve all external Domains names with the exception of www.lmsintl.com Doing a "dig www.lmsintl.com +trace returns the proper address If I do a ping or nslookup on www.lmsintl.com