Re: Problem resolving a domainkey TXT record

Hi Danilo, it is not a problem on your end, Their servers break the DNS protocol and don't respond to unknown names: $ dig +tries=1 -4 IN NS @nstll.eulisa.europa.eu ${RANDOM}.eulisa.europa.eu ;; communications error to 194.126.110.49#53: timed out ; <<>> DiG 9.21.3-1+0~20241211.133+debian12~1.

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

Agreed, but without the upstream provider actually fixing the issue I couldn't find a way to provide resolution of this domain to my customers - are there better ways to resolve this from our side? There seems to be a document about this issue - https://kb.isc.org/docs/aa-01387 Paul On Fri, 13 M

Re: Problem resolving a domain

Working around servers that drop queries causes problems for zones that do have protocol compliant servers. The workarounds cause problems with getting DNSSEC responses wic leads to validation failures. -- Mark Andrews > On 13 May 2022, at 22:58, Paul Stead wrote: > >  > Further to this,

Re: Problem resolving a domain

Further to this, I've discovered that disabling DNS cookies also seems to help with resolution - $ dig +nocookie +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com. @ns21.barclays.com. Maybe the send-cookie option could be investigated? YMMV.. On a side note other recursive DNS software

Re: Problem resolving a domain

I have noticed this, too, The problem seems to be related to edns - disabling edns for the upstream servers looks to resolve the issue, this can be seen with later versions of dig - $ dig *+noedns* +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com. @ns21.barclays.com. I have config alo

Re: Problem resolving a domain

Hi Rainer, I believe this is unrelated to any upgrade. The nameservers for the domain are broken: $ dig IN A myapplication.international.barclays.com @ns2.barcap.com. ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> IN A myapplication.international.barclays.com @ns2.barcap.co

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

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

Hi, Stephan, If the domain has one working DNS server and one that's broken, but both are in the delegation, then it's somewhat of random luck as to which one you'll try first... If you try the bad one first, then what happens next depends on "how" it's bad. If it's just dead/down, then after a ti

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

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

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

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

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 was fixed in 9.8.1 But note that the cur

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.isc.org/piperm

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

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

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