Re: Hell breaks loose in the afternoon with format error from X.X.X.X#53 resolving ./NS: non-improving referral

[Mark Andrews]

It’s a long known issue with so called “Transparent” DNS 
proxies/accelerators/firewalls.  Iterative resolvers expect to talk to 
authoritative servers.  They ask questions differently to the way they do when 
they talk to a recursive server.  Answers from different levels of the DNS 
hierarchy for the same question are different.  If you just cache and return 
the previous answer you break iterative lookups.  The answers from recursive 
servers are different to those from authoritative servers.

You get the same sort of problem in many hotels if you have an iterative 
resolver on your portable devices.  Switching named to use a public recursive 
server that supports DNSSEC in forward only mode helps sometimes.  It really 
depends on what the middleware is doing.

Mark

> On 6 May 2022, at 09:35, Ted Mittelstaedt  wrote:
> 
> Thought I would document this in case anyone else gets bit by it
> 
> I have several nameservers and other servers on a Comcast copper connection  
> (cable internet) in the office using a Technicolor Business Router CGA4131COM 
>  modem.  This is Comcast's de-facto standard modem as of 2022 for business 
> connections in the western half of the US (maybe countrywide)
> 
> I have a ticket with Comcast open on another issue that was escalated to
> second tier.  Well some bozo in second tier finally gets around to working it 
> and decides to login to the Technicolor and sees that the
> firewall is turned off, and so decides to helpfully "fix" the problem
> by turning it back on.
> 
> So there I am driving along, miles away, minding my own business then all the 
> sudden unknown to me in the office all DNS lookups fail, mailservers on the 
> circuit start spewing, and at the same time my cell phone rings with some 
> tech from Comcast brightly chirping how she "fixed" the problem.
> 
> Of course as icing on the cake when I pull over to deal with it I'm in an 
> area with so poor cell signal I can't even get an internet connection up from 
> my laptop.
> 
> By the time I get back to the office, discover what was going on, call back 
> into them, and have them reverse what was done the rest of the afternoon was 
> scotched and I was pissed!
> 
> Nearest sort-of explanation I could find was much handwaving and speculation 
> in the following:
> 
> https://serverfault.com/questions/489010/bind-formerr-errors-in-syslog
> 
> Anyway, it seems clear that the Technicolor's firewall, when enabled,
> transparently DOES intercept DNS queries to answer them out of a cache
> on the router, which has the effect of completely scotching the ability
> of a nameserver to do recursive queries.  My syslog logs were filling up
> and rolling over in less than 2 hours with thousands of these referral
> errors.
> 
> The serverfault seems to think that this kind of thing is due to possible 
> bugs in bind but the moment the modem was reconfigured to turn
> off the firewall the log entries stopped.
> 
> I'm not keen on further experimentation on this, I just wanted to post it in 
> case someone else is dealing with inexplicable errors and pulling their hair 
> out.
> 
> Ted
> -- 
> 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

Hell breaks loose in the afternoon with format error from X.X.X.X#53 resolving ./NS: non-improving referral

[Ted Mittelstaedt]

Thought I would document this in case anyone else gets bit by it

I have several nameservers and other servers on a Comcast copper 
connection  (cable internet) in the office using a Technicolor Business 
Router CGA4131COM  modem.  This is Comcast's de-facto standard modem as 
of 2022 for business connections in the western half of the US (maybe 
countrywide)


I have a ticket with Comcast open on another issue that was escalated to
second tier.  Well some bozo in second tier finally gets around to 
working it and decides to login to the Technicolor and sees that the

firewall is turned off, and so decides to helpfully "fix" the problem
by turning it back on.

So there I am driving along, miles away, minding my own business then 
all the sudden unknown to me in the office all DNS lookups fail, 
mailservers on the circuit start spewing, and at the same time my cell 
phone rings with some tech from Comcast brightly chirping how she 
"fixed" the problem.


Of course as icing on the cake when I pull over to deal with it I'm in 
an area with so poor cell signal I can't even get an internet connection 
up from my laptop.


By the time I get back to the office, discover what was going on, call 
back into them, and have them reverse what was done the rest of the 
afternoon was scotched and I was pissed!


Nearest sort-of explanation I could find was much handwaving and 
speculation in the following:


https://serverfault.com/questions/489010/bind-formerr-errors-in-syslog

Anyway, it seems clear that the Technicolor's firewall, when enabled,
transparently DOES intercept DNS queries to answer them out of a cache
on the router, which has the effect of completely scotching the ability
of a nameserver to do recursive queries.  My syslog logs were filling up
and rolling over in less than 2 hours with thousands of these referral
errors.

The serverfault seems to think that this kind of thing is due to 
possible bugs in bind but the moment the modem was reconfigured to turn

off the firewall the log entries stopped.

I'm not keen on further experimentation on this, I just wanted to post 
it in case someone else is dealing with inexplicable errors and pulling 
their hair out.


Ted
--
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: Transitioning to new algorithm for DNSSEC

[Mark Andrews]

> On 6 May 2022, at 04:53, frank picabia  wrote:
> 
> 
> 
> On Thu, May 5, 2022 at 3:48 PM Tony Finch  wrote:
> frank picabia  wrote:
> > On Thu, May 5, 2022 at 1:46 PM  wrote:
> > >
> > > Tony wrote a nice article about that:
> > > https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html
> >
> > Thanks for that.  My problem is these notes have little in common with how
> > the digital ocean guide
> > ran it (
> > https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server-2
> > ),
> 
> That guide is sadly very out of date. You really don't want to use SHA1
> (https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html)
> and for at least 10 years it has been much easier to use `named`s
> automatic signing than to use dnssec-signzone.
> 
> I think if you are still using `dnssec-signzone`, I would recommend
> switching over to automatic signing with your existing keys, before doing
> an algorithm rollover. And set up a test zone so that you can run through
> the process a few times, so that you can learn from your mistakes before
> doing it in production.
> 
> > and I don't think our domain registrar supports CDS records.
> 
> You can ignore the CDS stuff - my registrar didn't support it either, but
> I have tools that can use my CDS records to work out the correct thing to
> tell my registrar to do.
> 
> > I don't understand how people can run little rndc commands as if this
> > sticks without putting an include for the keys in the zone file.
> 
> `named` automatically adds the keys to the zone according to the timing
> information in the key files. (At least, that's the way I did it before
> dnssec-policy made things even more automatic.)

It still does.  dnssec-policy just automates steps that where done manually
previously.

> Agreed that the digital ocean guide is out of date. That's why I'm redoing 
> the steps with
> algorithm 8.  In our case, we have a DNS service to protect from DDOS
> and we need to transfer the whole zone to them periodically or from updates.
> I don't think the Bind built-in signing would work for this situation.

Of course it does.  You can extract the signed zone the same way as secondaries
transfer it.  Whatever you where doing for DDOS protection can still be done
with named signing the zone.  The key files are still there.  The zone content 
is
still there.

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

Re: Bind9 Server conflicts with docker0 interface

[Nick Tait via bind-users]

On 6/05/2022 7:51 am, Grant Taylor via bind-users wrote:

On my Bind9 server, I have the following zone-files:

forward.example.lan.db:
ns1     IN      A           192.168.0.10
ns1     IN          fe80::f21f:afff:fe5d:be90


I don't see the 2nd, Docker (?), address; 172.17.0.1, in the zone.  So 
if your client is still receiving that address in addition to the 
192.168.0.10 address, then something else is happening outside of BIND. 


Mauricio, was 172.17.0.1 in the zone file at any time in the past? 
Because if so, I'm betting that the problem is simply that after you 
removed it, you neglected to increment the SOA serial number? (In case 
you weren't aware the serial number needs to be increased every time you 
change the zone file.)


Can you please try updating the "1 ; Serial" line to "*2* ; Serial" as 
shown below:


$TTL    604800
@       IN      SOA     ns1.example.lan. hostmaster.example.lan. (
*2*         ; Serial
                        604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                        604800 )       ; Negative Cache TTL

Once you've done that, run "sudo rndc reload" on your the primary DNS 
server for the zone (or alternatively restart BIND), and see if that 
makes a difference?


Nick.
-- 
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: Bind9 Server conflicts with docker0 interface

[Grant Taylor via bind-users]

On 5/5/22 1:35 PM, Maurà cio Penteado via bind-users wrote:

Hi folks,


Hi,


Thank you for the reply.


:-)

Unfortunately, I did not understand how I am supposed to add multiple 
A-records for the same name to the zone-file to fix this issue.


Based on your first message, you already have multiple A records for 
ns1.example.lan; 192.168.0.10 and 172.17.0.1.


My suggestion was to have bind order the two records in a way favorable 
to the requesting client.  E.g. if the client is on the 172.17.0.0/24 
network, reply with 172.17.0.1 and 192.168.0.10 verses if the client is 
on the 192.168.0.0/24 network where the response would be 192.168.0.10 
and 172.17.0.1.  Both get the same A records, just in a different order. 
 Ideally the order puts the optimal IP for the client's use first.



On my Bind9 server, I have the following zone-files:

forward.example.lan.db:
ns1     IN      A           192.168.0.10
ns1     IN          fe80::f21f:afff:fe5d:be90


I don't see the 2nd, Docker (?), address; 172.17.0.1, in the zone.  So 
if your client is still receiving that address in addition to the 
192.168.0.10 address, then something else is happening outside of BIND.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Bind9 Server conflicts with docker0 interface

[Maurício Penteado via bind-users]

 Hi folks, 
Thank you for the reply.
Unfortunately, I did not understand how I am supposed to add multiple A-records 
for the same name to the zone-file to fix this issue.
On my Bind9 server, I have the following zone-files:

- - -
forward.example.lan.db:

$TTL    604800@       IN      SOA     ns1.example.lan. hostmaster.example.lan. 
(                                   1         ; Serial                          
604800         ; Refresh                            86400         ; Retry       
                 2419200         ; Expire                          604800 )     
  ; Negative Cache TTL
@          IN      NS      ns1.example.lan.
ns1     IN      A           192.168.0.10ns1     IN          
fe80::f21f:afff:fe5d:be90
- - -
reverse.example.lan.db:

$TTL    604800@       IN      SOA     example.lan. root.example.lan. (          
                          1         ; Serial                          604800    
     ; Refresh                            86400         ; Retry                 
       2419200         ; Expire                          604800 )       ; 
Negative Cache TTL
@       IN      NS     ns1.example.lan.10      IN      PTR    ns1.example.lan.
- - -
Please, advise.

Em quinta-feira, 5 de maio de 2022 17:26:24 GMT+1, Grant Taylor via 
bind-users  escreveu:  
 
 On 5/5/22 9:01 AM, Reindl Harald wrote:
> by not add multiple A-records for the same name to the zone-file
> BIND don't know about docker on it's own

Another option would be to leverage BIND's ability to sort A records 
based on configured preference (in the config file, not the zone file) 
based on client IP.  So even if BIND does return the Docker IP, it's not 
the 1st IP in the response, thereby hopefully alleviating the problems 
of it's existence.

This may be germane if the Docker IP is automatically registered and 
making it stop will be a different kettle of fish to roll up a different 
hill.

> and please avoid HTML formatted mails, it makes responding with inline 
> quotes more difficult as it should be

+10



-- 
Grant. . . .
unix || die

-- 
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: Transitioning to new algorithm for DNSSEC

[frank picabia]

On Thu, May 5, 2022 at 3:48 PM Tony Finch  wrote:

> frank picabia  wrote:
> > On Thu, May 5, 2022 at 1:46 PM  wrote:
> > >
> > > Tony wrote a nice article about that:
> > > https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html
> >
> > Thanks for that.  My problem is these notes have little in common with
> how
> > the digital ocean guide
> > ran it (
> >
> https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server-2
> > ),
>
> That guide is sadly very out of date. You really don't want to use SHA1
> (https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html)
> and for at least 10 years it has been much easier to use `named`s
> automatic signing than to use dnssec-signzone.
>
> I think if you are still using `dnssec-signzone`, I would recommend
> switching over to automatic signing with your existing keys, before doing
> an algorithm rollover. And set up a test zone so that you can run through
> the process a few times, so that you can learn from your mistakes before
> doing it in production.
>
> > and I don't think our domain registrar supports CDS records.
>
> You can ignore the CDS stuff - my registrar didn't support it either, but
> I have tools that can use my CDS records to work out the correct thing to
> tell my registrar to do.
>
> > I don't understand how people can run little rndc commands as if this
> > sticks without putting an include for the keys in the zone file.
>
> `named` automatically adds the keys to the zone according to the timing
> information in the key files. (At least, that's the way I did it before
> dnssec-policy made things even more automatic.)
>
>
Agreed that the digital ocean guide is out of date. That's why I'm redoing
the steps with
algorithm 8.  In our case, we have a DNS service to protect from DDOS
and we need to transfer the whole zone to them periodically or from updates.
I don't think the Bind built-in signing would work for this situation.
-- 
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: Transitioning to new algorithm for DNSSEC

[Tony Finch]

frank picabia  wrote:
> On Thu, May 5, 2022 at 1:46 PM  wrote:
> >
> > Tony wrote a nice article about that:
> > https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html
>
> Thanks for that.  My problem is these notes have little in common with how
> the digital ocean guide
> ran it (
> https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server-2
> ),

That guide is sadly very out of date. You really don't want to use SHA1
(https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html)
and for at least 10 years it has been much easier to use `named`s
automatic signing than to use dnssec-signzone.

I think if you are still using `dnssec-signzone`, I would recommend
switching over to automatic signing with your existing keys, before doing
an algorithm rollover. And set up a test zone so that you can run through
the process a few times, so that you can learn from your mistakes before
doing it in production.

> and I don't think our domain registrar supports CDS records.

You can ignore the CDS stuff - my registrar didn't support it either, but
I have tools that can use my CDS records to work out the correct thing to
tell my registrar to do.

> I don't understand how people can run little rndc commands as if this
> sticks without putting an include for the keys in the zone file.

`named` automatically adds the keys to the zone according to the timing
information in the key files. (At least, that's the way I did it before
dnssec-policy made things even more automatic.)

-- 
Tony Finch(he/they)  Cambridge, England
Trafalgar: Northerly or northeasterly 4 or 5, occasionally 3 in far
southeast. Moderate, but slight in far southeast. Fair. Good.
-- 
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: Transitioning to new algorithm for DNSSEC

[frank picabia]

On Thu, May 5, 2022 at 1:46 PM  wrote:

> Hi,
>
> On 5/5/22 6:37 PM, frank picabia  wrote:
> >
> > Hi,
> >
> > I've been running a Bind set up with DNSSEC for many years.
> > It was done following the guide at the digitalocean site.
> >
> > What I don't find in a nice guide, is how to change your algorithm
> > to a more current one, and seamlessly make your domain
> > run under this new chain of data.
> >
> > I tried it on my own estimates of what would be required, and
> > it seemed to be poisoned by dropping mention of the prior
> > keys files in my DNS while the Internet's cached info
> > on our DS is still out there.  Whatever has happened,
> > I've got a running domain again, but there is an angry diagram
> > being drawn at https://dnsviz.net/  when my domain
> > (which
> > will remain nameless) is analyzed.
> >
> > With DNS it is always hard to tell what is going on NOW due
> > to caching, and breakage works this way as well.
> >
> > Is there a guide on transitioning the DNSSEC signing algorithm,
> > or is ISC support the best way to handle this
> > and avoid the risk of total DNS calamity?
>
> Tony wrote a nice article about that:
> https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html
>
> Cheers,
>
> --
> Nico
>
>
Thanks for that.  My problem is these notes have little in common with how
the digital ocean guide
ran it (
https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server-2
),
and I don't think our domain registrar supports CDS records.

I don't understand how people can run little rndc commands as if this
sticks without putting
an include for the keys in the zone file.  In our setting, we re-sign the
zone from our host management automation.
There's not enough parallel in the world of that Math department's server
and what we have in our
host management in production.  Normally I'd be flexible to play around
with something
like this if it were apache or something, but I just experienced a domain
outage
that makes me prefer something I can really believe in.
-- 
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: Transitioning to new algorithm for DNSSEC

[Jan-Piet Mens via bind-users]

Is there a guide on transitioning the DNSSEC signing algorithm,


One of the best concise instructions on doing this was written by Tony Finch
while at Cambridge, and I have used this [1] successfully a few times.

My recommendation: print it out, and use a red pen to tick off the individual
points as you complete them. The most difficult phases are where the document
says 'wait'. Not only should you wait but also wait 'a bit more'. Timing is
of the essence.

Good luck!

-JP

[1] https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html
--
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: Transitioning to new algorithm for DNSSEC

[nicolas]

Hi,

On 5/5/22 6:37 PM, frank picabia  wrote:


Hi,

I've been running a Bind set up with DNSSEC for many years.
It was done following the guide at the digitalocean site.

What I don't find in a nice guide, is how to change your algorithm
to a more current one, and seamlessly make your domain
run under this new chain of data.

I tried it on my own estimates of what would be required, and
it seemed to be poisoned by dropping mention of the prior
keys files in my DNS while the Internet's cached info
on our DS is still out there.  Whatever has happened,
I've got a running domain again, but there is an angry diagram
being drawn at https://dnsviz.net/  when my domain 
(which

will remain nameless) is analyzed.

With DNS it is always hard to tell what is going on NOW due
to caching, and breakage works this way as well.

Is there a guide on transitioning the DNSSEC signing algorithm,
or is ISC support the best way to handle this
and avoid the risk of total DNS calamity?


Tony wrote a nice article about that: 
https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html

Cheers,

--
Nico
--
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: Transitioning to new algorithm for DNSSEC

[Petr Špaček]

On 05. 05. 22 18:37, frank picabia wrote:


Hi,

I've been running a Bind set up with DNSSEC for many years.
It was done following the guide at the digitalocean site.

What I don't find in a nice guide, is how to change your algorithm
to a more current one, and seamlessly make your domain
run under this new chain of data.

I tried it on my own estimates of what would be required, and
it seemed to be poisoned by dropping mention of the prior
keys files in my DNS while the Internet's cached info
on our DS is still out there.  Whatever has happened,
I've got a running domain again, but there is an angry diagram
being drawn at https://dnsviz.net/  when my domain 
(which

will remain nameless) is analyzed.

With DNS it is always hard to tell what is going on NOW due
to caching, and breakage works this way as well.

Is there a guide on transitioning the DNSSEC signing algorithm,
or is ISC support the best way to handle this
and avoid the risk of total DNS calamity?


We could provide specific answers if we knew enough. For "nameless 
domains" the only answer I can reasonably provide is:

https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open/

--
Petr Špaček
--
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

Transitioning to new algorithm for DNSSEC

[frank picabia]

Hi,

I've been running a Bind set up with DNSSEC for many years.
It was done following the guide at the digitalocean site.

What I don't find in a nice guide, is how to change your algorithm
to a more current one, and seamlessly make your domain
run under this new chain of data.

I tried it on my own estimates of what would be required, and
it seemed to be poisoned by dropping mention of the prior
keys files in my DNS while the Internet's cached info
on our DS is still out there.  Whatever has happened,
I've got a running domain again, but there is an angry diagram
being drawn at https://dnsviz.net/ when my domain (which
will remain nameless) is analyzed.

With DNS it is always hard to tell what is going on NOW due
to caching, and breakage works this way as well.

Is there a guide on transitioning the DNSSEC signing algorithm,
or is ISC support the best way to handle this
and avoid the risk of total DNS calamity?
-- 
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: Bind9 Server conflicts with docker0 interface

[Grant Taylor via bind-users]

On 5/5/22 9:01 AM, Reindl Harald wrote:

by not add multiple A-records for the same name to the zone-file
BIND don't know about docker on it's own


Another option would be to leverage BIND's ability to sort A records 
based on configured preference (in the config file, not the zone file) 
based on client IP.  So even if BIND does return the Docker IP, it's not 
the 1st IP in the response, thereby hopefully alleviating the problems 
of it's existence.


This may be germane if the Docker IP is automatically registered and 
making it stop will be a different kettle of fish to roll up a different 
hill.


and please avoid HTML formatted mails, it makes responding with inline 
quotes more difficult as it should be


+10



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Bind9 Server conflicts with docker0 interface

[Reindl Harald]

Am 05.05.22 um 16:05 schrieb Maurà cio Penteado via bind-users:



  What is the current behavior?

Nslookup from a DNS Client workstation  should not get docker0 ip 
addrees of the Bind9 Server PC.
|nslookup ns1.example.lan Server: UnKnown Address: 
fe80::f21f:afff:fe5d:be90 Name: ns1.example.lan Addresses: 
2a02:8084:601b:b80:f21f:afff:fe5d:be90 192.168.0.10 172.17.0.1|

Relevant configuration files

Interfaces from the ns1 server:


the relevant config file would have been the zone-file


||

Please, can you help?
How can I stop Bind to resolve docker0 ip address?


by not add multiple A-records for the same name to the zone-file
BIND don't know about docker on it's own

and please avoid HTML formatted mails, it makes responding with inline 
quotes more difficult as it should be



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

Bind9 Server conflicts with docker0 interface

[Maurício Penteado via bind-users]

Summary


Docker0 interface is being resolved and DNS Clients cannot deal with the 
address.

BIND version used

BIND 9.18.1-1ubuntu1-Ubuntu (Stable Release)

Steps to reproduce

On a fresh Ubuntu 22.04 Server install and set Bind9 up. After that install 
docker.

What is the current behavior?
Nslookup from a DNS Client workstation  should not get docker0 ip addrees of 
the Bind9 Server PC.nslookup ns1.example.lan
Server:  UnKnown
Address:  fe80::f21f:afff:fe5d:be90

Name:ns1.example.lan
Addresses:  2a02:8084:601b:b80:f21f:afff:fe5d:be90
  192.168.0.10
  172.17.0.1
What is the expected behavior?

I should have the following answer on a DNS Client workstation:
nslookup ns1.example.lan
Server:  UnKnown
Address:  fe80::f21f:afff:fe5d:be90

Name:ns1.example.lan
Addresses:  2a02:8084:601b:b80:f21f:afff:fe5d:be90
  192.168.0.10
Relevant configuration files

Interfaces from the ns1 server:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eno1:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
link/ether f0:1f:af:5d:be:90 brd ff:ff:ff:ff:ff:ff
altname enp0s25
inet 192.168.0.10/24 brd 192.168.0.255 scope global eno1
   valid_lft forever preferred_lft forever
inet6 2a02:8084:601b:b80:f21f:afff:fe5d:be90/64 scope global dynamic 
mngtmpaddr noprefixroute
   valid_lft 920763sec preferred_lft 317904sec
inet6 fe80::f21f:afff:fe5d:be90/64 scope link
   valid_lft forever preferred_lft forever
3: wlp2s0:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
link/ether e0:9d:31:07:f0:e8 brd ff:ff:ff:ff:ff:ff
4: docker0:  mtu 1500 qdisc noqueue state 
DOWN group default
link/ether 02:42:3a:db:3b:55 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
   valid_lft forever preferred_lft forever

What am I doing wrong?
Please, can you help?How can I stop Bind to resolve docker0 ip address?
Yours sincerely,Mauricio
-- 
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