Re: FORMERR-Format error issue

2024-01-31 Thread 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

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

2022-10-23 Thread 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

2022-10-22 Thread 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

2022-10-22 Thread 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

2022-10-21 Thread 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

2022-10-21 Thread 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

2022-10-21 Thread 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

2022-10-21 Thread 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

2022-10-21 Thread 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

2022-10-21 Thread 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

2022-10-21 Thread 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

2022-10-20 Thread 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

2022-10-20 Thread 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

2022-10-20 Thread 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

2022-10-20 Thread Ondřej Surý 
Hi,

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:

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


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

Re: FORMERR on packet received from Forwarder

2014-06-16 Thread 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: FORMERR for wikipedia...

2011-03-17 Thread 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...

2011-03-17 Thread 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...

2011-03-17 Thread 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

Re: FORMERR for wikipedia...

2011-03-16 Thread 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: FORMERR

2009-12-04 Thread 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: FORMERR resolving AAAA/IN records [solved]

2009-03-27 Thread Oliver Henriot 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Barry and list users,

Thanks for the info.

- From what you tell me, there's not much more to do than reduce logging
of this type of error on my side, so the logging info you gave in 2006
solves my problem just fine.
Thank you very much for your help.

Cheers,

Dans sa grande sagesse, b19...@anl.gov a écrit, le 26.03.2009 15:19 :
 Oliver Henriot oliver.henr...@imag.fr wrote:
 
 Dear list users,

 I have a bind 9.3 server on a centos 5.2 machine which logs huge (about
 12 errors every second) quantities of FORMERR messages while trying to
 resolve /IN records which look like this :

 Mar 25 08:44:24 myserver named[1124]: FORMERR resolving
 'auniarael.com//IN': 216.69.185.38#53

 I'm a bit of a bind noob so I scoured the bind 9.3 ARM and the web
 looking for info which could help me understand what is going wrong. I
 found nothing of much use to me, appart from a thread on this list from
 2006 in which Barry Finkel has a similar question. I followed the
 logging instructions he gives and solved the overfull /var/log problem
 but I presume I still have these FORMERR problems occuring.

 Just for info, if it of any use, in a log file from before modifying
 logging, I had 1826550 lines of  FORMERR but of these, only 275
 unique adresses, so it's always the same requests and always the same
 errors...
 I don't think it's a recursion problem, I have restricted that to my
 networks.
 I only get these logs on this server, not on any of the others.

 I'd greatly appreciate if someone could point me in the right direction
 to try and work out what is going wrong and fix it.
 
 Look at the output of these queries:
 
 dnsserver% dig auniarael.com @216.69.185.38
 
 ;  DiG 8.3  auniarael.com @216.69.185.38 
 ; (1 server found)
 ;; res options: init recurs defnam dnsrch
 ;; got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4
 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
 ;; QUERY SECTION:
 ;;  auniarael.com, type = A, class = IN
 
 ;; ANSWER SECTION:
 auniarael.com.  1H IN A 68.178.232.143
 
 ;; AUTHORITY SECTION:
 auniarael.com.  1H IN NScpns01.secureserver.net.
 auniarael.com.  1H IN NScpns02.secureserver.net.
 
 ;; Total query time: 62 msec
 ;; FROM: dnsserver.anl.gov to SERVER: 216.69.185.38  216.69.185.38
 ;; WHEN: Thu Mar 26 09:05:56 2009
 ;; MSG SIZE  sent: 31  rcvd: 105
 
 dnsserver% !! 
 dig auniarael.com @216.69.185.38 
 
 ;  DiG 8.3  auniarael.com @216.69.185.38  
 ; (1 server found)
 ;; res options: init recurs defnam dnsrch
 ;; got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4
 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
 ;; QUERY SECTION:
 ;;  auniarael.com, type = , class = IN
 
 ;; AUTHORITY SECTION:
 .   1D IN SOA   cpns01.secureserver.net. 
 dns.jomax.net. (
 20080922; serial
 8H  ; refresh
 2H  ; retry
 1W  ; expiry
 1D ); minimum
 
 auniarael.com.  1H IN NScpns01.secureserver.net.
 auniarael.com.  1H IN NScpns02.secureserver.net.
 
 ;; Total query time: 62 msec
 ;; FROM: dnsserver.anl.gov to SERVER: 216.69.185.38  216.69.185.38
 ;; WHEN: Thu Mar 26 09:06:02 2009
 ;; MSG SIZE  sent: 31  rcvd: 157
 
 dnsserver%
 
 Note that the first query defaults to an A record search, and the
 authority section gives the names of the two name servers.  This is
 fine.  The second query is specifically for an  record.
 Note the authority section - 
 
  ;; AUTHORITY SECTION:
  .   1D IN SOA...
 
 The authority is the root.  BIND (correctly) does not believe this
 and returns FORMERR (format error).  This occurs, as Mark Andrews
 pointed out to me a numbe of months ago, because the DNS administrator
 has placed all of the records for various zones into one zone, and thus
 cannot configure an SOA record that is correct.  A search for an A
 record that exists will return correct values, but a search for a
 record that does not exist forces DNS to return the faulty SOA record.
 
 I just ran my FORMERR script against our current /var/adm/messsages,
 and I see a handful of DNS servers producing most of the FORMERR
 messages:
 
  cnt DNS Server IP
  --- --
   37 60.191.254.243
   37 219.152.120.12
   24 203.93.208.86
   24 124.207.117.60
   12 75.126.8.248
   12 75.126.57.130
   12 65.55.238.126
   12 65.54.240.126
   12 213.199.161.77
   12 207.68.160.190
   12 207.46.66.126
6 66.211.162.250
6 66.135.220.69
6 66.135.220.68
4 159.215.217.197
4 159.215.16.197
4 159.215.117.197
3 209.235.30.142
3 204.77.28.20
1 68.156.138.136
1

Re: FORMERR resolving AAAA/IN records

2009-03-26 Thread Jeremy C. Reed 
 Mar 25 08:44:24 myserver named[1124]: FORMERR resolving
 'auniarael.com//IN': 216.69.185.38#53

The negative response includes the optional NS records.

My custom named has logging that says:
FORMERR: NS name matches domain name.

This new logging is not committed yet. If you have a good suggestion for 
improving this specific logging message, please let me know. (Maybe It 
has a referral to itself.?)

The comments in the lib/dns/resolver.c code (where this FORMERR is 
coming from) say:

/*
 * We already know ns_name is a subdomain of fctx-domain.
 * If ns_name is equal to fctx-domain, we're not making
 * progress.  We return DNS_R_FORMERR so that we'll keep
 * trying other servers.
 */

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

Re: FORMERR resolving AAAA/IN records

2009-03-26 Thread Mark Andrews 

In message 20090326141903.1917917...@britaine.cis.anl.gov, b19...@anl.gov writ
es:
 Oliver Henriot oliver.henr...@imag.fr wrote:
 
 dnsserver% !! 
 dig auniarael.com @216.69.185.38 
 
 ;  DiG 8.3  auniarael.com @216.69.185.38  
 ; (1 server found)
 ;; res options: init recurs defnam dnsrch
 ;; got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4
 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
 ;; QUERY SECTION:
 ;;  auniarael.com, type = , class = IN
 
 ;; AUTHORITY SECTION:
 .   1D IN SOA   cpns01.secureserver.net. dns.jomax.net
 . (
 20080922; serial
 8H  ; refresh
 2H  ; retry
 1W  ; expiry
 1D ); minimum
 
 auniarael.com.  1H IN NScpns01.secureserver.net.
 auniarael.com.  1H IN NScpns02.secureserver.net.
 
 ;; Total query time: 62 msec
 ;; FROM: dnsserver.anl.gov to SERVER: 216.69.185.38  216.69.185.38
 ;; WHEN: Thu Mar 26 09:06:02 2009
 ;; MSG SIZE  sent: 31  rcvd: 157

Note this answer is internally self inconsistant.  AA=1
which indicates the answer is authoritative yet the authority
section contains SOA and NS RRsets with different owners
with the SOA being higher in the namespace than the NS
RRset.

Even if AA=0 it would still be self inconsistant and the
relationship between the SOA and NS RRsets is impossible
in a well formed response.

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