Re: FORMERR-Format error issue

[Mark Andrews]

The nameservers for members.nmar.com are broken.  They are returning
2 CNAME records when only 1 is allowed.  The are also returning a
referral to the root servers.

Referrals to the root servers after following CNAMEs are supposed to
have gone the way of the dodo.  Multiple CNAMEs have never been allowed.

Just because Google accepts broken responses, it doesn’t make them correct.

Mark

% dig members.nmar.com +norec @ns2.hover.com

; <<>> DiG 9.19.20-dev <<>> members.nmar.com +norec @ns2.hover.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51358
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;members.nmar.com. IN A

;; ANSWER SECTION:
members.nmar.com. 900 IN CNAME public.west.us.memberzone.org.
members.nmar.com. 900 IN CNAME public.east.us.memberzone.org.

;; AUTHORITY SECTION:
. 518400 IN NS a.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS g.root-servers.net.
. 518400 IN NS h.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS m.root-servers.net.

;; Query time: 219 msec
;; SERVER: 64.98.148.13#53(ns2.hover.com) (UDP)
;; WHEN: Thu Feb 01 16:35:45 AEDT 2024
;; MSG SIZE  rcvd: 314

% 

> On 1 Feb 2024, at 16:27, Scott Richardson  wrote:
> 
> Hello,
> 
> -I have been troubleshooting a format error in BIND 9 for about a week at 
> this point.
> 
> -The symptoms:
> 
> -I am unable to resolve members.nmar.com.
> 
> -The nslookup output 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:
> 
> 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/A/IN': 
> 64.98.148.13#53
> 
> -It works with Cloudfare and Goole however:
> 
>> server 8.8.8.8
> Default Server:  dns.google
> Address:  8.8.8.8
> 
>> members.nmar.com
> Server:  dns.google
> Address:  8.8.8.8
> 
> Non-authoritative answer:
> Name:public.west.us.memberzone.org
> Address:  172.170.249.2
> Aliases:  members.nmar.com
> 
> -If I dig this from one of our other server it fails as well unless I add the 
> +norec option which DOES work.
> 
> -If I perform an nslookup to their authoritative DNS servers I get a referral 
> to the root name server list:
> 
> Server:  ns1.hover.com
> Address:  216.40.47.26
> 
> Name:nmar.com
> Address:  20.25.91.29
> 
>> members.nmar.com
> Server:  ns1.hover.com
> Address:  216.40.47.26
> 
> Non-authoritative answer:
> Non-authoritative answer:
> Name:members.nmar.com
> Served by:
> - a.root-servers.net
> 
> 
> - b.root-servers.net
> 
> 
> - c.root-servers.net
> 
> 
> - d.root-servers.net
> 
> 
> - e.root-servers.net
> 
> 
> - f.root-servers.net
> 
> 
> - g.root-servers.net
> 
> 
> - h.root-servers.net
> 
> 
> - i.root-servers.net
> 
> 
> - j.root-servers.net
> 
> -I am not sure if this is an issue with us or them or I need to adjust my 
> configuration somehow to accommodate a problem on their server.  I am not 
> sure why other DNS is working but ours is failing.
> 
> -This is tested with our server firewall disabled.
> 
> -I have disabled firewall rules within our network to confirm NO firewall 
> issues are causing this.
> 
> -I have checked the DNS with our upstream and they are resolving this url 
> correctly; therefore I don't suspect firewall issues within their network.
> 
> -We are not using IPV6 at all at this time.
> 
> -This is occurring with both of our redundant DNS servers and I fired up a 
> test server with Bind 9.16 and it is giving me the same result.
> 
> -Any thoughts or suggestions would be very helpful and much appreciated!
> 
> Regards,
> 
> 
> Scott
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
> this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

FORMERR-Format error issue

[Scott Richardson]

Hello,

-I have been troubleshooting a format error in BIND 9 for about a week 
at this point.


-The symptoms:

-I am unable to resolve members.nmar.com.

-The nslookup output 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:

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/A/IN': 64.98.148.13#53


-It works with Cloudfare and Goole however:


server 8.8.8.8

Default Server:  dns.google
Address:  8.8.8.8


members.nmar.com

Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:public.west.us.memberzone.org
Address:  172.170.249.2
Aliases:  members.nmar.com

-If I dig this from one of our other server it fails as well unless I 
add the +norec option which DOES work.


-If I perform an nslookup to their authoritative DNS servers I get a 
referral to the root name server list:


Server:  ns1.hover.com
Address:  216.40.47.26

Name:nmar.com
Address:  20.25.91.29


members.nmar.com

Server:  ns1.hover.com
Address:  216.40.47.26

Non-authoritative answer:
Non-authoritative answer:
Name:members.nmar.com
Served by:
- a.root-servers.net


- b.root-servers.net


- c.root-servers.net


- d.root-servers.net


- e.root-servers.net


- f.root-servers.net


- g.root-servers.net


- h.root-servers.net


- i.root-servers.net


- j.root-servers.net

-I am not sure if this is an issue with us or them or I need to adjust 
my configuration somehow to accommodate a problem on their server.  I am 
not sure why other DNS is working but ours is failing.


-This is tested with our server firewall disabled.

-I have disabled firewall rules within our network to confirm NO 
firewall issues are causing this.


-I have checked the DNS with our upstream and they are resolving this 
url correctly; therefore I don't suspect firewall issues within their 
network.


-We are not using IPV6 at all at this time.

-This is occurring with both of our redundant DNS servers and I fired up 
a test server with Bind 9.16 and it is giving me the same result.


-Any thoughts or suggestions would be very helpful and much appreciated!

Regards,


Scott
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS Cookies Causing FORMERR

[Justin Krejci]

Sounds good. I will just buckle down and stay the course. As I encounter these 
servers, I have been attempting to reach out to all of the organizations whose 
DNS servers exhibit this behavior. Some are less responsive than others, as in 
completely ignored. :/



Thanks for the feedback.




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 few remaining server 
operators and inform them that they are broken.  It should just be an upgrade 
to the current version to fix.

The behavior for unknown EDNS options 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 request. Some returned BADVER.  It was a mess.

There are also implementations that don’t know how to return FORMERR properly.  
You don’t echo back the request with rcode set to FORMERR and QR to 1 as that 
produces broken responses but some implementations do that. Why would you send 
a message that you don’t understand?  Nowhere is there any instructions to do 
this.

To send a FORMER you send a DNS message header with rcode set to FORMERR. If 
you can parse the question section for QUERY copy that into the response. If 
you understand EDNS you can add an OPT record. Similarly TSIG if appropriate 
and you support it  Yes you can sign a FORMERR.
--
Mark Andrews

On 7 Jan 2023, at 06:50, Justin Krejci  wrote:



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.

Example progrowth.com name severs.

Individual work arounds on caching BIND servers are not difficult to implement, 
like this

server  47.206.74.18 {
send-cookie no;
};
server  209.131.228.178 {
send-cookie no;
};


However this workaround is problematic in terms of ongoing upkeep of this list 
and the increasing need to add new entries to the list. I'd like to be able to 
start sending cookies again if the servers begin to operate compliant to the 
EDNS RFC and I would like to not have to write any tools to remove entries from 
this list or schedule some regular calendar reminder to check or add to Nagios 
or whatever. I'd also rather not just globally disable sending of DNS cookies 
but it is something being considered.

In this article @ https://kb.isc.org/docs/aa-01387 it states near the bottom

"Nevertheless, mishandling of the COOKIE option has been known to cause errors 
that are fatal to name resolution when the resolver is validating responses 
coming from a signed zone, and the authoritative server returns either FORMERR 
or BADVERS, or fails to respond to the query. named treats these answers as if 
the server does not support EDNS (which it doesn't) so it stops sending any 
EDNS queries at all, which makes it impossible to get a DNSSEC response back."

This statement indicates this fall-back method is only applicable to signed 
domains. Is there a knob in BIND to apply this behavior to all domains? 
Basically, if the authoritative server is behaving incorrectly in this way then 
enable no-EDNS or no-COOKIE mode in the interest of allowing DNS queries to 
continue to be answered for the end users.

My caching servers are running the BIND 9.18 branch

Thanks for any pointers or suggestions.

-Justin

--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS Cookies Causing FORMERR

[Mark Andrews]

Really there are very few servers that are broken and the numbers are 
decreasing.  They are well under 1%. Just contact the few remaining server 
operators and inform them that they are broken.  It should just be an upgrade 
to the current version to fix. 

The behavior for unknown EDNS options 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 request. Some returned BADVER.  It was a mess. 

There are also implementations that don’t know how to return FORMERR properly.  
You don’t echo back the request with rcode set to FORMERR and QR to 1 as that 
produces broken responses but some implementations do that. Why would you send 
a message that you don’t understand?  Nowhere is there any instructions to do 
this. 

To send a FORMER you send a DNS message header with rcode set to FORMERR. If 
you can parse the question section for QUERY copy that into the response. If 
you understand EDNS you can add an OPT record. Similarly TSIG if appropriate 
and you support it  Yes you can sign a FORMERR. 
-- 
Mark Andrews

> On 7 Jan 2023, at 06:50, Justin Krejci  wrote:
> 
> 
> 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.
> 
> Example progrowth.com name severs.
> 
> Individual work arounds on caching BIND servers are not difficult to 
> implement, like this
> 
> server  47.206.74.18 {
> send-cookie no;
> };
> server  209.131.228.178 {
> send-cookie no;
> };
> 
> 
> However this workaround is problematic in terms of ongoing upkeep of this 
> list and the increasing need to add new entries to the list. I'd like to be 
> able to start sending cookies again if the servers begin to operate compliant 
> to the EDNS RFC and I would like to not have to write any tools to remove 
> entries from this list or schedule some regular calendar reminder to check or 
> add to Nagios or whatever. I'd also rather not just globally disable sending 
> of DNS cookies but it is something being considered.
> 
> In this article @ https://kb.isc.org/docs/aa-01387 it states near the bottom
> 
> "Nevertheless, mishandling of the COOKIE option has been known to cause 
> errors that are fatal to name resolution when the resolver is validating 
> responses coming from a signed zone, and the authoritative server returns 
> either FORMERR or BADVERS, or fails to respond to the query. named treats 
> these answers as if the server does not support EDNS (which it doesn't) so it 
> stops sending any EDNS queries at all, which makes it impossible to get a 
> DNSSEC response back." 
> 
> This statement indicates this fall-back method is only applicable to signed 
> domains. Is there a knob in BIND to apply this behavior to all domains? 
> Basically, if the authoritative server is behaving incorrectly in this way 
> then enable no-EDNS or no-COOKIE mode in the interest of allowing DNS queries 
> to continue to be answered for the end users.
> 
> My caching servers are running the BIND 9.18 branch
> 
> Thanks for any pointers or suggestions.
> 
> -Justin
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
> this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

DNS Cookies Causing FORMERR

[Justin Krejci]

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.

Example progrowth.com name severs.

Individual work arounds on caching BIND servers are not difficult to implement, 
like this

server  47.206.74.18 {
send-cookie no;
};
server  209.131.228.178 {
send-cookie no;
};


However this workaround is problematic in terms of ongoing upkeep of this list 
and the increasing need to add new entries to the list. I'd like to be able to 
start sending cookies again if the servers begin to operate compliant to the 
EDNS RFC and I would like to not have to write any tools to remove entries from 
this list or schedule some regular calendar reminder to check or add to Nagios 
or whatever. I'd also rather not just globally disable sending of DNS cookies 
but it is something being considered.

In this article @ https://kb.isc.org/docs/aa-01387 it states near the bottom

"Nevertheless, mishandling of the COOKIE option has been known to cause errors 
that are fatal to name resolution when the resolver is validating responses 
coming from a signed zone, and the authoritative server returns either FORMERR 
or BADVERS, or fails to respond to the query. named treats these answers as if 
the server does not support EDNS (which it doesn't) so it stops sending any 
EDNS queries at all, which makes it impossible to get a DNSSEC response back."

This statement indicates this fall-back method is only applicable to signed 
domains. Is there a knob in BIND to apply this behavior to all domains? 
Basically, if the authoritative server is behaving incorrectly in this way then 
enable no-EDNS or no-COOKIE mode in the interest of allowing DNS queries to 
continue to be answered for the end users.

My caching servers are running the BIND 9.18 branch

Thanks for any pointers or suggestions.

-Justin
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Sandro]

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 zones.


https://developers.google.com/speed/public-dns/faq
Does Google Public DNS support the DNSSEC protocol?

Google Public DNS is a validating, security-aware resolver. All responses
from DNSSEC signed zones are validated unless clients explicitly set the CD
flag in DNS requests to disable the validation.

https://developers.cloudflare.com/1.1.1.1/faq/#how-does--work-with-dnssec
How does 1.1.1.1 work with DNSSEC?

1.1.1.1 is a DNSSEC validating resolver. 1.1.1.1 sends the DO (DNSSEC OK)
bit on every query to convey to the authoritative server that it wishes to
receive signed answers if available. 1.1.1.1 supports the signature
algorithms specified in Supported DNSKEY signature algorithms
.



--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Crist Clark]

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 support the DNSSEC protocol?

Google Public DNS is a validating, security-aware resolver. All responses
from DNSSEC signed zones are validated unless clients explicitly set the CD
flag in DNS requests to disable the validation.

https://developers.cloudflare.com/1.1.1.1/faq/#how-does--work-with-dnssec
How does 1.1.1.1 work with DNSSEC?

1.1.1.1 is a DNSSEC validating resolver. 1.1.1.1 sends the DO (DNSSEC OK)
bit on every query to convey to the authoritative server that it wishes to
receive signed answers if available. 1.1.1.1 supports the signature
algorithms specified in Supported DNSKEY signature algorithms
.
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Sandro]

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 follow their/the standards.


Doing favors for the better good does not seem to be in their 
dictionary. Look at DNSSEC.





Somebody needs to make the first step, so we did it. It’s documented
in the troubleshooting section, it can be disabled, and if anybody
feels there could be more or better documentation, we do accept
external Merge Requests, and we do appreciate improvements to the
documentation as well as to the code. The documentation is equally
important as correct code, and we are not operator ourselves, so we
might miss few things.


Kudos for biting the bullet. I hope it will trickle down and get the 
mopping done. I'm certainly in favor of reporting over working around 
the issue. But I don't have customers breathing down my neck.


-- Sandro
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Ondřej Surý]

Anand,

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.

On the authoritative side - it’s certainly true that neither DNS Cookies nor 
NSID is mandatory, but the part that is mandatory (**MUST**) is correct 
handling of the unknown EDNS0 option.

It’s kind of chicken-egg problem - resolver operators won’t enable DNS Cookies 
because there are some broken domains and the broken domains won’t fix it 
because it works with “big tech”. And the security suffers and everybody loses 
in the end.

Somebody needs to make the first step, so we did it. It’s documented in the 
troubleshooting section, it can be disabled, and if anybody feels there could 
be more or better documentation, we do accept external Merge Requests, and we 
do appreciate improvements to the documentation as well as to the code. The 
documentation is equally important as correct code, and we are not operator 
ourselves, so we might miss few things.

Ondrej
--
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 normal working hours.

> On 21. 10. 2022, at 14:26, Anand Buddhdev  wrote:
> 
> On 21/10/2022 14:04, Hugo Salgado wrote:
> 
>> But wasn't it exactly the idea with the 2019 DNS Flag Day campaign?
>>   http://www.dnsflagday.net/2019/
>> I see Google's name there, 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 discussing in this 
> thread return FORMERR when the query has the COOKIE or NSID options. DNS 
> cookies are recommended (RFC uses "should") rather than mandated. Now, if the 
> Google resolver simply isn't sending these options, then it is not affected. 
> Similarly, a resolver like Unbound (which as far as I know doesn't send 
> cookies yet), will also not be affected.
> 
> While DNS cookies are not mandatory, it's not fair to point a finger at a 
> resolver that doesn't use this feature yet.
> 
> Regards,
> Anand
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
> this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Andreas S. Kerber]

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 common good.

+1

While it's possible to enter those bad apples with a server{} statement in 
named.conf, this reactive approach is not always feasible. In our cases this 
week some mail bounced, since our MTAs could not resolve some domainnames and 
customers obviously don't like that, which triggered some support cases etc.

After further analysis of our logs the problem probably really is not all that 
big, just very few names where not resolvable. Nonetheless, we've decided to 
leave one of resolvers at 9.16 for now as a "last resort" for those faulty 
names, and the other resolvers continue to run fine with 9.18.

If I can find a few definite way to easily identify these bad apples from our 
resolver logs, I might notify the operators. I guess https://ednscomp.isc.org/ 
already has a way more comprehensive view on the issue and therefore better 
data for such notifications though ;-)
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Anand Buddhdev]

On 21/10/2022 14:04, Hugo Salgado wrote:


But wasn't it exactly the idea with the 2019 DNS Flag Day campaign?
   http://www.dnsflagday.net/2019/

I see Google's name there, 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 discussing in this 
thread return FORMERR when the query has the COOKIE or NSID options. DNS 
cookies are recommended (RFC uses "should") rather than mandated. Now, 
if the Google resolver simply isn't sending these options, then it is 
not affected. Similarly, a resolver like Unbound (which as far as I know 
doesn't send cookies yet), will also not be affected.


While DNS cookies are not mandatory, it's not fair to point a finger at 
a resolver that doesn't use this feature yet.


Regards,
Anand
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Hugo Salgado]

> > 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 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 common good.
> 
> 

But wasn't it exactly the idea with the 2019 DNS Flag Day campaign? 
  http://www.dnsflagday.net/2019/

I see Google's name there, 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)

Hugo



signature.asc
Description: PGP signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Borja Marcos]

> 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 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 common good.


I know!





Borja.


-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Ondřej Surý]

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 normal working hours.

> On 21. 10. 2022, at 10:50, Borja Marcos  wrote:
> 
> A wider consensus is needed.
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Borja Marcos]

> 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 argument - the DNS needs to evolve, and it can't 
>>> evolve if we keep supporting broken stuff. This needs to be fixed on the 
>>> authoritative operator side, not in BIND 9.
>> 
>> You're absolutely right. I guess I've just kind of given up on convincing 
>> other people the fix their stuff (dayjob trauma). Sorry about that.
> 
> It’s also a very small percentage of servers that are broken.  If you look at 
> the time series
> on https://ednscomp.isc.org/ you can drill done and see the values.  For 
> example there are a
> little over 10 servers for all zones in .GOV that exhibit this broken 
> behaviour.  It’s gone
> from ~11% in 2014 to 0.26% currently.  We are at the mop up stage.  For some 
> other populations
> we are at 0%.
> 
> The EDNS specification was updated in April 2013 to specify some unspecified 
> behaviour.  In
> particular this was added.

While I hearfully agree with the need to polish the network, some measures can 
be a problem unless there is a really big
commitment from the Big Guns.

In my case I had to abort an upgrade to 9.18 on our recursive servers because, 
well, “Google DNS worked better than ours”
going back to 9.16.

I know it´s the same situation that happened when Internet Explorer 
“successfully” rendered all kinds of abominations while proper web
clients barfed (with good reason!) and I also know that lousy formats and lack 
of respect for standars are the breeding
ground of serious security incidents.

End of rant: A wider consensus is needed.





Borja.


-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Mark Andrews]

> 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 SOA records, so let's see if anything happens.)
>> 
>> It's not lack of EDNS0 support, but they fail to properly process unknown 
>> EDNS0 options - DNS Cookie in this specific example:
> 
> Hi Ondřej,
> 
> thanks for your quick reply and analysis regarding DNS cookies.
> Is there maybe an option to configure 9.18 to act as if it was 9.16 in this 
> regard?
> Honestly I haven't contacted the elbrev.com people (see below).
> 
> 
>>> 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 argument - the DNS needs to evolve, and it can't evolve 
>> if we keep supporting broken stuff. This needs to be fixed on the 
>> authoritative operator side, not in BIND 9.
> 
> You're absolutely right. I guess I've just kind of given up on convincing 
> other people the fix their stuff (dayjob trauma). Sorry about that.

It’s also a very small percentage of servers that are broken.  If you look at 
the time series
on https://ednscomp.isc.org/ you can drill done and see the values.  For 
example there are a
little over 10 servers for all zones in .GOV that exhibit this broken 
behaviour.  It’s gone
from ~11% in 2014 to 0.26% currently.  We are at the mop up stage.  For some 
other populations
we are at 0%.

The EDNS specification was updated in April 2013 to specify some unspecified 
behaviour.  In
particular this was added.

   Any OPTION-CODE values not understood by a responder or requestor
   MUST be ignored.  Specifications of such options might wish to
   include some kind of signaled acknowledgement.  For example, an
   option specification might say that if a responder sees and supports
   option XYZ, it MUST include option XYZ in its response.


Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Ondřej Surý]

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:
> 
> 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 lack of EDNS0 support, but they fail to properly process unknown 
>> EDNS0 options - DNS Cookie in this specific example:
> 
> Hi Ondřej,
> 
> thanks for your quick reply and analysis regarding DNS cookies.
> Is there maybe an option to configure 9.18 to act as if it was 9.16 in this 
> regard?
> Honestly I haven't contacted the elbrev.com people (see below).
> 
> 
>>> 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 argument - the DNS needs to evolve, and it can't evolve 
>> if we keep supporting broken stuff. This needs to be fixed on the 
>> authoritative operator side, not in BIND 9.
> 
> You're absolutely right. I guess I've just kind of given up on convincing 
> other people the fix their stuff (dayjob trauma). Sorry about that.

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Andreas S. Kerber]

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 lack of EDNS0 support, but they fail to properly process unknown 
> EDNS0 options - DNS Cookie in this specific example:

Hi Ondřej,

thanks for your quick reply and analysis regarding DNS cookies.
Is there maybe an option to configure 9.18 to act as if it was 9.16 in this 
regard?
Honestly I haven't contacted the elbrev.com people (see below).


> > 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 argument - the DNS needs to evolve, and it can't evolve 
> if we keep supporting broken stuff. This needs to be fixed on the 
> authoritative operator side, not in BIND 9.

You're absolutely right. I guess I've just kind of given up on convincing other 
people the fix their stuff (dayjob trauma). Sorry about that.
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Ondřej Surý]

Hi,

did you try writing to elbrev.com <http://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 lack of EDNS0 support, but they fail to properly 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: ec9c994f850fe500 (echoed)

vs

ondrej@howl:~/Projects/bind9 (v9_18 $%=)$ bin/dig/dig +norec +noall +comments 
+nocookie bemacom.se @dns1.elbrev.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16277
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000

Their servers are clearly violating existing DNS standards: 
https://ednscomp.isc.org/ednscomp/11fd9e2e46 
<https://ednscomp.isc.org/ednscomp/11fd9e2e46>

> 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 argument - the DNS needs to evolve, and it can't evolve if 
we keep supporting broken stuff. This needs to be fixed on the authoritative 
operator side, not in BIND 9.

Cheers,
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 20. 10. 2022, at 13:09, Andreas S. Kerber  wrote:
> 
> 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 bit.  Here's an example:
> 
> 
> zone bemacom.se when querying a 9.18.8 resolver (status: SERVFAIL):
> 
> # dig bemacom.se @213.182.0.X
> 
> ; <<>> DiG 9.18.8 <<>> bemacom.se @213.182.0.X
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25874
> 
> 
> zone bemacom.se when querying a 9.16.34 resolver:
> 
> # dig bemacom.se @213.182.0.X
> 
> ; <<>> DiG 9.18.8 <<>> bemacom.se @213.182.0.X
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5496
> 
> 
> 
> The NS for bemacom.se seem to be dnsX.elbrev.com and I'm seeing FORMERR 
> messages in the BIND 9.18.8 logs:
> 
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns2.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns2.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns2.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns2.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
> 'dns2.elbrev.com/AAAA/IN': 92.33.14.98#53
> Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com/AAAA/IN': 194.17.14.66#53
> Oct 20 12:46:51 frontend1 named[2577193]: 

FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Andreas S. Kerber]

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 bit.  Here's an example:


zone bemacom.se when querying a 9.18.8 resolver (status: SERVFAIL):

# dig bemacom.se @213.182.0.X

; <<>> DiG 9.18.8 <<>> bemacom.se @213.182.0.X
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25874


zone bemacom.se when querying a 9.16.34 resolver:

# dig bemacom.se @213.182.0.X

; <<>> DiG 9.18.8 <<>> bemacom.se @213.182.0.X
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5496



The NS for bemacom.se seem to be dnsX.elbrev.com and I'm seeing FORMERR 
messages in the BIND 9.18.8 logs:

Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 194.17.14.66#53


According to dnscheck.ripe.net the zones NS don't support EDNS0: 
https://dnscheck.ripe.net/result/93ee1d56756536dd

I could manually fix this by adding those IP adresses with a server statement 
to named.conf like this: "server x.x.x.x { edns no; };"
Since this is only one a example of about 10 so far, I chose to downgrade one 
of my resolvers back to 9.16.X, to catch those faulty zones.

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..



-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[Tony Finch]

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 and
> queries for it are being rewritten - thus encouraging them to move
> sooner rather than later to a new name/zone.

Thinking about it further, the way this kind of leak can occur is if a
user visits a malicious web site which is only partially blocked; the bad
guys might then be able to work out that blocking has occurred - whether
by Safe Browsing blocks, or AV blocks, or RPZ blocks, etc. usw.

I think I prefer not to send traffic to malicious DNS servers if I can
avoid it, and rely on the threat intelligence bods to keep on top of
things (that's why we pay them the big bucks).

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
the quest for freedom and justice can never end
___
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: Saurabh: Not getting the answer with AAAA record. Error FORMERR resolving 'gim8.pl/AAAA/IN comes.

[Cathy Almond]

On 22/05/2018 15:58, Tony Finch wrote:
> Saurabh Srivastava  wrote:
> 
>> I have faced an issue on my RPZ Server.
>> I have added the A record Entry &  record entry for some domains.
>> The RPZ Policy is running fine.
>> But the werired response that i am getting 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.132.112#53
> 
> RPZ is a bit weird because it performs the query as usual, then applies
> its rewrite rules. In this case, the original query fails, so there isn't
> an  in the answer to rewrite.
> 
> You can set the `qname-wait-recurse` option, so that RPZ will skip
> recursion when it is able to rewrite a response based only on the query.
> You might also want to set `break-dnssec` to make it ignore the DO bit.
> 
> If you are using `qname-wait-recurse`, you need to be careful about the
> order of the policy zones listed in your RPZ clause so that it works as
> expected: you should keep qname and client-ip triggers in separate zones,
> and list those zones first - other RPZ rewrite rules force recursion to
> happen.
> 
> The manual says the reason for this weird behaviour is: "not resolving the
> requested name can leak the fact that response policy rewriting is in use
> and that the name is listed in a policy zone to operators of servers for
> listed names." If you are worried about that, it implies that (sadly) you
> have an adversarial relationship with your users, since they are the only
> people who can observe this information leak.
> 
> In my opinion your users should be able to trust you, so you should be
> up-front about DNS rewriting, and you should explain to your users clearly
> what your rewrite policy is. And if you have documented your policy,
> there's no information leak because the information is in the documentation.
> 
> Tony.
> 

Hi Tony,

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 and
queries for it are being rewritten - thus encouraging them to move
sooner rather than later to a new name/zone.

Cathy
___
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: Saurabh: Not getting the answer with AAAA record. Error FORMERR resolving 'gim8.pl/AAAA/IN comes.

[Tony Finch]

Saurabh Srivastava <jp.saur...@gmail.com> wrote:

> I have faced an issue on my RPZ Server.
> I have added the A record Entry &  record entry for some domains.
> The RPZ Policy is running fine.
> But the werired response that i am getting 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.132.112#53

RPZ is a bit weird because it performs the query as usual, then applies
its rewrite rules. In this case, the original query fails, so there isn't
an  in the answer to rewrite.

You can set the `qname-wait-recurse` option, so that RPZ will skip
recursion when it is able to rewrite a response based only on the query.
You might also want to set `break-dnssec` to make it ignore the DO bit.

If you are using `qname-wait-recurse`, you need to be careful about the
order of the policy zones listed in your RPZ clause so that it works as
expected: you should keep qname and client-ip triggers in separate zones,
and list those zones first - other RPZ rewrite rules force recursion to
happen.

The manual says the reason for this weird behaviour is: "not resolving the
requested name can leak the fact that response policy rewriting is in use
and that the name is listed in a policy zone to operators of servers for
listed names." If you are worried about that, it implies that (sadly) you
have an adversarial relationship with your users, since they are the only
people who can observe this information leak.

In my opinion your users should be able to trust you, so you should be
up-front about DNS rewriting, and you should explain to your users clearly
what your rewrite policy is. And if you have documented your policy,
there's no information leak because the information is in the documentation.

Tony.
-- 
f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/
promote human rights and open government
___
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

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

[Saurabh Srivastava]

Dear Bind-Users,

Greetings of the Day!!!

I have faced an issue on my RPZ Server.
I have added the A record Entry &  record entry for some domains.
The RPZ Policy is running fine.
But the werired response that i am getting 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.
When I have run the dig query using any option, it has shown me the A
record as well as  record too.
I have facing this issue while querying following domains:
1.  gim8.pl
2.  ns-cnc1.qq.com
3.  ns-tel1.qq.com

Lets take an example of first doamin:
I have sharing the dig o/p here with different options:
A. querying A Record:
-
; <<>> DiG 9.10.3-P3 <<>> gim8.pl
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19768
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;gim8.pl.   IN  A

;; ANSWER SECTION:
gim8.pl.5   IN  A   10.40.124.13

;; AUTHORITY SECTION:
rpz.nkn.in. 3600IN  NS  ns1.rpz.nkn.in.

;; ADDITIONAL SECTION:
ns1.rpz.nkn.in. 3600IN  A   10.199.88.2

;; Query time: 4406 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue May 22 17:22:57 IST 2018
;; MSG SIZE  rcvd: 96

B: Query the  Record:
-
; <<>> DiG 9.10.3-P3 <<>> gim8.pl 
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60907
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;gim8.pl.   IN  

;; Query time: 517 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue May 22 17:24:13 IST 2018
;; MSG SIZE  rcvd: 36

C: Query the Record with ANY option:
--
; <<>> DiG 9.10.3-P3 <<>> gim8.pl any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 583
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;gim8.pl.   IN  ANY

;; ANSWER SECTION:
gim8.pl.5   IN  2001:4408:5240::13
gim8.pl.5   IN  A   10.40.124.13

;; AUTHORITY SECTION:
rpz.nkn.in. 3600IN  NS  ns1.rpz.nkn.in.

;; ADDITIONAL SECTION:
ns1.rpz.nkn.in. 3600IN  A   10.199.88.2

;; Query time: 821 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue May 22 17:24:42 IST 2018
;; MSG SIZE  rcvd: 124
 Last o/p shows the  record too...but alone its not working.

I 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 RPZ named[17245]: FORMERR resolving 'gim8.pl//IN':
104.130.132.112#53
May 22 17:25:46 RPZ named[17245]: FORMERR resolving 'gim8.pl//IN':
198.245.62.20#53


Can anyone suggest, what goes wrong & why the RPZ policy is not throuugh
the   result when the dig alone run with  query?


Thanks & Regards,

Saurabh Srivastava,
Mobile: +91-9958399291
Email: jp.saur...@gmail.com
___
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: bind9 Numerous recent - error (FORMERR) resolving 'dns3.registrar-servers.com/AAAA/IN'

[Reindl Harald]

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
resolving dns2.registrar-servers.com.


Thank you. If I recall correctly, 208.67.220.220 was a DNS that came
from a test of list of public DNS IPs several years ago using dig to
test 'Query times' in a script that parsed and computed min, max and
avg, and produced a sorted list. That particular IP ended up in my
forwarders list which is the reason behind the errors.

Checking recent publication of the public DNS server lists, the
opendns address of 208.67.220.220 is no longer listed. (sigh...) The
current best performers


just don't use forwarders, do recursion at your own



signature.asc
Description: OpenPGP digital signature
___
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: bind9 Numerous recent - error (FORMERR) resolving 'dns3.registrar-servers.com/AAAA/IN'

[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
resolving dns2.registrar-servers.com.



Mark,

  Thank you. If I recall correctly, 208.67.220.220 was a DNS that came from a 
test of list of public DNS IPs several years ago using dig to test 'Query times' 
in a script that parsed and computed min, max and avg, and produced a sorted 
list. That particular IP ended up in my forwarders list which is the reason 
behind the errors.


  Checking recent publication of the public DNS server lists, the opendns 
address of 208.67.220.220 is no longer listed. (sigh...) The current best 
performers (throwing out the nonworking and china based IPs) from:


http://portforward.com/networking/dns.htm
http://public-dns.tk/nameserver/us.html

with response times between 38-48 msec, seem to be:

204.97.212.10
173.232.2.245
4.2.2.6
173.232.2.249
173.232.2.236
68.87.66.196
204.11.64.239

  Let's hope this list stays working for another few years.

--
David C. Rankin, J.D.,P.E.
___
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

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

[David C. Rankin]

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 
resolving dns3.registrar-servers.com/: invalid response
May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving 
'dns3.registrar-servers.com//IN': 208.67.222.222#53
May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.222.222#53 
resolving dns4.registrar-servers.com/: invalid response
May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving 
'dns4.registrar-servers.com//IN': 208.67.222.222#53
May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.222.222#53 
resolving dns2.registrar-servers.com/: invalid response
May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving 
'dns2.registrar-servers.com//IN': 208.67.222.222#53
May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.220.220#53 
resolving dns3.registrar-servers.com/: invalid response
May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving 
'dns3.registrar-servers.com//IN': 208.67.220.220#53
May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.220.220#53 
resolving dns4.registrar-servers.com/: invalid response
May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving 
'dns4.registrar-servers.com//IN': 208.67.220.220#53
May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.220.220#53 
resolving dns2.registrar-servers.com/: invalid response
May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving 
'dns2.registrar-servers.com//IN': 208.67.220.220#53


  I'm not sure what to make of it. Is there something that has changed 
requiring an update on my end, or is this just an issue with the remote? I have 
an older bind 9.9.1 running.


--
David C. Rankin, J.D.,P.E.
___
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: bind9 Numerous recent - error (FORMERR) resolving 'dns3.registrar-servers.com/AAAA/IN'

[Mark Andrews]

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.

registrar-servers.com.  2898IN  NS  dns1.name-services.com.
registrar-servers.com.  2898IN  NS  dns3.name-services.com.
registrar-servers.com.  2898IN  NS  dns4.name-services.com.
registrar-servers.com.  2898IN  NS  dns5.name-services.com.
registrar-servers.com.  2898IN  NS  dns2.name-services.com.

;; ADDITIONAL SECTION:
dns4.name-services.com. 7   IN  A   98.124.194.1
dns3.name-services.com. 7   IN  A   98.124.193.1
dns5.name-services.com. 7   IN  A   98.124.196.1
dns2.name-services.com. 7   IN  A   98.124.197.1
dns1.name-services.com. 6   IN  A   98.124.192.1

;  DiG 9.11.0pre-alpha  dns2.registrar-servers.com  @208.67.220.220
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 41549
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;dns2.registrar-servers.com.IN  

;; AUTHORITY SECTION:
.   1434IN  SOA a.root-servers.net. 
nstld.verisign-grs.com. 2015052601 1800 900 604800 86400

;; Query time: 19 msec
;; SERVER: 208.67.220.220#53(208.67.220.220)
;; WHEN: Wed May 27 08:24:35 EST 2015
;; MSG SIZE  rcvd: 130


In message 5564f08c.4070...@suddenlinkmail.com, David C. Rankin writes:
 All,
 
I have run bind8 and bind9 for the past 15 years beginning on 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-servers.com/: invalid response
 May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving 
 'dns3.registrar-servers.com//IN': 208.67.222.222#53
 May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.222.222#5
 3 
 resolving dns4.registrar-servers.com/: invalid response
 May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving 
 'dns4.registrar-servers.com//IN': 208.67.222.222#53
 May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.222.222#5
 3 
 resolving dns2.registrar-servers.com/: invalid response
 May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving 
 'dns2.registrar-servers.com//IN': 208.67.222.222#53
 May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.220.220#5
 3 
 resolving dns3.registrar-servers.com/: invalid response
 May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving 
 'dns3.registrar-servers.com//IN': 208.67.220.220#53
 May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.220.220#5
 3 
 resolving dns4.registrar-servers.com/: invalid response
 May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving 
 'dns4.registrar-servers.com//IN': 208.67.220.220#53
 May 26 16:44:24 nirvana named[23136]: DNS format error from 208.67.220.220#5
 3 
 resolving dns2.registrar-servers.com/: invalid response
 May 26 16:44:24 nirvana named[23136]: error (FORMERR) resolving 
 'dns2.registrar-servers.com//IN': 208.67.220.220#53
 
I'm not sure what to make of it. Is there something that has changed 
 requiring an update on my end, or is this just an issue with the remote? I h
 ave 
 an older bind 9.9.1 running.
 
 -- 
 David C. Rankin, J.D.,P.E.
 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscrib
 e from this list
 
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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

FORMERR on packet received from Forwarder

[Levi Pederson]

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.



16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'):
cancelquery
16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'):
add_bad
16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'): try
16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'):
cancelqueries
16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'):
getaddresses
16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'): no
addresses
16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'): done
16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'):
stopeverything
16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'):
cancelqueries
16-Jun-2014 09:53:54.002 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'):
sendevents
16-Jun-2014 09:53:54.003 fetch 0x7f92383471b0 (fctx
0x7f92322d5010(QUERIED-HOSTNAME/NAPTR)): destroyfetch
16-Jun-2014 09:53:54.003 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'):
shutdown
16-Jun-2014 09:53:54.003 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'):
doshutdown
16-Jun-2014 09:53:54.003 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'):
stopeverything
16-Jun-2014 09:53:54.003 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'):
cancelqueries
16-Jun-2014 09:53:54.003 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'):
unlink
16-Jun-2014 09:53:54.003 fctx 0x7f92322d5010(QUERIED-HOSTNAME/NAPTR'):
destroy
16-Jun-2014 09:53:59.611 createfetch: QUERIED-HOSTNAME NAPTR
16-Jun-2014 09:53:59.611 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'):
create
16-Jun-2014 09:53:59.611 log_ns_ttl: fctx 0x7f92321d1010: fctx_create:
QUERIED-HOSTNAME (in 'HOSTNAME'?): 1 85178
16-Jun-2014 09:53:59.611 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'): join
16-Jun-2014 09:53:59.611 fetch 0x7f92383471b0 (fctx
0x7f92321d1010(QUERIED-HOSTNAME/NAPTR)): created
16-Jun-2014 09:53:59.611 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'): start
16-Jun-2014 09:53:59.611 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'): try
16-Jun-2014 09:53:59.611 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'):
cancelqueries
16-Jun-2014 09:53:59.611 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'):
getaddresses
16-Jun-2014 09:53:59.611 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'): query
16-Jun-2014 09:53:59.611 resquery 0x7f92321d8010 (fctx
0x7f92321d1010(QUERIED-HOSTNAME/NAPTR)): send
16-Jun-2014 09:53:59.612 resquery 0x7f92321d8010 (fctx
0x7f92321d1010(QUERIED-HOSTNAME/NAPTR)): sent
16-Jun-2014 09:53:59.612 resquery 0x7f92321d8010 (fctx
0x7f92321d1010(QUERIED-HOSTNAME/NAPTR)): udpconnected
16-Jun-2014 09:53:59.612 resquery 0x7f92321d8010 (fctx
0x7f92321d1010(QUERIED-HOSTNAME/NAPTR)): senddone
16-Jun-2014 09:53:59.683 resquery 0x7f92321d8010 (fctx
0x7f92321d1010(QUERIED-HOSTNAME/NAPTR)): response
16-Jun-2014 09:53:59.683 received packet:
;; -HEADER- opcode: QUERY, status: NOERROR, id:  45393
;; flags: qr rd; QUESTION: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;QUERIED-HOSTNAME.IN NAPTR

;; AUTHORITY SECTION:
CORRECT-UPSTREAMREAPONSE 86400 IN NS  CORRECT-UPSTREAMREAPONSE
CORRECT-UPSTREAMREAPONSE 86400 IN NS  CORRECT-UPSTREAMREAPONSE

;; ADDITIONAL SECTION:
CORRECT-UPSTREAMREAPONSE 86400 IN A CORRECT-Resolved-IP
CORRECT-UPSTREAMREAPONSE 86400 IN A CORRECT-Resolved-IP


16-Jun-2014 09:53:59.683 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'):
noanswer_response
16-Jun-2014 09:53:59.683 log_ns_ttl: fctx 0x7f92321d1010:
noanswer_response: QUERIED-HOSTNAME (in 'HOSTNAME'?): 1 85178
16-Jun-2014 09:53:59.683 fctx 0x7f92321d1010: trimming ttl of HOSTNAME/NS
for QUERIED-HOSTNAME/NAPTR: 86400 - 85178
16-Jun-2014 09:53:59.683 DNS format error from 65.119.117.13#53 resolving
QUERIED-HOSTNAME/NAPTR for client 66.171.30.193#15000: non-improving
referral
16-Jun-2014 09:53:59.683 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'):
cancelquery
16-Jun-2014 09:53:59.683 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'):
add_bad
16-Jun-2014 09:53:59.683 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'): try
16-Jun-2014 09:53:59.683 fctx 0x7f92321d1010(QUERIED-HOSTNAME/NAPTR'): query

The big thing to NOTE is we're recieving the UPSTREAM packet back with the
correct information!  But alas our system says there is a formatting error.
 Does anyone have a quick response to this odd issue?

Thank you,


*Levi Pederson*
Mankato Networks LLC
cell | 612.481.0769
work | 612.787.7392
levipeder...@mankatonetworks.net
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

Re: FORMERR on packet received from Forwarder

[Tony Finch]

Levi Pederson levipeder...@mankatonetworks.net 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
forward queries on an authoritative server.

When BIND forwards to an upstream server it makes recursive queries and
expects the upstream server to return a complete response. Your upstream
server is not a recursive server: there is no RA bit set in the response,
and the response is a referral. BIND is objecting to a non-improving
referral which means that BIND thinks the server is authoritative for
zone X but the referral says zone X is elsewhere.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Fisher: North or northwest 5 to 7, occasionally gale 8 at first. Moderate or
rough. Fair. Good.
___
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

[Noel Butler]

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 Settings\admin\dig\9.9.2-P2dig www.alarmspecs.com 
 @172.31.123.6
 
 ;  DiG 9.9.2-P2  www.alarmspecs.com @172.31.123.6
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: FORMERR, id: 47614
 ;; flags: qr rd ra ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
 


~$ dig www.alarmspecs.com

;  DiG 9.9.2  www.alarmspecs.com
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 50631
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 3





signature.asc
Description: This is a digitally signed message part
___
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

[Pascal]

Sorry, I guess I wasn't clear enough.  I was just using 
www.alarmspecs.com as a sample domain.  As you see, that domain is 
working fine.


My problem is 172.31.123.6 is a NetWare DNS server.  I maintain several 
in different locations and trees.  Any time I try to use Dig 9.9 against 
one 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

[Pascal]

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 command line to disable EDNS.

Mark

___
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

[Kevin Darcy]

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: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 command line to disable EDNS.

Mark

___
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





___
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: lame-servers: error (FORMERR) resolving [something]

[Daniele]

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? And why 'named'
doesn't understand the responses from these cache-servers?


2013/1/18 Mark Andrews ma...@isc.org


 In message 
 cal_2sc1szstumpmfceuqrf87nqwe+5n30qvguds7q-4g6va...@mail.gmail.com,
 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, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14
 
  ;; QUESTION SECTION:
  ;.INNS
 
  ;; ANSWER SECTION:
  .243196INNSl.root-servers.net.
  .243196INNSg.root-servers.net.
  .243196INNSk.root-servers.net.
  .243196INNSa.root-servers.net.
  .243196INNSe.root-servers.net.
  .243196INNSd.root-servers.net.
  .243196INNSc.root-servers.net.
  .243196INNSi.root-servers.net.
  .243196INNSf.root-servers.net.
  .243196INNSh.root-servers.net.
  .243196INNSj.root-servers.net.
  .243196INNSb.root-servers.net.
  .243196INNSm.root-servers.net.
 
  ;; ADDITIONAL SECTION:
  a.root-servers.net.502389INA198.41.0.4
  a.root-servers.net.508720IN2001:503:ba3e::2:30
  b.root-servers.net.502640INA192.228.79.201
  c.root-servers.net.502640INA192.33.4.12
  d.root-servers.net.523851INA199.7.91.13
  e.root-servers.net.502640INA192.203.230.10
  f.root-servers.net.581030INA192.5.5.241
  f.root-servers.net.236384IN2001:500:2f::f
  g.root-servers.net.502640INA192.112.36.4
  i.root-servers.net.502640INA192.36.148.17
  i.root-servers.net.555890IN2001:7fe::53
  j.root-servers.net.537043INA192.58.128.30
  j.root-servers.net.236384IN2001:503:c27::2:30
  k.root-servers.net.502394INA193.0.14.129
 
  ;; Query time: 62 msec
  ;; SERVER: 198.41.0.4#53(198.41.0.4)
  ;; WHEN: Fri Jan 18 15:38:42 2013
  ;; MSG SIZE  rcvd: 500

 Below is what the answer should look like.  The TTLs should be these
 values shown below (6 days and 1000 hours) and aa should be set
 in the flags and ra should NOT be set in the flags.  You have a
 transparent DNS caching proxy between you and the Internet as a
 whole.

 Some routers try to be helpful by maintaining a DNS cache.  You
 need to turn the feature off.  Otherwise it is your ISP doing it
 and you need to get them to stop mucking with your DNS queries.

 Named issues non-recursive queries and sticking a normal recursive
 server in the path that pays attention to the setting of rd doesn't
 result in getting the required answers back.

 Mark

 ;  DiG 9.10.0pre-alpha  ns . +norec +noedns @198.41.0.4
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 18118
 ;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14

 ;; QUESTION SECTION:
 ;.  IN  NS

 ;; ANSWER SECTION:
 .   518400  IN  NS  c.root-servers.net.
 .   518400  IN  NS  m.root-servers.net.
 .   518400  IN  NS  b.root-servers.net.
 .   518400  IN  NS  f.root-servers.net.
 .   518400  IN  NS  j.root-servers.net.
 .   518400  IN  NS  g.root-servers.net.
 .   518400  IN  NS  i.root-servers.net.
 .   518400  IN  NS  h.root-servers.net.
 .   518400  IN  NS  d.root-servers.net.
 .   518400  IN  NS  l.root-servers.net.
 .   518400  IN  NS  a.root-servers.net.
 .   518400  IN  NS  e.root-servers.net.
 .   518400  IN  NS  k.root-servers.net.

 ;; ADDITIONAL SECTION:
 a.root-servers.net. 360 IN  A   198.41.0.4
 a.root-servers.net. 360 IN  2001:503:ba3e::2:30
 b.root-servers.net. 360 IN  A   192.228.79.201
 c.root-servers.net. 360 IN  A   192.33.4.12
 d.root-servers.net. 360 IN  A   199.7.91.13
 d.root-servers.net. 360 IN  2001:500:2d::d
 e.root-servers.net. 360 IN  A   192.203.230.10
 f.root-servers.net. 

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

[Warren Kumari]

On Jan 22, 2013, at 5:18 AM, Daniele d.imbrog...@gmail.com 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 arrive to the real root-server (first of all), or is 
 it processed by some other cache-server on the path? And why 'named' doesn't 
 understand the responses from these cache-servers?
 
 
 2013/1/18 Mark Andrews ma...@isc.org
 
 In message 
 cal_2sc1szstumpmfceuqrf87nqwe+5n30qvguds7q-4g6va...@mail.gmail.com, 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, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14
 
  ;; QUESTION SECTION:
  ;.INNS
 
  ;; ANSWER SECTION:
  .243196INNSl.root-servers.net.
  .243196INNSg.root-servers.net.
  .243196INNSk.root-servers.net.
  .243196INNSa.root-servers.net.
  .243196INNSe.root-servers.net.
  .243196INNSd.root-servers.net.
  .243196INNSc.root-servers.net.
  .243196INNSi.root-servers.net.
  .243196INNSf.root-servers.net.
  .243196INNSh.root-servers.net.
  .243196INNSj.root-servers.net.
  .243196INNSb.root-servers.net.
  .243196INNSm.root-servers.net.
 
  ;; ADDITIONAL SECTION:
  a.root-servers.net.502389INA198.41.0.4
  a.root-servers.net.508720IN2001:503:ba3e::2:30
  b.root-servers.net.502640INA192.228.79.201
  c.root-servers.net.502640INA192.33.4.12
  d.root-servers.net.523851INA199.7.91.13
  e.root-servers.net.502640INA192.203.230.10
  f.root-servers.net.581030INA192.5.5.241
  f.root-servers.net.236384IN2001:500:2f::f
  g.root-servers.net.502640INA192.112.36.4
  i.root-servers.net.502640INA192.36.148.17
  i.root-servers.net.555890IN2001:7fe::53
  j.root-servers.net.537043INA192.58.128.30
  j.root-servers.net.236384IN2001:503:c27::2:30
  k.root-servers.net.502394INA193.0.14.129
 
  ;; Query time: 62 msec
  ;; SERVER: 198.41.0.4#53(198.41.0.4)
  ;; WHEN: Fri Jan 18 15:38:42 2013
  ;; MSG SIZE  rcvd: 500
 
 Below is what the answer should look like.  The TTLs should be these
 values shown below (6 days and 1000 hours) and aa should be set
 in the flags and ra should NOT be set in the flags.  You have a
 transparent DNS caching proxy between you and the Internet as a
 whole.
 
 Some routers try to be helpful by maintaining a DNS cache.  You
 need to turn the feature off.  Otherwise it is your ISP doing it
 and you need to get them to stop mucking with your DNS queries.
 
 Named issues non-recursive queries and sticking a normal recursive
 server in the path that pays attention to the setting of rd doesn't
 result in getting the required answers back.
 
 Mark
 
 ;  DiG 9.10.0pre-alpha  ns . +norec +noedns @198.41.0.4
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 18118
 ;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14
 
 ;; QUESTION SECTION:
 ;.  IN  NS
 
 ;; ANSWER SECTION:
 .   518400  IN  NS  c.root-servers.net.
 .   518400  IN  NS  m.root-servers.net.
 .   518400  IN  NS  b.root-servers.net.
 .   518400  IN  NS  f.root-servers.net.
 .   518400  IN  NS  j.root-servers.net.
 .   518400  IN  NS  g.root-servers.net.
 .   518400  IN  NS  i.root-servers.net.
 .   518400  IN  NS  h.root-servers.net.
 .   518400  IN  NS  d.root-servers.net.
 .   518400  IN  NS  l.root-servers.net.
 .   518400  IN  NS  a.root-servers.net.
 .   518400  IN  NS  e.root-servers.net.
 .   518400  IN  NS  k.root-servers.net.
 
 ;; ADDITIONAL SECTION:
 a.root-servers.net. 360 IN  A   198.41.0.4
 a.root-servers.net. 360 IN  2001:503:ba3e::2:30
 b.root-servers.net. 360 IN  A   192.228.79.201
 c.root-servers.net. 360 IN  A   192.33.4.12
 d.root-servers.net. 360 IN  A   199.7.91.13
 d.root-servers.net. 

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

[Daniele]

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 SECTION:
;.INNS

;; ANSWER SECTION:
.243196INNSl.root-servers.net.
.243196INNSg.root-servers.net.
.243196INNSk.root-servers.net.
.243196INNSa.root-servers.net.
.243196INNSe.root-servers.net.
.243196INNSd.root-servers.net.
.243196INNSc.root-servers.net.
.243196INNSi.root-servers.net.
.243196INNSf.root-servers.net.
.243196INNSh.root-servers.net.
.243196INNSj.root-servers.net.
.243196INNSb.root-servers.net.
.243196INNSm.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.502389INA198.41.0.4
a.root-servers.net.508720IN2001:503:ba3e::2:30
b.root-servers.net.502640INA192.228.79.201
c.root-servers.net.502640INA192.33.4.12
d.root-servers.net.523851INA199.7.91.13
e.root-servers.net.502640INA192.203.230.10
f.root-servers.net.581030INA192.5.5.241
f.root-servers.net.236384IN2001:500:2f::f
g.root-servers.net.502640INA192.112.36.4
i.root-servers.net.502640INA192.36.148.17
i.root-servers.net.555890IN2001:7fe::53
j.root-servers.net.537043INA192.58.128.30
j.root-servers.net.236384IN2001:503:c27::2:30
k.root-servers.net.502394INA193.0.14.129

;; Query time: 62 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Fri Jan 18 15:38:42 2013
;; MSG SIZE  rcvd: 500

/

;  DiG 9.8.1-P1  ns . +norec +edns=0 @198.41.0.4
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 41815
;; flags: qr ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 19

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.INNS

;; ANSWER SECTION:
.243102INNSf.root-servers.net.
.243102INNSh.root-servers.net.
.243102INNSi.root-servers.net.
.243102INNSd.root-servers.net.
.243102INNSb.root-servers.net.
.243102INNSl.root-servers.net.
.243102INNSm.root-servers.net.
.243102INNSe.root-servers.net.
.243102INNSa.root-servers.net.
.243102INNSc.root-servers.net.
.243102INNSj.root-servers.net.
.243102INNSk.root-servers.net.
.243102INNSg.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.502295INA198.41.0.4
a.root-servers.net.508626IN2001:503:ba3e::2:30
b.root-servers.net.502546INA192.228.79.201
c.root-servers.net.502546INA192.33.4.12
d.root-servers.net.523757INA199.7.91.13
e.root-servers.net.502546INA192.203.230.10
f.root-servers.net.580936INA192.5.5.241
f.root-servers.net.236290IN2001:500:2f::f
g.root-servers.net.502546INA192.112.36.4
i.root-servers.net.502546INA192.36.148.17
i.root-servers.net.555796IN2001:7fe::53
j.root-servers.net.536949INA192.58.128.30
j.root-servers.net.236290IN2001:503:c27::2:30
k.root-servers.net.502300INA193.0.14.129
k.root-servers.net.75429IN2001:7fd::1
l.root-servers.net.502546INA199.7.83.42
m.root-servers.net.502546INA202.12.27.33
m.root-servers.net.30760IN2001:dc3::35

;; Query time: 274 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Fri Jan 18 15:40:15 2013
;; MSG SIZE  rcvd: 599

///

;  DiG 9.8.1-P1  ns . +norec +dnssec @198.41.0.4
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 2272
;; flags: qr ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 20

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;.INNS

;; ANSWER SECTION:
.243053INNSd.root-servers.net.
.243053INNSf.root-servers.net.
.243053INNSh.root-servers.net.
.243053INNSa.root-servers.net.
.243053INNSb.root-servers.net.
.243053INNS  

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

[Warren Kumari]

On Jan 18, 2013, at 9:44 AM, Daniele d.imbrog...@gmail.com 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

dig ns org +norec +noedns @198.41.0.4

Now add in EDNS support

dig ns org +norec +edns=0 @198.41.0.4

Now add in DNSEC support

dig ns org +norec +dnssec @198.41.0.4

And then:
  dig ns org +norec  +dnssec +tcp  @198.41.0.4

The responses in your previous mail all looked sane, as Leonard mentioned a 
packet dump would be helpful, so can you do:

sudo tcpdump -w queries.pcap  -s  -i eth0 port 53

and then your original query ( dig +trace +nodnssec www.isc.org )

and then kill the tcpdump and send us the queries.pcap file (or, capture in 
wireshark and do the same)

W

 
 
 
 2013/1/17 Mark Andrews ma...@isc.org
 
 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 responses to all these queries
 --
 Mark Andrews, ISC
 1 Seymour St., Dundas Valley, NSW 2117, Australia
 PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
 
 output.txt___
 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

---
Schizophrenia beats being alone.


___
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: lame-servers: error (FORMERR) resolving [something]

[Mark Andrews]

In message 
cal_2sc1szstumpmfceuqrf87nqwe+5n30qvguds7q-4g6va...@mail.gmail.com, 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, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14
 
 ;; QUESTION SECTION:
 ;.INNS
 
 ;; ANSWER SECTION:
 .243196INNSl.root-servers.net.
 .243196INNSg.root-servers.net.
 .243196INNSk.root-servers.net.
 .243196INNSa.root-servers.net.
 .243196INNSe.root-servers.net.
 .243196INNSd.root-servers.net.
 .243196INNSc.root-servers.net.
 .243196INNSi.root-servers.net.
 .243196INNSf.root-servers.net.
 .243196INNSh.root-servers.net.
 .243196INNSj.root-servers.net.
 .243196INNSb.root-servers.net.
 .243196INNSm.root-servers.net.
 
 ;; ADDITIONAL SECTION:
 a.root-servers.net.502389INA198.41.0.4
 a.root-servers.net.508720IN2001:503:ba3e::2:30
 b.root-servers.net.502640INA192.228.79.201
 c.root-servers.net.502640INA192.33.4.12
 d.root-servers.net.523851INA199.7.91.13
 e.root-servers.net.502640INA192.203.230.10
 f.root-servers.net.581030INA192.5.5.241
 f.root-servers.net.236384IN2001:500:2f::f
 g.root-servers.net.502640INA192.112.36.4
 i.root-servers.net.502640INA192.36.148.17
 i.root-servers.net.555890IN2001:7fe::53
 j.root-servers.net.537043INA192.58.128.30
 j.root-servers.net.236384IN2001:503:c27::2:30
 k.root-servers.net.502394INA193.0.14.129
 
 ;; Query time: 62 msec
 ;; SERVER: 198.41.0.4#53(198.41.0.4)
 ;; WHEN: Fri Jan 18 15:38:42 2013
 ;; MSG SIZE  rcvd: 500
 
Below is what the answer should look like.  The TTLs should be these
values shown below (6 days and 1000 hours) and aa should be set
in the flags and ra should NOT be set in the flags.  You have a
transparent DNS caching proxy between you and the Internet as a
whole.

Some routers try to be helpful by maintaining a DNS cache.  You
need to turn the feature off.  Otherwise it is your ISP doing it
and you need to get them to stop mucking with your DNS queries.

Named issues non-recursive queries and sticking a normal recursive
server in the path that pays attention to the setting of rd doesn't
result in getting the required answers back.

Mark

;  DiG 9.10.0pre-alpha  ns . +norec +noedns @198.41.0.4
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 18118
;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14

;; QUESTION SECTION:
;.  IN  NS

;; ANSWER SECTION:
.   518400  IN  NS  c.root-servers.net.
.   518400  IN  NS  m.root-servers.net.
.   518400  IN  NS  b.root-servers.net.
.   518400  IN  NS  f.root-servers.net.
.   518400  IN  NS  j.root-servers.net.
.   518400  IN  NS  g.root-servers.net.
.   518400  IN  NS  i.root-servers.net.
.   518400  IN  NS  h.root-servers.net.
.   518400  IN  NS  d.root-servers.net.
.   518400  IN  NS  l.root-servers.net.
.   518400  IN  NS  a.root-servers.net.
.   518400  IN  NS  e.root-servers.net.
.   518400  IN  NS  k.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net. 360 IN  A   198.41.0.4
a.root-servers.net. 360 IN  2001:503:ba3e::2:30
b.root-servers.net. 360 IN  A   192.228.79.201
c.root-servers.net. 360 IN  A   192.33.4.12
d.root-servers.net. 360 IN  A   199.7.91.13
d.root-servers.net. 360 IN  2001:500:2d::d
e.root-servers.net. 360 IN  A   192.203.230.10
f.root-servers.net. 360 IN  A   192.5.5.241
f.root-servers.net. 360 IN  2001:500:2f::f
g.root-servers.net. 360 IN  A   192.112.36.4
h.root-servers.net. 360 IN  A   128.63.2.53
h.root-servers.net. 360 IN  2001:500:1::803f:235
i.root-servers.net. 360 IN  A   192.36.148.17
i.root-servers.net. 360 IN  2001:7fe::53

;; Query time: 182 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Sat Jan 19 08:06:22 

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

[Daniele]

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;
};

category default {
default_logfile;
};

category lame-servers {null;};
};

options {
directory /var/cache/bind;

dnssec-validation auto;

auth-nxdomain no;# conform to RFC1035
listen-on-v6 { any; };
};

and the default zones (not shown here).

This is the output of `dig +trace +nodnssec www.isc.org`
;  DiG 9.8.1-P1  +trace +nodnssec www.isc.org
;; global options: +cmd
.360INNSM.ROOT-SERVERS.NET.
.360INNSK.ROOT-SERVERS.NET.
.360INNSG.ROOT-SERVERS.NET.
.360INNSL.ROOT-SERVERS.NET.
.360INNSB.ROOT-SERVERS.NET.
.360INNSE.ROOT-SERVERS.NET.
.360INNSA.ROOT-SERVERS.NET.
.360INNSF.ROOT-SERVERS.NET.
.360INNSJ.ROOT-SERVERS.NET.
.360INNSH.ROOT-SERVERS.NET.
.360INNSC.ROOT-SERVERS.NET.
.360INNSI.ROOT-SERVERS.NET.
.360INNSD.ROOT-SERVERS.NET.
dig: couldn't get address for 'M.ROOT-SERVERS.NET': not found


During `dig` operations, using Wireshark I can see outgoing packets to port
53 and incoming ones from port 53

The default policy of my firewall, configured via `iptables`, is to accept
everything (I'm on VirtualBox); the only rule is to MASQUERADE outgoing
packets for NAT reasons (this box is the gateway of my private network).

What's wrong?

2013/1/15 Chris Thompson c...@cam.ac.uk

 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

 dig +trace +nodnssec www.isc.org

 --
 Chris Thompson
 Email: c...@cam.ac.uk

___
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: lame-servers: error (FORMERR) resolving [something]

[Warren Kumari]

On Jan 17, 2013, at 9:04 AM, Daniele d.imbrog...@gmail.com 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;
 print-severity yes;
 print-time yes;
 };
 
 category default {
 default_logfile;
 };
 
 category lame-servers {null;};
 };
 
 options {
 directory /var/cache/bind;
 
 dnssec-validation auto;
 
 auth-nxdomain no;# conform to RFC1035
 listen-on-v6 { any; };
 };
 
 and the default zones (not shown here).
 
 This is the output of `dig +trace +nodnssec www.isc.org`
 ;  DiG 9.8.1-P1  +trace +nodnssec www.isc.org
 ;; global options: +cmd
 .360INNSM.ROOT-SERVERS.NET.
 .360INNSK.ROOT-SERVERS.NET.
 .360INNSG.ROOT-SERVERS.NET.
 .360INNSL.ROOT-SERVERS.NET.
 .360INNSB.ROOT-SERVERS.NET.
 .360INNSE.ROOT-SERVERS.NET.
 .360INNSA.ROOT-SERVERS.NET.
 .360INNSF.ROOT-SERVERS.NET.
 .360INNSJ.ROOT-SERVERS.NET.
 .360INNSH.ROOT-SERVERS.NET.
 .360INNSC.ROOT-SERVERS.NET.
 .360INNSI.ROOT-SERVERS.NET.
 .360INNSD.ROOT-SERVERS.NET.
 dig: couldn't get address for 'M.ROOT-SERVERS.NET': not found
 
 
 During `dig` operations, using Wireshark I can see outgoing packets to port 
 53 and incoming ones from port 53

What size is the return packet? Do you have anything in the path that might be 
helpfully trying to monkey with the replies? 
What do you get for just 'dig NS .' and 'dig NS org.'?

Does anything change if you do 'dig +nodnssec +noedns NS .' versus 'dig 
+nodnssec NS .'

Including the comment bit from digs output (;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 17 09:18:57 2013
;; MSG SIZE  rcvd: 512


would help.

W


 
 The default policy of my firewall, configured via `iptables`, is to accept 
 everything (I'm on VirtualBox); the only rule is to MASQUERADE outgoing 
 packets for NAT reasons (this box is the gateway of my private network).
 
 What's wrong?
 
 2013/1/15 Chris Thompson c...@cam.ac.uk
 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
 
 dig +trace +nodnssec www.isc.org
 
 -- 
 Chris Thompson
 Email: c...@cam.ac.uk
 
 ___
 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

-- 
Militant Agnostic -- I don't know and you don't either...



___
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: lame-servers: error (FORMERR) resolving [something]

[Daniele]

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

;; Query time: 1474 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 17 15:28:04 2013
;; MSG SIZE  rcvd: 17

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

;; QUESTION SECTION:
;org.INNS

;; Query time: 467 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 17 15:29:47 2013
;; MSG SIZE  rcvd: 21

Output for `dig +nodnssec +noedns NS .` is the same as the previous, as for
`dig +nodnssec NS .`

The return packets have size of 743 bytes and they all contains infos about
NS for root zone.


2013/1/17 Warren Kumari war...@kumari.net


 On Jan 17, 2013, at 9:04 AM, Daniele d.imbrog...@gmail.com 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;
  print-severity yes;
  print-time yes;
  };
 
  category default {
  default_logfile;
  };
 
  category lame-servers {null;};
  };
 
  options {
  directory /var/cache/bind;
 
  dnssec-validation auto;
 
  auth-nxdomain no;# conform to RFC1035
  listen-on-v6 { any; };
  };
 
  and the default zones (not shown here).
 
  This is the output of `dig +trace +nodnssec www.isc.org`
  ;  DiG 9.8.1-P1  +trace +nodnssec www.isc.org
  ;; global options: +cmd
  .360INNSM.ROOT-SERVERS.NET.
  .360INNSK.ROOT-SERVERS.NET.
  .360INNSG.ROOT-SERVERS.NET.
  .360INNSL.ROOT-SERVERS.NET.
  .360INNSB.ROOT-SERVERS.NET.
  .360INNSE.ROOT-SERVERS.NET.
  .360INNSA.ROOT-SERVERS.NET.
  .360INNSF.ROOT-SERVERS.NET.
  .360INNSJ.ROOT-SERVERS.NET.
  .360INNSH.ROOT-SERVERS.NET.
  .360INNSC.ROOT-SERVERS.NET.
  .360INNSI.ROOT-SERVERS.NET.
  .360INNSD.ROOT-SERVERS.NET.
  dig: couldn't get address for 'M.ROOT-SERVERS.NET': not found
 
 
  During `dig` operations, using Wireshark I can see outgoing packets to
 port 53 and incoming ones from port 53

 What size is the return packet? Do you have anything in the path that
 might be helpfully trying to monkey with the replies?
 What do you get for just 'dig NS .' and 'dig NS org.'?

 Does anything change if you do 'dig +nodnssec +noedns NS .' versus 'dig
 +nodnssec NS .'

 Including the comment bit from digs output (;; Query time: 0 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Thu Jan 17 09:18:57 2013
 ;; MSG SIZE  rcvd: 512


 would help.

 W


 
  The default policy of my firewall, configured via `iptables`, is to
 accept everything (I'm on VirtualBox); the only rule is to MASQUERADE
 outgoing packets for NAT reasons (this box is the gateway of my private
 network).
 
  What's wrong?
 
  2013/1/15 Chris Thompson c...@cam.ac.uk
  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
 
  dig +trace +nodnssec www.isc.org
 
  --
  Chris Thompson
  Email: c...@cam.ac.uk
 
  ___
  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

 --
 Militant Agnostic -- I don't know and you don't either...




___
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: lame-servers: error (FORMERR) resolving [something]

[Daniele]

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 d.imbrog...@gmail.com

 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

 ;; Query time: 1474 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Thu Jan 17 15:28:04 2013
 ;; MSG SIZE  rcvd: 17

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

 ;; QUESTION SECTION:
 ;org.INNS

 ;; Query time: 467 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Thu Jan 17 15:29:47 2013
 ;; MSG SIZE  rcvd: 21

 Output for `dig +nodnssec +noedns NS .` is the same as the previous, as
 for `dig +nodnssec NS .`

 The return packets have size of 743 bytes and they all contains infos
 about NS for root zone.


 2013/1/17 Warren Kumari war...@kumari.net


 On Jan 17, 2013, at 9:04 AM, Daniele d.imbrog...@gmail.com 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;
  print-severity yes;
  print-time yes;
  };
 
  category default {
  default_logfile;
  };
 
  category lame-servers {null;};
  };
 
  options {
  directory /var/cache/bind;
 
  dnssec-validation auto;
 
  auth-nxdomain no;# conform to RFC1035
  listen-on-v6 { any; };
  };
 
  and the default zones (not shown here).
 
  This is the output of `dig +trace +nodnssec www.isc.org`
  ;  DiG 9.8.1-P1  +trace +nodnssec www.isc.org
  ;; global options: +cmd
  .360INNSM.ROOT-SERVERS.NET.
  .360INNSK.ROOT-SERVERS.NET.
  .360INNSG.ROOT-SERVERS.NET.
  .360INNSL.ROOT-SERVERS.NET.
  .360INNSB.ROOT-SERVERS.NET.
  .360INNSE.ROOT-SERVERS.NET.
  .360INNSA.ROOT-SERVERS.NET.
  .360INNSF.ROOT-SERVERS.NET.
  .360INNSJ.ROOT-SERVERS.NET.
  .360INNSH.ROOT-SERVERS.NET.
  .360INNSC.ROOT-SERVERS.NET.
  .360INNSI.ROOT-SERVERS.NET.
  .360INNSD.ROOT-SERVERS.NET.
  dig: couldn't get address for 'M.ROOT-SERVERS.NET': not found
 
 
  During `dig` operations, using Wireshark I can see outgoing packets to
 port 53 and incoming ones from port 53

 What size is the return packet? Do you have anything in the path that
 might be helpfully trying to monkey with the replies?
 What do you get for just 'dig NS .' and 'dig NS org.'?

 Does anything change if you do 'dig +nodnssec +noedns NS .' versus 'dig
 +nodnssec NS .'

 Including the comment bit from digs output (;; Query time: 0 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Thu Jan 17 09:18:57 2013
 ;; MSG SIZE  rcvd: 512


 would help.

 W


 
  The default policy of my firewall, configured via `iptables`, is to
 accept everything (I'm on VirtualBox); the only rule is to MASQUERADE
 outgoing packets for NAT reasons (this box is the gateway of my private
 network).
 
  What's wrong?
 
  2013/1/15 Chris Thompson c...@cam.ac.uk
  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
 
  dig +trace +nodnssec www.isc.org
 
  --
  Chris Thompson
  Email: c...@cam.ac.uk
 
  ___
  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

 --
 Militant Agnostic -- I don't know and you don't either...





___
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: lame-servers: error (FORMERR) resolving [something]

[Mark Andrews]

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 responses to all these queries
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: lame-servers: error (FORMERR) resolving [something]

[Chris Thompson]

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

dig +trace +nodnssec www.isc.org

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: lame-servers: error (FORMERR) resolving [something]

[Daniele]

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 Lyle Giese l...@lcrcomputer.net

  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 l...@lcrcomputer.net

   On 01/09/13 08:39, Daniele wrote:

  2013/1/9 Phil Mayers p.may...@imperial.ac.uk

 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,
 `nameserver 8.8.8.8`) the lookups and any action on the Internet
 succeed.


  No, this assumption is not valid.


  I meant that I can reach the Internet and, vice versa, the Internet can
 reach my terminal.


   ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
 unsubscribe from this list

 bind-users mailing 
 listbind-us...@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users

  Recursive queries that named does for a client are different than your
 machine as a dns client reaching out to Google's recursive service.

 You need to have UDP  TCP port 53 open to your recursive server(the one
 running named) first of all.  And if any network element within your
 network limits the size of UDP packets, you will have problems with EDNS0
 queries.

 On this box running named, try this:

 dig +trace www.msn.com

 dig +trace imperial.ac.uk

 After dig gets a copy of the root servers from the local named, it will
 do the same type of queries that a recursive name server does.

 Lyle Giese
 LCR Computer Services, Inc.


   Saying port 53 is open because you can telnet to it from a local
 computer is a very limited test.

 1) Telnet only use TCP, UDP is the primary/first communication channel DNS
 uses.

 2) The router between this computer and the Internet is not at fault?  You
 have done no tests to prove that one way or the other.

 Do a couple of dig +trace runs and see what that shows.  And try some any
 queries to a dnssec enable domain.


 Lyle Giese
 LCR Computer Services, Inc.


 ___
 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

___
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: lame-servers: error (FORMERR) resolving [something]

[Shane Kerr]

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 +trace +dnssec www.isc.org

This will ask for DNSSEC, which will mean enabling EDNS0 and getting
bigger response packets, both of which can cause problems with broken
middleboxes (although BIND 9 should work even in those cases).

Cheers,

--
Shane

On Monday, 2013-01-14 10:44:44 +0100, 
Daniele d.imbrog...@gmail.com wrote:
 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?
___
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: lame-servers: error (FORMERR) resolving [something]

[Leonard Mills]

Packet dumps at your edge would likely be helpful to your diagnosis.

At your firewall (or other edge appliance) you are seeing successful UDP from a 
high port on your system (DNS client) to port 53 on the server and a reply in 
the opposite direction.  You are not seeing success from an external client 
high port to 53 to on your server.

The two operations are absolutely disjoint when you deal with firewall tuples.

Hope this helps,

Len






 From: Daniele d.imbrog...@gmail.com
To: bind-users@lists.isc.org 
Sent: Monday, January 14, 2013 1:44 AM
Subject: 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?___
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: lame-servers: error (FORMERR) resolving [something]

[Daniele]

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 l...@lcrcomputer.net

  On 01/09/13 08:39, Daniele wrote:

 2013/1/9 Phil Mayers p.may...@imperial.ac.uk

 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,
 `nameserver 8.8.8.8`) the lookups and any action on the Internet succeed.


  No, this assumption is not valid.


  I meant that I can reach the Internet and, vice versa, the Internet can
 reach my terminal.


 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
 from this list

 bind-users mailing 
 listbind-us...@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users

  Recursive queries that named does for a client are different than your
 machine as a dns client reaching out to Google's recursive service.

 You need to have UDP  TCP port 53 open to your recursive server(the one
 running named) first of all.  And if any network element within your
 network limits the size of UDP packets, you will have problems with EDNS0
 queries.

 On this box running named, try this:

 dig +trace www.msn.com

 dig +trace imperial.ac.uk

 After dig gets a copy of the root servers from the local named, it will do
 the same type of queries that a recursive name server does.

 Lyle Giese
 LCR Computer Services, Inc.


 ___
 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

___
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: lame-servers: error (FORMERR) resolving [something]

[Lyle Giese]

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 l...@lcrcomputer.net mailto:l...@lcrcomputer.net

On 01/09/13 08:39, Daniele wrote:

2013/1/9 Phil Mayers p.may...@imperial.ac.uk
mailto:p.may...@imperial.ac.uk

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,
`nameserver 8.8.8.8`) the lookups and any action on the
Internet succeed.


No, this assumption is not valid.


I meant that I can reach the Internet and, vice versa, the
Internet can reach my terminal.


___
Please visithttps://lists.isc.org/mailman/listinfo/bind-users  to 
unsubscribe from this list

bind-users mailing list
bind-users@lists.isc.org  mailto:bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Recursive queries that named does for a client are different than
your machine as a dns client reaching out to Google's recursive
service.

You need to have UDP  TCP port 53 open to your recursive
server(the one running named) first of all.  And if any network
element within your network limits the size of UDP packets, you
will have problems with EDNS0 queries.

On this box running named, try this:

dig +trace www.msn.com http://www.msn.com

dig +trace imperial.ac.uk http://imperial.ac.uk

After dig gets a copy of the root servers from the local named, it
will do the same type of queries that a recursive name server does.

Lyle Giese
LCR Computer Services, Inc.


Saying port 53 is open because you can telnet to it from a local 
computer is a very limited test.


1) Telnet only use TCP, UDP is the primary/first communication channel 
DNS uses.


2) The router between this computer and the Internet is not at fault?  
You have done no tests to prove that one way or the other.


Do a couple of dig +trace runs and see what that shows.  And try some 
any queries to a dnssec enable domain.


Lyle Giese
LCR Computer Services, Inc.

___
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: lame-servers: error (FORMERR) resolving [something]

[Daniele]

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,
`nameserver 8.8.8.8`) the lookups and any action on the Internet succeed.

BIND9 configuration is the default one.
I deleted all local zones that I added (even if internal lookups worked
correctly). Now there are only default zones (root, localhost,
127.in-addr.arpa, 0.in-addr.arpa, 255.in-addr.arpa).
Options are the default ones
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 the presence of “dnssec-validaton“ line?


2013/1/8 Matus UHLAR - fantomas uh...@fantomas.sk

  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 sh...@isc.org

 When acting as a recursive resolver, BIND 9 follows the chain of
 delegation from the root, contacting name servers identified for each
 domain on the way.

 In this case, one of those name servers returned a packet that BIND 9
 did not like for some reason - a FORMat ERRor. The offending server is
 marked as lame since it cannot answer queries for the domain in
 question.

 The message should also include the IP address of the server that it is
 going to at the end of the line.


 On 08.01.13 13:05, Daniele wrote:

 So it's not my responsibility to resolve the problem, right?

 The point is that, sometimes, I can't resolve an address because of this
 lame servers, and dig (for example) fails.

 Is it possible?


 possible, yes. but I would not be sure, since there are many different
 reasons for the lookups to fail.

 and there are few web services that check proper DNS functionality. I
 advise
 check with more of them, since there's none I would completely trust.


 --
 Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
 Warning: I wish NOT to receive e-mail advertising to this address.
 Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
 Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
 __**_
 Please visit 
 https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-usersto
  unsubscribe from this list

 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-users

___
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: lame-servers: error (FORMERR) resolving [something]

[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 '/etc/resolv.conf' is, for example,
`nameserver 8.8.8.8`) the lookups and any action on the Internet succeed.



No, this assumption is not valid.

A recursive resolver emits different queries, and different kinds of 
queries, to those a client sends *to* a recursive resolver. Most 
notably, EDNS is enabled and this large IP/UDP fragments can be 
expected, particularly if you are doing DNSSEC validation.


Whether that's your problem I don't know. But you can't assume the 
network path is good just because you can query googles public recursive 
DNS.

___
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: lame-servers: error (FORMERR) resolving [something]

[Daniele]

2013/1/9 Phil Mayers p.may...@imperial.ac.uk

 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,
 `nameserver 8.8.8.8`) the lookups and any action on the Internet succeed.


 No, this assumption is not valid.


I meant that I can reach the Internet and, vice versa, the Internet can
reach my terminal.
___
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: lame-servers: error (FORMERR) resolving [something]

[Lyle Giese]

On 01/09/13 08:39, Daniele wrote:
2013/1/9 Phil Mayers p.may...@imperial.ac.uk 
mailto:p.may...@imperial.ac.uk


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,
`nameserver 8.8.8.8`) the lookups and any action on the
Internet succeed.


No, this assumption is not valid.


I meant that I can reach the Internet and, vice versa, the Internet 
can reach my terminal.



___
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
Recursive queries that named does for a client are different than your 
machine as a dns client reaching out to Google's recursive service.


You need to have UDP  TCP port 53 open to your recursive server(the one 
running named) first of all.  And if any network element within your 
network limits the size of UDP packets, you will have problems with 
EDNS0 queries.


On this box running named, try this:

dig +trace www.msn.com

dig +trace imperial.ac.uk

After dig gets a copy of the root servers from the local named, it will 
do the same type of queries that a recursive name server does.


Lyle Giese
LCR Computer Services, Inc.

___
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

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

[Daniele]

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?

Thank you!
___
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: lame-servers: error (FORMERR) resolving [something]

[Shane Kerr]

Daniele,

On Tuesday, 2013-01-08 09:49:57 +0100, 
Daniele d.imbrog...@gmail.com 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 trying to resolve).
 
 What does it means?

When acting as a recursive resolver, BIND 9 follows the chain of
delegation from the root, contacting name servers identified for each
domain on the way.

In this case, one of those name servers returned a packet that BIND 9
did not like for some reason - a FORMat ERRor. The offending server is
marked as lame since it cannot answer queries for the domain in
question.

The message should also include the IP address of the server that it is
going to at the end of the line.

 And how can I resolve this problem?

In theory, you could try contacting the administrator of the server at
that IP address, and letting her know that there is some technical
problem so she can resolve it.

In practice, this is a worthless message and you should disable it in
named.conf:

logging {
category lame-servers { null; };
};



A couple of questions to everyone on the list...

1. Should ISC change the default logging for lame servers to disabled?

2. Are there other usually worthless default log messages we should
   disable?


Cheers,

--
Shane
___
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: lame-servers: error (FORMERR) resolving [something]

[Daniele]

Thank you.

So it's not my responsibility to resolve the problem, right?

The point is that, sometimes, I can't resolve an address because of this
lame servers, and dig (for example) fails.

Is it possible?


2013/1/8 Shane Kerr sh...@isc.org

 Daniele,

 On Tuesday, 2013-01-08 09:49:57 +0100,
 Daniele d.imbrog...@gmail.com 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 trying to resolve).
 
  What does it means?

 When acting as a recursive resolver, BIND 9 follows the chain of
 delegation from the root, contacting name servers identified for each
 domain on the way.

 In this case, one of those name servers returned a packet that BIND 9
 did not like for some reason - a FORMat ERRor. The offending server is
 marked as lame since it cannot answer queries for the domain in
 question.

 The message should also include the IP address of the server that it is
 going to at the end of the line.

  And how can I resolve this problem?

 In theory, you could try contacting the administrator of the server at
 that IP address, and letting her know that there is some technical
 problem so she can resolve it.

 In practice, this is a worthless message and you should disable it in
 named.conf:

 logging {
 category lame-servers { null; };
 };



 A couple of questions to everyone on the list...

 1. Should ISC change the default logging for lame servers to disabled?

 2. Are there other usually worthless default log messages we should
disable?


 Cheers,

 --
 Shane

___
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: lame-servers: error (FORMERR) resolving [something]

[Matus UHLAR - fantomas]

 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 sh...@isc.org

When acting as a recursive resolver, BIND 9 follows the chain of
delegation from the root, contacting name servers identified for each
domain on the way.

In this case, one of those name servers returned a packet that BIND 9
did not like for some reason - a FORMat ERRor. The offending server is
marked as lame since it cannot answer queries for the domain in
question.

The message should also include the IP address of the server that it is
going to at the end of the line.


On 08.01.13 13:05, Daniele wrote:

So it's not my responsibility to resolve the problem, right?

The point is that, sometimes, I can't resolve an address because of this
lame servers, and dig (for example) fails.

Is it possible?


possible, yes. but I would not be sure, since there are many different
reasons for the lookups to fail.

and there are few web services that check proper DNS functionality. I advise
check with more of them, since there's none I would completely trust.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
___
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: Understanding cause of DNS format error (FORMERR)

[Sam Wilson]

In article mailman.1145.1340719800.63724.bind-us...@lists.isc.org,
 Barry Margolin bar...@alum.mit.edu wrote:

 In article mailman.1144.1340718471.63724.bind-us...@lists.isc.org,
  Sam Wilson sam.wil...@ed.ac.uk 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 server is proving that it has 
  authority to tell you that the information doesn't exist.
 
 More important, the SOA record contains the TTL that should be used for 
 the negative cache entry.

More important for the operation of the DNS, but I'd think less 
important from the point of view of manual debugging, like we're doing 
here.

  The fact that looking for nonexistent data for 
  vlasext.partners.extranet.microsoft.com returns the 
  partners.extranet.microsoft.com SOA record shows that the vlasext 
  subdomain has not been delegated.  The servers should therefore be able 
  to offer an authoritative answer for data that does exist for 
  vlasext.etc... but they don't.
 
 This type of inconsistency often suggests a DNS-based load balancer is 
 involved.

I wondered that but it's not consistent with earlier results in the 
thread which suggested Windows DNS server for at least one of them.  An 
old version of fpdns (someone might like to try a newer one) concurs:

$ for i in 0 1 2 3 ; do fpdns dns1$i.one.microsoft.com  ; done
fingerprint (dns10.one.microsoft.com, 131.107.125.65): Microsoft \
Windows 2003 
fingerprint (dns11.one.microsoft.com, 94.245.124.49): Microsoft \
Windows 2003 
fingerprint (dns12.one.microsoft.com, 207.46.55.10): Microsoft \
Windows 2003 
fingerprint (dns13.one.microsoft.com, 65.55.31.17): Microsoft \
Windows 2003 
$ fpdns -v
fpdns.pl version 0.9.1


Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Understanding cause of DNS format error (FORMERR)

[Gabriele Paggi]

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 of misconfiguration could lead to SOA records for hosts on
the internet to be privately addressed?
Misconfigured split horizon server?

[...]
 The authority for zero-answer responses such as
 vlasext.partners.extranet.microsoft.com/IN/ is the SOA for
 partners.extranet.microsoft.com

What do you mean with authority for zero-answer responses?
What is the normal authority response I should get when querying for
non-existent records?
I'm trying a few third level domains (e.g. fabric.readthedocs.org) and
I most of the time get as authority section the SOA for the second
level domain (readthedocs.org).

Thanks!

 It's all rather horrible.

I concur!

Gabriele
___
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: Understanding cause of DNS format error (FORMERR)

[Sam Wilson]

In article mailman.1143.1340715359.63724.bind-us...@lists.isc.org,
 Gabriele Paggi gabriele@gmail.com 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 those origins are
  privately addressed.
 
 Which kind of misconfiguration could lead to SOA records for hosts on
 the internet to be privately addressed?
 Misconfigured split horizon server?

It's not difficult for private addresses to escape. It need not actually 
be a problem.  It's not necessarily a problem here but it does make it 
difficult to work out what's going on.

 [...]
  The authority for zero-answer responses such as
  vlasext.partners.extranet.microsoft.com/IN/ is the SOA for
  partners.extranet.microsoft.com
 
 What do you mean with authority for zero-answer responses?
 What is the normal authority response I should get when querying for
 non-existent records?

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 server is proving that it has 
authority to tell you that the information doesn't exist.

The fact that looking for nonexistent data for 
vlasext.partners.extranet.microsoft.com returns the 
partners.extranet.microsoft.com SOA record shows that the vlasext 
subdomain has not been delegated.  The servers should therefore be able 
to offer an authoritative answer for data that does exist for 
vlasext.etc... but they don't.

 I'm trying a few third level domains (e.g. fabric.readthedocs.org) and
 I most of the time get as authority section the SOA for the second
 level domain (readthedocs.org).
 
 Thanks!

dig domain +trace will also (normally) show you how the tree is 
delegated, though it doesn't print out the SOA records.  Try 
www.automation.ucs.ed.ac.uk.

  It's all rather horrible.
 
 I concur!

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Understanding cause of DNS format error (FORMERR)

[Barry Margolin]

In article mailman.1144.1340718471.63724.bind-us...@lists.isc.org,
 Sam Wilson sam.wil...@ed.ac.uk 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 server is proving that it has 
 authority to tell you that the information doesn't exist.

More important, the SOA record contains the TTL that should be used for 
the negative cache entry.

 
 The fact that looking for nonexistent data for 
 vlasext.partners.extranet.microsoft.com returns the 
 partners.extranet.microsoft.com SOA record shows that the vlasext 
 subdomain has not been delegated.  The servers should therefore be able 
 to offer an authoritative answer for data that does exist for 
 vlasext.etc... but they don't.

This type of inconsistency often suggests a DNS-based load balancer is 
involved.

-- 
Barry Margolin
Arlington, MA
___
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: Understanding cause of DNS format error (FORMERR)

[Tony Finch]

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
does not exist therefore partners.extranet.microsoft.com cannot exist.


;  DiG 9.9.1-P1  +noedns @ns1.msft.net. partners.extranet.microsoft.com 
ns
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 9931
;; flags: qr rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;partners.extranet.microsoft.com. INNS

;; ANSWER SECTION:
partners.extranet.microsoft.com. 3600 IN NS dns12.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns10.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns13.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns11.one.microsoft.com.

;; ADDITIONAL SECTION:
dns12.one.microsoft.com. 3600   IN  A   207.46.55.10
dns10.one.microsoft.com. 3600   IN  A   131.107.125.65
dns13.one.microsoft.com. 3600   IN  A   65.55.31.17
dns11.one.microsoft.com. 3600   IN  A   94.245.124.49

;; Query time: 159 msec
;; SERVER: 2a01:111:2005::1:1#53(2a01:111:2005::1:1)
;; WHEN: Mon Jun 25 12:38:51 2012
;; MSG SIZE  rcvd: 197


;  DiG 9.9.1-P1  +edns=0 @ns1.msft.net. partners.extranet.microsoft.com 
ns
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: FORMERR, id: 20875
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;partners.extranet.microsoft.com. INNS

;; Query time: 142 msec
;; SERVER: 2a01:111:2005::1:1#53(2a01:111:2005::1:1)
;; WHEN: Mon Jun 25 12:38:57 2012
;; MSG SIZE  rcvd: 60


;  DiG 9.9.1-P1  +noedns @ns1.msft.net extranet.microsoft.com ns
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 141
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;extranet.microsoft.com.IN  NS

;; AUTHORITY SECTION:
microsoft.com.  3600IN  SOA ns1.msft.net.
msnhst.microsoft.com. 2012062205 300 600 2419200 3600

;; Query time: 142 msec
;; SERVER: 2a01:111:2005::1:1#53(2a01:111:2005::1:1)
;; WHEN: Mon Jun 25 12:44:44 2012
;; MSG SIZE  rcvd: 95


Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Sole, Lundy, Fastnet: Southeast at first in Lundy and Fastnet, otherwise
southwest, 4 or 5. Slight or moderate, occasionally rough in west Sole.
Occasional rain or drizzle, fog patches. Moderate, occasionally very poor.
___
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: Understanding cause of DNS format error (FORMERR)

[Tony Finch]

Carsten Strotmann (private) c...@strotmann.de 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 query.


;  DiG 9.9.1-P1  +noad +qr @ns1.msft.net. 
partners.extranet.microsoft.com ns
; (2 servers found)
;; global options: +cmd
;; Sending:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 3331
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;partners.extranet.microsoft.com. INNS

;; Got answer:
;; -HEADER- opcode: QUERY, status: FORMERR, id: 3331
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;partners.extranet.microsoft.com. INNS

;; Query time: 142 msec
;; SERVER: 2a01:111:2005::1:1#53(2a01:111:2005::1:1)
;; WHEN: Mon Jun 25 12:57:06 2012
;; MSG SIZE  rcvd: 60


;  DiG 9.9.1-P1  +qr @ns1.msft.net. partners.extranet.microsoft.com ns
; (2 servers found)
;; global options: +cmd
;; Sending:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 21060
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;partners.extranet.microsoft.com. INNS

;; Got answer:
;; -HEADER- opcode: QUERY, status: FORMERR, id: 21060
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;partners.extranet.microsoft.com. INNS

;; Query time: 142 msec
;; SERVER: 2a01:111:2005::1:1#53(2a01:111:2005::1:1)
;; WHEN: Mon Jun 25 12:56:22 2012
;; MSG SIZE  rcvd: 60


Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Dogger: Northwest 5 or 6 becoming variable 3 or 4. Moderate, becoming slight
in west. Showers. Moderate or good.
___
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: Understanding cause of DNS format error (FORMERR)

[Sam Wilson]

In article mailman.1121.1340625284.63724.bind-us...@lists.isc.org,
 Tony Finch d...@dotat.at 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 queried and those origins are 
privately addressed.

If I query dns1[0-3].one.microsoft.com for 
vlasext.partners.extranet.microsoft.com/IN/A I get answers with no AA 
bit set and a decreasing TTL as if the data were cached.  It does not 
appear that vlasext.partners.extranet.microsoft.com is delegated itself 
so it's not cached answers from a child zone.  The authority for 
zero-answer responses such as 
vlasext.partners.extranet.microsoft.com/IN/ is the SOA for 
partners.extranet.microsoft.com

It's all rather horrible.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Understanding cause of DNS format error (FORMERR)

[Carsten Strotmann (private)]

-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 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.extranet.microsoft.com:
 That doesn't explain why I get a correct reply to my query if I use
 a Windows DNS or one of the Google DNS (what software do they run?)
 or my home ISP DNS (UPC, Netherlands).

what we see is that we get different responses for the NS record set
for partners.extranet.microsoft.com:

1) a list of 4 NS records (dns10/11/12/13.one.microsoft.com) with
public route-able IPv4 addresses, answer size is around 200 byte

2) a list of 18 NS records
(-ptnr-dc-02.partners.extranet.microsoft.com.) with private RFC
1918 addresses and an answer size of above 800 byte. These are
internal domain controllers.

The answer size of 800 bytes can create the FORMERR issue.

I'm using BIND 9.9.1(-P1) and Unbound 1.4.17 here. Today I'm getting
answer type 1) from my home and also from a machine in the datacenter,
yesterday I'm seen answer type 2) and the FORMERR.

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:

;; -HEADER- opcode: QUERY, status: FORMERR, id: 30679
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

I have no explanation of this issue at the moment.

To my knowledge Google is using a homegrown DNS resolver, not BIND.

Best regards

Carsten Strotmann

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/mxZ4ACgkQsUJ3c+pomYHc6QCfeONcluurcPOX4dMqMWDm4pnf
SlgAnAxlJ1UQRSdE+WgN28RYVBmo/N03
=DT/n
-END PGP SIGNATURE-
___
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: Understanding cause of DNS format error (FORMERR)

[Carsten Strotmann (private)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Jeffry,

On 6/22/12 1:25 PM, Spain, Dr. Jeffry A. wrote:
 From what I observed I would conclude that dns11.one.microsoft.com
 is a Windows DNS server since it behaves like mine except for the
 AA flag not being set in theirs.

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 good to be able to isolate
that issue soon (so that it can be fixed before Windows 2012 is released).

 The missing AA flag 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 yesterday, but shows the same good
answers that you report today.

What is see today when I send a direct query to
dns10.one.microsoft.com. (or dns11/12/13) is that both AA
(Authoritative Answer) and AD (Authenticated Data) flags are set, but
the zone does not seem to be DNSSEC signed (no RRSIGs, no DNSKEY):

bash-3.2# dig partners.extranet.microsoft.com. INNS
@dns11.one.microsoft.com. +dnssec

;  DiG 9.9.1-P1  partners.extranet.microsoft.com. IN NS
@dns11.one.microsoft.com. +dnssec
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 40230
;; flags: qr aa ra ad; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;partners.extranet.microsoft.com. INNS

;; ANSWER SECTION:
partners.extranet.microsoft.com. 10 IN  NS  dns11.one.microsoft.com.
partners.extranet.microsoft.com. 10 IN  NS  dns10.one.microsoft.com.
partners.extranet.microsoft.com. 10 IN  NS  dns13.one.microsoft.com.
partners.extranet.microsoft.com. 10 IN  NS  dns12.one.microsoft.com.
dns11.one.microsoft.com. 10 IN  A   94.245.124.49
dns10.one.microsoft.com. 10 IN  A   131.107.125.65
dns13.one.microsoft.com. 10 IN  A   65.55.31.17
dns12.one.microsoft.com. 10 IN  A   207.46.55.10

;; Query time: 37 msec
;; SERVER: 94.245.124.49#53(94.245.124.49)
;; WHEN: Sun Jun 24 10:00:54 2012
;; MSG SIZE  rcvd: 228


Having AD-Flag set on an non-DNSSEC zone might be a protocol
violation, and that might be the cause of FORMERR.

Best regards

Carsten Strotmann
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/myqQACgkQsUJ3c+pomYGzyQCdF6q+TeWUmA4TWYgiOn6pA0ha
HHgAn2Amo54kuiNEIJ4hU1kXOwjnY7Pb
=7x6l
-END PGP SIGNATURE-
___
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: Understanding cause of DNS format error (FORMERR)

[Carsten Strotmann (private)]

-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 good to be able to
 isolate that issue soon (so that it can be fixed before Windows
 2012 is released).

I did some tests with the release candidate version of Windows 2012,
and I could not reproduce the error. Windows 2012 internal version
number is 6.2 (6.2.8400) and it does not implement the version.bind
request (returns a NOTIMPL error).

However the dns11.one.microsoft.com DNS server returns

bash-3.2# dig @94.245.124.49 txt ch version.bind
;; Warning: query response not set
;; Warning: Message parser reports malformed message packet.

;  DiG 9.9.1-P1  @94.245.124.49 txt ch version.bind
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 11512
;; flags: aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;version.bind.  CH  TXT

;; ANSWER SECTION:
version.bind.   1476526080 IN   TXT Microsoft DNS
6.1.7601 (1DB14556)

;; Query time: 36 msec
;; SERVER: 94.245.124.49#53(94.245.124.49)
;; WHEN: Sun Jun 24 10:26:11 2012
;; MSG SIZE  rcvd: 76

which is

Version Product Milestone   Service branch
6.1.7600.16xxx  Windows Server 2008 R2  RTM GDR

I'm now setting up a Windows 2008R2 DNS Server with the latest patches
in the test lab to see if I can recreate the issue.

Best regards

Carsten Strotmann

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/m1ioACgkQsUJ3c+pomYEXWQCfYge8Sjqa4YIhztZLZt5Z9PRp
WuYAnjxfbhVJPRm9y31CKPiO/7wCp/fv
=oS8C
-END PGP SIGNATURE-
___
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: Understanding cause of DNS format error (FORMERR)

[Carsten Strotmann (private)]

-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.com:
 

At Men  Mice I've investigated this issue a few weeks ago for one of
our customers. At that point of time, we've seen NS records with
private addresses:

dig ns partners.extranet.microsoft.com.

;  DiG 9.9.1  ns partners.extranet.microsoft.com.
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 53053
;; flags: qr rd ra; QUERY: 1, ANSWER: 18, AUTHORITY: 0, ADDITIONAL: 19

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;partners.extranet.microsoft.com. INNS

;; ANSWER SECTION:
partners.extranet.microsoft.com. 2311 IN NS
db3-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
tk5-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
by1-ptnr-dc-03.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
co2-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
co2-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
sinxtdnsz01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
kaw-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
ph1-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
tk5-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
tk5-ptnr-dc-05.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
rno-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
tk5-ptnr-dc-03.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
sin-ptnr-dc-03.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
sin-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
by1-ptnr-dc-04.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
kaw-ptnr-dc-03.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
db3-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
ph1-ptnr-dc-02.partners.extranet.microsoft.com.

;; ADDITIONAL SECTION:
db3-ptnr-dc-01.partners.extranet.microsoft.com. 1406 IN A 10.251.138.15
tk5-ptnr-dc-02.partners.extranet.microsoft.com. 26 IN A 10.251.51.102
by1-ptnr-dc-03.partners.extranet.microsoft.com. 3505 IN A 10.251.94.15
co2-ptnr-dc-02.partners.extranet.microsoft.com. 2941 IN A 10.251.152.89
co2-ptnr-dc-01.partners.extranet.microsoft.com. 2679 IN A 10.251.152.173
sinxtdnsz01.partners.extranet.microsoft.com. 171 IN A 10.251.168.142
kaw-ptnr-dc-02.partners.extranet.microsoft.com. 1101 IN A 10.251.162.20
ph1-ptnr-dc-01.partners.extranet.microsoft.com. 1417 IN A 10.251.26.11
tk5-ptnr-dc-01.partners.extranet.microsoft.com. 2872 IN A 10.251.51.13
tk5-ptnr-dc-05.partners.extranet.microsoft.com. 137 IN A 10.251.52.143
rno-ptnr-dc-01.partners.extranet.microsoft.com. 1375 IN A 10.251.64.113
tk5-ptnr-dc-03.partners.extranet.microsoft.com. 1564 IN A 10.251.52.124
sin-ptnr-dc-03.partners.extranet.microsoft.com. 882 IN A 10.251.168.67
sin-ptnr-dc-02.partners.extranet.microsoft.com. 505 IN A 10.251.169.47
by1-ptnr-dc-04.partners.extranet.microsoft.com. 2270 IN A 10.251.94.16
kaw-ptnr-dc-03.partners.extranet.microsoft.com. 3461 IN A 10.251.162.193
db3-ptnr-dc-02.partners.extranet.microsoft.com. 1690 IN A 10.251.138.59
ph1-ptnr-dc-02.partners.extranet.microsoft.com. 3018 IN A 10.251.26.12

;; Query time: 1314 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed May 30 18:57:27 2012
;; MSG SIZE  rcvd: 867

The issue seem to differ from the point in the network you are sending
the query, and if the resolving DNS server has only IPv4 or is
dual-stack (IPv4 + IPv6). It seems that the resolution is sometimes
broken, but we have not found the root cause of the issue.

This forward zone proved to be an (ugly, but working) workaround:

zone partners.extranet.microsoft.com IN {
type forward;
forwarders { 131.107.125.65;
 94.245.124.49;
 207.46.55.10;
 65.55.31.17; };
};

We've also informed Microsoft about the issue.

Best regards

Carsten Strotmann
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/le38ACgkQsUJ3c+pomYEwDACgit4MdoFl4rfSCcapx1NMr9cB
1bUAn1QNRM2Gw//EsLYnH1jw1g25IvFl
=hB+P
-END PGP SIGNATURE-
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 

Re: Understanding cause of DNS format error (FORMERR)

[Carsten Strotmann (private)]

-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.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.extranet.microsoft.com:

# dig @ns1.msft.net. partners.extranet.microsoft.com ns

;  DiG 9.9.1-P1  ns @ns1.msft.net. partners.extranet.microsoft.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: FORMERR, id: 30679
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;partners.extranet.microsoft.com. INNS

;; Query time: 167 msec
;; SERVER: 2a01:111:2005::1:1#53(2a01:111:2005::1:1)
;; WHEN: Sat Jun 23 10:47:33 2012
;; MSG SIZE  rcvd: 60

If some other members of this mailing list also see the same FORMERR
(I'm seeing it over IPv4+IPv6), that is is very likely a firewall or
middlebox on the Microsoft side.

Best regards

Carsten Strotmann
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/lhEsACgkQsUJ3c+pomYE8RwCgldVhiIiwuavJGy0VEQAbek5M
d7sAoKg1ny9dN6UMhuXyF1a6diylGyzz
=+PcU
-END PGP SIGNATURE-
___
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: Understanding cause of DNS format error (FORMERR)

[Gabriele Paggi]

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 partners.extranet.microsoft.com:
That doesn't explain why I get a correct reply to my query if I use a 
Windows DNS or one of the Google DNS (what software do they run?) or my 
home ISP DNS (UPC, Netherlands).


stanislao:~ gpaggi$ dig A @62.179.104.196 
vlasext.partners.extranet.microsoft.com +short

70.42.230.20
stanislao:~ gpaggi$ dig A @8.8.8.8 
vlasext.partners.extranet.microsoft.com +short

70.42.230.20

I'm trying to understand if this behavior is specific to the BIND 
release that I'm running (should be the latest available on CentOS 5) 
and what's triggering it.
Increasing debug logging to 90 doesn't tell me what's wrong with the 
reply BIND gets from the Microsoft DNS.



# dig @ns1.msft.net. partners.extranet.microsoft.com ns

[...]


If some other members of this mailing list also see the same FORMERR
(I'm seeing it over IPv4+IPv6), that is is very likely a firewall or
middlebox on the Microsoft side.

I do get indeed a reply from my home connection:

stanislao:~ gpaggi$ dig @ns1.msft.net. partners.extranet.microsoft.com ns

;  DiG 9.6-ESV-R4-P3  @ns1.msft.net. 
partners.extranet.microsoft.com ns

; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 37303
;; flags: qr rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;partners.extranet.microsoft.com. INNS

;; ANSWER SECTION:
partners.extranet.microsoft.com. 3600 IN NSdns13.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NSdns11.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NSdns12.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NSdns10.one.microsoft.com.

;; ADDITIONAL SECTION:
dns13.one.microsoft.com. 3600INA65.55.31.17
dns11.one.microsoft.com. 3600INA94.245.124.49
dns12.one.microsoft.com. 3600INA207.46.55.10
dns10.one.microsoft.com. 3600INA131.107.125.65

;; Query time: 201 msec
;; SERVER: 65.55.37.62#53(65.55.37.62)
;; WHEN: Sun Jun 24 05:51:37 2012
;; MSG SIZE  rcvd: 197


Gabriele

PS. Carsten, apologizes for the double message.

___
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: Understanding cause of DNS format error (FORMERR)

[Gabriele Paggi]

Hello Carsten,


At Men  Mice I've investigated this issue a few weeks ago for one of
our customers. At that point of time, we've seen NS records with
private addresses:
That's interesting but it still doesn't explain why BIND reports a 
format error in the reply it 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 IPv4 or is
dual-stack (IPv4 + IPv6). It seems that the resolution is sometimes
broken, but we have not found the root cause of the issue.
I'm running with only IPv4. May I ask you which version of BIND are you 
running?
Jeffry is not able to reproduce the issue using BIND 9.9.1-P1 and I 
might consider an upgrade.




We've also informed Microsoft about the issue.


I know what the answer is but I'll ask anyway: did you ever get a reply 
/ acknowledgement from them?


Thanks!

Gabriele
___
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: Understanding cause of DNS format error (FORMERR)

[Gabriele Paggi]

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 @94.245.124.49 vlasext.partners.extranet.microsoft.com a also returns the answer 70.42.230.20, but no authority or additional records (except EDNS UDP 4000), and with no AA flag set. On the contrary querying one of my own authoritative servers, also running BIND 9.9.1-P1, for a record for which it is authoritative (dig @ns2.countryday.net countryday.net a) does return the answer along with authority and additional records for the name servers and does have the AA flag set. Finally querying one of my internal Microsoft DNS servers (Windows Server 2008 R2 SP1) for a record for which it is authoritative gives me a correct answer, no authority or additional records (except EDNS UDP 4000), but does 

have the AA flag set.
Thanks. At least I know an upgrade would fix the issue although I still 
don't know what and where the problem is (Microsoft DNS reply? BIND?).

 From what I observed I would conclude that dns11.one.microsoft.com is a 
Windows DNS server since it behaves like mine except for the AA flag not being 
set in theirs. The missing AA flag 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.
I kind of assumed Microsoft would have been running a Windows DNS for 
their domains ;-)


Gabriele



___
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

Understanding cause of DNS format error (FORMERR)

[Gabriele Paggi]

Hello,

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:

Jun 22 11:14:47 res1 named[32210]: DNS format error from
94.245.124.49#53 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.125.65#53 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': 131.107.125.65#53
Jun 22 11:14:47 res1 named[32210]: DNS format error from
207.46.55.10#53 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': 207.46.55.10#53

If I submit the same query to a Windows DNS, or one of the Google DNS,
I do get a reply:
[gpaggi@res1 ~]# dig A @8.8.8.8 vlasext.partners.extranet.microsoft.com +short
70.42.230.20
[gpaggi@res1 ~]#

Is it related to the AA bit strictness[1] ? 94.245.124.49 is
dns11.one.microsoft.com and does indeed reply without setting the AA
bit.
As far as know the 'strictness' was removed in P2, correct me if I'm wrong.

Thanks!

Gabriele


[1] 
http://www.isc.org/community/blog/201007/compatibility-issues-bind-970-and-971
___
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

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

[Nicolas Michel]

Hello guys,

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 with dig on my BIND server, I get a
SERVFAIL return code. When doing the same query on the google DNS (8.8.8.8)
I only get no answer but a return code of NOERROR.

(I only took www.ryanair.com as an exemple but I get the same behavior with
some other records like exch-eu.atdmt.com ...)

*Here is the dig on google DNS*

dig @8.8.8.8  www.ryanair.com

;  DiG 9.9.0  @8.8.8.8  www.ryanair.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 56244
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

*Here is the dig on my bind server:*

dig  www.ryanair.com

;  DiG 9.9.0   www.ryanair.com
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 25197
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

*So I configured a channel with a debug3 severity on my BIND to try
understanding what's happening. Here is the response exerpt:*

25-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/'): 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.ryanair.com/'): add_bad
25-Apr-2012 14:00:52.010 lame-servers: info: FORMERR resolving '
www.ryanair.com//IN': 193.95.148.92#53
25-Apr-2012 14:00:52.010 lame-servers: info: FORMERR resolving '
www.ryanair.com//IN': 193.95.148.92#53
25-Apr-2012 14:00:52.010 lame-servers: info: FORMERR resolving '
www.ryanair.com//IN': 193.95.148.92#53
25-Apr-2012 14:00:52.010 resolver: debug 3: fctx 0x7f0d23be2dc0(
www.ryanair.com/'): try
25-Apr-2012 14:00:52.010 resolver: debug 3: fctx 0x7f0d23be2dc0(
www.ryanair.com/'): query
25-Apr-2012 14:00:52.010 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx
0x7f0d23be2dc0(www.ryanair.com/)): send
25-Apr-2012 14:00:52.010 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx
0x7f0d23be2dc0(www.ryanair.com/)): sent
25-Apr-2012 14:00:52.010 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx
0x7f0d23be2dc0(www.ryanair.com/)): udpconnected
25-Apr-2012 14:00:52.010 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx
0x7f0d23be2dc0(www.ryanair.com/)): senddone
25-Apr-2012 14:00:52.030 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx
0x7f0d23be2dc0(www.ryanair.com/)): response
25-Apr-2012 14:00:52.030 resolver: debug 3: fctx 0x7f0d23be2dc0(
www.ryanair.com/'): cancelquery
25-Apr-2012 14:00:52.030 resolver: debug 3: fctx 0x7f0d23be2dc0(
www.ryanair.com/'): resend
25-Apr-2012 14:00:52.030 resolver: debug 3: fctx 0x7f0d23be2dc0(
www.ryanair.com/'): query
25-Apr-2012 14:00:52.030 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx
0x7f0d23be2dc0(www.ryanair.com/)): send
25-Apr-2012 14:00:52.030 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx
0x7f0d23be2dc0(www.ryanair.com/)): sent
25-Apr-2012 14:00:52.030 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx
0x7f0d23be2dc0(www.ryanair.com/)): udpconnected
25-Apr-2012 14:00:52.030 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx
0x7f0d23be2dc0(www.ryanair.com/)): senddone
25-Apr-2012 14:00:52.047 client: debug 3: client 195.130.131.10#3449: UDP
request
25-Apr-2012 14:00:52.047 client: debug 3: client 195.130.131.10#3449: view
MLT-EXTERNAL: query
25-Apr-2012 14:00:52.047 client: debug 3: client 195.130.131.10#3449: view
MLT-EXTERNAL: send
25-Apr-2012 14:00:52.047 client: debug 3: client 195.130.131.10#3449: view
MLT-EXTERNAL: sendto
25-Apr-2012 14:00:52.047 client: debug 3: client 195.130.131.10#3449: view
MLT-EXTERNAL: senddone
25-Apr-2012 14:00:52.047 client: debug 3: client 195.130.131.10#3449: view
MLT-EXTERNAL: next
25-Apr-2012 14:00:52.047 client: debug 3: client 195.130.131.10#3449: view
MLT-EXTERNAL: endrequest
25-Apr-2012 14:00:52.047 client: debug 3: client @0x7f0d238e0380: udprecv
25-Apr-2012 14:00:52.050 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx
0x7f0d23be2dc0(www.ryanair.com/)): response
25-Apr-2012 14:00:52.050 resolver: debug 3: fctx 0x7f0d23be2dc0(
www.ryanair.com/'): noanswer_response
25-Apr-2012 14:00:52.050 resolver: debug 3: fctx 0x7f0d23be2dc0(
www.ryanair.com/'): cancelquery
25-Apr-2012 14:00:52.050 resolver: debug 3: fctx 0x7f0d23be2dc0(
www.ryanair.com/'): add_bad
25-Apr-2012 14:00:52.050 lame-servers: info: FORMERR resolving '
www.ryanair.com//IN': 62.73.129.182#53
25-Apr-2012 14:00:52.050 lame-servers: info: FORMERR resolving '
www.ryanair.com//IN': 62.73.129.182#53
25-Apr-2012 14:00:52.050 lame-servers: info: FORMERR

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

[Mark Andrews]

The root cause is that the name servers for www.ryanair.com are
misconfigured.  They are returning answers as if they are configured
for ryanair.com (see the SOA record) instead of www.ryanair.com as
can be seen below.

;  DiG 9.9.0rc2  www.ryanair.com  @fr27dns.ryanair.com +noedns
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 22179
;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.ryanair.com.   IN  

;; AUTHORITY SECTION:
ryanair.com.10  IN  SOA fr27dns.ryanair.com. 
root.ryanair.com. 1 10 10 10 10

;; Query time: 366 msec
;; SERVER: 62.134.190.242#53(62.134.190.242)
;; WHEN: Wed Apr 25 23:44:37 2012
;; MSG SIZE  rcvd: 104

Mark

In message 
CAO5znasqndyUCiKOXMb_9GE2oSYQ-nsfg1RSLu7wGedtoGGn=w...@mail.gmail.com
, Nicolas Michel writes:
 --===4894654662251574803==
 Content-Type: multipart/alternative; boundary=f46d0444044c8d70a804be804c64
 
 --f46d0444044c8d70a804be804c64
 Content-Type: text/plain; charset=UTF-8
 
 Hello guys,
 
 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 with dig on my BIND server, I get a
 SERVFAIL return code. When doing the same query on the google DNS (8.8.8.8)
 I only get no answer but a return code of NOERROR.
 
 (I only took www.ryanair.com as an exemple but I get the same behavior with
 some other records like exch-eu.atdmt.com ...)
 
 *Here is the dig on google DNS*
 
 dig @8.8.8.8  www.ryanair.com
 
 ;  DiG 9.9.0  @8.8.8.8  www.ryanair.com
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 56244
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
 
 *Here is the dig on my bind server:*
 
 dig  www.ryanair.com
 
 ;  DiG 9.9.0   www.ryanair.com
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 25197
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
 
 *So I configured a channel with a debug3 severity on my BIND to try
 understanding what's happening. Here is the response exerpt:*
 
 25-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/'): 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.ryanair.com/'): add_bad
 25-Apr-2012 14:00:52.010 lame-servers: info: FORMERR resolving '
 www.ryanair.com//IN': 193.95.148.92#53
 25-Apr-2012 14:00:52.010 lame-servers: info: FORMERR resolving '
 www.ryanair.com//IN': 193.95.148.92#53
 25-Apr-2012 14:00:52.010 lame-servers: info: FORMERR resolving '
 www.ryanair.com//IN': 193.95.148.92#53
 25-Apr-2012 14:00:52.010 resolver: debug 3: fctx 0x7f0d23be2dc0(
 www.ryanair.com/'): try
 25-Apr-2012 14:00:52.010 resolver: debug 3: fctx 0x7f0d23be2dc0(
 www.ryanair.com/'): query
 25-Apr-2012 14:00:52.010 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx
 0x7f0d23be2dc0(www.ryanair.com/)): send
 25-Apr-2012 14:00:52.010 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx
 0x7f0d23be2dc0(www.ryanair.com/)): sent
 25-Apr-2012 14:00:52.010 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx
 0x7f0d23be2dc0(www.ryanair.com/)): udpconnected
 25-Apr-2012 14:00:52.010 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx
 0x7f0d23be2dc0(www.ryanair.com/)): senddone
 25-Apr-2012 14:00:52.030 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx
 0x7f0d23be2dc0(www.ryanair.com/)): response
 25-Apr-2012 14:00:52.030 resolver: debug 3: fctx 0x7f0d23be2dc0(
 www.ryanair.com/'): cancelquery
 25-Apr-2012 14:00:52.030 resolver: debug 3: fctx 0x7f0d23be2dc0(
 www.ryanair.com/'): resend
 25-Apr-2012 14:00:52.030 resolver: debug 3: fctx 0x7f0d23be2dc0(
 www.ryanair.com/'): query
 25-Apr-2012 14:00:52.030 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx
 0x7f0d23be2dc0(www.ryanair.com/)): send
 25-Apr-2012 14:00:52.030 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx
 0x7f0d23be2dc0(www.ryanair.com/)): sent
 25-Apr-2012 14:00:52.030 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx
 0x7f0d23be2dc0(www.ryanair.com/)): udpconnected
 25-Apr-2012 14:00:52.030 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx
 0x7f0d23be2dc0(www.ryanair.com/)): senddone
 25-Apr-2012 14:00:52.047 client: debug 3: client 195.130.131.10#3449: UDP
 request
 25-Apr-2012 14:00:52.047 client: debug 3: client 195.130.131.10#3449: view
 MLT-EXTERNAL: query
 25-Apr-2012 14:00:52.047 client: debug 3

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

[Nicolas Michel]

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 decide wether to raise an error or not in that case?)

Nicolas
___
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: Don't understand why I get a FORMERR (quad-A - ipv6 related)

[Matus UHLAR - fantomas]

In message 
CAO5znasqndyUCiKOXMb_9GE2oSYQ-nsfg1RSLu7wGedtoGGn=w...@mail.gmail.com
, 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 with dig on my BIND server, I get a
SERVFAIL return code. When doing the same query on the google DNS (8.8.8.8)
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 returning answers as if they are configured
for ryanair.com (see the SOA record) instead of www.ryanair.com as
can be seen below.


Hmm, I've been solving their problem years ago. Haven't they still fix 
that?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
REALITY.SYS corrupted. Press any key to reboot Universe.
___
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: Don't understand why I get a FORMERR (quad-A - ipv6 related)

[Alan Clegg]

On 4/25/2012 10:28 AM, Matus UHLAR - fantomas wrote:
 In message
 CAO5znasqndyUCiKOXMb_9GE2oSYQ-nsfg1RSLu7wGedtoGGn=w...@mail.gmail.com
 , 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 returning answers as if they are configured
 for ryanair.com (see the SOA record) instead of www.ryanair.com as
 can be seen below.

 Hmm, I've been solving their problem years ago. Haven't they still fix
 that?

You can get correct  records, but it costs an extra Euro.  :-)

AlanC
-- 
a...@clegg.com | acl...@infoblox.com
  1.919.355.8851



signature.asc
Description: OpenPGP digital signature
___
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: Getting a formerr 'invalid response' for winqual.microsoft.com. but dig +trace works.

[Matt Doughty]

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, which happily serves up the data, and lodge a complaint
with Microsoft to fix their servers, but I want to make sure there
isn't something wrong somewhere in my network that is causing this
problem.

thanks,

--Matt

On Wed, Feb 8, 2012 at 8:05 PM, David Miller dmil...@tiggee.com wrote:
 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 what is going on there,
 and the comment 'responder is insane' leaves something to be desired.
 Any help would be appreciated here. I have included the dig +trace
 output below:

 dig +trace winqual.partners.extranet.microsoft.com.

 ;  DiG 9.7.0-P1  +trace winqual.partners.extranet.microsoft.com.
 ;; global options: +cmd
 .                       518004  IN      NS      j.root-servers.net.
 .                       518004  IN      NS      e.root-servers.net.
 .                       518004  IN      NS      l.root-servers.net.
 .                       518004  IN      NS      c.root-servers.net.
 .                       518004  IN      NS      m.root-servers.net.
 .                       518004  IN      NS      d.root-servers.net.
 .                       518004  IN      NS      b.root-servers.net.
 .                       518004  IN      NS      h.root-servers.net.
 .                       518004  IN      NS      k.root-servers.net.
 .                       518004  IN      NS      a.root-servers.net.
 .                       518004  IN      NS      g.root-servers.net.
 .                       518004  IN      NS      i.root-servers.net.
 .                       518004  IN      NS      f.root-servers.net.
 ;; Received 228 bytes from 172.16.255.1#53(172.16.255.1) in 1 ms

 com.                    172800  IN      NS      h.gtld-servers.net.
 com.                    172800  IN      NS      f.gtld-servers.net.
 com.                    172800  IN      NS      m.gtld-servers.net.
 com.                    172800  IN      NS      g.gtld-servers.net.
 com.                    172800  IN      NS      l.gtld-servers.net.
 com.                    172800  IN      NS      c.gtld-servers.net.
 com.                    172800  IN      NS      d.gtld-servers.net.
 com.                    172800  IN      NS      a.gtld-servers.net.
 com.                    172800  IN      NS      b.gtld-servers.net.
 com.                    172800  IN      NS      i.gtld-servers.net.
 com.                    172800  IN      NS      j.gtld-servers.net.
 com.                    172800  IN      NS      e.gtld-servers.net.
 com.                    172800  IN      NS      k.gtld-servers.net.
 ;; Received 497 bytes from 192.33.4.12#53(c.root-servers.net) in 18 ms

 microsoft.com.          172800  IN      NS      ns3.msft.net.
 microsoft.com.          172800  IN      NS      ns1.msft.net.
 microsoft.com.          172800  IN      NS      ns5.msft.net.
 microsoft.com.          172800  IN      NS      ns2.msft.net.
 microsoft.com.          172800  IN      NS      ns4.msft.net.
 ;; Received 235 bytes from 192.43.172.30#53(i.gtld-servers.net) in 67 ms

 partners.extranet.microsoft.com. 3600 IN NS     dns10.one.microsoft.com.
 partners.extranet.microsoft.com. 3600 IN NS     dns13.one.microsoft.com.
 partners.extranet.microsoft.com. 3600 IN NS     dns11.one.microsoft.com.
 partners.extranet.microsoft.com. 3600 IN NS     dns12.one.microsoft.com.
 ;; Received 236 bytes from 64.4.59.173#53(ns2.msft.net) in 3 ms

 winqual.partners.extranet.microsoft.com. 10 IN A 131.107.97.31
 ;; Received 112 bytes from 131.107.125.65#53(dns10.one.microsoft.com) in
 23 ms


 If I just dig at their servers for NS, I get a trunc and retry over TCP that
 times out.

 If I signal a bufsize, I get back a 777 byte response with NS that don't
 match the parent and an additional full of private 10/8 addresses

 # dig +norecurse +bufsize=1024 ns partners.extranet.microsoft.com
 @dns10.one.microsoft.com.

 ;  DiG 9.8.1  +norecurse +bufsize=1024 ns
 partners.extranet.microsoft.com @dns10.one.microsoft.com.

 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 10678
 ;; flags: qr ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 17

 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags:; udp: 4000
 ;; QUESTION SECTION:
 ;partners.extranet.microsoft.com. IN    NS

 ;; ANSWER SECTION:
 partners.extranet.microsoft.com. 1076 IN NS
 tk5-ptnr-dc-02.partners.extranet.microsoft.com.
 partners.extranet.microsoft.com. 1076 IN NS
 kaw-ptnr-dc-02.partners.extranet.microsoft.com.
 partners.extranet.microsoft.com

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

[Spain, Dr. Jeffry A.]

 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 accept none aa 
 answers from servers that have been listed as being authoritative for the 
 zone.  This allowed the resolver to ignore broken authoritative servers.

 This got relaxed in later release of BIND 9.7.

It's fairly easy for me to deploy a VM and build a particular version of bind. 
Below is your query run on 9.7.0-P1 and 9.7.4-P1. It fails on the former and 
succeeds on the latter, as suggested by Mark Andrews above. Are you in a 
position to upgrade bind? Jeff.


;  DiG 9.7.0-P1  @localhost winqual.partners.extranet.microsoft.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 28201
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;winqual.partners.extranet.microsoft.com. IN A

;; Query time: 1744 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Feb  9 19:36:51 2012
;; MSG SIZE  rcvd: 57


;  DiG 9.7.4-P1  @localhost winqual.partners.extranet.microsoft.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 47557
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;winqual.partners.extranet.microsoft.com. IN A

;; ANSWER SECTION:
winqual.partners.extranet.microsoft.com. 10 IN A 131.107.97.31

;; AUTHORITY SECTION:
partners.extranet.microsoft.com. 3600 IN NS dns11.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns12.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns10.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns13.one.microsoft.com.

;; Query time: 668 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Feb  9 19:15:58 2012
;; MSG SIZE  rcvd: 157

___
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: Getting a formerr 'invalid response' for winqual.microsoft.com. but dig +trace works.

[Matt Doughty]

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. Jeffry A.
spa...@countryday.net wrote:
 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 accept none aa 
 answers from servers that have been listed as being authoritative for the 
 zone.  This allowed the resolver to ignore broken authoritative servers.

 This got relaxed in later release of BIND 9.7.

 It's fairly easy for me to deploy a VM and build a particular version of 
 bind. Below is your query run on 9.7.0-P1 and 9.7.4-P1. It fails on the 
 former and succeeds on the latter, as suggested by Mark Andrews above. Are 
 you in a position to upgrade bind? Jeff.


 ;  DiG 9.7.0-P1  @localhost winqual.partners.extranet.microsoft.com.
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 28201
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

 ;; QUESTION SECTION:
 ;winqual.partners.extranet.microsoft.com. IN A

 ;; Query time: 1744 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Thu Feb  9 19:36:51 2012
 ;; MSG SIZE  rcvd: 57


 ;  DiG 9.7.4-P1  @localhost winqual.partners.extranet.microsoft.com.
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 47557
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0

 ;; QUESTION SECTION:
 ;winqual.partners.extranet.microsoft.com. IN A

 ;; ANSWER SECTION:
 winqual.partners.extranet.microsoft.com. 10 IN A 131.107.97.31

 ;; AUTHORITY SECTION:
 partners.extranet.microsoft.com. 3600 IN NS     dns11.one.microsoft.com.
 partners.extranet.microsoft.com. 3600 IN NS     dns12.one.microsoft.com.
 partners.extranet.microsoft.com. 3600 IN NS     dns10.one.microsoft.com.
 partners.extranet.microsoft.com. 3600 IN NS     dns13.one.microsoft.com.

 ;; Query time: 668 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Thu Feb  9 19:15:58 2012
 ;; MSG SIZE  rcvd: 157




-- 
--Matt
___
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: Getting a formerr 'invalid response' for winqual.microsoft.com. but dig +trace works.

[David Miller]

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 what is going on there,
and the comment 'responder is insane' leaves something to be desired.
Any help would be appreciated here. I have included the dig +trace
output below:

dig +trace winqual.partners.extranet.microsoft.com.

;  DiG 9.7.0-P1  +trace winqual.partners.extranet.microsoft.com.
;; global options: +cmd
.   518004  IN  NS  j.root-servers.net.
.   518004  IN  NS  e.root-servers.net.
.   518004  IN  NS  l.root-servers.net.
.   518004  IN  NS  c.root-servers.net.
.   518004  IN  NS  m.root-servers.net.
.   518004  IN  NS  d.root-servers.net.
.   518004  IN  NS  b.root-servers.net.
.   518004  IN  NS  h.root-servers.net.
.   518004  IN  NS  k.root-servers.net.
.   518004  IN  NS  a.root-servers.net.
.   518004  IN  NS  g.root-servers.net.
.   518004  IN  NS  i.root-servers.net.
.   518004  IN  NS  f.root-servers.net.
;; Received 228 bytes from 172.16.255.1#53(172.16.255.1) in 1 ms

com.172800  IN  NS  h.gtld-servers.net.
com.172800  IN  NS  f.gtld-servers.net.
com.172800  IN  NS  m.gtld-servers.net.
com.172800  IN  NS  g.gtld-servers.net.
com.172800  IN  NS  l.gtld-servers.net.
com.172800  IN  NS  c.gtld-servers.net.
com.172800  IN  NS  d.gtld-servers.net.
com.172800  IN  NS  a.gtld-servers.net.
com.172800  IN  NS  b.gtld-servers.net.
com.172800  IN  NS  i.gtld-servers.net.
com.172800  IN  NS  j.gtld-servers.net.
com.172800  IN  NS  e.gtld-servers.net.
com.172800  IN  NS  k.gtld-servers.net.
;; Received 497 bytes from 192.33.4.12#53(c.root-servers.net) in 18 ms

microsoft.com.  172800  IN  NS  ns3.msft.net.
microsoft.com.  172800  IN  NS  ns1.msft.net.
microsoft.com.  172800  IN  NS  ns5.msft.net.
microsoft.com.  172800  IN  NS  ns2.msft.net.
microsoft.com.  172800  IN  NS  ns4.msft.net.
;; Received 235 bytes from 192.43.172.30#53(i.gtld-servers.net) in 67 ms

partners.extranet.microsoft.com. 3600 IN NS dns10.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns13.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns11.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns12.one.microsoft.com.
;; Received 236 bytes from 64.4.59.173#53(ns2.msft.net) in 3 ms

winqual.partners.extranet.microsoft.com. 10 IN A 131.107.97.31
;; Received 112 bytes from 131.107.125.65#53(dns10.one.microsoft.com) in 23 ms



If I just dig at their servers for NS, I get a trunc and retry over TCP 
that times out.


If I signal a bufsize, I get back a 777 byte response with NS that don't 
match the parent and an additional full of private 10/8 addresses


# dig +norecurse +bufsize=1024 ns partners.extranet.microsoft.com 
@dns10.one.microsoft.com.


;  DiG 9.8.1  +norecurse +bufsize=1024 ns 
partners.extranet.microsoft.com @dns10.one.microsoft.com.

;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 10678
;; flags: qr ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 17

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;partners.extranet.microsoft.com. INNS

;; ANSWER SECTION:
partners.extranet.microsoft.com. 1076 IN NS 
tk5-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 1076 IN NS 
kaw-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 1076 IN NS 
co2-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 1076 IN NS 
co2-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 1076 IN NS 
tk5-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 1076 IN NS 
db3-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 1076 IN NS 
db3-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 1076 IN NS 
tk5-ptnr-dc-03.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 1076 IN NS 

treatment of FORMERR response in a lookup

[Mark Jeftovic]

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.com
Read My Blog:http://markable.com
+1-416-535-8672 ext 225
___
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: FORMERR for wikipedia...

[Chris Thompson]

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. Distinguishing these is a sensitive business,
as RFC 2308 section 2.2 explains.

--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FORMERR for wikipedia...

[Jay Ford]

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't seem to care.  They fail to acknowledge the
problem or to fix the problem.  wikimedia.org are not alone in this.
There are thousands on web sites that return the wrong answers to
 lookups.

Meanwhile everyone wants resolver vendors to make the lookups work.
We can't when the authoritative servers are broken.  It time the
users complained.


That's where I'm going with this, but specific information with a suggested 
fix is usually better than just pointing out that it's broken.  Is it known 
what software and/or config causes this broken behavior?



Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FORMERR for wikipedia...

[Jay Ford]

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 wikimedia.org were informed about this months
ago but they don't seem to care.  They fail to acknowledge the
problem or to fix the problem.  wikimedia.org are not alone in this.
There are thousands on web sites that return the wrong answers to
 lookups.

Meanwhile everyone wants resolver vendors to make the lookups work.
We can't when the authoritative servers are broken.  It time the
users complained.


That's where I'm going with this, but specific information with a 
suggested fix is usually better than just pointing out that it's broken. 
Is it known what software and/or config causes this broken behavior?




It's PowerDNS 2.9.22 that is breaking this, and it will be fixed by 
PowerDNS 3.0 once that's released, and we get around to deploying it.

HTH!


Indeed it helps.  Thanks for the info  good luck with the upgrade.


Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

FORMERR for wikipedia...

[Jay Ford]

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.80.152.130#53

I see this for a variety of domains, including wikipedia.org, yahoodns.net,
officedepot.com,  staples.com.  I did some investigation, including sniffing
the DNS traffic.  The problematic case seems to be names which have CNAMEs to
names in other zones for which the queried record type doesn't exist.  For
example:

   en.wikipedia.org is a CNAME - text.wikimedia.org
   text.wikimedia.org is a CNAME - text.pmtpa.wikimedia.org
   text.pmtpa.wikimedia.org has an A record, but no , TXT...

A query for type= name=en.wikipedia.org returns:

   % dig -t  en.wikipedia.org

   ;  DiG 9.7.3  -t  en.wikipedia.org
   ;; global options: +cmd
   ;; Got answer:
   ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 45218
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

   ;; QUESTION SECTION:
   ;en.wikipedia.org.  IN  

   ;; Query time: 229 msec
   ;; SERVER: ::1#53(::1)
   ;; WHEN: Wed Mar 16 11:34:08 2011
   ;; MSG SIZE  rcvd: 34

The response packet from the wikipedia/wikimedia DNS servers is:

   Internet Protocol, Src: 208.80.152.142 (208.80.152.142), \
  Dst: 128.255.204.16 (128.255.204.16)
   User Datagram Protocol, Src Port: 53 (53), Dst Port: 55497 (55497)
   Domain Name System (response)
   [Request In: 159]
   [Time: 0.061065000 seconds]
   Transaction ID: 0xd49c
   Flags: 0x8400 (Standard query response, No error)
   Questions: 1
   Answer RRs: 0
   Authority RRs: 1
   Additional RRs: 0
   Queries
   en.wikipedia.org: type , class IN
   Authoritative nameservers
   wikimedia.org: type SOA, class IN, mname ns0.wikimedia.org

so, basically:
   code NOERROR
   no answer
   authority citing wikimedia.org

NOERROR seems right, but it includes authority information for the zone of
the CNAME target without including the CNAME as an answer, amounting to a
mismatch between the original query  the cited authority.

Note that if I do an A query first, I get the CNAME via a correctly formed
response, after which the TXT   queries work, with the CNAME chain 
filled in from local cache.


To me it looks like BIND is doing the right thing (as usual ;^), but the 
wikipedia... servers are returning bogus responses.  Is this interpretation 
correct?  If so, does anybody know what apparently screwy DNS server or 
configuration causes this behavior?  I saw something similar with an F5 
installation here on campus briefly before I had the local folks fix it, but 
I'd like some confirmation that's what's going on with wikipedia... before I 
try to get them  others to fix it.  Further, if it's a systemic F5... 
problem, then a different approach is probably in order.



Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FORMERR for wikipedia...

[Mark Andrews]

The nameservers for wikipedia.org are broken.  They put the wrong
SOA record in the negative response, wikipedia.org != wikimedia.org.

M vs P

wikipedia.org.  86400   IN  NS  ns0.wikimedia.org.
wikipedia.org.  86400   IN  NS  ns1.wikimedia.org.
wikipedia.org.  86400   IN  NS  ns2.wikimedia.org.
;; Received 146 bytes from 2001:500:f::1#53(d0.org.afilias-nst.org) in 201 ms

wikimedia.org.  86400   IN  SOA ns0.wikimedia.org. 
hostmaster.wikimedia.org. 2011031404 43200 7200 1209600 600
;; Received 108 bytes from 91.198.174.4#53(ns2.wikimedia.org) in 335 ms

The adminstrators of wikimedia.org were informed about this months
ago but they don't seem to care.  They fail to acknowledge the
problem or to fix the problem.  wikimedia.org are not alone in this.
There are thousands on web sites that return the wrong answers to
 lookups.

Meanwhile everyone wants resolver vendors to make the lookups work.
We can't when the authoritative servers are broken.  It time the
users complained.

Mark

In message alpine.deb.2.02.1103161239300.19...@seatpost.its.uiowa.edu, Jay Fo
rd writes:
 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.80.152.130#53
 
 I see this for a variety of domains, including wikipedia.org, yahoodns.net,
 officedepot.com,  staples.com.  I did some investigation, including sniffing
 the DNS traffic.  The problematic case seems to be names which have CNAMEs to
 names in other zones for which the queried record type doesn't exist.  For
 example:
 
 en.wikipedia.org is a CNAME - text.wikimedia.org
 text.wikimedia.org is a CNAME - text.pmtpa.wikimedia.org
 text.pmtpa.wikimedia.org has an A record, but no , TXT...
 
 A query for type= name=en.wikipedia.org returns:
 
 % dig -t  en.wikipedia.org
 
 ;  DiG 9.7.3  -t  en.wikipedia.org
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 45218
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;en.wikipedia.org.  IN  
 
 ;; Query time: 229 msec
 ;; SERVER: ::1#53(::1)
 ;; WHEN: Wed Mar 16 11:34:08 2011
 ;; MSG SIZE  rcvd: 34
 
 The response packet from the wikipedia/wikimedia DNS servers is:
 
 Internet Protocol, Src: 208.80.152.142 (208.80.152.142), \
Dst: 128.255.204.16 (128.255.204.16)
 User Datagram Protocol, Src Port: 53 (53), Dst Port: 55497 (55497)
 Domain Name System (response)
 [Request In: 159]
 [Time: 0.061065000 seconds]
 Transaction ID: 0xd49c
 Flags: 0x8400 (Standard query response, No error)
 Questions: 1
 Answer RRs: 0
 Authority RRs: 1
 Additional RRs: 0
 Queries
 en.wikipedia.org: type , class IN
 Authoritative nameservers
 wikimedia.org: type SOA, class IN, mname ns0.wikimedia.org
 
 so, basically:
 code NOERROR
 no answer
 authority citing wikimedia.org
 
 NOERROR seems right, but it includes authority information for the zone of
 the CNAME target without including the CNAME as an answer, amounting to a
 mismatch between the original query  the cited authority.
 
 Note that if I do an A query first, I get the CNAME via a correctly formed
 response, after which the TXT   queries work, with the CNAME chain 
 filled in from local cache.
 
 To me it looks like BIND is doing the right thing (as usual ;^), but the 
 wikipedia... servers are returning bogus responses.  Is this interpretation 
 correct?  If so, does anybody know what apparently screwy DNS server or 
 configuration causes this behavior?  I saw something similar with an F5 
 installation here on campus briefly before I had the local folks fix it, but 
 I'd like some confirmation that's what's going on with wikipedia... before I 
 try to get them  others to fix it.  Further, if it's a systemic F5... 
 problem, then a different approach is probably in order.
 
 
 Jay Ford, Network Engineering Group, Information Technology Services
 University of Iowa, Iowa City, IA 52242
 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Update returns FORMERR: ran out of space

[Stephane Bortzmeyer]

On Thu, Feb 25, 2010 at 10:02:45AM +1100,
 Mark Andrews ma...@isc.org 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, status: NOERROR, id:  20340
;; flags: ; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 0
;; ZONE SECTION:
;toto.fr.   IN  SOA

;; UPDATE SECTION:
toto.fr.3600IN  DNSKEY  256 3 8 
AwEAAbQuvEyzE/+5giH+QBjynhogDchi4AaB0YPZR79BRLlXLB34pjzw 
ArvI1dwuqaXW1jwvT5nQ1TDMZHH/qZgBU0X5532zxPi+MOj+Ec3EUp0k 
clsEz5kHwATTG5paqueAd/0N/1iW8SVqNARsIRlcrTU+DENv1z8hhTQq FVoiefGf


Reply from update query:
;; -HEADER- opcode: UPDATE, status: NOERROR, id:  20340
;; flags: qr ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0


25-Feb-2010 09:54:17.287 update: debug 8: client ::1#50327: updating zone 
'toto.fr/IN': prerequisites are OK
25-Feb-2010 09:54:17.287 update: debug 8: client ::1#50327: updating zone 
'toto.fr/IN': update section prescan OK
25-Feb-2010 09:54:17.287 update: info: client ::1#50327: updating zone 
'toto.fr/IN': adding an RR at 'toto.fr' DNSKEY
25-Feb-2010 09:54:17.287 update: debug 8: client ::1#50327: updating zone 
'toto.fr/IN': redundant request
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Update returns FORMERR: ran out of space

[Stephane Bortzmeyer]

On Wed, Feb 24, 2010 at 10:18:31AM +0100,
 Stephane Bortzmeyer bortzme...@nic.fr wrote 
 a message of 39 lines which said:

 With 'severity debug 30', all I get is:

And, for a successful dynamic update (it works with A records):

24-Feb-2010 14:31:44.803 update: debug 8: client ::1#13202: updating zone 
'toto.fr/IN': prerequisites are OK
24-Feb-2010 14:31:44.803 update: debug 8: client ::1#13202: updating zone 
'toto.fr/IN': update section prescan OK
24-Feb-2010 14:31:44.803 update: info: client ::1#13202: updating zone 
'toto.fr/IN': adding an RR at 'created-dyn-1267018304-26805.toto.fr' A
24-Feb-2010 14:31:44.803 update: debug 3: client ::1#13202: updating zone 
'toto.fr/IN': checking for NSEC3PARAM changes
24-Feb-2010 14:31:44.806 update: debug 3: client ::1#13202: updating zone 
'toto.fr/IN': updated data signatures
24-Feb-2010 14:31:44.806 update: debug 3: client ::1#13202: updating zone 
'toto.fr/IN': removed any orphaned NSEC records
24-Feb-2010 14:31:44.806 update: debug 3: client ::1#13202: updating zone 
'toto.fr/IN': rebuilding NSEC3 chains
24-Feb-2010 14:31:44.806 update: debug 3: client ::1#13202: updating zone 
'toto.fr/IN': signing rebuilt NSEC3 chain
24-Feb-2010 14:31:44.808 update: debug 8: client ::1#13202: updating zone 
'toto.fr/IN': writing journal toto.fr.db.signed.jnl
24-Feb-2010 14:31:44.819 update: debug 8: client ::1#13202: updating zone 
'toto.fr/IN': committing update transaction

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Update returns FORMERR: ran out of space

[Stephane Bortzmeyer]

On Wed, Feb 24, 2010 at 10:18:31AM +0100,
 Stephane Bortzmeyer bortzme...@nic.fr 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 the line number:

24-Feb-2010 15:04:26.343 update: info: client ::1#60371: updating zone 
'toto.fr/IN': error: ran out of space at line 1945

which, in my case, is:

/* Calculate the signature, creating a RRSIG RDATA. */
CHECKV(dns_dnssec_sign(name, rdataset, keys[i],
  inception, expire,
  mctx, buffer, sig_rdata));

So, the problem lies somewhere in dns_dnssec_sign but my knowledge
stops there.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Update returns FORMERR: ran out of space

[Mark Andrews]

In message 20100224091831.ga3...@nic.fr, Stephane Bortzmeyer writes:
 On Wed, Feb 24, 2010 at 11:32:35AM +1100,
  Mark Andrews ma...@isc.org 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: debug 8: client ::1#45986: updating zone 'to
 to.fr/IN': prerequisites are OK
 24-Feb-2010 10:17:01.047 update: debug 8: client ::1#45986: updating zone 'to
 to.fr/IN': update section prescan OK
 24-Feb-2010 10:17:01.047 update: info: client ::1#45986: updating zone 'toto.
 fr/IN': adding an RR at 'toto.fr' DNSKEY
 24-Feb-2010 10:17:01.048 update: debug 3: client ::1#45986: updating zone 'to
 to.fr/IN': checking for NSEC3PARAM changes
 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
 24-Feb-2010 10:17:01.057 update: debug 8: client ::1#45986: updating zone 'to
 to.fr/IN': rolling back
 
 I log 'dnssec' events:
 
 logging {
   channel debugging {
  file /tmp/bind-dnssec.log versions 2 size 5m;
severity debug 30;
print-time yes;
  print-severity yes;
  print-category yes;
};
   category update {
 debugging;
   };
   category dnssec {
 debugging;
   };
 };
 
 
 But I do not see them in the log.

You won't see DNSSEC events as DNSSEC basically covers validation.

Try this patch.  It resets the scratch space 'data' used by
dns_dnssec_sign().

Index: bin/named/update.c
===
RCS file: /proj/cvs/prod/bind9/bin/named/update.c,v
retrieving revision 1.176.4.3
diff -u -r1.176.4.3 update.c
--- bin/named/update.c  30 Dec 2009 03:55:03 -  1.176.4.3
+++ bin/named/update.c  24 Feb 2010 22:58:21 -
@@ -1941,6 +1941,7 @@
CHECK(update_one_rr(db, ver, diff, DNS_DIFFOP_ADDRESIGN, name,
rdataset.ttl, sig_rdata));
dns_rdata_reset(sig_rdata);
+   isc_buffer_init(buffer, data, sizeof(data));
added_sig = ISC_TRUE;
}
if (!added_sig) {
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Update returns FORMERR: ran out of space

[Stephane Bortzmeyer]

On Tue, Feb 23, 2010 at 02:56:15PM +0100,
 Stephane Bortzmeyer bortzme...@nic.fr wrote 
 a message of 17 lines which said:

 Trying to add/delete DNSSEC keys with dynamic update (first time I try
 that), the nsupdate client gets a FORMERR and BIND logs:

Some details:

* I use NSEC3 with opt-out
* I checked with a completely new zone, with an empty history (same
  problem)
* I checked the ARM which says that dynupdating DNSKEY is supported
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Update returns FORMERR: ran out of space

[Mark Andrews]

In message 20100223135615.ga30...@nic.fr, Stephane Bortzmeyer writes:
 Trying to add/delete DNSSEC keys with dynamic update (first time I try
 that), the nsupdate client gets a FORMERR and BIND logs:
 
 Feb 23 14:53:24 jezabel named[10174]: client ::1#29411: updating zone 'bortzm
 eyer.fr/IN': RRSIG/NSEC/NSEC3 update failed: ran out of space
 
 I checked the disk space (plenty) but I suspect that the problem is
 more complicated.

Turn the debugging up to 3.  The log message is a result of
update_signatures() detecting a error.

ran out of space usually means a fixed sized buffer is not big
enough or the change exceeded a architectual limit of the protocol.

Mark

 I can add A records just fine:
 
 Feb 23 14:55:46 jezabel named[10174]: client ::1#51231: updating zone 'bortzm
 eyer.fr/IN': adding an RR at 'created-dyn-1266933346-8636.bortzmeyer.fr' A
 
 BIND 9.7.0 built with '--without-idnlib' '--without-dlz' '--without-idn' '--w
 ith-libxml2=yes' '--enable-openssl'
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FORMERR

[Mark Andrews]

The SOA record in the negative response didn't match the delegation.

cloudfront.net != stl2.cloudfront.net

Mark


In message alpine.neb.2.01.0912041447110.12...@t1.m.reedmedia.net, Jeremy C.
 Reed writes:
 The upcoming BIND 9.7.0 has several logging improvements, for example:
 
 04-Dec-2009 14:46:41.020 resolver: notice: DNS format error from 
 216.137.38.22#53 resolving d2rdfnizen5apl.stl2.cloudfront.net/ for 
 client 127.0.0.1#53764: invalid response
 
 04-Dec-2009 14:46:41.060 resolver: notice: DNS format error from 
 216.137.38.23#53 resolving d2rdfnizen5apl.stl2.cloudfront.net/ for 
 client 127.0.0.1#53764: invalid response
 
 The comments in the source for that one is:
 
 /*
  * The responder is insane.
  */
 
 Also the query-errors logging (already in recent BIND releases) says:
 
 04-Dec-2009 14:46:41.060 query-errors: debug 1: client 127.0.0.1#53764: 
 query failed (SERVFAIL) for d2rdfnizen5apl.stl2.cloudfront.net/IN/ 
 at query.c:4673
 
 That line number in my code has:
 /* 
  * Something has gone wrong.
  */
 
 04-Dec-2009 14:46:41.060 query-errors: debug 2: fetch completed at 
 resolver.c:3024 for d2rdfnizen5apl.stl2.cloudfront.net/ in 0.079283: 
 failure/success 
 [domain:stl2.cloudfront.net,referral:0,restart:2,qrysent:2,timeout:0,lame:0,
 neterr:0,badresp:2,adberr:0,findfail:0,valfail:0]
 
/*
 * Something bad happened.
 */
 
 Sorry, even with the new logging, this one is not answered adequately... 
 will need to look further.
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Dig ANY gives SERVFAIL / FORMERR

[Stephane Bortzmeyer]

On Thu, Sep 24, 2009 at 07:16:35AM +1000,
 Mark Andrews ma...@isc.org wrote 
 a message of 77 lines which said:

 It's a pity registries are not required to verify correct operation
 of the nameservers they are delegating to before accepting the
 delegation.

Some do!

http://www.afnic.fr/outils/zonecheck/_en
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Dig ANY gives SERVFAIL / FORMERR

[Mark Andrews]

In message 20090929122845.ga13...@nic.fr, Stephane Bortzmeyer writes:
 On Thu, Sep 24, 2009 at 07:16:35AM +1000,
  Mark Andrews ma...@isc.org wrote 
  a message of 77 lines which said:
 
  It's a pity registries are not required to verify correct operation
  of the nameservers they are delegating to before accepting the
  delegation.
 
 Some do!
 
 http://www.afnic.fr/outils/zonecheck/_en

The key word is required.  I know some do, I just wish more did.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Dig ANY gives SERVFAIL / FORMERR

[Paul Wouters]

On Wed, 30 Sep 2009, Mark Andrews wrote:


http://www.afnic.fr/outils/zonecheck/_en


The key word is required.  I know some do, I just wish more did.


I for one, welcome our new named-checkzone overlords.

(especially if named-checkzone would fail to OK a zone with NSEC3RSASHA1 keys
and re-used NSEC records :)

Paul
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Dig ANY gives SERVFAIL / FORMERR

[Mark Andrews]

In message alpine.lfd.1.10.0909291125070.11...@newtla.xelerance.com, Paul Wou
ters writes:
 On Wed, 30 Sep 2009, Mark Andrews wrote:
 
  http://www.afnic.fr/outils/zonecheck/_en
 
  The key word is required.  I know some do, I just wish more did.
 
 I for one, welcome our new named-checkzone overlords.
 
 (especially if named-checkzone would fail to OK a zone with NSEC3RSASHA1 keys
 and re-used NSEC records :)

NSEC3RSASHA1 w/ NSEC is fine and is required if you want to transition
from RSASHA1 (w/ NSEC) to NSEC3RSASHA1 w/ NSEC3 w/o going insecure.

NSEC + NSEC3PARAM however could be rejected as could having multiple
NSEC3PARAM records.

 Paul

Not named-checkzone (yet) but the following are in BIND 9.6.2.

2686.   [bug]   dnssec-signzone should clean the old NSEC chain when
signing with NSEC3 and vice versa. [RT #20301]

2683.   [bug]   dnssec-signzone should clean out old NSEC3 chains when
the NSEC3 parameters used to sign the zone change.
[RT #20246]

dnssec-signzone works on the zone as a whole so it is in the position
to do this in a straight forward manner.  Named, however, needs to
support multiple NSEC3 chains (though not all may be complete) as
it does its work incrementally but perhaps it could be argued that
when you finish adding new NSEC3 chain incrementally the old one
should be removed.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users