Re: BIND 9.18 unable to successfully transfer zone from axfrdns primary

[Michael Sinatra]

Right, BIND 9.18 now enforces Section 2.2 of RFC 5936, specifically, this:
   "The AXFR server MUST copy the
   Question section from the corresponding AXFR query message into the
   first response message's Question section.  For subsequent messages,
   it MAY do the same or leave the Question section empty."

There are some older implementations out there that don't do this 
correctly.  I have a vendor supported IPAM implementation, where I have 
gone back to the vendor and quoted the above, and they have fixed the 
implementation.


michael

On 8/31/23 17:34, Ian Bobbitt wrote:
That gets me more information, and I think puts the problem onto 
axfrdns. Thanks.


xfer-in: info: zone example.net/IN: Transfer started.
xfer-in: debug 1: zone example.net/IN: forced reload, requesting AXFR of 
initial version from 198.51.100.1#53
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
connected using 198.51.100.1#53
xfer-in: debug 3: transfer of 'example.net/IN' from 198.51.100.1#53: 
sent request data
xfer-in: debug 3: transfer of 'example.net/IN' from 198.51.100.1#53: 
missing question section
xfer-in: error: transfer of 'example.net/IN' from 198.51.100.1#53: 
failed while receiving responses: FORMERR

xfer-in: debug 1: zone example.net/IN: zone transfer finished: FORMERR
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
Transfer status: FORMERR


Looks like this isn't going to be solvable on my side. 
https://gitlab.isc.org/isc-projects/bind9/-/blob/v9.18.17/lib/dns/xfrin.c?ref_type=tags#L1657-1663


Packet capture confirms that we are indeed not getting a response with 
the question section.


I'm running the same version of dig, on the same system. Interesting 
that dig isn't as strict about this.


-- Ian

On 8/31/23 7:58 PM, Mark Andrews wrote:
Set debug level 3 on the xfrin channel.  There are some debug level 
messages that really should be set to error level in lib/dns/xfrin.c 
on FORMERR.


Also make sure you are running dig from the same version as later 
versions are more strict in parsing responses from the wire.



On 1 Sep 2023, at 09:23, Ian Bobbitt  wrote:

I have a system running BIND 9.18.17 that needs to transfer a zone 
from djbdns/axfrdns. I receive FORMERRs, and haven't been able to get 
any log messages indicating the problem.


xfer-in: info: zone example.net/IN: Transfer started.
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
connected using192.0.2.1 #53
xfer-in: error: transfer of 'example.net/IN' from 198.51.100.1#53: 
failed while receiving responses: FORMERR
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
Transfer status: FORMERR
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
Transfer completed: 0 messages, 0 records, 0 bytes, 0.008 secs (0 
bytes/sec) (serial 0)


This replaced a long obsolete system running 9.8.2 that was able to 
successfully transfer the zone. I can also successfully transfer the 
zone with `dig -t axfr ...` from the new system, which gives no 
errors. named-checkzone on the resulting data also gives no errors, 
and BIND is able to successfully load it as a primary.


How do I go about finding the cause of the FORMERR and resolve it?

-- Ian
--
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: BIND 9.18 unable to successfully transfer zone from axfrdns primary

[Ian Bobbitt]

That gets me more information, and I think puts the problem onto 
axfrdns. Thanks.


xfer-in: info: zone example.net/IN: Transfer started.
xfer-in: debug 1: zone example.net/IN: forced reload, requesting AXFR of 
initial version from 198.51.100.1#53
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
connected using 198.51.100.1#53
xfer-in: debug 3: transfer of 'example.net/IN' from 198.51.100.1#53: 
sent request data
xfer-in: debug 3: transfer of 'example.net/IN' from 198.51.100.1#53: 
missing question section
xfer-in: error: transfer of 'example.net/IN' from 198.51.100.1#53: 
failed while receiving responses: FORMERR

xfer-in: debug 1: zone example.net/IN: zone transfer finished: FORMERR
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
Transfer status: FORMERR


Looks like this isn't going to be solvable on my side. 
https://gitlab.isc.org/isc-projects/bind9/-/blob/v9.18.17/lib/dns/xfrin.c?ref_type=tags#L1657-1663


Packet capture confirms that we are indeed not getting a response with 
the question section.


I'm running the same version of dig, on the same system. Interesting 
that dig isn't as strict about this.


-- Ian

On 8/31/23 7:58 PM, Mark Andrews wrote:

Set debug level 3 on the xfrin channel.  There are some debug level messages 
that really should be set to error level in lib/dns/xfrin.c on FORMERR.

Also make sure you are running dig from the same version as later versions are 
more strict in parsing responses from the wire.


On 1 Sep 2023, at 09:23, Ian Bobbitt  wrote:

I have a system running BIND 9.18.17 that needs to transfer a zone from 
djbdns/axfrdns. I receive FORMERRs, and haven't been able to get any log 
messages indicating the problem.

xfer-in: info: zone example.net/IN: Transfer started.
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: connected 
using192.0.2.1 #53
xfer-in: error: transfer of 'example.net/IN' from 198.51.100.1#53: failed while 
receiving responses: FORMERR
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: Transfer 
status: FORMERR
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: Transfer 
completed: 0 messages, 0 records, 0 bytes, 0.008 secs (0 bytes/sec) (serial 0)

This replaced a long obsolete system running 9.8.2 that was able to 
successfully transfer the zone. I can also successfully transfer the zone with 
`dig -t axfr ...` from the new system, which gives no errors. named-checkzone 
on the resulting data also gives no errors, and BIND is able to successfully 
load it as a primary.

How do I go about finding the cause of the FORMERR and resolve it?

-- Ian
--
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: BIND 9.18 unable to successfully transfer zone from axfrdns primary

[Mark Andrews]

Set debug level 3 on the xfrin channel.  There are some debug level messages 
that really should be set to error level in lib/dns/xfrin.c on FORMERR.

Also make sure you are running dig from the same version as later versions are 
more strict in parsing responses from the wire.

> On 1 Sep 2023, at 09:23, Ian Bobbitt  wrote:
> 
> I have a system running BIND 9.18.17 that needs to transfer a zone from 
> djbdns/axfrdns. I receive FORMERRs, and haven't been able to get any log 
> messages indicating the problem.
> 
> xfer-in: info: zone example.net/IN: Transfer started.
> xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: connected 
> using192.0.2.1 #53
> xfer-in: error: transfer of 'example.net/IN' from 198.51.100.1#53: failed 
> while receiving responses: FORMERR
> xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: Transfer 
> status: FORMERR
> xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: Transfer 
> completed: 0 messages, 0 records, 0 bytes, 0.008 secs (0 bytes/sec) (serial 0)
> 
> This replaced a long obsolete system running 9.8.2 that was able to 
> successfully transfer the zone. I can also successfully transfer the zone 
> with `dig -t axfr ...` from the new system, which gives no errors. 
> named-checkzone on the resulting data also gives no errors, and BIND is able 
> to successfully load it as a primary.
> 
> How do I go about finding the cause of the FORMERR and resolve it?
> 
> -- Ian
> -- 
> 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

BIND 9.18 unable to successfully transfer zone from axfrdns primary

[Ian Bobbitt]

I have a system running BIND 9.18.17 that needs to transfer a zone from 
djbdns/axfrdns. I receive FORMERRs, and haven't been able to get any log 
messages indicating the problem.


xfer-in: info: zone example.net/IN: Transfer started.
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
connected using 192.0.2.1#53
xfer-in: error: transfer of 'example.net/IN' from 198.51.100.1#53: 
failed while receiving responses: FORMERR
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
Transfer status: FORMERR
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
Transfer completed: 0 messages, 0 records, 0 bytes, 0.008 secs (0 
bytes/sec) (serial 0)


This replaced a long obsolete system running 9.8.2 that was able to 
successfully transfer the zone. I can also successfully transfer the 
zone with `dig -t axfr ...` from the new system, which gives no errors. 
named-checkzone on the resulting data also gives no errors, and BIND is 
able to successfully load it as a primary.


How do I go about finding the cause of the FORMERR and resolve it?

-- Ian
--
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: Facing issues while resolving only one record

[Mark Andrews]

The servers don’t respond to DNSKEY queries.  No every error is an indication
that the validator should switch tracks from proving an answer is secure (the
server is sending signed responses) to proving that it is insecure.


> On 31 Aug 2023, at 17:28, stuart@registry.godaddy wrote:
> 
> This is odd.
>  “incometax.gov.in” hasn’t published a DS record, so no DNSSEC validation 
> should be occurring for any child. The registry object hasn’t been changed 
> since 2022, so its behaviour should be nothing new.
>  Testing various public verifying resolvers (google, cloudflare, local 
> unbound instances) shows no issue retrieving an A record for 
> eportal.incometax.gov.in., from many places around the world (nlnog ring 
> nodes).
>  So, weird.
>  Stuart Browne
> GoDaddy Registry | Eng - System IVstuart@registry.godaddy
>  i.e. I’m one of the people who maintains the registry and DNS servers for 
> “in” / “gov.in”.
>  From: bind-users  on behalf of Blason R 
> 
> Date: Thursday, 31 August 2023 at 1:42 pm
> To: "Bhangui, Sandeep - BLS CTR" 
> Cc: bind-users 
> Subject: Re: Facing issues while resolving only one record
>  You don't often get email from blaso...@gmail.com. Learn why this is 
> important
> Caution: This email is from an external sender. Please do not click links or 
> open attachments unless you recognize the sender and know the content is 
> safe. Forward suspicious emails to isitbad@.
>  Yes, bypassing DNSSEC Validation seems to have a solution.
>  Thanks for the help.
>  On Wed, Aug 30, 2023 at 7:30 PM Bhangui, Sandeep - BLS CTR via bind-users 
>  wrote:
>> 
>> 
>> This seems to be an issue with the domain incometax.gov.in.
>>  DNSSEC looks like is broken for that domain.
>>  NS servers at our location also cannot resolve that directly  but if I 
>> forward that query to any ISP provider NS which are more lax it resolves 
>> just fine.
>>  Thanks
>> Sandeep
>>  From: bind-users  On Behalf Of John W. 
>> Blue via bind-users
>> Sent: Wednesday, August 30, 2023 9:39 AM
>> To: bind-users 
>> Subject: RE: Facing issues while resolving only one record
>>  CAUTION: This email originated from outside of BLS. DO NOT click (select) 
>> links or open attachments unless you recognize the sender and know the 
>> content is safe. Please report suspicious emails through the “Phish Alert 
>> Report” button on your email toolbar. Recommend you turn off DNSSEC 
>> validation and see if it starts working.
>>  If it does, then you know the issue is with how DNSSEC is configured on 
>> your server.
>>  John
>>  From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
>> Blason R
>> Sent: Wednesday, August 30, 2023 8:20 AM
>> To: bind-users
>> Subject: Facing issues while resolving only one record
>>  Hi all,
>>  I have bind BIND 9.18.17-1+ubuntu22.04.1+isc+1-Ubuntu (Extended Support 
>> Version)
>> And I am facing this weird issue. Somehow eportal.incometax.gov.in site is 
>> not getting resolved through DNS.
>>  I tried a lot but unfortunately the issue still persists.
>>  Here are packet capture logs.
>>  listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 
>> 262144 bytes
>> 18:47:19.56 ens18 In  IP 192.168.1.162.61110 > 192.168.1.133.53: 20+ A? 
>> eportal.incometax.gov.in. (42)
>> 18:47:19.587705 ens18 Out IP 192.168.1.133.40263 > 208.67.222.222.53: 
>> 30627+% [1au] A? eportal.incometax.gov.in. (65)
>> 18:47:19.599214 ens18 Out IP 192.168.1.133.44299 > 1.1.1.1.53: 62952+% [1au] 
>> DNSKEY? incometax.gov.in. (57)
>> 18:47:20.800736 ens18 Out IP 192.168.1.133.56154 > 8.8.8.8.53: 16152+% [1au] 
>> DNSKEY? incometax.gov.in. (57)
>> 18:47:21.573628 ens18 In  IP 192.168.1.162.53536 > 192.168.1.133.53: 21+ 
>> ? eportal.incometax.gov.in. (42)
>> 18:47:21.576427 ens18 Out IP 192.168.1.133.55356 > 8.8.8.8.53: 57361+% [1au] 
>> ? eportal.incometax.gov.in. (65)
>> 18:47:22.002738 ens18 Out IP 192.168.1.133.33064 > 208.67.222.222.53: 
>> 16204+% [1au] DNSKEY? incometax.gov.in. (57)
>> 18:47:22.777934 ens18 Out IP 192.168.1.133.58739 > 208.67.222.222.53: 
>> 34205+% [1au] ? eportal.incometax.gov.in. (65)
>> 18:47:23.20 ens18 Out IP 192.168.1.133.60920 > 9.9.9.9.53: 46145+% [1au] 
>> DNSKEY? incometax.gov.in. (57)
>> 18:47:23.584820 ens18 In  IP 192.168.1.162.53962 > 192.168.1.133.53: 22+ A? 
>> eportal.incometax.gov.in. (42)
>> 18:47:24.405041 ens18 Out IP 192.168.1.133.56475 > 198.41.0.4.53: 12349 
>> [1au] DNSKEY? incometax.gov.in. (57)
>> 18:47:25.205136 ens18 Out IP 192.168.1.133.33517 > 192.36.148.17.53: 18768 
>> [1au] DNSKEY? incometax.gov.in. (57)
>> 18:47:25.237837 ens18 Out IP 192.168.1.133.43646 > 156.154.100.20.53: 28883 
>> [1au] DNSKEY? incometax.gov.in. (57)
>> 18:47:25.259888 ens18 Out IP 192.168.1.133.51762 > 59.160.103.171.53: 46716 
>> [1au] DNSKEY? incometax.gov.in. (57)
>> 18:47:25.597312 ens18 In  IP 192.168.1.162.53963 > 192.168.1.133.53: 23+ 
>> ? eportal.incometax.gov.in. (42)
>> 18:47:26.498891 ens18 Out IP 192.168.1.133.52631 > 

Re: Facing issues while resolving only one record

[stuart@registry.godaddy]

This is odd.

“incometax.gov.in” hasn’t published a DS record, so no DNSSEC validation should 
be occurring for any child. The registry object hasn’t been changed since 2022, 
so its behaviour should be nothing new.

Testing various public verifying resolvers (google, cloudflare, local unbound 
instances) shows no issue retrieving an A record for eportal.incometax.gov.in., 
from many places around the world (nlnog ring nodes).

So, weird.


Stuart Browne
GoDaddy Registry | Eng - System IV
[signature_3682002026]
stuart@registry.godaddy

i.e. I’m one of the people who maintains the registry and DNS servers for “in” 
/ “gov.in”.

From: bind-users  on behalf of Blason R 

Date: Thursday, 31 August 2023 at 1:42 pm
To: "Bhangui, Sandeep - BLS CTR" 
Cc: bind-users 
Subject: Re: Facing issues while resolving only one record

You don't often get email from blaso...@gmail.com. Learn why this is 
important
Caution: This email is from an external sender. Please do not click links or 
open attachments unless you recognize the sender and know the content is safe. 
Forward suspicious emails to isitbad@.


Yes, bypassing DNSSEC Validation seems to have a solution.

Thanks for the help.

On Wed, Aug 30, 2023 at 7:30 PM Bhangui, Sandeep - BLS CTR via bind-users 
mailto:bind-users@lists.isc.org>> wrote:
This seems to be an issue with the domain 
incometax.gov.in.

DNSSEC looks like is broken for that domain.

NS servers at our location also cannot resolve that directly  but if I forward 
that query to any ISP provider NS which are more lax it resolves just fine.

Thanks
Sandeep

From: bind-users 
mailto:bind-users-boun...@lists.isc.org>> On 
Behalf Of John W. Blue via bind-users
Sent: Wednesday, August 30, 2023 9:39 AM
To: bind-users mailto:bind-users@lists.isc.org>>
Subject: RE: Facing issues while resolving only one record

CAUTION: This email originated from outside of BLS. DO NOT click (select) links 
or open attachments unless you recognize the sender and know the content is 
safe. Please report suspicious emails through the “Phish Alert Report” button 
on your email toolbar.
Recommend you turn off DNSSEC validation and see if it starts working.

If it does, then you know the issue is with how DNSSEC is configured on your 
server.

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Blason R
Sent: Wednesday, August 30, 2023 8:20 AM
To: bind-users
Subject: Facing issues while resolving only one record

Hi all,

I have bind BIND 9.18.17-1+ubuntu22.04.1+isc+1-Ubuntu (Extended Support Version)
And I am facing this weird issue. Somehow 
eportal.incometax.gov.in site is not getting 
resolved through DNS.

I tried a lot but unfortunately the issue still persists.

Here are packet capture logs.

listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 
262144 bytes
18:47:19.56 ens18 In  IP 192.168.1.162.61110 > 192.168.1.133.53: 20+ A? 
eportal.incometax.gov.in. (42)
18:47:19.587705 ens18 Out IP 192.168.1.133.40263 > 208.67.222.222.53: 30627+% 
[1au] A? eportal.incometax.gov.in. (65)
18:47:19.599214 ens18 Out IP 192.168.1.133.44299 > 1.1.1.1.53: 62952+% [1au] 
DNSKEY? incometax.gov.in. (57)
18:47:20.800736 ens18 Out IP 192.168.1.133.56154 > 8.8.8.8.53: 16152+% [1au] 
DNSKEY? incometax.gov.in. (57)
18:47:21.573628 ens18 In  IP 192.168.1.162.53536 > 192.168.1.133.53: 21+ ? 
eportal.incometax.gov.in. (42)
18:47:21.576427 ens18 Out IP 192.168.1.133.55356 > 8.8.8.8.53: 57361+% [1au] 
? eportal.incometax.gov.in. (65)
18:47:22.002738 ens18 Out IP 192.168.1.133.33064 > 208.67.222.222.53: 16204+% 
[1au] DNSKEY? incometax.gov.in. (57)
18:47:22.777934 ens18 Out IP 192.168.1.133.58739 > 208.67.222.222.53: 34205+% 
[1au] ? eportal.incometax.gov.in. (65)
18:47:23.20 ens18 Out IP 192.168.1.133.60920 > 9.9.9.9.53: 46145+% [1au] 
DNSKEY? incometax.gov.in. (57)
18:47:23.584820 ens18 In  IP 192.168.1.162.53962 > 192.168.1.133.53: 22+ A? 
eportal.incometax.gov.in. (42)
18:47:24.405041 ens18 Out IP 192.168.1.133.56475 > 198.41.0.4.53: 12349 [1au] 
DNSKEY? incometax.gov.in. (57)
18:47:25.205136 ens18 Out IP 192.168.1.133.33517 > 192.36.148.17.53: 18768 
[1au] DNSKEY? incometax.gov.in. (57)
18:47:25.237837 ens18 Out IP 192.168.1.133.43646 > 156.154.100.20.53: 28883 
[1au] DNSKEY? incometax.gov.in. (57)
18:47:25.259888 ens18 Out IP 192.168.1.133.51762 > 59.160.103.171.53: 46716 
[1au] DNSKEY? incometax.gov.in. (57)
18:47:25.597312 ens18 In  IP