EDNS0 would be my first guess. It’s very hard to tell without debugging output 
from `named`.

But let me rephrase my response: If this is for an experiment or a school 
project I would be happy to help, but if the goal is to unleash yet another 
incomplete DNS server implementation then I would be happier if this activity 
ceased in the beginning. That’s why I asked about the design goals of the 
project, so we can recommend a proper solution instead of giving advice like 
“this bit needs to be 1 and not 0” that would break the DNS ecosystem in some 
other creative way.

DNS is hard to implement right, let’s not make this any harder by adding more 
weirdness into the wild.

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 13. 9. 2021, at 14:42, Ondřej Surý <ond...@isc.org> wrote:
> 
> https://datatracker.ietf.org/doc/html/rfc6891
> 
> --
> 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 13. 9. 2021, at 14:31, Petr Menšík <pemen...@redhat.com> wrote:
>>> 
>> 
>> Hello Sonal,
>> 
>> are those queries done on internal network only? If global public DNS root 
>> is used, how did bind9 found it should contact your server? Is it configured 
>> via forward zone?
>> 
>> Public zone uses DNSSEC and bind9 does validate by default. I think your 
>> problem is too short authority zone of SOA record used.
>> 
>> delv ns e164.arpa
>> ; fully validated
>> e164.arpa.        43200    IN    NS    ns4.apnic.net.
>> e164.arpa.        43200    IN    NS    ns3.afrinic.net.
>> e164.arpa.        43200    IN    NS    ns3.lacnic.net.
>> e164.arpa.        43200    IN    NS    rirns.arin.net.
>> e164.arpa.        43200    IN    NS    pri.authdns.ripe.net.
>> e164.arpa.        43200    IN    RRSIG    NS 13 2 172800 20210921103016 
>> 20210907090016 28754 e164.arpa. 
>> hYukapDuiBGjbjWlmWLOqkjX4zsGkkF88BshSPiXZrC3/6mSmCGEOJDv 
>> xdUstlg/CIdXrYIh4mYL1Tr2cAG2oQ==
>> 
>> Any validating server would refuse your response, because ns.abc1.com is 
>> clearly not authoritative for in e164.arpa. But result would be SERVFAIL, 
>> not FORMERR. I can only guess, because we know nothing about queries. Nor 
>> error logged by bind9. We have seen only image of wireshark instead of pcap 
>> file itself, containing both queries and responses. Please include at least 
>> some of these if you seek our help.
>> 
>> In general, I would recommend following Onřej's advice and choose any 
>> existing implementations with a compatible license and extending it if 
>> required. There are many details to make correct.
>> 
>> Best Regards,
>> 
>> Petr
>> 
>> On 9/13/21 10:09 AM, Sonal Pahuja wrote:
>>>  
>>> 
>>> Hello All,
>>> 
>>>  
>>> 
>>> Currently we are facing below issue:-
>>> 
>>>  
>>> 
>>> We have built a response for NS query and sending it to bind9. But however 
>>> bind9 is rejecting and getting server fail error.
>>> 
>>> NAPTR and CNAME queries are working fine.
>>> 
>>>  
>>> 
>>> Wireshark of response built by our application:
>>> 
>>> 
>>> 
>>>  
>>> 
>>>  
>>> 
>>> Above messages is getting received by bind9, bind 9 is rejecting it and 
>>> sending server fail message to sender
>>> 
>>>  
>>> 
>>> In named.run getting below output:-
>>> 
>>>  
>>> 
>>> error (FORMERR) resolving
>>> 
>>>  
>>> 
>>> 
>>> 
>>> Kindly let us know what can be issue here.
>>> 
>>>  
>>> 
>>> Regards
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Please 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
>> -- 
>> Petr Menšík
>> Software Engineer
>> Red Hat, http://www.redhat.com/
>> email: pemen...@redhat.com
>> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
>> _______________________________________________
>> Please 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
_______________________________________________
Please 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

Reply via email to