Re: Master file permission denied

[Danilo Godec via bind-users]

  
  
Hello,


I think 


  chmod ug+x /etc/bind/zonas/

should solve the issue by giving the
  owner (bind) and the group (bind) permissions to enter the
  directory.




  Danilo








On 28.6.2023 20:44, Daniel Armando
  Rodriguez via bind-users wrote:


  
  Before I start describing the problem, I should mention that
this incident started when I tried to enable DNSSEC. I
understand that it is unrelated, but previously everything was
working correctly.
  
  
  I'm using Debian 11 and Bind 9.18 from backports
   
  This is current config
   
  # named-checkconf -px
options {
    directory "/var/cache/bind/";
    listen-on  {
        127.0.0.1/32;
        170.210.45.130/32;
    };
    listen-on-v6  {
        2800:110:44:6260::130/128;
    };
    querylog yes;
    transfers-in 20;
    transfers-per-ns 20;
    version "Info not currently available";
    allow-recursion {
        "localhost";
        ::1/128;
        170.210.0.0/16;
        2800:110:44:6260::/64;
    };
    auth-nxdomain no;
    recursion yes;
    allow-query {
        "any";
    };
    allow-transfer  {
        "none";
    };
    key-directory "/var/cache/bind/keys";
    masterfile-format text;
};
statistics-channels {
    inet 127.0.0.1 port 8053 allow {
        127.0.0.1/32;
    };
};
zone "10.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "16.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "17.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "18.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "19.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "20.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "21.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "22.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "23.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "24.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "25.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "26.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "27.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "28.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "29.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "30.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "31.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "unau.edu.ar" {
    type primary;
    file "/etc/bind/zonas/db.unau.edu.ar";
    allow-query {
        "any";
    };
    allow-transfer  {
        170.210.45.131/32;
    };
    allow-update {
        "none";
    };
    also-notify {
        170.210.45.131;
    };
    serial-update-method increment;
};
zone "133.45.210.170.in-addr.arpa" {
    type primary;
    file
  "/etc/bind/zonas/133.45.210.170.in-addr.arpa";
    allow-transfer  {
        170.210.45.131/32;
    };
    also-notify {
        170.210.45.131;
    };
};
zone
"3.3.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.2.6.4.4.0.0.0.1.1.0.0.0.8.2.ip6.arpa"
  {
    type primary;
    file
"/etc/bind/zonas/3.3.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.2.6.4.4.0.0.0.1.1.0.0.0.8.2.ip6.arpa";
    allow-transfer  {
        170.210.45.131/32;
    };
    also-notify {
        170.210.45.131;
    };
};
zone "." {
    type hint;
    file "/usr/share/dns/root.hints";
};
  

Changing DNS servers (name only) for a DNSSEC enabled domain

[Danilo Godec via bind-users]

Hello,


in the near future I will have to change NS records for one of my 
domains, as DNS servers currently use an old domain (not mine), that 
will be phased out. DNS servers will actually remain the same, only the 
domain name will change.


So, basically:

 * mydomain currently uses dns1.olddomain, dns2.olddomain,
   dns3.olddomain, ...
 * dns*.olddomain are the same servers as dns*.newdomain
 * mydomain has to change DNS server to dns1.newdomain, dns2.newdomain,
   dns3.newdomain, ...



Since DNSSEC is enabled on mydomain, I've been reading some instructions 
about doing this with DNSSEC and they say:


1. Disable DNSSEC at Registrar
2. Wait 24 hours
3. Disable DNSSEC at Name Server (remove DS-records)
4. Switch name servers
5. Wait 24 hours
6. Re-enable DNSSEC


Is this really necessary in this case, changing only DNS server names? I 
would like to avoid changing DS records at the registrar level as they 
don't provide a 'self-service' interface for managing them, so I have to 
go though their support and that's usually tedious.


If that is necessary, why?


   Thanks, Danilo

PS: If it matters, this is (still) a manually DNSSEC'd domain.-- 
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: Changing the DNSSEC algorithm

[Danilo Godec via bind-users]

  
  

  I read several articles regarding algorithm rollover,
including:
  * https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html
  *
https://downloads.isc.org/isc/bind9/9.16.6/doc/arm/html/advanced.html#dnssec-dynamic-zones-and-automatic-signing
  
  Unfortunately I can't find all of them in my browser history...
  
  
  
  For re-signing I have a Bash script running once a month
through cron.
  
  
  
  With only a few zones to manage I think I'll stick with the
simple way of editing them by hand.
  
  
   Thanks for your thoughts,
  

    Danilo




On 6.4.2022 13:18, Petr Menšík wrote:


  
  Hi Danilo,
  I think the way you have describe should work. But can I ask
what source this recipe has? I have seen recently similar
signing in one of our test. I guess this should be from public
recipe. Would you share its origin, please?
  
  I would recommend having DNS server do the job of maintaining
signatures. If you do it this way manually, you have to resign
your zone each time your signatures expire. Do you have set some
kind of reminder to remind you?
  I would try DNSSEC guide [1] with bind 9.16 or more recent. It
provides a policy inside named. It depends on what version do
you have. Even 9.11 can maintain signatures [2] and resign them,
but the process is more complicated. You would have to just
regenerate keys, otherwise it will maintain your signatures. But
yes, it won't be able to edit zone file by hand this way.
  Read dnssec-settime manual page and way to set times, when each
key should be activated or deactivated. It should be more safe
if done the right way. You can use dnssec-signzone -S to use
smart signing and then omit step 2. Just provide correct
directory to keys. But I admit it might be simpler to do it
manually if you would upgrade just single zone, which has no
high impact in case of error.
  Btw. it seems really clumsy to read 1000 characters from proper
entropy source and then use just 16 hexcoded chars from it.
/dev/urandom might be better source and 16 bytes should be
enough.
  Regards,
Petr
  
  1. https://bind9.readthedocs.io/en/v9_16_27/dnssec-guide.html
  2.
https://ftp.isc.org/isc/bind9/cur/9.11/doc/arm/Bv9ARM.ch04.html#dnssec.dynamic.zones
  
  On 4/5/22 09:07, Danilo Godec via
bind-users wrote:
  
  
Hello,


I implemented DNSSEC for my personal domain a good while ago
  with an older Bind and back then, I used RSASHA1-NSEC3-SHA1
  algorithm, which by now is not recommended... So I'm going to
  change the algorithm, probably to ECDSAP256SHA256, which
  should also be NSEC3 capable.
Since my domain is small and rarely changes, I'm not using
  any fancy updating features - I manage it manually, by editing
  the non-signed version of the zone file and then signing it to
  create a signed version.


Here I'd like to verify that I understand the steps required
  to change DNSEC key / algorithm without disruption:


1. create new keys for my zone

  dnssec-keygen -a ECDSAP256SHA256 -n ZONE mydomain
  dnssec-keygen -f KSK -a ECDSAP256SHA256 -n ZONE mydomain



2. include new keys in my zone while keeping old keys too:

    $INCLUDE Kmydomain.+008+14884.key <- old key
      $INCLUDE Kmydomain.+008+27618.key <- old key
      $INCLUDE Kmydomain.+013+10503.key <- new key
      $INCLUDE Kmydomain.+013+39532.key <- new key


3. sign the zone file
    /usr/sbin/dnssec-signzone -A -3 $(head -c 1000
  /dev/random | sha1sum | cut -b 1-16) -e +3024000 -o mydomain
  -t mydomain.hosts


4. ask the registrar to add new DS record to TLD (I have to
  do this by mail, there is no 'self-service' UI)
5. wait at least one TTL (making sure to use the longest TTL
  in my zone)
6. ask the registrar to remove old DS record(s) (I don't
  quite remember why, but I had two)
7. wait another TTL period
8. remove old keys from zone
9. re-sign the zone



Will that be OK?


   Best regards,
 Danilo




  
  -- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931

Re: Changing the DNSSEC algorithm

[Danilo Godec via bind-users]

On 6.4.2022 8:52, Daniel Stirnimann wrote:

Hello Danilo,

A simple schema to change DNSSEC algorithms is as follows:

1. Add new KSK/ZSK and double sign DNSKEY and all zone RRs
with both the new and old algorithm
2. Replace DS at parent
3. Remove old DNSKEY and all RRSIGs from the old algorithm

Before step 2 wait the max zone TTL to expire.
Before step 3 wait the DS TTL to expire.


Here I'd like to verify that I understand the steps required to change
DNSEC key / algorithm without disruption:


1. create new keys for my zone

   * dnssec-keygen -a ECDSAP256SHA256 -n ZONE mydomain
   * dnssec-keygen -f KSK -a ECDSAP256SHA256 -n ZONE mydomain


2. include new keys in my zone while keeping old keys too:

     $INCLUDE Kmydomain.+008+14884.key <- old key
     $INCLUDE Kmydomain.+008+27618.key <- old key
     $INCLUDE Kmydomain.+013+10503.key <- new key
     $INCLUDE Kmydomain.+013+39532.key <- new key


Looks good to me.



3. sign the zone file

     /usr/sbin/dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum
| cut -b 1-16) -e +3024000 -o mydomain -t mydomain.hosts


Not related to the algorithm rollover but you may want to reconsider the
use of NSEC3 using opt-out, the use of NSEC3 salt or the use of NSEC3
all together. Please have a look at:

https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-nsec3-guidance

This is currently an IETF dnsop working group document.



4. ask the registrar to add new DS record to TLD (I have to do this by
mail, there is no 'self-service' UI)


As you use a Double-Signature [1] KSK roll, you can replace the DS
record in a single step. While your procedure does not break anything it
does not need to be more complicated then necessary. You description is
a mix of the Double-Singature / Double-DS KSK rollover.

I would suggest you go directly to step 5 instead and in step 6 you
*replace* the DS record.



5. wait at least one TTL (making sure to use the longest TTL in my zone)

6. ask the registrar to remove old DS record(s) (I don't quite remember
why, but I had two)


As mentioned above, in step 6 you can *replace* the DS record.



7. wait another TTL period


You need to wait at least for the DS TTL to expire.



8. remove old keys from zone

9. re-sign the zone


Looks good to me.


Daniel


[1] https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.1.2



Thank you, it seems I was close enough (it would've worked).


I read the draft-ietf-dnsop-nsec3-guidance and while it's a bit above my 
level of understanding, I think the gist is that one should not use 
'advanced' NSEC3 features like iterations and salt - achieved by setting 
NSEC3PARAM to 1 0 0 - .



    Regards,
  Danilo


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

Changing the DNSSEC algorithm

[Danilo Godec via bind-users]

Hello,


I implemented DNSSEC for my personal domain a good while ago with an 
older Bind and back then, I used RSASHA1-NSEC3-SHA1 algorithm, which by 
now is not recommended... So I'm going to change the algorithm, probably 
to ECDSAP256SHA256, which should also be NSEC3 capable.


Since my domain is small and rarely changes, I'm not using any fancy 
updating features - I manage it manually, by editing the non-signed 
version of the zone file and then signing it to create a signed version.



Here I'd like to verify that I understand the steps required to change 
DNSEC key / algorithm without disruption:



1. create new keys for my zone

 * dnssec-keygen -a ECDSAP256SHA256 -n ZONE mydomain
 * dnssec-keygen -f KSK -a ECDSAP256SHA256 -n ZONE mydomain


2. include new keys in my zone while keeping old keys too:

    $INCLUDE Kmydomain.+008+14884.key <- old key
    $INCLUDE Kmydomain.+008+27618.key <- old key
    $INCLUDE Kmydomain.+013+10503.key <- new key
    $INCLUDE Kmydomain.+013+39532.key <- new key


3. sign the zone file

    /usr/sbin/dnssec-signzone -A -3 $(head -c 1000 /dev/random | 
sha1sum | cut -b 1-16) -e +3024000 -o mydomain -t mydomain.hosts



4. ask the registrar to add new DS record to TLD (I have to do this by 
mail, there is no 'self-service' UI)


5. wait at least one TTL (making sure to use the longest TTL in my zone)

6. ask the registrar to remove old DS record(s) (I don't quite remember 
why, but I had two)


7. wait another TTL period

8. remove old keys from zone

9. re-sign the zone


Will that be OK?


   Best regards,

 Danilo

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

dnssec rookie question

[Danilo Godec via bind-users]

Hello,


today I implemented DNSSEC for a domain - by that I mean that the DS 
records have been published / added to TLD DNS today, while the zone has 
been signed a couple of days ago.



So a couple of hours later I went to https://dnsviz.net to see if 
everything seems OK and it reports one error and a couple of warnings. 
The error is:



RRSIG sid.si/NSEC3PARAM alg 13, id 48018: The TTL of the RRset (3600) exceeds 
the value of the Original TTL field of the RRSIG RR covering it (0).


But if I use /dig/ for, I get this:

;; ANSWER SECTION:
sid.si. 3600IN  NSEC3PARAM 1 0 10 -
sid.si. 3600IN  RRSIG   NSEC3PARAM 13 2 0 
20220205091303 20220106091303 48018 sid.si. 
WVstsjBLSQNS+PaKbR3LAAALG7tlV+cuzLYUKgWDXKrFnxe+dxx5Tmsa 
pYIrabwi/sANBgEBMHtW1Z3NS7hRow==


Both records show TTL 3600 - which should be OK, I think? Where does 
dnsviz.net get that TTL 0?





The warnings are:

sid.si/DS (alg 13, id 12603): DNSSEC specification prohibits signing with DS 
records that use digest algorithm 1 (SHA-1).

sid.si/DS (alg 13, id 12603): DNSSEC specification prohibits signing with DS 
records that use digest algorithm 1 (SHA-1).

sid.si/DS (alg 13, id 12603): DS records with digest type 1 (SHA-1) are ignored 
when DS records with digest type 2 (SHA-256) exist in the same RRset.

sid.si/DS (alg 13, id 12603): DS records with digest type 1 (SHA-1) are ignored 
when DS records with digest type 2 (SHA-256) exist in the same RRset.


This is probably due to the fact that Bind version included in CentOS 8 
/dnssec-signzone/ creates two 'digests' in the /dsset/ file (sha-1 and 
sha-256 - which is what I've sent to the domain registrar to include), 
while newer Bind versions only create one...



Is including SHA-1 bad in some way? Should I change that?



  Thanks,

 Danilo
___
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: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?

[Danilo Godec via bind-users]

On 29. 12. 21 19:24, tale wrote:

On Wed, Dec 29, 2021 at 5:31 AM Danilo Godec via bind-users
 wrote:

I have an authoritative DNS server for a domain, but I was also going to
use the same server as a recursive DNS for my internal network, limiting
recursion by the IP. Apparently, this is a bad idea that can lead to
cache poisoning...

In short, no, this configuration with a BIND 9 server does not
increase your risk of cache poisoning any more than running your local
server in pure recursive mode.  I'm curious to hear more from the
source that has given you this impression.  I suspect there were some
additional qualifications that don't align with what you've described.

The source is a security audit report, claiming that using a single 
server for both authoritative (for public use) and recursive (limited to 
internal clients by means of 'allow-recursion' directive) roles 
increases the risk of DoS attacks and DNS cache poisoning... They 
mentioned CVE-2021-20322 that supposedly makes cache poisoning feasible 
(again) - that made them increase the concern level to a 'medium'.



While I understand how and why DoS and cache poisoning are bad, I don't 
understand how separating these two roles would help mitigate the risk.



Thanks for helping me understand,

  Danilo


___
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

DNS cache poisoning - am I safe if I limit recursion to trusted local networks?

[Danilo Godec via bind-users]

Hello,


I have an authoritative DNS server for a domain, but I was also going to 
use the same server as a recursive DNS for my internal network, limiting 
recursion by the IP. Apparently, this is a bad idea that can lead to 
cache poisoning...


After watching a Computerphile Youtube video 
(https://www.youtube.com/watch?v=7MT1F0O3_Yw) on that topic I have a 
rough understanding of how cache poisoning works, but it doesn't explain 
why limiting recursion to 'trusted' IP networks doesn't help.



Is it because with UDP IP's can be 'easily' spoofed and if someone 
guessed my internal network IPs and spoofed the IP, my DNS server would 
happily accept their requests? Or is it even wider than that?



    Danilo


___
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

Millions of './ANY/IN' queries denied

[Danilo Godec via bind-users]

Hello,


I'm noticing some unusual activity where 48 external IPs generated over
2M queries that have all been denied (just today):

15-Dec-2021 00:01:42.023 security: info: client @0x7f96180b3fe0
194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20
194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20
194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20
194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
15-Dec-2021 00:01:42.123 security: info: client @0x7f9618019e20
45.145.227.33#11092 (.): view outside: query (cache) './ANY/IN' denied
15-Dec-2021 00:01:42.127 security: info: client @0x7f96180b3fe0
45.145.227.33#11092 (.): view outside: query (cache) './ANY/IN' denied


I'm guessing this is some sort of an reflection attack attempt, but I
don't quite understand if these are the perpetrators or victims?

Would I be doing a bad thing by using fail2ban to block these IPs?


    Regards,

 Danilo


___
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: CNAME query

[Danilo Godec via bind-users]

Don't know if that helps, but if I query my local Bind DNS for a CNAME,
that doesn't exists, dig gives me the SOA record:


> dig cname nonexisting.example.com @mydns

; <<>> DiG 9.16.6 <<>> cname nonexisting.example.com @mydns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22683
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nonexisting.example.com. IN  CNAME

;; AUTHORITY SECTION:
example.com.  600 IN  SOA mydns.example.com. 
hostmaster.mydns.example.com. 2020042504 86400 3600 604800 604800

;; Query time: 0 msec
;; SERVER: mydns#53(mydns)
;; WHEN: thu sep 23 13:50:00 CEST 2021
;; MSG SIZE  rcvd: 100




Obviously I replaced my real domain with 'example.com'...



  Regards,

   Danilo






On 23. 09. 21 13:36, Sonal Pahuja wrote:
> Can some one please help me on this
> 
> *From:* Sonal Pahuja
> *Sent:* Thursday, September 23, 2021 10:26:48 AM
> *To:* bind-users@lists.isc.org 
> *Subject:* CNAME query
>  
>
> Hi All,
>
>  
>
> We are sending a CNAME query but currently we don’t have any CNAME
> record, just have NS info.
>
> What should be the Bind9 response for this CNAME query? Will it return
> NS Record in Authority/Answer section?
>
>  
>
> Regards,
>
> Sonal
>
>
> ___
> 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


-- 
Danilo Godec | Sistemska podpora / System Administration
AGENDA d.o.o. | Ul. Pohorskega bataljona 49, Sl-2000 Maribor
E: danilo.go...@example.com  | T: +386
(0)2 421 61 31 | F: +386 (0)2 420 06 90
Agenda OpenSystems  | Največji slovenski
odprtokodni integrator
Red Hat v Sloveniji  | Red Hat Premier Business
Partner
ElasticBox  | Poslovne rešitve v oblaku
Agenda d.o.o. 
Izjava o omejitvi odgovornosti / Legal disclaimer statement


___
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

Problem resolving

[Danilo Godec via bind-users]

Hello,


I recently stumbled upon a problem trying to update my root hints file
from *ftp.rs.internic.net*. For some reason, one of my DNS servers
running on Alpine Linux, can't resolve this name properly and always fails:

# ping ftp.rs.internic.net
ping: ftp.rs.internic.net: Try again

nslookup starts off fine, it prints the A record, but then it fails to:

# nslookup ftp.rs.internic.net
Server: 127.0.0.1
Address:127.0.0.1#53

Non-authoritative answer:
ftp.rs.internic.net canonical name = ftp.rs.verisigndns.com.
Name:   ftp.rs.verisigndns.com
Address: 69.58.179.79
** server can't find ftp.rs.verisigndns.com: SERVFAIL


It seems the problem is with  records, as apparently musl libc tries
to resolve both A and  record and fails if either of them are not
available. Unfortunately, I couldn't find a way to configure the musl
resolver not to try  records.

Digging a bit deeper I found out that these queries cause BIND to log
errors:

named[12737]: DNS format error from 185.100.2.22#53 resolving 
ftp.rs.verisigndns.com/ for 127.0.0.1#39521: Name rs.verisigndns.com (SOA) 
not subdomain of zone ftp.rs.verisigndns.com -- invalid response
named[12737]: DNS format error from 72.13.39.22#53 resolving 
ftp.rs.verisigndns.com/ for 127.0.0.1#39521: Name rs.verisigndns.com (SOA) 
not subdomain of zone ftp.rs.verisigndns.com -- invalid response
named[12737]: DNS format error from 69.36.158.22#53 resolving 
ftp.rs.verisigndns.com/ for 127.0.0.1#39521: Name rs.verisigndns.com (SOA) 
not subdomain of zone ftp.rs.verisigndns.com -- invalid response
named[12737]: DNS format error from 199.16.87.22#53 resolving 
ftp.rs.verisigndns.com/ for 127.0.0.1#39521: Name rs.verisigndns.com (SOA) 
not subdomain of zone ftp.rs.verisigndns.com -- invalid response


However, if I point the system resolver (or nslookup) to some other DNS
(my ISP's DNS, for examle), neither ping or nslookup fail.


Is there anything I can do on my BIND to make musl libc happy and not
fail in such a case?


 Thanks,

    Danilo


___
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