Re: FORMERR-Format error issue

utput from a client to OUR private recursive DNS server is as > follows: > >> members.nmar.com > Server: [100.101.0.10] > Address: 100.101.0.10 > > *** [100.101.0.10] can't find members.nmar.com: Server failed > > -Our DNS server log output follows: > >

FORMERR-Format error issue

: 100.101.0.10 *** [100.101.0.10] can't find members.nmar.com: Server failed -Our DNS server log output follows: Jan 26 13:48:00 dns1 named[1609]: FORMERR resolving 'members.nmar.com/A/IN': 216.40.47.26#53 Jan 26 13:48:00 dns1 named[1609]: FORMERR resolving 'members.nmar.com

Re: DNS Cookies Causing FORMERR

. From: Mark Andrews Sent: Friday, January 6, 2023 2:57 PM To: Justin Krejci Cc: bind-users@lists.isc.org Subject: Re: DNS Cookies Causing FORMERR Really there are very few servers that are broken and the numbers are decreasing. They are well under 1%. Just contact the

Re: DNS Cookies Causing FORMERR

was tightened nearly 10 years ago (April 2013). It was unspecified in the original EDNS RFC and made ignored in in the updated RFC which every vendor should have picked up. At the time some vendors ignored unknown options and others returned FORMERR or NOTIMP or REFUSED. Others just dropped the

DNS Cookies Causing FORMERR

DNS Servers that do not properly support or properly ignore DNS cookies and instead return FORMERR is annoying. This is not new. However I have been seeing more or perhaps just have more users that are finding more domains that are hosted on authoritative servers with this unfortunate behavior

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

On 23-10-2022 01:18, Crist Clark wrote: On Sat, Oct 22, 2022 at 3:20 PM Sandro wrote: [snip] Doing favors for the better good does not seem to be in their dictionary. Look at DNSSEC. Do you mean signing their domains or their public resolver services? I was referring to signing their own

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

On Sat, Oct 22, 2022 at 3:20 PM Sandro wrote: [snip] > Doing favors for the better good does not seem to be in their > dictionary. Look at DNSSEC. > Do you mean signing their domains or their public resolver services? https://developers.google.com/speed/public-dns/faq Does Google Public DNS su

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

On 21-10-2022 16:53, Ondřej Surý wrote: there are two layers- Google certainly doesn’t do anything wrong, but they would do a world a favor if there was a stronger push towards compliance with DNS protocol. That's the conundrum with big tech. If it serves them well, they will force others to f

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

e, so I would expect their commitment to refuse >> to solve incorrect domains. They do a skinny favor to all the Internet >> by returning to the workarounds, and blaming those who do well (as >> Bind 9.18) > > I wouldn't blame Google so quickly. The servers we're di

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

Am Fri, Oct 21, 2022 at 01:21:36PM +0200 schrieb Borja Marcos: > But tell your customer that their email message didn’t arrive on time because > the recipient has a misconfigured DNS server and > try to explain to them that, yes, Google resolved it successfully but you are > working for the commo

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

nternet by returning to the workarounds, and blaming those who do well (as Bind 9.18) I wouldn't blame Google so quickly. The servers we're discussing in this thread return FORMERR when the query has the COOKIE or NSID options. DNS cookies are recommended (RFC uses "should") rath

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

> > On 21 Oct 2022, at 12:23, Ondřej Surý wrote: > > > > What you are really saying that we should dance how tech giants whistle, > > and I don’t think succumbing to tech giants is a good strategy long term. > > Not at all and I agree with you. > > But tell your customer that their email mess

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

> On 21 Oct 2022, at 12:23, Ondřej Surý wrote: > > What you are really saying that we should dance how tech giants whistle, and > I don’t think succumbing to tech giants is a good strategy long term. Not at all and I agree with you. But tell your customer that their email message didn’t arr

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

What you are really saying that we should dance how tech giants whistle, and I don’t think succumbing to tech giants is a good strategy long term. Ondřej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your no

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

> On 21 Oct 2022, at 03:51, Mark Andrews wrote: > >> >> Of course I would prefer to upgrade back to 9.18.X, but I guess I won't be able to find all EDNS0 incompatible servers and loosing customers to 8.8.8.8 - which is able to resolve these names.. >>> This is kind of moot ar

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

> On 20 Oct 2022, at 22:49, Andreas S. Kerber wrote: > > Am Thu, Oct 20, 2022 at 01:23:47PM +0200 schrieb Ondřej Surý: >> did you try writing to elbrev.com operators to fix >> their servers to stop breaking DNS protocol? It often helps. (I'm ccing the >> contact in their

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

https://bind9.readthedocs.io/en/v9_18_8/chapter9.html?highlight=cookie -- 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 20. 10. 2022, at 13:49, Andreas S. Kerber wrote:

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

Am Thu, Oct 20, 2022 at 01:23:47PM +0200 schrieb Ondřej Surý: > did you try writing to elbrev.com operators to fix their > servers to stop breaking DNS protocol? It often helps. (I'm ccing the contact > in their SOA records, so let's see if anything happens.) > > It's not lac

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

perly process unknown EDNS0 options - DNS Cookie in this specific example: ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 57723 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: ec9c

FORMERR responses after upgrading resolver from 9.16 to 9.18.8

I've just finished upgrading our last resolver from 9.16 to 9.18.8 a few days ago. As it turn out a number of zones are no longer resolveable with 9.18. Some nameservers out there don't seem to support EDNS0 and the number of FORMERR responses in our resolver logs went up quite a bi

Re: Saurabh: Not getting the answer with AAAA record. Error FORMERR resolving 'gim8.pl/AAAA/IN comes.

Cathy Almond wrote: > > My understanding of why RPZ by default queries for names that it's going > to rewrite anyway, is that the lack of regular queries to the > authoritative servers alerts the zone owners (who we assume are > malicious or similar) to the fact that their zone is being blocked an

Re: Saurabh: Not getting the answer with AAAA record. Error FORMERR resolving 'gim8.pl/AAAA/IN comes.

ing with few domains are that when I >> have quered the A record for that domain, the answer is OK. >> When I have quered for record, it is not given the answer. > >> May 22 17:24:13 RPZ named[17245]: FORMERR resolving 'gim8.pl//IN': >> 104.130.13

Re: Saurabh: Not getting the answer with AAAA record. Error FORMERR resolving 'gim8.pl/AAAA/IN comes.

ord for that domain, the answer is OK. > When I have quered for record, it is not given the answer. > May 22 17:24:13 RPZ named[17245]: FORMERR resolving 'gim8.pl//IN': > 104.130.132.112#53 RPZ is a bit weird because it performs the query as usual, then applies its rew

Saurabh: Not getting the answer with AAAA record. Error FORMERR resolving 'gim8.pl/AAAA/IN comes.

am sharing you the messages that i received when I hit the query using dig: May 22 17:24:13 RPZ named[17245]: FORMERR resolving 'gim8.pl//IN': 104.130.132.112#53 May 22 17:24:13 RPZ named[17245]: FORMERR resolving 'gim8.pl//IN': 198.245.62.20#53 May 22 17:25:46 RP

Re: bind9 Numerous recent - error (FORMERR) resolving 'dns3.registrar-servers.com/AAAA/IN'

Am 28.05.2015 um 06:26 schrieb David C. Rankin: On 05/26/2015 05:31 PM, Mark Andrews wrote: Well 208.67.220.220 returns the wrong SOA record which is why you are getting the message. For that matter why are you talking to 208.67.220.220 in the first place? It is not normally involved in resol

Re: bind9 Numerous recent - error (FORMERR) resolving 'dns3.registrar-servers.com/AAAA/IN'

On 05/26/2015 05:31 PM, Mark Andrews wrote: Well 208.67.220.220 returns the wrong SOA record which is why you are getting the message. For that matter why are you talking to 208.67.220.220 in the first place? It is not normally involved in resolving dns2.registrar-servers.com. Mark, Thank

Re: bind9 Numerous recent - error (FORMERR) resolving 'dns3.registrar-servers.com/AAAA/IN'

Mandrake be > fore > it went corporate and tanked. Over the past few weeks to a month or so, my l > ogs > have been filling with (FORMERR) messages like: > > May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.222.222#5 > 3 > resolving dns3.registrar-serv

bind9 Numerous recent - error (FORMERR) resolving 'dns3.registrar-servers.com/AAAA/IN'

All, I have run bind8 and bind9 for the past 15 years beginning on Mandrake before it went corporate and tanked. Over the past few weeks to a month or so, my logs have been filling with (FORMERR) messages like: May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.222.222#53

Re: FORMERR on packet received from Forwarder

Levi Pederson wrote: > > I have an authoritative DNS server that is supposed to forward any > unknowns to a specific upstream server. You are mixing authoritative and recursive service in a way that is not going to work well. Forwarding is designed for recursive clients. It doesn't make sense to

FORMERR on packet received from Forwarder

All, I'm in an odd situation. I have an authoritative DNS server that is supposed to forward any unknowns to a specific upstream server. These requests seem to process just fine till the response packet gets back to the system. Here is the resolver.log output specifics omitted. **

Re: Dig 9.9 FORMERR with NetWare

The last (and presumably final) point release (6.5) of NetWare was in 2003, only 4 years after RFC 2671. Just saying... - Kevin On 4/30/2013 7:08 PM, Pascal wrote: Thank you. That does appear to be the problem. -Pascal On 4/30/2013 5:

Re: Dig 9.9 FORMERR with NetWare

Thank you. That does appear to be the problem. -Pascal On 4/30/2013 5:17 PM, Mark Andrews wrote: BIND 9.9 dig turns on EDNS by default. You really should be asking why 172.31.123.6 doesn't suppport EDNS nearly 14 years after it was specified (RFC 2671 August 1999). Add +noedns to the comman

Re: Dig 9.9 FORMERR with NetWare

ne of them with any domain or record type I get FORMERR. -Pascal ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users

Re: Dig 9.9 FORMERR with NetWare

In message <51803fd2.3070...@users.sourceforge.net>, Pascal writes: > Dig 9.9 consistently gives me "FORMERR" against NetWare DNS servers. > Previous versions worked fine. Suggestions on how to figure out if the > bug is in Dig or NetWare? > > -Pascal BIND 9

Re: Dig 9.9 FORMERR with NetWare

On Tue, 2013-04-30 at 17:04 -0500, Pascal wrote: > Dig 9.9 consistently gives me "FORMERR" against NetWare DNS servers. > Previous versions worked fine. Suggestions on how to figure out if the > bug is in Dig or NetWare? > > -Pascal > > O:\Documents and

Dig 9.9 FORMERR with NetWare

Dig 9.9 consistently gives me "FORMERR" against NetWare DNS servers. Previous versions worked fine. Suggestions on how to figure out if the bug is in Dig or NetWare? -Pascal O:\Documents and Settings\admin\dig>dig www.alarmspecs.com @172.31.123.6 ; <<>> DiG 9.8.4-P

Re: lame-servers: error (FORMERR) resolving [something]

In message <20130122142136.ga21...@fantomas.sk>, Matus UHLAR - fantomas writes: > On 22.01.13 11:18, Daniele wrote: > >My router doesn't maintain a DNS cache, so it must be my IPS's fault. > > > >The last questions, if it's possible: what happens when my 'named' starts > >an iterative query? Does

Re: lame-servers: error (FORMERR) resolving [something]

On Jan 22, 2013, at 5:18 AM, Daniele wrote: > Ok! Thank you all! > > My router doesn't maintain a DNS cache, And what are you basing this upon? W > so it must be my IPS's fault. > > The last questions, if it's possible: what happens when my 'named' starts an > iterative query? Does it arri

Re: lame-servers: error (FORMERR) resolving [something]

On 22.01.13 11:18, Daniele wrote: My router doesn't maintain a DNS cache, so it must be my IPS's fault. The last questions, if it's possible: what happens when my 'named' starts an iterative query? Does it arrive to the real root-server (first of all), it should, but it appears that it does no

Re: lame-servers: error (FORMERR) resolving [something]

Ok! Thank you all! My router doesn't maintain a DNS cache, so it must be my IPS's fault. The last questions, if it's possible: what happens when my 'named' starts an iterative query? Does it arrive to the real root-server (first of all), or is it processed by some other cache-server on the path?

Re: lame-servers: error (FORMERR) resolving [something]

In message , Daniele writes: > These are the outputs. I also attach the file containing them. > > > ; <<>> DiG 9.8.1-P1 <<>> ns . +norec +noedns @198.41.0.4 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25625 > ;; flags: qr ra; QUERY: 1, ANSWE

Re: lame-servers: error (FORMERR) resolving [something]

On Jan 18, 2013, at 9:44 AM, Daniele wrote: > These are the outputs. I also attach the file containing them. > > [ SNIP ] Weird…. Do things work well enough for: dig +short rs.dns-oarc.net txt ? Can you also do: the following queries starting with the slightly less plain DNS query

Re: lame-servers: error (FORMERR) resolving [something]

These are the outputs. I also attach the file containing them. ; <<>> DiG 9.8.1-P1 <<>> ns . +norec +noedns @198.41.0.4 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25625 ;; flags: qr ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14 ;; QUESTION

Re: lame-servers: error (FORMERR) resolving [something]

What are the answers to the following queries starting with the very basic plain DNS query dig ns . +norec +noedns @198.41.0.4 Now add in EDNS support dig ns . +norec +edns @198.41.0.4 Now add in DNSEC support dig ns . +norec +dnssec @198.41.0.4 Please post the respon

Re: lame-servers: error (FORMERR) resolving [something]

For example, also a `dig a.root-servers.net` fails with SERVFAIL, but in Wireshark I can see the packet with the correct response that arrives at my network interface. 2013/1/17 Daniele > Output for `dig NS .` > ; <<>> DiG 9.8.1-P1 <<>> @127.0.0.1 NS . > ; (1 server found) > ;; global options:

Re: lame-servers: error (FORMERR) resolving [something]

Output for `dig NS .` ; <<>> DiG 9.8.1-P1 <<>> @127.0.0.1 NS . ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37032 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;.INNS

Re: lame-servers: error (FORMERR) resolving [something]

On Jan 17, 2013, at 9:04 AM, Daniele wrote: > I'm going crazy. > > This is my named.conf > > logging { > > channel default_logfile { > file "/var/cache/bind/logs/default.log"; > severity info; > print-category yes; > prin

Re: lame-servers: error (FORMERR) resolving [something]

I'm going crazy. This is my named.conf logging { channel default_logfile { file "/var/cache/bind/logs/default.log"; severity info; print-category yes; print-severity yes; print-time yes; }; c

Re: lame-servers: error (FORMERR) resolving [something]

On Jan 14 2013, Shane Kerr wrote: [...] You may want to try: dig +trace www.isc.org [...] The next step may be to try: dig +trace +dnssec www.isc.org Beware that if you have a dig(1) from BIND 9.9.x, +dnssec has become the default with +trace. In that case replace the first attempt with

Re: lame-servers: error (FORMERR) resolving [something]

e: lame-servers: error (FORMERR) resolving [something] > > >What tests should I do? >If I query directly an external name-server (one of the root ones or 8.8.8.8 >for example) I receive the correct response. >For this reason I'm inclined to think that the router doesn&#

Re: lame-servers: error (FORMERR) resolving [something]

Daniele, It may be a simple case of your firewall not allowing any DNS queries that do not request recursion. Difficult to know. You may want to try: dig +trace www.isc.org This will follow the referrals from the root, and you can verify that this works. The next step may be to try: dig +trac

Re: lame-servers: error (FORMERR) resolving [something]

What tests should I do? If I query directly an external name-server (one of the root ones or 8.8.8.8 for example) I receive the correct response. For this reason I'm inclined to think that the router doesn't block packets to/from port 53. Why should it block packets generated by BIND9? 2013/1/12

Re: lame-servers: error (FORMERR) resolving [something]

On 01/11/13 03:05, Daniele wrote: Port 53 is open, I can also telnet it from another box in the same network. Now I think the problem can be on the packets size, because I'm trying every solution but nothing works. 2013/1/9 Lyle Giese mailto:l...@lcrcomputer.net>> On 01/09/13 08:39, Dani

Re: lame-servers: error (FORMERR) resolving [something]

Port 53 is open, I can also telnet it from another box in the same network. Now I think the problem can be on the packets size, because I'm trying every solution but nothing works. 2013/1/9 Lyle Giese > On 01/09/13 08:39, Daniele wrote: > > 2013/1/9 Phil Mayers > >> On 09/01/13 13:53, Daniele

Re: lame-servers: error (FORMERR) resolving [something]

On 01/09/13 08:39, Daniele wrote: 2013/1/9 Phil Mayers > On 09/01/13 13:53, Daniele wrote: This is the scenario. I installed BIND9 via `apt-get` on a newly installed UBUNTU 12.04, virtualized on VirtualBox. The network works p

Re: lame-servers: error (FORMERR) resolving [something]

2013/1/9 Phil Mayers > On 09/01/13 13:53, Daniele wrote: > >> This is the scenario. >> >> I installed BIND9 via `apt-get` on a newly installed UBUNTU 12.04, >> virtualized on VirtualBox. >> The network works properly because if I indicate a different server from >> my own BIND9 (the first line of

Re: lame-servers: error (FORMERR) resolving [something]

On 09/01/13 13:53, Daniele wrote: This is the scenario. I installed BIND9 via `apt-get` on a newly installed UBUNTU 12.04, virtualized on VirtualBox. The network works properly because if I indicate a different server from my own BIND9 (the first line of '/etc/resolv.conf' is, for example, `name

Re: lame-servers: error (FORMERR) resolving [something]

es options { directory "/var/cache/bind"; dnssec-validation auto; auth-nxdomain no; listen-on-v6 {any;} }; In this situation, if I dig anything the lookup fails, and the log is full of "lame server" and "FORMERR". Why? Perhaps the problem is due to

Re: lame-servers: error (FORMERR) resolving [something]

> Sometimes I can't resolve some addresses and, in the logs, I can find > the message in the title: >lame-servers: error (FORMERR) resolving [something] > (where `something` is the address I'm trying to resolve). > > What does it means? 2013/1/8 Shane Kerr

Re: lame-servers: error (FORMERR) resolving [something]

57 +0100, > Daniele wrote: > > Hi all. > > > > Sometimes I can't resolve some addresses and, in the logs, I can find > > the message in the title: > >lame-servers: error (FORMERR) resolving [something] > > (where `something` is the address I'm

Re: lame-servers: error (FORMERR) resolving [something]

Daniele, On Tuesday, 2013-01-08 09:49:57 +0100, Daniele wrote: > Hi all. > > Sometimes I can't resolve some addresses and, in the logs, I can find > the message in the title: >lame-servers: error (FORMERR) resolving [something] > (where `something` is the addres

lame-servers: error (FORMERR) resolving [something]

Hi all. Sometimes I can't resolve some addresses and, in the logs, I can find the message in the title: lame-servers: error (FORMERR) resolving [something] (where `something` is the address I'm trying to resolve). What does it means? And how can I resolve this problem?

Re: Understanding cause of DNS format error (FORMERR)

In article , Barry Margolin wrote: > In article , > Sam Wilson wrote: > > > For a NXDOMAIN response, or NOERROR with an empty answer section, the > > server should provide the SOA record in the authority section. That SOA > > is the apex of the zone which doesn't contain the answer record

Re: Understanding cause of DNS format error (FORMERR)

In article , Sam Wilson wrote: > For a NXDOMAIN response, or NOERROR with an empty answer section, the > server should provide the SOA record in the authority section. That SOA > is the apex of the zone which doesn't contain the answer record you > asked for, if you see what I mean. The ser

Re: Understanding cause of DNS format error (FORMERR)

In article , Gabriele Paggi wrote: > Hello Sam, > > > There's some kind of delegation bug as well.  If I query > > dns1[0-3].one.microsoft.com for SOA and NS for > > partners.extranet.microsoft.com you get sensible answers though the > > origin host is different for each server queried and thos

Re: Understanding cause of DNS format error (FORMERR)

Hello Sam, > There's some kind of delegation bug as well.  If I query > dns1[0-3].one.microsoft.com for SOA and NS for > partners.extranet.microsoft.com you get sensible answers though the > origin host is different for each server queried and those origins are > privately addressed. Which kind o

Re: Understanding cause of DNS format error (FORMERR)

In article , Tony Finch wrote: > It looks to me like this is an EDNS bug. ... There's some kind of delegation bug as well. If I query dns1[0-3].one.microsoft.com for SOA and NS for partners.extranet.microsoft.com you get sensible answers though the origin host is different for each server q

Re: Understanding cause of DNS format error (FORMERR)

Carsten Strotmann (private) wrote: > > The FORMERR I'm seeing is also quite odd, as it has the "AD" flag set, > which should normally not appear in an error type of response, but > might be caused by a mangled DNS packet: I think it is echoing the AD bit in the q

Re: Understanding cause of DNS format error (FORMERR)

It looks to me like this is an EDNS bug. I am querying the authoritative server directly, with no firewalls in the way. The FORMERR is coming from the authoritative server not from BIND. I get the same result over IPv4 and IPv6. They also have a bug in their NXDOMAIN logic: extranet.microsoft.com

Re: Understanding cause of DNS format error (FORMERR)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On 6/24/12 10:07 AM, Carsten Strotmann (private) wrote: > It might even be a new Windows 2012 DNS server, and it might be an > issue with this new version. This is just speculation, but if it is > an issue with Windows 2012 DNS, it might be g

Re: Understanding cause of DNS format error (FORMERR)

and lack of authority and additional records in > their response seems like improper behavior to me, but I don't know > whether or not the DNS protocol actually requires this. Apparently > BIND 9.9.1-P1 is able to handle this situation. my BIND 9.9.1-P1 showed FORMERR yesterda

Re: Understanding cause of DNS format error (FORMERR)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Gabriele, On 6/24/12 5:57 AM, Gabriele Paggi wrote: > Hello Carsten, > > Thanks for your reply! >> about the FORMERR. This might be caused by a Firewall or other >> middlebox that truncates the large answer containing the

Re: Understanding cause of DNS format error (FORMERR)

Hello Jeffry, FWIW I'm not able to reproduce this using a BIND 9.9.1-P1 recursive resolver. On this system "dig @localhost vlasext.partners.extranet.microsoft.com a" returns the answer 70.42.230.20 and identifies dns11.one.microsoft.com (94.245.124.49) as one of four authoritative servers. "dig @

Re: Understanding cause of DNS format error (FORMERR)

t receives. The reply is nonsense but it's legit and BIND should just return it. Am I wrong? Beside that, I've been constantly getting a FORMERR reply for a week now. The issue seem to differ from the point in the network you are sending the query, and if the resolving DNS server has only

Re: Understanding cause of DNS format error (FORMERR)

Hello Carsten, Thanks for your reply! about the FORMERR. This might be caused by a Firewall or other middlebox that truncates the large answer containing the NS record set for this domain. I see the same if I try to fetch the delegation NS records from the parent domain (microsoft.com) for

Re: Understanding cause of DNS format error (FORMERR)

for the A record of vlasext.partners.extranet.microsoft.com: about the FORMERR. This might be caused by a Firewall or other middlebox that truncates the large answer containing the NS record set for this domain. I see the same if I try to fetch the delegation NS records from the parent domain (microsoft.com) for partners.ext

Re: Understanding cause of DNS format error (FORMERR)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Gabriele, On 6/22/12 11:22 AM, Gabriele Paggi wrote: > I'm a BIND novice and I'm trying to understand what causes my > BIND9 resolver (bind97-9.7.0-10.P2) to return an error when queried > for the A record of vlasext.partners.extranet.microsoft.

RE: Understanding cause of DNS format error (FORMERR)

> I'm a BIND novice and I'm trying to understand what causes my BIND9 resolver > (bind97-9.7.0-10.P2) to return an error when queried for the A record of > vlasext.partners.extranet.microsoft.com: FWIW I'm not able to reproduce this using a BIND 9.9.1-P1 recursive resolver. On this system "dig

Understanding cause of DNS format error (FORMERR)

resolving vlasext.partners.extranet.microsoft.com/A for client 10.16.32.4#50421: invalid response Jun 22 11:14:47 res1 named[32210]: error (FORMERR) resolving 'vlasext.partners.extranet.microsoft.com/A/IN': 94.245.124.49#53 Jun 22 11:14:47 res1 named[32210]: DNS format error from 131.107

Re: Don't understand why I get a FORMERR (quad-A - ipv6 related)

On 4/25/2012 10:28 AM, Matus UHLAR - fantomas wrote: >> In message >> >> , Nicolas Michel writes: >>> I only get no answer but a return code of NOERROR. > On 25.04.12 23:53, Mark Andrews wrote: >> The root cause is that the name servers for www.ryanair.com are >> misconfigured. They are returni

Re: Don't understand why I get a FORMERR (quad-A - ipv6 related)

In message , Nicolas Michel writes: I have BIND 9.6-ESV-R5-P1 on SLES 11 SP1 installed and it is working fine. I only have a situation where I don't understand what's happening and why : I try to do a quad-A query to www.ryanair.com (which is doesn't exists, only single A). When trying this wit

Re: Don't understand why I get a FORMERR (quad-A - ipv6 related)

Thank you for your answers guys! It's much more clear now ;) But the google DNS (8.8.8.8) still return NOERROR for the same query and the same situation. So I wonder what is the "right" behavior (documented in RFC? or maybe that situation is not documented so it is right to the software dev to deci

Re: Don't understand why I get a FORMERR (quad-A - ipv6 related)

Apr-2012 14:00:52.009 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx > 0x7f0d23be2dc0(www.ryanair.com/)): response > 25-Apr-2012 14:00:52.009 resolver: debug 3: fctx 0x7f0d23be2dc0( > www.ryanair.com/AAAA'): noanswer_response > 25-Apr-2012 14:00:52.009 resolver: debug 3: fctx 0x

Don't understand why I get a FORMERR (quad-A - ipv6 related)

)): response 25-Apr-2012 14:00:52.009 resolver: debug 3: fctx 0x7f0d23be2dc0( www.ryanair.com/'): noanswer_response 25-Apr-2012 14:00:52.009 resolver: debug 3: fctx 0x7f0d23be2dc0( www.ryanair.com/'): cancelquery 25-Apr-2012 14:00:52.010 resolver: debug 3: fctx 0x7f0d23be2dc0( www.ryan

Re: Getting a formerr 'invalid response' for winqual.microsoft.com. but dig +trace works.

I would have to back port right now, and I have a work around that will work until the we bump our fleet to a newer version. I was mostly concerned about whether it was something in our network causing the problem. Thanks for all the help guys, --Matt On Thu, Feb 9, 2012 at 4:42 PM, Spain, Dr. J

RE: Getting a formerr 'invalid response' for winqual.microsoft.com. but dig +trace works.

> It's because a few load balancer vendors don't read freely available > specifications but instead appear to reverse engineer the protocol and get it > wrong. > BIND 9.7.0 fixed a long standing of accepting glue promoted to answer by > parent nameservers. Once we did that there was no need to

Re: Getting a formerr 'invalid response' for winqual.microsoft.com. but dig +trace works.

In message , Matt Doughty writes: > It seems like multiple things are wrong, but I'm still trying to > understand what part of the breakage is causing Bind to throw out the > response with the formerr 'invalid response'. Is this broken for > everyone using bind 9.7 or

Re: Getting a formerr 'invalid response' for winqual.microsoft.com. but dig +trace works.

It seems like multiple things are wrong, but I'm still trying to understand what part of the breakage is causing Bind to throw out the response with the formerr 'invalid response'. Is this broken for everyone using bind 9.7 or later? I can just forward this zone to HonestDNS

Re: Getting a formerr 'invalid response' for winqual.microsoft.com. but dig +trace works.

On 2/8/2012 10:32 PM, Matt Doughty wrote: I have spend the afternoon trying to figure this out. The response I get back from their nameserver looks fine to me, and dig +trace works fine, but a regular dig returns a servfail. I have looked at the code for invalid response, but I don't quite follow

Re: Getting a formerr 'invalid response' for winqual.microsoft.com. but dig +trace works.

Microsoft's servers are broken. "aa" should be set but it isn't. Mark ; <<>> DiG 9.7.3-P3 <<>> winqual.partners.extranet.microsoft.com @dns10.one.microsoft.com +norec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24074 ;; flags: qr ra; QUERY: 1, ANS

Getting a formerr 'invalid response' for winqual.microsoft.com. but dig +trace works.

I have spend the afternoon trying to figure this out. The response I get back from their nameserver looks fine to me, and dig +trace works fine, but a regular dig returns a servfail. I have looked at the code for invalid response, but I don't quite follow what is going on there, and the comment 're

treatment of FORMERR response in a lookup

Guys, If a resolver gets a FORMERR back from an authoritative nameserver, will it stop there and treat it similar to NXDOMAIN, or will it try another auth server (a la SERVFAIL)? Thanks, -mark -- Mark Jeftovic, Founder & CEO, easyDNS Technologies Inc. Company Website: http://easydns

Re: FORMERR for wikipedia...

On Thu, 17 Mar 2011, Mark Bergsma wrote: On Mar 17, 2011, at 6:48 AM, Jay Ford wrote: On Thu, 17 Mar 2011, Mark Andrews wrote: The nameservers for wikipedia.org are broken. They put the wrong SOA record in the negative response, wikipedia.org != wikimedia.org. The adminstrators of wikimedi

Re: FORMERR for wikipedia...

On Thu, 17 Mar 2011, Mark Andrews wrote: The nameservers for wikipedia.org are broken. They put the wrong SOA record in the negative response, wikipedia.org != wikimedia.org. M vs P Exactly. The adminstrators of wikimedia.org were informed about this months ago but they don'

Re: FORMERR for wikipedia...

On Mar 16 2011, Jay Ford wrote: [...] To me it looks like BIND is doing the right thing (as usual ;^), Yes (or *a* right thing, anyway). but the wikipedia... servers are returning bogus responses. Yes. Specifically the response is neither a valid "nodata" response, nor a valid referral. Di

Re: FORMERR for wikipedia...

messages like: > > resolver: DNS format error from 208.80.152.130#53 resolving \ > en.wikipedia.org/ for client ::1#33887: invalid response > lame-servers: error (FORMERR) resolving 'en.wikipedia.org//IN': \ > 208.80.152.130#53 > > I see this for a

FORMERR for wikipedia...

A recursive resolver of mine running BIND 9.7.3 logs many messages like: resolver: DNS format error from 208.80.152.130#53 resolving \ en.wikipedia.org/ for client ::1#33887: invalid response lame-servers: error (FORMERR) resolving 'en.wikipedia.org//IN': \ 208.

Re: Update returns FORMERR: ran out of space

On Thu, Feb 25, 2010 at 10:02:45AM +1100, Mark Andrews wrote a message of 68 lines which said: > Try this patch. It resets the scratch space 'data' used by > dns_dnssec_sign(). It works fine. Many thanks. Sending update to ::1#8053 Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, stat

Re: Update returns FORMERR: ran out of space

In message <20100224091831.ga3...@nic.fr>, Stephane Bortzmeyer writes: > On Wed, Feb 24, 2010 at 11:32:35AM +1100, > Mark Andrews wrote > a message of 35 lines which said: > > > Turn the debugging up to 3. > > With 'severity debug 30', all I get is: > > 24-Feb-2010 10:17:01.047 update: deb

Re: Update returns FORMERR: ran out of space

On Wed, Feb 24, 2010 at 10:18:31AM +0100, Stephane Bortzmeyer wrote a message of 39 lines which said: > 24-Feb-2010 10:17:01.057 update: error: client ::1#45986: updating zone > 'toto.fr/IN': RRSIG/NSEC/NSEC3 update failed: ran out of space Adding a fair amount of debugging traces, I can get

  1   2   >