Re: NS query on bind9
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ý 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 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.43200INNSns4.apnic.net. >> e164.arpa.43200INNSns3.afrinic.net. >> e164.arpa.43200INNSns3.lacnic.net. >> e164.arpa.43200INNSrirns.arin.net. >> e164.arpa.43200INNSpri.authdns.ripe.net. >> e164.arpa.43200INRRSIGNS 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
Re: NS query on bind9
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 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.43200INNSns4.apnic.net. > e164.arpa.43200INNSns3.afrinic.net. > e164.arpa.43200INNSns3.lacnic.net. > e164.arpa.43200INNSrirns.arin.net. > e164.arpa.43200INNSpri.authdns.ripe.net. > e164.arpa.43200INRRSIGNS 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
Re: NS query on bind9
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
Re: NS query on bind9
Hi Sonal, > On 13. 9. 2021, at 10:09, Sonal Pahuja wrote: > > Kindly let us know what can be issue here. DNS is hard. My recommendation would be to not write your own DNS server, but use an existing implementation that could be extended. Perhaps if you share your design goals, we could help you point you to the right direction. If you insist on writing your own DNS server, I would recommend starting with reading: https://labs.ripe.net/author/bert_hubert/introducing-tdns-the-teachable-authoritative-dns-server/ Ondrej -- Ondřej Surý (He/Him) ond...@isc.org ___ 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
RE: NS query on bind9
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: [cid:image003.jpg@01D7A8A4.B454D3C0] 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 [cid:image004.jpg@01D7A8A4.B454D3C0] 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
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
> On 13 Sep 2021, at 09:40, Ondřej Surý wrote: > > Hi, > > if you have reliable reproducer, please fill an issue at > https://gitlab.isc.org/isc-projects/bind9/-/issues > > While this mailing list is monitored by the BIND 9 team, it’s more practical > to have an issue filled by > a person experiencing the problem where we can interact directly and ask > additional questions. > Scraping the information from the mailing list chatter is very impractical. Thanks, I understand. Right now I don’t have anything solid. As I said, I have not experienced Mark’s serious issue. But trying to assign a bogus address to an unnumbered interface I wasn’t using *seems* to reduce the growth in memory footprint. I said *seems*, so again nothing solid. If I can I will set up a spare non production server and run a stress test with OARC’s tools and some sample data sets. In that case make sure I will report what I find. Borja. ___ 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
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
Hi, if you have reliable reproducer, please fill an issue at https://gitlab.isc.org/isc-projects/bind9/-/issues While this mailing list is monitored by the BIND 9 team, it’s more practical to have an issue filled by a person experiencing the problem where we can interact directly and ask additional questions. Scraping the information from the mailing list chatter is very impractical. Thanks, -- Ondřej Surý (He/Him) ond...@isc.org > On 13. 9. 2021, at 9:12, Borja Marcos wrote: > > 2- Adding a bogus 127.10.whatever to the spare Ethernet interface I am not > using, per a previous comment on > this thread about a memory leak due to interfaces with no addresses. ___ 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
NS query on bind9
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 In named.run getting below output:- ___ 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
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 9/13/21 09:12, Borja Marcos wrote:
2- Adding a bogus 127.10.whatever to the spare Ethernet interface I am not
using, per a previous comment on
this thread about a memory leak due to interfaces with no addresses.
This issue does need to get fixed. Assigning random, unused IP addresses
to interfaces to avoid a memory leak is messy.
So now I have two recursives running FreeBSD 13, one with libuv 1.41, the other
one with 1.42. The behavior
seems to be similar, I had a slow growing memory usage when there was no IP
address assigned to the spare, unused
Ethernet interface...
Will be good to check with you at the end of the week to see how it's going.
(even though I didn’t put a listen-on { any; }; clause.
This is weird. If you are not listening on all interfaces, why would
BIND care about an interface that has no IP address, then?
Mark.
___
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
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
> On 10 Sep 2021, at 13:30, Mark Tinka wrote:
>
>
>
> On 9/10/21 12:35, sth...@nethelp.no wrote:
>
>> Freebsd 12.2-STABLE here with servers running BIND 9.16.15, 9.16.18
>> and 9.16.20, all using libuv 1.41.0, all installed from ports. Typical
>> query load from around 3k qps to around 14k qps. No sign of any memory
>> leak.
>
> Would be interesting to hear your experiences when/if you do move to
> FreeBSD-13.0.
>
> Still going nice and stable with 9.11.
I haven’t noticed any of that, although the memory footprint seems to be lower
after doing a couple of things.
1- Updating libuv to 1.42 on one of the servers
2- Adding a bogus 127.10.whatever to the spare Ethernet interface I am not
using, per a previous comment on
this thread about a memory leak due to interfaces with no addresses.
So now I have two recursives running FreeBSD 13, one with libuv 1.41, the other
one with 1.42. The behavior
seems to be similar, I had a slow growing memory usage when there was no IP
address assigned to the spare, unused
Ethernet interface (even though I didn’t put a listen-on { any; }; clause.
Borja.
___
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
