NS query on bind9

Ondřej Surý ondrej at isc.org
Mon Sep 13 12:51:28 UTC 2021


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ý <ondrej at 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 <pemensik at 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 at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>> -- 
>> Petr Menšík
>> Software Engineer
>> Red Hat, http://www.redhat.com/
>> email: pemensik at 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 at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210913/6bc6abb6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 53172 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210913/6bc6abb6/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 44852 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210913/6bc6abb6/attachment-0003.jpg>


More information about the bind-users mailing list