dnssec-keymgr: Plans and usage?
Hi, lastly I've discovered the new python tool dnssec-keymgr included in BIND 9.11 alpha release. I'm seeking for simple tools to handle key rollovers unattended. And the lightweight dnssec-keymgr could be the right one. Are there any future plans or milestones out there (expect of 'remaining work' from the manual)? I would like to handle KSK updates of second level domains using that tool (option -k applies policy only on KSKs). And especially I'm looking for an interface to trigger updates of DS records. The call on dnssec-settime may could be wrapped using the -s option of dnssec-keymgr to send a DS update via the registrar to the parent on publications or removals of DNSKEYs from the zone. But are there any other concepts or thoughts like supporting hooks for different phases in key rollovers? Thanks, Armin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Need DNS records help for single server (and IP), and multi-domain mail server.
On 08/23/2017 05:47 PM, Reindl Harald wrote: arrakis.thelounge.net. 86399 IN SPF "v=spf1 a ip4:91.118.73.0/24 ip4:95.129.202.170 -all" prometheus.thelounge.net. 86399 IN SPF "v=spf1 a ip4:91.118.73.0/24 ip4:95.129.202.170 -all" otherwise only @example.com *itself* is protected from forging, our homegrown DNS backend automatcially publishes SPF records for every hostname in every domain This might be a case to use the include so that each host can include (read: pull in) the SPF record for the parent domain. Obviously it depends on how your infrastructure is configured. also avoid "v=spf1 mx" - why? because it's a useless DNS lookup on the receiver publish ip-adresses whenever possible - the connecting IP is known for free, the MX is not relevant on the destination server when receive email as long as you force the lookup by careless SPF records I think that it may be possible for someone to publish a PTR record in their IP space that reverse resolves to a name of one of your MX servers. There by allowing their bogus server to send email as you. -- Grant. . . . unix || die -- Grant. . . . unix || die ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
test - plz ignore
___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Debugging Information Lacking?
I have some other issues that I'm trying to work through, but I wanted to ask about a specific issue. I'm trying to see what BIND currently thinks all of the zones are, so I issue the "rndc dumpdb -zones" command. I get the following output: Nov 27 07:36:26 DNA-DNS1 named[20035]: received control channel command 'trace 99' Nov 27 07:36:26 DNA-DNS1 named[20035]: debug level is now 99 Nov 27 07:36:28 DNA-DNS1 named[20035]: received control channel command 'dumpdb -zones' Nov 27 07:36:28 DNA-DNS1 named[20035]: dumpdb started: -zones Nov 27 07:36:28 DNA-DNS1 named[20035]: dumpdb complete However, it appears no file is generated. "find / -name cache_dump.db" doesn't return anything. The log says that dumpdb is complete, but it doesn't say what it wrote. I would expect the log file to say something like: Nov 27 07:36:28 DNA-DNS1 named[20035]: dumpdb output to: /var/lib/bind/ cache_dump.db It doesn't. Could we get that added to the logging information? root@DNA-DNS1:/var/lib/bind# named -v BIND 9.10.3-P4-Debian root@DNA-DNS1:/var/lib/bind# cat /etc/debian_version 9.11 - Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP _______ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debugging Information Lacking?
Frak, so I was looking for the wrong file name the whole time. I must have
latched on to the wrong one and then ran with it.
If the logging captured the path and name of the file it was writing, I
probably would have noticed my error the first time around.
-
Mike Hammett
Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
- Original Message -
From: "Lee"
To: isc-bind-us...@ics-il.net
Cc: bind-users@lists.isc.org
Sent: Wednesday, November 27, 2019 8:59:51 AM
Subject: Re: Debugging Information Lacking?
On 11/27/19, isc-bind-us...@ics-il.net wrote:
>
> I have some other issues that I'm trying to work through, but I wanted to
> ask about a specific issue.
>
> I'm trying to see what BIND currently thinks all of the zones are, so I
> issue the "rndc dumpdb -zones" command.
<.. snip ..>
> However, it appears no file is generated. "find / -name cache_dump.db"
> doesn't return anything.
the default file name is named_dump.db
If your named.conf has this bit
options {
directory "/var/cache/bind";
# working directory
then "rndc dumpdb -zones" creates the file /var/cache/bind/named_dump.db
If your named.conf has this bit
options {
dump-file "/tmp/cache_dump.db";
then "rndc dumpdb -zones" creates the file /tmp/cache_dump.db
> The log says that dumpdb is complete, but it doesn't say what it wrote. I
> would expect the log file to say something like:
>
> Nov 27 07:36:28 DNA-DNS1 named[20035]: dumpdb output to: /var/lib/bind/
> cache_dump.db
>
> It doesn't. Could we get that added to the logging information?
Yes, it would be nice if that was added
Lee
_______
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Primary/Secondary (Was: Master/Slave)
Terminology, Power, and Exclusionary Language in Internet-Drafts and RFCs Abstract This document argues for more inclusive language conventions sometimes used by RFC authors and the RFC Production Centre in Internet-Drafts that are work in progress, and in new RFCs that may be published in any of the RFC series, in order to foster greater knowledge transfer and improve diversity of participation in the IETF. This document represents the opinion of the authors and does not have IETF consensus. https://www.ietf.org/archive/id/draft-knodel-terminology-09.html -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* -- 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: RFC7344 (was: Funky Key Tag in AWS Route53 (2))
On Fri, Dec 30, 2022 at 12:39:30PM +0100, Peter wrote: > On Thu, Dec 29, 2022 at 03:43:35PM -0500, Timothe Litt wrote: > > ! So much like DNSSEC itself, the technology is there, but the will to use it > ! everywhere it's needed is not. > > Timothy, thank You for the update. I agree to Your viewpoints, and we > have seen mostly the same with IPv6. Apparently it needs serious pain to > move something in technology that is mostly invisible to the common > user. (OTOH we can see new collaboration tools or javascript > frameworks every day.) > > PMc The only hope is for the customers of domain registrars to request that they implement this, and to cite it as a problem when publically reviewing registrars. For example, my registrar has their own API, but that's all. When asked to add support for RFC7344, they say they'll consider it. The more customers who ask for it, the better (I hope). And now that DNSSEC is so much easier to use than in the past, maybe more people will start asking for RFC7344. cheers, raf -- 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: Intermittent issues resolving "labor.upload.akamai.com"
On Fri, Feb 3, 2023 at 4:32 AM Greg Choules via bind-users
wrote:
>> From a quick look in Wireshark at what my own server (9.18.8) is doing, this
>> looks like Akamai not responding correctly to a BIND QNAME minimisation
>> query. Here's one response, from 95.101.36.192 for example, of many similar
>> ones showing an issue. The response code shouldn't be REFUSED:
Definitely protocol issues going on with akamai.net. A query for the
target in the OP, at an akamai.net auth, indicates that there's a
zone cut at e.stor:
dig +noall +auth r33674-33729.neards.1.cftp.e.stor.lb.akamai.net
@zc.akamaitech.net
e.stor.lb.akamai.net. 4000IN NS n4e.stor.lb.akamai.net.
e.stor.lb.akamai.net. 4000IN NS n0e.stor.lb.akamai.net.
e.stor.lb.akamai.net. 4000IN NS n3e.stor.lb.akamai.net.
e.stor.lb.akamai.net. 4000IN NS n2e.stor.lb.akamai.net.
e.stor.lb.akamai.net. 4000IN NS n1e.stor.lb.akamai.net.
but it returns that the stor label is a lame delegation:
dig stor.lb.akamai.net @zc.akamaitech.net | awk '/status/ {print $6}'
REFUSED,
Even if lb were itself delegated, REFUSED is still the wrong answer
for stor; in that case it should get the delegation for lb. But lb
isn't delegated either, so refused is even more wrongerer.
I'll forward this over to Akamai.
--
tale
--
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
Is there an incompatibility between 9.16.37/9.18.11 and 9.9 when doing HMAC-MD5 AXFR?
Hi all
Due to circumstances beyond my control a remote partner needs to use a 9.9.9
version of bind and we are required to use HMAC-MD5 for zone transfers. There
is no (big) security concern since the networks are isolated and not exposed to
the larger Internet.
When the secondary requests an AXFR I see:
client @0x nnn.nnn.nnn.nnn#xx: request has invalid signature:
TSIG : tsig verify failure (BADSIG)
Doing a dig directly (with the same key) I get the zone:
client @0x nnn.nnn.nnn.nnn#xx /key (zone.tld): transfer
of 'zone.tld/IN': AXFR started: TSIG (serial )
Is there any known incompatibilities - preferably with workarounds :) - that
anyone knows about?
I apologize in advance if the info is lacking but here are, what I consider,
the relevant parts from named.conf:
key "." {
algorithm hmac-md5;
secret "XX";
};
acl servers {
nnn.nnn.nnn.nnn;
nnn.nnn.nnn.nnn;
nnn.nnn.nnn.nnn;
};
acl transfer {
!servers;
!localhost;
!nnn.nnn.nnn.nnn;
any;
};
zone "zone.tld." IN {
type master;
file "/etc/bind/zones/zone.file";
allow-transfer { !transfer; key .; };
};
Again - sorry if this is insufficient information.
It could be as simple as the remote not having everything in order but they
swear up and down that they have checked, doublechecked and enlisted multiple
persons in doing the checks.
I would appreciate any and all hints even if they are farfetched.
Best Regards
Patrik Graeser
--
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
Bind listener to an IPv6 from AnyIP subnet
Hello, I am trying to bind named listener to an IPv6 from prefix which
is assigned to a system via AnyIP kernel feature - basically, it is done
by the following command: sudo ip -6 route add local 2001:db8::/32 dev lo.
To be able to use IPv6 from AnyIP prefix the following sysctl must be
applied: net.ipv6.ip_nonlocal_bind = 1
Having above, I am able to use any IP from AnyIP prefix in all software
but named refuses to create socket, which listens to that kind of an IP
address.
As an alternative approach I have tried to run with a configuration
"listen-on-v6 { any; }", but it does behave in a way I need - it binds
separate socket for each discovered IP address rather wildcard address
of [::].
Had anyone faced the same or similar issue?
--
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 listener to an IPv6 from AnyIP subnet
I have reloaded the configuration as well as restarted the bind9. The
simpliest workaround I see - bind IPv6 explicitly to the interface using
command "ip address add 2001:db8::1 dev eth0" and then I am able to use
2001:db8::1 for the named. But I would like to take advantage of using
AnyIP.
On 3/12/23 19:03, Darren Ankney wrote:
Just a quick question because I ran into this problem before... is it
possible that named was started before the ip was added?
On Sun, Mar 12, 2023 at 12:55 PM Serg via bind-users
wrote:
Hello, I am trying to bind named listener to an IPv6 from prefix which
is assigned to a system via AnyIP kernel feature - basically, it is done
by the following command: sudo ip -6 route add local 2001:db8::/32 dev lo.
To be able to use IPv6 from AnyIP prefix the following sysctl must be
applied: net.ipv6.ip_nonlocal_bind = 1
Having above, I am able to use any IP from AnyIP prefix in all software
but named refuses to create socket, which listens to that kind of an IP
address.
As an alternative approach I have tried to run with a configuration
"listen-on-v6 { any; }", but it does behave in a way I need - it binds
separate socket for each discovered IP address rather wildcard address
of [::].
Had anyone faced the same or similar issue?
--
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: Bind listener to an IPv6 from AnyIP subnet
The problem is I have lots of IPv6 addresses where I need to listen DNS
requests (IPv6 prefix of /64) and I could not just explicitly add each to the
interface, thus I use AnyIP feature to be able to use entire prefix by locally
by such software like nginx, curl, etc.
Regarding the usage of [::] - due to usage of firewall I am able to block
connections to the 53/udp and 53/tcp which are not coming to specific IP
addresses or ranges, I do not need such filtering functionality within bind
itself.
Anyway, the better option is to allow bind to a so known "non-local" IP
addresses. Currently if I try to bind named to a IP address within AnyIP prefix
but which is not explicitly added to an interface it just not bind socket here.
Read this blog post for more details on AnyIP feature:
https://blog.widodh.nl/2016/04/anyip-bind-a-whole-subnet-to-your-linux-machine/
2023-03-13T08:55:16Z Michael Richardson :
>
> Serg via bind-users wrote:
> > As an alternative approach I have tried to run with a configuration
> > "listen-on-v6 { any; }", but it does behave in a way I need - it binds
> > separate socket for each discovered IP address rather wildcard address
> > of [::].
>
> Bind needs to bind a new socket for each address so that it can easily know
> which address is being communicated with. While there are newer ways to do
> this, they aren't that portable.
>
> What is the problem with binding to all the addresses, if you then filter
> which addresses will actually respond?
>
> Many large authoritative resolvers put the anycast address on the lo, and
> then use
> BGP to announce connectivity, and AFAIK, they all just listen on all
> addresses, because sometimes you want to ask a specific server a question.
--
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 dns amplification attack
Are you an open recursor? If the answer is no, you should not face any amplifications attacks. If you are an open recursor, the best solution is to restrict which IP addresses are allowed to access your recursor. -- 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
BIND | Cname chain resolution using forward ( CNAME&A returned but no use A) (#3995)
hi bind admin,
when i use bind-9.11 for my interdns?? deviceip is 10.1.1.1,
i config
zone "bd.baidubce.com."
in { type forward ; forward only; forwarders { 10.10.10.10; }; };
1??when i dig @10.1.1.1 x.bd.bcebos.com.
2??10.10.10.10 return record "CNAME bd.bcebos.com., A 100.67.96.26, A
100.67.96.27" to device10.1.1.1
3??but device10.1.1.1 not return A 100.67.96.26, A 100.67.96.27 to me
4??device10.1.1.1 go to qurey bd.bcebos.com. recursive itself??and get another
record 110.242.70.8
i have questions
1??why config is forward only?? but bind get CNAME & A??bind do not return
A to me??and query cname again itself??
thanks--
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
BIND | Cname chain resolution using forward ( CNAME&A returned but no use A) (#3995)
i am very very sorry ,
the zone info of first mail -> zone "bd.baidubce.com." i write
wrong;
the wright info is zone "x.bd.bcebos.com."
please just see this mail,
when i use bind-9.11 for my interdns deviceip is 10.1.1.1, i config
zone "x.bd.bcebos.com."
in { type forward ; forward only; forwarders { 10.10.10.10; }; };
1,when i dig @10.1.1.1 x.bd.bcebos.com.
2,10.10.10.10 return record "CNAME
bd.bcebos.com., bd.bcebos.com. A 100.67.96.26, A 100.67.96.27"
to device10.1.1.1
3,but device10.1.1.1 not return A 100.67.96.26, A 100.67.96.27 to me
4,device10.1.1.1 go to qurey bd.bcebos.com. recursive itself, and
get another record 110.242.70.8
i have questions
1,why config is forward only, bind get CNAME & A records from forwarders,
but bind do not return A record to me?and query cname domain
recursive again itself?
thanks
hi bind admin,
when i use bind-9.11 for my interdns?? deviceip is 10.1.1.1,
i config
zone "bd.baidubce.com."
in { type forward ; forward only; forwarders { 10.10.10.10; }; };
1??when i dig @10.1.1.1 x.bd.bcebos.com.
2??10.10.10.10 return record "CNAME bd.bcebos.com., A 100.67.96.26, A
100.67.96.27" to device10.1.1.1
3??but device10.1.1.1 not return A 100.67.96.26, A 100.67.96.27 to me
4??device10.1.1.1 go to qurey bd.bcebos.com. recursive itself??and get another
record 110.242.70.8
i have questions
1??why config is forward only?? but bind get CNAME & A??bind do not return
A to me??and query cname again itself??
thanks--
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: DNSSEC regulatory requirements?
On Wed, Apr 05, 2023 at 11:04:10AM +0200, Klaus Malorny wrote: > On 04.04.23 15:11, Josh Kuo wrote: > > Hi all, > > > > [...] > > > > The only one I know of is the very dated US OMB memo from 2008. I see > > several European domains have better DNSSEC deployment rates (such as > > .de). Are there any regulations or friendly recommendations from some > > kind of governing body at work here? > > > > Thank you. > > > > -Josh > > > > Hi Josh, > > at least not in Germany/.de. There may be rules for governmental domain > names, but not for the general public/commercial domains. Other European > ccTLD registry have/had promotions for DNSSEC, so this might be the reason > for higher deployment rates. > > Greetings, > Klaus I think at least one Scandinavian country had a tax incentive to encourage DNSSEC adoption, but no regulatory requirement. cheers, raf -- 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: Delegation NS-records when zones share an authority server
it'll matter when you decide to add DNSSEC to the zone, and it's also good hygiene in the absence of DNSSEC so that any future maintainer can be reminded that there is a subdomain at that name when looking at the parent. -- 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
What is the equivalent of this dnsmasq configuration
I need to hijack certain domains and not its subdomains, so I use dnsmasq to achieve it: ``` [host-record=example.com](http://host-record=google.com),1.2.3.4 ``` In bind I have to create a zone and copy everything there, is there a simple way for domains I have no authority for?-- 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 with recursion for windows bind for Teamviewer
I don't know if this will be fixed before EOL for windows bind but here is the problem Teamviewer (and maybe other sites too) when you do the recursion when no answer under 1000ms it tries again which is trigged by client windows (not the one running bind) which also tries again for a answer this seems to causes the bind server not to give a answer but it tries and tries then Teamviewer works so Teamviewer DNS is doing a delayed reply which seems to be causing a problem for bind for windows because I tested bind in Ubuntu having DNS forward for teamviewer.com to it and Teamviewer loads faster. So it be nice if this could be fixed but I will not hold my breath. Thanks for any insight on this -- 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: Problem with recursion for windows bind for Teamviewer
I'm by no means an expert in DNS or how it fully works so I can't be of any more help about this problem then I already have. But it seems Teamviewer have rebooted their DNS servers and now windows bind allows the Teamviewer to load faster -- 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: Problem with recursion for windows bind for Teamviewer
So more tests and the problem has come back but I think I know why thinking internet sharing was the problem I found a way to disable it because it bind shared access for port 53 on 0.0.0.0 so that the problem I think now after testing with it on. For any interested MS has made it really hard to disable ICS on windows 11 I have tried many ways to disable it all over the web none worked but what did work was to delete the start key for: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess -- 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: Problem with recursion for windows bind for Teamviewer
Now its not working fast again! I don't know now must be Teamviewer DNS delaying replies causing windows bind to fail in some way. -- 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: Problem with recursion for windows bind for Teamviewer
I'm just using bind to do my DNS look ups with no forwarders thats all Teamviewer app uses DNS to find its servers from what I can tell it can take over 4000ms to get a answer. The following seems to help in bind resolver-retry-interval 5000; I think if I can then find a setting in windows to do the same thing that might help even over here is what I see from Wireshark https://ufile.io/q0kxqltc -- 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: Problem with recursion for windows bind for Teamviewer
On starting Teamviewer it can say no connection when bind does the lookup with this delay it cause bind to not reply LAN side sometimes which causes the app to fail yet with a bind on Ubuntu there is no problem. -- 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: Problem with recursion for windows bind for Teamviewer
This might show the problem even more on two interfaces WAN side and LAN you can see 192.168.53.19 ask for routerpool8 #60 then bind goes out #62 gets a answer # 75 and no reply back to 192.168.53.19 https://ufile.io/v8oob3jg -- 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: Problem with recursion for windows bind for Teamviewer
This is the thing the setup works for many site fast just this Teamviewer and their DNS servers are a problem and bind does reply to 192.168.53.19 all be it 26 seconds later! but Teamviewer trys over and over then it connects yet the for the WAN side took under 4 seconds to get the answer WAN side https://ufile.io/6ofm19ng -- 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: Problem with recursion for windows bind for Teamviewer
and this from dig maybe a routing iusse why it take so long for me? C:\Program Files\ISC BIND 9\bin>dig @213.227.191.1 router14.teamviewer.com +norecurs ; <<>> DiG 9.16.45 <<>> @213.227.191.1 router14.teamviewer.com +norecurs ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36405 ;; flags: qr aa; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;router14.teamviewer.com. IN A ;; ANSWER SECTION: router14.teamviewer.com. 3600 IN CNAME routerpool14.rlb.teamviewer.com. routerpool14.rlb.teamviewer.com. 120 IN A 188.172.235.146 routerpool14.rlb.teamviewer.com. 120 IN A 217.146.13.137 routerpool14.rlb.teamviewer.com. 120 IN A 34.17.240.4 routerpool14.rlb.teamviewer.com. 120 IN A 217.146.21.139 routerpool14.rlb.teamviewer.com. 120 IN A 37.252.234.165 ;; Query time: 3106 msec ;; SERVER: 213.227.191.1#53(213.227.191.1) ;; WHEN: Mon Nov 20 18:49:09 GMT Standard Time 2023 ;; MSG SIZE rcvd: 177 -- 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: Problem with recursion for windows bind for Teamviewer
So here is a theory if a client asks a query and bind goes out for that query and the reply is delayed but you get the answer then for what ever reason the reply to the client from bind is delayed more! So the quicker the answer the quicker the answer to the client. Why? I have no idea? -- 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
Queries/day
Hello all, <https://serverfault.com/questions/106920/how-to-get-dns-server-statistics-t otal-queries-per-day-windows-server-2003> How to get DNS SERVER Statistics ? Total Queries per day and month. the Rndc statistics file is quite difficult to read. Is there a simplest method? Nevertheless, I've attached my stats file, which I ran manually. After examining this file, is there anyone who can tell? How many queries each day and month Thanks a lot in advance for your reponse.. Ejaz named.stats Description: Binary data -- 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
unable-resolve-bank=domain
8OpyIcR7GmK1NhQtYQZXqPMmcFS6We G0c3ohwJSMSN8L2LpCx44Z1crr9CvA== ;; Received 650 bytes from 192.55.83.30#53(m.gtld-servers.net) in 63 ms gslb.sabbnet.com. 7200IN NS ns3.sabb.com. gslb.sabbnet.com. 7200IN NS ns4.sabb.com. ;; Received 161 bytes from 108.59.171.0#53(ns21.hsbc.net) in 16 ms www.services.online-banking.gslb.sabbnet.com. 900 IN A 193.27.7.78 ;; Received 89 bytes from 193.27.7.38#53(ns3.sabb.com) in 3 ms When we dig without +trace, no response [root@ns10 ~]# dig www.services.online-banking.gslb.sabbnet.com ;; communications error to 212.119.64.2#53: timed out ;; communications error to 212.119.64.2#53: timed out ; <<>> DiG 9.18.11 <<>> www.services.online-banking.gslb.sabbnet.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17592 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 14886f221081fc8e0100657e9abb46c04b22e6da4f29 (good) ;; QUESTION SECTION: ;www.services.online-banking.gslb.sabbnet.com. IN A ;; Query time: 1990 msec ;; SERVER: 212.119.64.2#53(212.119.64.2) (UDP) ;; WHEN: Sun Dec 17 09:52:43 +03 2023 ;; MSG SIZE rcvd: 101 -- 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: unable-resolve-bank=domain
My queries logs shows the below, [root@ns10 ~]# tail -f /var/log/querylog | grep www.services.online-banking.gslb.sabbnet.com. 17-Dec-2023 11:06:03.438 queries: info: client @0x7f29940013a8 167.86.165.83#64231 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN +E(0)D (212.119.64.2) 17-Dec-2023 11:10:20.186 queries: info: client @0x7f294c64f3c8 213.210.238.28#30304 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN HTTPS +E(0)D (212.119.64.2) 17-Dec-2023 11:13:55.798 queries: info: client @0x7f2970c9fe18 212.119.64.2#53159 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN A +E(0)K (212.119.64.2) 17-Dec-2023 11:13:57.480 queries: info: client @0x7f295411def8 46.152.39.165#15007 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN A +E(0)D (212.119.64.2) 17-Dec-2023 11:13:57.505 queries: info: client @0x7f2a0060db68 46.152.39.165#25046 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN +E(0)D (212.119.64.2) 17-Dec-2023 11:13:57.513 queries: info: client @0x7f29c419e0b8 46.152.39.165#42489 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN A + (212.119.64.2) Ejaz -Original Message- From: Ondřej Surý [mailto:ond...@isc.org] Sent: Sunday, December 17, 2023 11:01 AM To: MEjaz Cc: bind-users@lists.isc.org Subject: Re: unable-resolve-bank=domain > On 17. 12. 2023, at 8:20, MEjaz via bind-users > wrote: > > Any hint would be highly appreciated.. Paraphrasing: Logs or it didn’t happen… Always start with logs. The dig output is useless as we can’t possibly know what is happening inside named on that server. Ondrej -- 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. -- 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: unable-resolve-bank=domain
Some additional information 17-Dec-2023 11:14:20.737 queries: debug 3: client @0x7f2a1027d6f8 88.213.90.92#64617 (www.services.online-banking.gslb.sabbnet.com): looking for relevant NSEC 17-Dec-2023 11:14:20.737 queries: debug 3: client @0x7f2a1027d6f8 88.213.90.92#64617 (www.services.online-banking.gslb.sabbnet.com): ignoring nsec because name is past end of range Ejaz -Original Message- From: MEjaz [mailto:me...@cyberia.net.sa] Sent: Sunday, December 17, 2023 11:16 AM To: 'Ondřej Surý' Cc: 'bind-users@lists.isc.org' Subject: RE: unable-resolve-bank=domain My queries logs shows the below, [root@ns10 ~]# tail -f /var/log/querylog | grep www.services.online-banking.gslb.sabbnet.com. 17-Dec-2023 11:06:03.438 queries: info: client @0x7f29940013a8 167.86.165.83#64231 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN +E(0)D (212.119.64.2) 17-Dec-2023 11:10:20.186 queries: info: client @0x7f294c64f3c8 213.210.238.28#30304 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN HTTPS +E(0)D (212.119.64.2) 17-Dec-2023 11:13:55.798 queries: info: client @0x7f2970c9fe18 212.119.64.2#53159 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN A +E(0)K (212.119.64.2) 17-Dec-2023 11:13:57.480 queries: info: client @0x7f295411def8 46.152.39.165#15007 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN A +E(0)D (212.119.64.2) 17-Dec-2023 11:13:57.505 queries: info: client @0x7f2a0060db68 46.152.39.165#25046 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN +E(0)D (212.119.64.2) 17-Dec-2023 11:13:57.513 queries: info: client @0x7f29c419e0b8 46.152.39.165#42489 (www.services.online-banking.gslb.sabbnet.com): query: www.services.online-banking.gslb.sabbnet.com IN A + (212.119.64.2) Ejaz -Original Message- From: Ondřej Surý [mailto:ond...@isc.org] Sent: Sunday, December 17, 2023 11:01 AM To: MEjaz Cc: bind-users@lists.isc.org Subject: Re: unable-resolve-bank=domain > On 17. 12. 2023, at 8:20, MEjaz via bind-users > wrote: > > Any hint would be highly appreciated.. Paraphrasing: Logs or it didn’t happen… Always start with logs. The dig output is useless as we can’t possibly know what is happening inside named on that server. Ondrej -- 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. -- 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
Unable to Query DoH with `tls none` and Plain HTTP
Hello,
Hope you are having a great day.
I am trying to setup a BIND9 DNS over HTTP (DoH but in plain HTTP)
server with the ubuntu/bind9:latest docker image behind a HTTPS load
balancer however I am unable to perform any DNS query with the newly
installed BIND9 server(not through the load balancer).
I am getting the following when I try to perform the query:
➜ curl -v -H 'accept: application/dns-message'
'http://172.23.0.2:80/dns-query?dns=AAABAAABA3d3dwdleGFtcGxlA2NvbQAAAQAB'
* Trying 172.23.0.2:80...
* Connected to 172.23.0.2 (172.23.0.2) port 80
GET /dns-query?dns=AAABAAABA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/1.1
Host: 172.23.0.2
User-Agent: curl/8.5.0
accept: application/dns-message
* Received HTTP/0.9 when not allowed
* Closing connection
curl: (1) Received HTTP/0.9 when not allowed
and here is my named.conf.options
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://psrp.bbqporkmccity.com/vye5rn/iw5hSZ1O
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
//
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See
http://psrp.bbqporkmccity.com/vye5rn/nH13n27l
//
dnssec-validation auto;
listen-on-v6 { any; };
// Custom Options From Here
allow-query { any;};
allow-transfer { none; };
listen-on port 53 { any; };
listen-on port 80 tls none http default { any; };
};
Am I doing something wrong?
Thank you very much and I am looking forward to a solution.
--
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: Unable to Query DoH with `tls none` and Plain HTTP
Hello,
Thank you very much, I was unaware of the HTTP/2 requirement and was
assuming it is a bug. Is there any reason for omitting the HTTP/1.1
upgrade part of the protocol?
On 2024/01/01 22:30, Ondřej Surý wrote:
Hi,
BIND 9 DoH implementation always uses HTTP/2, so you
can't talk to it via HTTP/0.9, so your proxy balancer needs
to talk HTTP/2.
curl --http2-prior-knowledge -v -H 'accept: application/dns-message'
'http://172.23.0.2:80/dns-query?dns=AAABAAABA3d3dwdleGFtcGxlA2NvbQAAAQAB'
should work if I am reading the curl man page correctly (I don't have bind with
doh no-tls here)
dig +http-plain @172.23.0.2
will definitely work.
Ondřej
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
On 1. 1. 2024, at 13:35, r1wcp42w--- via bind-users
wrote:
Hello,
Hope you are having a great day.
I am trying to setup a BIND9 DNS over HTTP (DoH but in plain HTTP) server with
the ubuntu/bind9:latest docker image behind a HTTPS load balancer however I am
unable to perform any DNS query with the newly installed BIND9 server(not
through the load balancer).
I am getting the following when I try to perform the query:
➜ curl -v -H 'accept: application/dns-message'
'http://172.23.0.2:80/dns-query?dns=AAABAAABA3d3dwdleGFtcGxlA2NvbQAAAQAB'
* Trying 172.23.0.2:80...
* Connected to 172.23.0.2 (172.23.0.2) port 80
GET /dns-query?dns=AAABAAABA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/1.1
Host: 172.23.0.2
User-Agent: curl/8.5.0
accept: application/dns-message
* Received HTTP/0.9 when not allowed
* Closing connection
curl: (1) Received HTTP/0.9 when not allowed
and here is my named.conf.options
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://psrp.bbqporkmccity.com/vye5rn/vXKoBzwW
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
//
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See
http://psrp.bbqporkmccity.com/vye5rn/WflSTkLF
//
dnssec-validation auto;
listen-on-v6 { any; };
// Custom Options From Here
allow-query { any;};
allow-transfer { none; };
listen-on port 53 { any; };
listen-on port 80 tls none http default { any; };
};
Am I doing something wrong?
Thank you very much and I am looking forward to a solution.
--
Visit http://psrp.bbqporkmccity.com/vye5rn/jprjhJwF to unsubscribe from this
list
ISC funds the development of this software with paid support subscriptions.
Contact us at http://psrp.bbqporkmccity.com/vye5rn/HiPEm7Fv for more
information.
bind-users mailing list
bind-users@lists.isc.org
http://psrp.bbqporkmccity.com/vye5rn/pgPJe84v
--
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: Unable to Query DoH with `tls none` and Plain HTTP
On Tue, Jan 2, 2024 at 4:38 AM Jakob Bohm via bind-users wrote: > Having the DoH server as a standalone process talking to DNS/TCP would > be a solid implementation given the constant flow of changes made to > HTTP(S) by the Big 5. Perhaps, but for reference here is the relevant section of the DoH spec: https://datatracker.ietf.org/doc/html/rfc8484#section-5.2 HTTP/2 [RFC7540] is the minimum RECOMMENDED version of HTTP for use with DoH. The messages in classic UDP-based DNS [RFC1035] are inherently unordered and have low overhead. A competitive HTTP transport needs to support reordering, parallelism, priority, and header compression to achieve similar performance. Those features were introduced to HTTP in HTTP/2 [RFC7540]. Earlier versions of HTTP are capable of conveying the semantic requirements of DoH but may result in very poor performance. That ISC has chosen to follow the minimum HTTP version as recommended by the RFC is solid ground on which to be standing. -- tale -- 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-key 'unknown algorithm RSASHA512'
Hello, I'm using ubuntu 22.04 server on which bind 9.18.8 service is running. I'm trying to generate dnssec-key by using the command "dnssec-keygen -a RSASHA512 -b 2048 -n zone example.com" After doing this, it is generating both public key and private key. When I generate a file with aprivate key in /etc/bind directory, it is throwing error 'unknown algorithm 'RSASHA512' Same error is thrown when tried with other algorithms like ECDSAP256SHA256, RSASHA1, RSASHA256 etc Any help is greatly appreciated. -- Regards, पं. विष्णु शंकर P. Vishnu Sankar टीम लीडरTeam Leader-Network Operations सी-डॉट C-DOT इलैक्ट्रॉनिक्स सिटी फेज़ IElectronics City Phase I होसूर रोड बेंगलूरु Hosur Road Bengaluru – 560100 फोन Ph91 80 25119466 -- Disclaimer : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. The sender does not accept liability for any errors or omissions in the contents of this message, which arise as a result. -- 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: dnssec-key 'unknown algorithm RSASHA512'
Hello,
Bind version - 9.18.12
-->This is the command I used for generating dnssec-keygen keys -
root@dhcpt: /etc/bind# dnssec-keygen -a ECDSAP256SHA256 -n ZONE example.com
Kexample.com.+013+43215.key
Kexample.com.+013+43215.private
root@dhcpt:/etc/bind# cat Kexample.com.+013+43215.private
Private-key-format: v1.3
Algorithm: 13 (ECDSAP256SHA256)
PrivateKey: ESkrVALONh7Rj4UZVsOy54Y2SIJiY5HYhoQdxJLuWPk=
Created: 20240111045202
Publish: 20240111045202
Activate: 20240111045202
-->With help of the private key i generated one file with name
"named.conf.tsigkeys" at
/etc/bind -
root@dhcpt:/etc/bind# cat named.conf.tsigkeys
key "my-tsig" {
algorithm "ECDSAP256SHA256";
secret "ESkrVALONh7Rj4UZVsOy54Y2SIJiY5HYhoQdxJLuWPk=";
};
--> below is the error received when i restart named service
root@dhcpt:/etc/bind# named-checkconf
/etc/bind/named.conf.tsigkeys:2: unknown algorithm 'ECDSAP256SHA256'
Any help is greatly appreciated.
Regards,
Mounika
On Thu, 11 Jan 2024 15:49:18 +1100, Mark Andrews wrote
> Firstly show what you are actually doing. It it too much for you to actually
> cut-and-paste what you are doing?
>
> Secondly BIND 9.18 is at 9.18.22. Version 9.18.8 is seriously out of date.
>
> > On 11 Jan 2024, at 15:21, pvs via bind-users
> > wrote:
> >
> > Hello,
> >
> > I'm using ubuntu 22.04 server on which bind 9.18.8 service is running.
> > I'm trying to generate dnssec-key by using the command "dnssec-keygen -a
> > RSASHA512
-b 2048 -n zone example.com"
> >
> > After doing this, it is generating both public key and private key. When I
> > generate
a file with aprivate key in /etc/bind directory, it is throwing error 'unknown
algorithm 'RSASHA512'
> > Same error is thrown when tried with other algorithms like ECDSAP256SHA256,
> > RSASHA1,
RSASHA256 etc
> > Any help is greatly appreciated.
> >
> > --
> > Regards,
> >
> > पं. विष्णु शंकर P. Vishnu Sankar
> > टीम लीडर Team Leader-Network Operations
> > सी-डॉट C-DOT
> > इलैक्ट्रॉनिक्स सिटी फेज़ I Electronics City Phase I
> > होसूर रोड बेंगलूरु Hosur Road Bengaluru – 560100
> > फोन Ph 91 80 25119466
> > --
> > Disclaimer :
> > This email and any files transmitted with it are confidential and intended
> > solely
for the use of the individual or entity to whom they are addressed.
> > If you are not the intended recipient you are notified that disclosing,
> > copying,
distributing or taking any action in reliance on the contents of this
information is
strictly prohibited.
> > The sender does not accept liability for any errors or omissions in the
> > contents of
this message, which arise as a result.
> > --
> > 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
### Please consider the environment and print this email only if necessary . Go
Green
###
Disclaimer :
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you are not the intended recipient you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents of this
information is strictly prohibited. The sender does not accept liability
for any errors or omissions in the contents of this message, which arise as a
result.
--
Open WebMail Project (http://openwebmail.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
DiG DoH TLS Error
Hello, I am trying to resolve a DNS record with DNS over HTTPS with DiG on our DNS server. However DiG is returning a TLS error. See following anonymized result ➜ dig +trace +https @dns.example.com www.example.com ;; Connection to 192.168.132.5#443(192.168.132.5) for www.example.com failed: TLS error. ;; no servers could be reached ;; Connection to 192.168.132.5#443(192.168.132.5) for www.example.com failed: TLS error. ;; no servers could be reached ;; Connection to 192.168.132.5#443(192.168.132.5) for www.example.com failed: TLS error. ;; no servers could be reached I can confirm that the server can be reached and with openssl s_client -connect, the certificate returned OK result Connecting to 192.168.132.5 CONNECTED(0003) depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1 verify return:1 depth=1 C=US, O=Let's Encrypt, CN=R3 verify return:1 depth=0 CN=*.example.com verify return:1 --- Certificate chain 0 s:CN=*.example.com i:C=US, O=Let's Encrypt, CN=R3 a:PKEY: id-ecPublicKey, 384 (bit); sigalg: RSA-SHA256 v:NotBefore: Jan 2024 GMT; NotAfter: Apr 2024 GMT 1 s:C=US, O=Let's Encrypt, CN=R3 i:C=US, O=Internet Security Research Group, CN=ISRG Root X1 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep 4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT --- Server certificate -BEGIN CERTIFICATE- -END CERTIFICATE- subject=CN=*.example.com issuer=C=US, O=Let's Encrypt, CN=R3 --- No client certificate CA names sent Peer signing digest: SHA384 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits --- SSL handshake has read 2816 bytes and written 392 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256 Server public key is 384 bit This TLS version forbids renegotiation. Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher: TLS_AES_128_GCM_SHA256 Session-ID: Session-ID-ctx: Resumption PSK: PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 604800 (seconds) TLS session ticket: . Start Time: 1705398062 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- read R BLOCK Any idea what is causing the TLS error? -- 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
How to use different views on DNS-over-HTTPS vs normal DNS on port 53
Hello, How can I configure BIND9 to reply to requests from DNS-over-HTTPS with view A, and if the requests is from normal DNS on port 53, reply with view B? Example: client 192.168.1.5 requests A record test.example.com with DNS over HTTPS, BIND should reply with view A client 192.168.1.5 requests A record test.example.com with DNS on port 53, BIND should reply with view B -- 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
error: 'allow-update' is not allowed in 'slave' zone
Hello,
I configured Bind 9.18.12 as slave DDNS with dynamic updates from DHCP (ISC
DHCP 4.4)
running on the same server (Ubuntu 22.04 server)
When I run "named-checkconf named.conf", I get the following error
"named.conf:2018: option 'allow-update' is not allowed in 'slave' zone
'zonename.com'"
Following is the named.conf file (part)
zone "zonename.com" {
type slave;
file "com/zonename/sec.zonename.com";
masters {
IP address;
};
allow-update {
key rndc-key;
};
allow-transfer {
IP address;
};
};
I am clueless what is going wrong. Any help is greatly appreciated
Thanks in advance,
Mounika
### Please consider the environment and print this email only if necessary . Go
Green
###
Disclaimer :
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you are not the intended recipient you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents of this
information is strictly prohibited. The sender does not accept liability
for any errors or omissions in the contents of this message, which arise as a
result.
--
Open WebMail Project (http://openwebmail.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: Observation: BIND 9.18 qname-minimization strict vs dig +trace
Hmm, I wonder if qname-minimisation is at issue here. My trace dies with: 85.191.131.in-addr.arpa. 1800 IN NS fs838.click-network.com. 85.191.131.in-addr.arpa. 1800 IN NS ns102.click-network.com. couldn't get address for 'fs838.click-network.com': not found couldn't get address for 'ns102.click-network.com': not found -- 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
[help]how to configure ecs subnet for bind-9.18-21
dear admin: now, i use bind-9.18-21, i want to use ecs client subnet function; but i don't know how to configure it, and i don't get method from google please give me some example,or document , or google links to learn about it ; thanks! Yang 395096...@qq.com-- 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
To the last windows Bind
Eagle-Eye Cherry - Save Tonight (youtube.com) <https://www.youtube.com/watch?v=Nntd2fgMUYw> -- 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: qname minimization: me too :(
On Tue, Jun 25, 2024 at 10:42 AM Stephane Bortzmeyer wrote:
> > Jun 25 16:18:31 conr named[4725]: lame-servers:
> >info: success resolving 'bar.foo.isc.org/A' after disabling
> >qname minimization due to 'ncache nxdomain'
>
> I do not see how this is possible ("success resolving") since the name
> does not exist and all ISC name servers reply it does not exist.
>
> And all the resolvers I tried (through RIPE Atlas) say the same. No
> "success resolving".
Admittedly "success" can be ambiguous, and in this case it means
successfully got an answer for the question that was originally being
pursued. In this context, a negative answer is still a successful
resolution, unlike timeout or servfail from auths or various other
failures.
--
tale
--
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: Advice on balancing web traffic using geoip ACls
On 23 Feb 2020, at 07:57, @lbutlr wrote: > (9.11.6 should be coming really soon) 9.11.16, and I appear to be behind a touch, it is already released. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
delv 9.16.0, failed to add trusted key '.': ran out of space
Hi, The 9.16.0 version of delv seems to have trouble reading the root trust anchor from the bind.keys file. I'm seeing this in multiple environments, CentOS 6.10 and FreeBSD 11.3: [user@host ~]$ delv -v delv 9.16.0 [user@host ~]$ delv isc.org ;; /etc/bind.keys:31: failed to add trusted key '.': ran out of space ;; setup_dnsseckeys: failure Attempting to rule out a problem with my local bind.keys, I grabbed a fresh copy, but delv produces the same output: [user@host ~]$ wget -qO /tmp/bind.keys.916 https://gitlab.isc.org/isc-projects/bind9/raw/v9_16/bind.keys [user@host ~]$ delv -a /tmp/bind.keys.916 isc.org ;; /tmp/bind.keys.916:31: failed to add trusted key '.': ran out of space ;; setup_dnsseckeys: failure The above output is from CentOS but the behavior is identical on FreeBSD. Has anyone observed delv 9.16.0 to work in these environments? Before opening a bug I want to make sure I didn't goof something on my end. Thanks, Shaun ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: delv 9.16.0, failed to add trusted key '.': ran out of space
On Fri, 28 Feb 2020 20:07:47 + Tony Finch wrote: > Shaun via bind-users wrote: > > > > The 9.16.0 version of delv seems to have trouble reading the root trust > > anchor from the bind.keys file. > > I see this too. The bug is that dns_client_addtrustedkey() has a buffer > for parsing DNSKEY or DS records, but it's only big enough for DS. Thanks for tracking this down! I've opened an issue in GitLab and included your patch there. Shaun ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Compile errors for Bind 9.16.1 on RHEL7.x and RHEL 6.X
Hi Sandeep, I encountered this on RHEL 6 and got past it by tweaking an environment variable: export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig libuv places a meta file into that directory, and the configure script needed a little hint to find it. Shaun On Tue, 24 Mar 2020 19:44:20 + "Bhangui, Sandeep - BLS CTR via bind-users" wrote: > Hello > > Trying to compile Bind 9.16.1 on RHEL 7.X and RHEL 6.X and getting compile > errors hopefully someone can point me in the right direction. > > The download for the source code from the ISC site was done sometimes late > last week. > > Configuration. > > RHEL 7.X and RHEL 6.X running on HP-BLADE physical server. > > RHEL 7.X Kernel > > Linux 3.10.0-1062.12.1.el7.x86_64 #1 SMP Thu Dec 12 06:44:49 EST 2019 x86_64 > x86_64 x86_64 GNU/Linux > > As far as I can tell has the libuv library packageis installed on this > RHEL 7.X machine. > > sh-4.2# rpm -qa | grep -i libuv > > libuv-1.34.0-1.el7.x86_64 > > > This is the configure error I getwhen I try to compileon the RHEL 7.X > machine. > > checking for sched_setaffinity... yes > > checking for pthread_setname_np... yes > > checking for pthread_set_name_np... no > > checking for pthread_np.h... no > > checking for libuv... checking for libuv >= 1.0.0... no > > configure: error: libuv not found > > + exit 0 > > I am getting a similar error on RHEL 6.X machine but on that machine I do not > have the libuv package so that could explain that. > > Please advise. > > Thanks in advance. > > Sandeep > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
"lame-servers: info: no valid RRSIG resolving ..."
hi- i'm seeing what i'm wondering if is a lot of "lame-servers: info: no valid RRSIG resolving ..." messages in the logs [on average ~500 messages per day]. a small snippet: 15-Apr-2020 18:11:46.057 lame-servers: info: no valid RRSIG resolving 'jwplayer.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:11:46.150 lame-servers: info: no valid RRSIG resolving 'tranet.net/DS/IN': 192.5.6.30#53 15-Apr-2020 18:11:47.559 lame-servers: info: no valid RRSIG resolving 'inboxsdk.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:11:49.146 lame-servers: info: no valid RRSIG resolving 'basis.net/DS/IN': 192.5.6.30#53 15-Apr-2020 18:11:58.474 lame-servers: info: no valid RRSIG resolving 'starfinancial.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:11:59.665 lame-servers: info: no valid RRSIG resolving 'vice.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:09.501 lame-servers: info: no valid RRSIG resolving 'lithium.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:09.756 lame-servers: info: no valid RRSIG resolving 'sc-static.net/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:10.004 lame-servers: info: no valid RRSIG resolving 'snapchat.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:12.638 lame-servers: info: no valid RRSIG resolving 'yimg.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:16.823 lame-servers: info: no valid RRSIG resolving 'transamerica.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:16.932 lame-servers: info: no valid RRSIG resolving 'quantummetric.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:17.129 lame-servers: info: no valid RRSIG resolving 'tealiumiq.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:17.171 lame-servers: info: no valid RRSIG resolving 'bounceexchange.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:22.971 lame-servers: info: no valid RRSIG resolving 'mwefinancial.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:23.248 lame-servers: info: no valid RRSIG resolving 'redditmedia.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:23.869 lame-servers: info: no valid RRSIG resolving 'imtwjwoasak.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:25.189 lame-servers: info: no valid RRSIG resolving 'b.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:25.313 lame-servers: info: no valid RRSIG resolving 'jquery.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:26.555 lame-servers: info: no valid RRSIG resolving 'forter.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:29.008 lame-servers: info: no valid RRSIG resolving 'quovadisoffshore.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:29.029 lame-servers: info: no valid RRSIG resolving 'quovadisglobal.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:29.974 lame-servers: info: no valid RRSIG resolving 'mixpanel.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:35.786 lame-servers: info: no valid RRSIG resolving 'spotify.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:36.982 lame-servers: info: no valid RRSIG resolving 'freeform.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:38.295 lame-servers: info: no valid RRSIG resolving 'edgedatg.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:12:58.190 lame-servers: info: no valid RRSIG resolving 'footprintdns.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:13:01.282 lame-servers: info: no valid RRSIG resolving 'qualifiedaddress.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:13:01.744 lame-servers: info: no valid RRSIG resolving 'dc-msedge.net/DS/IN': 192.5.6.30#53 15-Apr-2020 18:14:54.009 lame-servers: info: no valid RRSIG resolving 'facebook.com/DS/IN': 192.5.6.30#53 15-Apr-2020 18:16:20.039 lame-servers: info: no valid RRSIG resolving 'pphosted.com/DS/IN': 192.5.6.30#53 a number of these [most?] are zones that are signed, and some don't even exist, so i'm curious about seeing these messages. what am i not understanding, and/or what can i do to troubleshoot further? thanks! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: "lame-servers: info: no valid RRSIG resolving ..."
thanks- we're running 9.14.8, courtesy of the isc ubuntu ppa [https://launchpad.net/~isc]: >named -v BIND 9.14.8-Ubuntu (Stable Release) >dpkg -s bind9 Package: bind9 Status: install ok installed Priority: optional Section: net Installed-Size: 872 Maintainer: Debian DNS Team Architecture: amd64 Version: 1:9.14.8-1+ubuntu19.10.1+isc+1 Replaces: bind (<< 1:9.13.6~) [...] Homepage: https://www.isc.org/downloads/bind/ does that mean in theory the version we're running would be new enough we shouldn't be seeing that particular symptom? thanks > On Apr 17, 2020, at 19.01, Mark Andrews wrote: > > They are almost certainly the result of running an older version of named and > packet loss > causing named to fallback to plain DNS which doesn’t return DNSSEC records. > Newer versions > of named don’t fallback to plain DNS on packet loss. > > 5029. [func] Workarounds for servers that misbehave when queried >with EDNS have been removed, because these broken >servers and the workarounds for their noncompliance >cause unnecessary delays, increase code complexity, >and prevent deployment of new DNS features. See >https://dnsflagday.net for further details. [GL #150] > > BIND 9.14.0 is the first non development version with this behaviour. > > Mark > >> On 18 Apr 2020, at 01:24, btb via bind-users >> wrote: >> >> hi- >> >> i'm seeing what i'm wondering if is a lot of "lame-servers: info: no valid >> RRSIG resolving ..." messages in the logs [on average ~500 messages per >> day]. a small snippet: >> >> 15-Apr-2020 18:11:46.057 lame-servers: info: no valid RRSIG resolving >> 'jwplayer.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:11:46.150 lame-servers: info: no valid RRSIG resolving >> 'tranet.net/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:11:47.559 lame-servers: info: no valid RRSIG resolving >> 'inboxsdk.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:11:49.146 lame-servers: info: no valid RRSIG resolving >> 'basis.net/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:11:58.474 lame-servers: info: no valid RRSIG resolving >> 'starfinancial.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:11:59.665 lame-servers: info: no valid RRSIG resolving >> 'vice.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:09.501 lame-servers: info: no valid RRSIG resolving >> 'lithium.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:09.756 lame-servers: info: no valid RRSIG resolving >> 'sc-static.net/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:10.004 lame-servers: info: no valid RRSIG resolving >> 'snapchat.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:12.638 lame-servers: info: no valid RRSIG resolving >> 'yimg.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:16.823 lame-servers: info: no valid RRSIG resolving >> 'transamerica.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:16.932 lame-servers: info: no valid RRSIG resolving >> 'quantummetric.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:17.129 lame-servers: info: no valid RRSIG resolving >> 'tealiumiq.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:17.171 lame-servers: info: no valid RRSIG resolving >> 'bounceexchange.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:22.971 lame-servers: info: no valid RRSIG resolving >> 'mwefinancial.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:23.248 lame-servers: info: no valid RRSIG resolving >> 'redditmedia.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:23.869 lame-servers: info: no valid RRSIG resolving >> 'imtwjwoasak.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:25.189 lame-servers: info: no valid RRSIG resolving >> 'b.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:25.313 lame-servers: info: no valid RRSIG resolving >> 'jquery.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:26.555 lame-servers: info: no valid RRSIG resolving >> 'forter.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:29.008 lame-servers: info: no valid RRSIG resolving >> 'quovadisoffshore.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:29.029 lame-servers: info: no valid RRSIG resolving >> 'quovadisglobal.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:29.974 lame-servers: info: no valid RRSIG resolving >> 'mixpanel.com/DS/IN': 192.5.6.30#53 >> 15-Apr-2020 18:12:35.786 lame-servers
Nsupdate and TTL
What is the proper syntax gor changing the TTL on a zone with nsupdate? Does the existence of $TTL 86400 in the domain.conf file override nssupdate’s attempts to change the TTL? # nsupdate -k /path/to/key > zone example.com > ttl 3600 > send > ^d No errors, but no change in the TTL. -- "I know she's in there," said Verence, holding his crown in his hands in the famous Ai-Se-or-Mexican-Bandits-Have-Raided-Our-Village position ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
unknown option 'trust-anchors'
In named.conf I have dnssec-enable yes; dnssec-validation auto; # rndc managed-keys status view: _default next scheduled event: Sun, 05 Jul 2020 20:43:00 GMT name: . keyid: 20326 algorithm: RSASHA256 flags: SEP next refresh: Sun, 05 Jul 2020 20:43:00 GMT trusted since: Mon, 21 Jan 2019 14:53:55 GMT mail # rndc reload rndc: 'reload' failed: failure mail # tail /var/log/messages Jul 5 07:41:24 mail.covisp.net named[53940] /usr/local/etc/namedb/bind.keys:29: unknown option 'trust-anchors' Jul 5 07:41:24 mail.covisp.net named[53940] reloading configuration failed: failure Bind is currently running just fine and has been since 8 June. The bind.keys file has: # See https://data.iana.org/root-anchors/root-anchors.xml for current trust # anchor information for the root zone. But that URL does not load and gives an XML error. -- -=> <http://xkcd.com/241/> <http://xkcd.com/304/> <http://xkcd.com/635/> <=- ___ 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: Debian/Ubuntu: Why was the service renamed from bind9 to named?
On Sun, Jul 19, 2020 at 7:06 AM @lbutlr wrote: > On 17 Jul 2020, at 11:56, Ted Mittelstaedt wrote: > > In fact, the ONLY reason that the name "bind9" was ever even coined > > at all was because the changes from bind8 both in the syntax of the > > config file and how the program operated they wanted to boot admins > > in the behind to get them to change their config files. > > This. Exactly this. Well, one minor bit of clarification is important. While highlighting the significant change in software might have been the motivation for why some installers chose to go with the name bind9 in place of named in some contexts, it was also a major design goal of BIND9 that it could run as a drop-in replacement for BIND8 on most configurations. It achieved this goal. The basic syntax was unchanged and configuration behavior was largely the same but for a little bit around the edges. And for what it's worth, not all systems moved away from "named" to "bind9". I've been running FreeBSD for decades, and I can't remember ever calling the service "bind9". ___ 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: /etc/bind.keys in a chrooted environment
On Wed, Jul 22, 2020 at 11:05 AM Anand Buddhdev wrote: > There is no harm in copying the file into the chroot. It will get rid of > the warning. With the caveat that you have to be sure that if you keep the original copy outside of the chroot, you have to be sure updates get reflected inside the chroot. NAMED_CONF_INCLUDE_FILES mentioned in the OP seems to be a SuSE-ism and I didn't dig into whatever bearing it might have for maintenance of the chroot. -- tale ___ 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: Error "Query section mismatch : got"
On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas
wrote:
> again, why you query for 250.0-24.199.212.125.in-addr.arpa
> under normal circumstances there's no point of querying that name.
>
Well yes and no. While an individual user would typically not,
resolvers sure will. While trying to resolve
250.199.212.125.in-addr.arpa, it will eventually get to
250.199.212.125.in-addr.arpa CNAME 250.0-24.199.212.125.in-addr.arpa.
Then it will need to resolve the canonical name, and a response like
the original one that was shown will be clearly buggy.
I say "possibly" because from my vantage, all three of
ns{,1,2}.viettelidc.com.vn, the authorities for
0-24.199.212.125.in-addr.arpa, are giving fine answers right now (on
udp; blocked on tcp). This includes the originally reported problem
IP, 115.84.177.8
--
tale
___
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: Reverse lookup response format
> Instead of the way it is now: > # nslookup 192.168.2.206 > 206.2.168.192.in-addr.arpa name = > server1.ctois.local.2.168.192.in-addr.arpa. In your zone file be sure that the name that is the target of the PTR records has a final dot. Without the trailing dot, the names are interpreted as relative to the current origin. ___ 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: [DNSfirewalls] Response Policy Zone: disabling "leaking" of lookups
It is a well known behaviour. This is the way how your DNS client works (not DNS server). Get rid of the search list or block requests to the domains in the search lists by RPZ (e.g. if it is pushed by ISP). BR, Vadim >Четверг, 3 сентября 2020, 19:04 +03:00 от Fred Morris : > >It comes to my attention that when an unresolvable query occurs, it gets >forwarded to the authoritative zone regardless of anything I can set in >named.conf. Closest I can come is qname-wait-recurse which has the opposite >effect sort of, namely waiting for recursion to complete. If I have something >in an RPZ, I want it to accept that; period, full stop, no outwardly visible >effects. >Ironically the text surrounding this option in the ARM is to the effect that >"... not resolving the requested name can leak the fact that response policy >rewriting is in use..." and leaking the fact that it is in use by not leaking >the query in the first place is what I'm trying to achieve: how do I disable >the (useless) resolution directed at upstream servers? >Here is a use case: >* A search list is in place for example.com. This means that if "foo.bar" >fails to resolve then "foo.bar.example.com" will be tried, followed by >"foo.bar.com". >* In addition to the foregoing a rule is placed in the RPZ that >"com.example.com" and "*.com.example.com" are NXDOMAIN. >* An additional rule is present in the RPZ that "my-outhouse-example.com" is >NXDOMAIN. >In this case: >* "my-outhouse-example.com.example.com" will return NXDOMAIN (it does!) >* There should be no upstream (pointless) query for >my-outhouse-example.com.example.com. (oops!) >Let's stop the leaks. >-- >Fred Morris > >___ >DNSfirewalls mailing list >dnsfirewa...@lists.redbarn.org >http://lists.redbarn.org/mailman/listinfo/dnsfirewalls > ___ 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: Do not cache certain domains
On Mon, Sep 7, 2020 at 6:01 PM Ben Lavender wrote: > Without having to alter the TTL of the existing RRs as well as the > default TTL. I know this can be done using cache-max-ttl to limit the > whole cache, but can this be done for say one single or multiple defined > domains only? AFAIK there's no specially designed way to handle this, so achieving it will basically mean cobbling some parts together. max-cache-ttl is usable in a view statement, and each view by default gets its own cache. With the caveat that this might not be the best way and I haven't actually tested it, I'd try this. Set up a view that bound a listener to an interface alias on your host, and inside that view clamp down max-cache-ttl however you like. Back in your main configuration set up the zone(s) to forward to that private listener. I think even on the first hit, the TTL that your main resolver sees will be the one that got clamped in the view resolver, but I'm not positive about that. You will also get double the number of cache entries for each lookup, of course. ___ 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: forwarders used in order or based on RTT ?
On Fri, Oct 16, 2020 at 10:22 AM Matus UHLAR - fantomas wrote: >> On 16.10.20 09:56, Bob Harold wrote: > >The BIND ARM (9.16.2) says: > >"There may be one or more forwarders, and they are queried in turn until > >the list is exhausted or an answer is found." > > > >But [an old mailinglist post] says: > >"Forwarders are selected based on an RTT(round-trip-time)-based algorithm" > > > >So which is correct? > > both are. The ARM does not say they are queried in defined order. > The order is defined by RTT To be fair, the ARM strongly implies in its context that it's the order you put them in the list. The ARM discrepancy has already been noted by ISC, but the first bug report in the long long ago on it was never really fixed.They raised the issue again internally a few months ago and so I would anticipate that the ARM will be fixed in a not too distant release. https://gitlab.isc.org/isc-projects/bind9/-/issues/2030 ___ 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: Weird DNS behaviour resolution issues when more labels are present in a zone
On Wed, Dec 16, 2020 at 3:48 AM Prasanna Mathivanan (pmathiva) via
bind-users wrote:
> Whenever we have broken delegation as domain owners didn't follow proper RFC,
> the default behaviour of the query hits " _." which
> doesn’t exist.? And we get NXDOMAIN or SERVFAIL response.
Going back to your original example, a.b.c.example.com, qname
minimisation first identifies that there is a delegation at .com for
example.com, and then asks the example.com namesevers for
_.c.example.com. Typically this _.c.example.com query would come
back with either an NXDOMAIN answer, which means that the queried
nameserver believes it is authoritative for all names within
c.example.com, or it comes back with a NOERROR answer that lists a
delegation in the authority section.
In the first case (NXDOMAIN), the resolver knows it can ask the same
servers about _.b.c.example.com and the cycle repeats. In the latter
case, the resolver is able to distinguish between whether there was a
delegation for c.example.com (and ask the new nameservers about
_.b.c.example.com) or a delegation that's actually at _.c.example.com
(highly unusual, in which case, ask the original example.com
nameservers about _.b.c.example.com).
Getting a SERVFAIL throws a wrench in all this. It's the
authoritative server basically saying, "I'm badly broken and can't
tell you how." Generally this means the resolver should ask the next
server in the authoritative list. If they're all giving SERVFAIL then
the resolver can either try to work around the brokenness (for
example, by querying the full name at its closest enclosing
delegation) or just give up on the SERVFAIL.
--
tale
PS: While thinking about this I realized a weird case, which is if
only a subset of the parent nameservers are authoritative for a
subdomain. That is, imagine example.com is served by the four servers
ns{1,2,34}.example.com, but c.example.com is delegated only to
ns{1,2}.example.com. If you ask ns1 or ns2 about _.c.example.com,
they'll give an authoritative answer and the fact that a delegation
exists wouldn't be identified (absent DNSSEC), but asking ns3 or ns4
would give the delegation to ns1 and ns2. I can't think of how this
might be a real problem for future queries though, outside of the
usual type of brokenness that can happen even with full name queries
(eg, a parent has a subdomain configured that it isn't actually
delegated to it).
___
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: SRV Record Server Availability
On Tue, Jan 5, 2021 at 4:30 AM Wilfred Sarmiento via bind-users wrote: > Is DNS Bind SRV record can detect the Server's availability? If yes, how? Could you provide more information about your goal? I don't fully understand the question. For my reading, the answer is basically no, in that an SRV record just provides data about where.a particular service can be found. It's up to other systems to fetch that data and interpret it, including whether that service is actually available at the given endpoint. In its typical operation, BIND will just take whatever name and port the zone administrator said to provide for that SRV record, and not do any sort of availability checks on it. However, if you go deep into a far more complicated, custom use of BIND, you could set up a process that monitors the availability and changes the SRV record accordingly. -- tale ___ 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: Getting "query failed (REFUSED) for ./IN/ANY"
> >Are the queries refused because of the dot (.)? In the query log, I also > > found some 28 IN ANY queries from 7 IPs for xxx.at.fragolina.it, which > > probably got away with a NXDOMAIN. > > no. the dot is just the root domain. Correct that . is the root domain, but I'd say the answer is a qualified yes. If you are not providing open recursive services and are not authoritative for the root domain, BIND will respond with REFUSED just like it would if someone asked you about example.com when you're not authoritative for that. In the old days you'd get a root referral for authoritative resolution, but now you get a minimal REFUSED to signal lack of authority for the question. -- tale ___ 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: Updating a DNSSEC config to use a different algorithm
R9HEG6Sl9gIU9Nl73uRktnUxJspUjqrmOaWsUBcNXA== ) ; KSK; alg = ECDSAP256SHA256; key id = 42793 yourdomain.com. 1200 IN DNSKEY 256 3 13 ( w4SA1p/BBBrfs3216YNkQ6+xyoPkttXQNCHhoaNbPl4lI l0PDL9REtOhjo54p943UNFWXg/ZHUqzZzzu321Ztgw== ) ; ZSK; alg = ECDSAP256SHA256; key id = 34567 @host01:/etc/bind# 6. Update your TLSA & DKIM records == Hopefully you are using DANE with Postfix, update your host TLSA entry for your zone: Update TLSA: tlsa --create --selector 1 --certificate host01.yourdomain.com.pem host01.yourdomain.com @host01:/xx/# tlsa --create --selector 1 --certificate host01.yourdomain.com.pem host01.yourdomain.com Got a certificate with Subject: /CN=host01.yourdomain.com _443._tcp.host01.yourdomain.com. IN TLSA 3 1 1 FF774433KK5cdbccb18f278fccfdb833f1b8cf81e37c2e212b147D88vBBns632 Update DKIM: cd /etc/opendkim/keys/yourdomain.com opendkim-genkey -r -h sha256 -d yourdomain.com -s mail -b 2048 root@host01:/etc/opendkim/keys/yourdomain.com# ls -lt -rw--- 1 opendkim opendkim 1456 Jan 5 11:05 mail.private -rw--- 1 opendkim opendkim 502 Jan 5 11:05 mail.txt @host01:/etc/opendkim/keys/yourdomain.com# more mail.txt mail._domainkey IN TXT ( "v=DKIM1; h=sha256; k=rsa; s=email; " "p=MII...etc.. xxw22" "89uADXXUC/5BugylW8327dDQA18m1X...etc..F893P99xaAB ) ; - DKIM key mail for yourdomain.com Place the new TLSA and DKIM records in your zone, inc Serial, re-sign. Job done. Mal ___ 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: DNSSEC and NSEC missing ZSK?
On 09/02/2021 10:47 pm, @ wrote: > Well, I have finally ogttenteh test zone to the point where dnssec-verify is > happy and everything that I can check also seems happy except dnsviz which is > very very VERY angry and basically says the zone is entirely garabge. I am > hoping this is a propagation issue, but I kind of doubt it since it should be > quarrying the authoritative DNS for the DNSKEY and RRSIG and such, I'd think. The easiest way to get help is to post your named.conf and zone file. Obfuscating the configuration works against you, especially when you have a limited understanding of DNSSEC. DNSVIZ displays your current state very well. If its showing you errors, then it requires you to act. The query IPs DNSVIZ typically uses are: 64.191.0.132 64.191.0.138 2620:ff:c000::132 2620:ff:c000::138 So you can easily reconcile the DNSVIZ query, in real time, that produced your data set. The DS record propagation, at the registry level, should never take days (no more than 15-30 minutes is my experience). You need to make sure you have configured (or instructed the registry, per manual intervention) the correct Algorithm (13) and the digest type (SHA256) when you provide your Hash. ___ 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
broken trust chain with my DNS setup
Hi hope someone can help here is my setup on Bind 9.17.10. https://bridgemode.bounceme.net/DNS%20BIND%20setup.html <https://bridgemode.bounceme.net/DNS%20BIND%20setup.html> https://bridgemode.bounceme.net/DNS%20BIND%20setup2.txt When working what happens is: first lookup Lookup by 127.0.0.1 on main PC then bind forwards to 192.168.255.53 from 192.168.255.56 then HTPC by bind forwards to 192.168.255.55 from 192.168.255.53 Main PC then does the recursion lookup in the given view/ACL second lookup Lookup by 192.168.255.53 on main PC from 192.168.255.55 then HTPC by bind forwards to 192.168.255.56 from 192.168.255.54 Main PC then does the recursion lookup in the given view/ACL *issue* What happens is this after many days of working fine: querylog yes; client @0227150F1FE8 127.0.0.1#55768 (community.zyxel.com): view loopbackPC: query failed (broken trust chain) for community.zyxel.com/IN/A at c:\builds\isc-private\bind9\lib\ns\query.c:7581 ^This is from windows event viewer Only way to fix is to restart bind on the main PC. Thanks if you can help ___ 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
broken trust chain with my DNS setup
ys";
querylog yes;
};
view "lookupbacktoPC" {
match-clients { lookupbacktoPC;};
forward only;
forwarders { 192.168.255.55; };
query-source address 192.168.255.53 port *;
// root zone
zone "." in { type hint; file "named.root";
};
// local direct zone
zone"localhost" { type master; file "localhost";
};
// local reverse zone
zone"0.0.127.in-addr.arpa"{ type master; file "127.0.0.zone";
};
};
view "lookup2backtoPC" {
match-clients { lookup2backtoPC; };
forward only;
forwarders { 192.168.255.56; };
query-source address 192.168.255.54 port *;
// root zone
zone "." in { type hint; file "named.root";
};
// local direct zone
zone"localhost" { type master; file "localhost";
};
// local reverse zone
zone"0.0.127.in-addr.arpa" { type master; file "127.0.0.zone";
};
};
___
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
sub-zone on the same server but in different backend - how?
Hi guys. To experts that most likely be silly easy but my brain got tangled up and cannot get around it now(also being a novice) Have a zone on a server, say: - the.zone with "flat" files being the backend for it. Now wanting to have: - sub.the.zone served by the same BIND server, but stored in.. "SQL" backend. How... well how to make that work if at all possible? I'd hope it can be done with some "trickery" in config/zone files if it is not 'easy-peasy' many thanks, L. ___ 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
Temporarily no name resolution using second/virtual ip address
Hi everybody,
for the name resolution in my network I use bind-9.16.6 based on openSuse Leap
15.2. On that server I have two IP addresses configured. The one for the server
itself - e.g. 192.168.3.150 - and a second one for the DNS - e.g.
192.168.3.200.
If I send DNS-Queries to the IP 192.168.3.150, all queries will be
answered. Sending queries to the IP 192.168.3.200, some of them become
answered, but most of them not. The DNS-Client like nslookup or dig runs into
timeouts.
I have increased my debug level and what I see is the following:
17-Mar-2021 22:44:06.079 client: debug 3: client @0x7f063000b180
127.0.0.1#55255: UDP request 17-Mar-2021 22:44:06.079 client: debug 5: client
@0x7f063000b180 127.0.0.1#55255: using view '_default' 17-Mar-2021 22:44:06.079
security: debug 3: client @0x7f063000b180 127.0.0.1#55255: request is not
signed 17-Mar-2021 22:44:06.079 security: debug 3: client @0x7f063000b180
127.0.0.1#55255: recursion available 17-Mar-2021 22:44:06.079 security: debug
3: client @0x7f063000b180 127.0.0.1#55255 (my.host.domain.de): query
'my.host.domain.de/A/IN' approved 17-Mar-2021 22:44:06.079 security: debug 3:
client @0x7f0630007440 127.0.0.1#35797 (my.host.domain.de): reset client
17-Mar-2021 22:44:06.079 security: debug 3: client @0x7f063000b180
127.0.0.1#55255 (my.host.domain.de): reset client
My bind-config and examples are attached below.
/etc/named.conf
options { directory "/var/lib/named"; managed-keys-directory
"/var/lib/named/dyn/"; dump-file "/var/log/named_dump.db"; statistics-file
"/var/log/named.stats"; forwarders { xxx.xxx.xxx.xxx; }; listen-on port 53 {
127.0.0.1; 192.168.3.150; 192.168.3.200; }; listen-on-v6 { none; };
query-source address 192.168.3.200 port *; transfer-source 192.168.3.200 port
53; allow-query { 127.0.0.1; 192.168.0.0/24; 192.168.1.0/24; 192.168.2.0/24;
192.168.3.0/24; 192.168.4.0/24; }; notify no; disable-empty-zone
"1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
allow-transfer { localhost; 192.168.0.170; }; recursion yes; }; logging {
channel default_file { file "/var/log/named.log" size 10m; severity dynamic;
print-time yes; print-severity yes; print-category yes; }; category default{
default_file; }; }; zone "." in { type hint; file "root.hint"; }; zone
"localhost" in { type master; file "localhost.zone"; }; zone
"0.0.127.in-addr.arpa" in { type master; file "127.0.0.zone"; }; include
"/etc/bind/zones.conf";
It makes no difference from which subnet the queries come from. For testing I
used a server in the same subnet like my DNS is, so there is no firewall or NAT
in between.
I also captured the network traffic of the DNS-Server and -Client. All I can
see is, that the server receives the query from the client, but no response is
sent from the server.
When I run dig with the +tcp option, all of the queries will be answered.
Any idea why named resets the client? Thanks and regard,
Jonathan
___
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
Dnssec delegation NS RRset
I am getting the following warning: The following NS name(s) were found in the authoritative NS RRset, but not in the delegation NS RRset (i.e., in the com zone): (a DNS server) The DNS server exists and is used by other domains, so This is something specific to this one domain and not to the DNS servers, so I think it must be something on the registrar. Missing glue records? -- You have the effrontery to be squeamish, it thought at him. But we were dragons. We were supposed to be cruel, cunning, heartless, and terrible. But this much I can tell you, you ape - the great face pressed even closer, so that Wonse was staring into the pitiless depths of his eyes - we never burned and tortured and ripped one another apart and called it morality. --Guards! Guards! ___ 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
Dnssec-policy Purge-keys
Doe anyone know the syntax for using purge-keys in 9.16.13? I've search and all I can find is notes that it was added. I've tried a couple of things, but I am shooting in the dark. I cannot redefine the "default" policy as that gives and error and simply putting "purge-keys P90D;" or "dnssec-policy purge-keys P90D;" in options files. I'm sure it's simple, but simply what? -- So, the apocalypse is happening and whatever and this little piggy comes all this way, but you won’t accept my help because I’m a woman? Pig: Quite right. ___ 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
NXDOMAIN processing
Hi!
BIND 9.11.5, I forward the request ("forward zone" or global "forward first")
to another server and I get NXDOMAIN. Is it possible to process NXDOMAIN other
than "redirect zone"? I just want to repeat the request to another forwarder.
Dmitry Filimonov___
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: REST API for recursive queries
On Tue, May 4, 2021 at 8:42 AM Roee Mayerowicz wrote: > Do you know of a way to ask multiple DNS queries in a recursive bind server > at the same packet\request? > Using DoH might work? How? Is there a plugin which does that? The short answer is no, but it might not be answering the question you're really trying to ask. In strict terms of what would constitute "the same request", though, no. While you could conceive of a legally-formed DNS packet that had multiple questions in the Question section, a server has no way to acceptably indicate the proper response for all questions. In some cases, it might be obvious -- say, asking for the address of a.example.com and b.example.com, and them both having addresses -- but things quickly get out of hand when you look at the problems of indicating the many other ways that DNS can answer, like NXDOMAIN, NODATA, or delegation. With various forms of DNS TCP connections -- vanilla DNS, DNS over TLS (DoT), DNS over HTTPS (DoH) -- you can put multiple DNS request messages over the same connection. But that's not quite the same as "at the same packet\request". It also can depend on the end points; you might want to shove 1000 requests down a TCP connection, but server policy might limit the number it will actually process before terminating the link. And plugins are specific to a particular software package. Plugin to what? BIND and other major DNS resolvers and authoritative servers support TCP technologies natively. The clients that talk to them are numerous, with varying degrees of support for both TCP initiation and multi-request streaming. -- tale ___ 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: Any interest in a write-up showing how to configure BIND 9.17x with DoH and LetsEncrypt?
On 30 May 2021, at 12:23, Grant Taylor via bind-users wrote: > On 5/30/21 9:24 AM, Richard T.A. Neal wrote: >> I spent a little time this weekend setting-up BIND 9.17.13 on Ubuntu 21.04 >> and configuring the system as a recursive resolver offering DNS over HTTPS >> using a LetsEncrypt certificate. > > Nice work. > >> Is there any interest in me writing this up as a web article, or has >> everyone who’s interested in DoH already got it running comfortably in their >> test environment? > > Yes! +1 Or, perhaps, +100 -- NO ONE WANTS TO HEAR FROM MY ARMPITS Bart chalkboard Ep. 3F01 ___ 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
Deprecating BIND 9.18+ on Windows (or making it community improved and supported
Well that sucks no more bind for windows...:( ___ 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
Deprecating BIND 9.18+ on Windows (or making it community improved and supported
Maybe they could release a bind for windows ever year with limited support? But I guess bind will still work long after its not supported which is the only good thing. ___ 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
Deprecating BIND 9.18+ on Windows (or making it community improved and supported
Guess not even a subscription will not happen too. I'm having to try and do Bind on ubuntu and it just will not let me edit files like named.conf unless you do some vodoo that I don't understand and even updating the bind like how? Windows no problem you want to edit a file no problem can't edit a file/folder because of permissions your a admin you can do that too. Bind is easy on windows. On another note when you stop the bind service you get “windows could not stop ISC BIND service on local computer. Error 1067 the process terminated unexpectedly.” wonder if that be the last fix for 9.17.14. ___ 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
No more support for windows
When people find out2024 is the year bind is no longer supported for windows people aregoing to be upset this all seems to be done quietly nothing posted on the the isc.org site about this just how many people depend on bind for windows will be shocking. ___ 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
No more support for windows
On 04/06/2021 6:05 pm, John Thurston wrote: On 6/4/2021 8:48 AM, Peter via bind-users wrote: When people find out2024 is the year bind is no longer supported for windows people aregoing to be upset this all seems to be done quietly nothing posted on the the isc.org site about this just how many people depend on bind for windows will be shocking. And griping about the decision on the mailing list is annoying. If you want to alter the decision, bring something new to the discussion. Funding to pay for the windows development team? Logistical support for the project? Anything constructive will be better received than repeating "I don't like your decision". Yes John Thurston I said about a subscription here which I guess will not happen if they made up thier mind its likly no going to happen. Deprecating BIND 9.18+ on Windows (or making it community improved and supported (isc.org) <https://lists.isc.org/pipermail/bind-users/2021-June/104719.html> ___ 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: No more support for windows
Well its clearly not working so it needs to change just like DDNS is free but you can paid for a subscription thats easy to do or SSL is free for 90days but you have the option to pay easily for a year but that might not work for bind for windows so it needs to be a subscription to run it at least for windows so it can be supported. This would mean some type of activation that can't work on another system how thats done I don't know like what if the system its running on goes down and you have to put bind on another system how do you deal with that and so onmaybe if you do a year subscription of some amount you get 12 one time keys in a file that bind uses each month to valid your use and removes a key this list can be updated to add more keys as you extend the subscription so in the event the system dies you have some keys for a new system. But I don't really see this happening would like to be proven wrong... ___ 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
cmdns.dev.dns-oarc.net oddness with windows 10 and bind
So I redone my windows bind setup on a new system and this bug may never get fixed but I wanted to post the oddness of this bug. Bind on New PC as servers 127.0.0.1 for dns on that system cmdns.dev.dns-oarc.net reports fine except for IPv6 test OK I then have two PC's as clients to this DNS bind server 192.168.255.62 and 192.168.53.2 the internet works fine DNS seems to work fine but testing at cmdns.dev.dns-oarc.net shows some failed tests for IPv4. And it gets odder if on that PC I remove 192.168.255.62 and 192.168.53.2 and put in 127.0.0.1 setup bind with forwarder only 192.168.255.62 and 192.168.53.2 then run cmdns.dev.dns-oarc.net it shows as fine! I just don't get it? ___ 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
9.11 to 9.16: need directions
Hi All, I just upgraded from Fedora 33 to Fedora 34. Bind was updated from 9.11 to 9.16 in Fedora 34. It completely broke my Fedora 33 configuration. Would someone please point me to the directions as to how to migrate from 9.11 to 9.16? Many thanks, -T ___ 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: 9.11 to 9.16: need directions
On 6/12/21 5:30 PM, ToddAndMargo via bind-users wrote: Hi All, I just upgraded from Fedora 33 to Fedora 34. Bind was updated from 9.11 to 9.16 in Fedora 34. It completely broke my Fedora 33 configuration. Would someone please point me to the directions as to how to migrate from 9.11 to 9.16? Many thanks, -T Some of my error messages: # named-checkzone -t /var/named/chroot/var/named/slaves xyz xyz.hosts xyz.hosts:3: ignoring out-of-zone data (xyz.local) xyz.hosts:15: ignoring out-of-zone data (DeadStick.xyz.local) 1$ORIGIN . 2$TTL 86400; 1 day 3xyz.localIN SOAxyz.local. root\@rn6.xyz.local. ( 4265; serial 510800 ; refresh (3 hours) 63600 ; retry (1 hour) 7360; expire (5 weeks 6 days 16 hours) 886400 ; minimum (1 day) 9) 10NSxyz.local. 11A192.168.255.10 12MX10 xyz.local. 13$ORIGIN xyz.local. 14$TTL 3600; 1 hour 15DeadStickA192.168.255.156 16TXT"310702541c5622d0e6001136bd71a6578b" ___ 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: 9.11 to 9.16: need directions
On 6/12/21 7:49 PM, Mark Andrews wrote:
Please don’t hid details if you want help.
If you really want help post all the un-doctored log messages.
B.T.W. The messages below are because you used the wrong zone name on the
named-checkconf command line. The zone file is for xyz.local and you said the
zone name you used was xyz without the .local.
I posted the error I have see so far. Please give me a list of other
error reporting options.
Please note that everything worked perfectly under Fedora 33 and bind 9,11.
Now that I have the .local, things improved for abc.hosts,
# named-checkzone -t /var/named/chroot/var/named/slaves abc.local abc.hosts
zone abc.local/IN: loaded serial 265
OK
but not abc.hosts.rev
# named-checkzone -t /var/named/chroot/var/named/slaves abc.local
abc.hosts.rev
abc.hosts.rev:3: ignoring out-of-zone data (255.168.192.in-addr.arpa)
abc.hosts.rev:14: ignoring out-of-zone data
abc.hosts(10.255.168.192.in-addr.arpa)
abc.hosts.rev:17: ignoring out-of-zone data
12 repeats
zone abc.local/IN: has 0 SOA records
zone abc.local/IN: has no NS records
zone abc.local/IN: not loaded due to errors.
# cat --number /var/named/chroot/var/named/slaves/abc.hosts.rev
1 $ORIGIN .
2 $TTL 86400 ; 1 day
3 255.168.192.in-addr.arpa IN SOA rn6.abc.local.
root\@rn6.abc.local. (
4 213; serial
5 10800 ; refresh (3 hours)
6 3600 ; retry (1 hour)
7 360; expire (5 weeks 6 days 16
hours)
8 86400 ; minimum (1 day)
9 )
10 NS rn6.abc.local.
11 A 192.168.255.10
12 PTR rn6.abc.local.
13 $ORIGIN 255.168.192.in-addr.arpa.
14 10 A 192.168.255.10
15 PTR rn6.abc.local.
16 $TTL 3600 ; 1 hour
17 112 PTR KVM-W7.abc.local.
What exactly is wrong with the zone?
3 255.168.192.in-addr.arpa IN SOA rn6.abc.local.
And here is status ("not loaded due to errors"):
# systemctl status named.service
× named.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named.service; enabled;
vendor preset: disabled)
Active: failed (Result: exit-code) since Sat 2021-06-12 16:31:16
PDT; 3h 46min ago
Process: 18368 ExecStartPre=/bin/bash -c if [ !
"$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z
"$NAMEDCONF"; else echo "Checking of zone files is >
CPU: 12ms
Jun 12 16:31:16 rn6.abc.local bash[18369]: _default/abc.local/IN: file
not found
Jun 12 16:31:16 rn6.abc.local bash[18369]: zone
255.168.192.in-addr.arpa/IN: loading from master file
slaves/abc.hosts.rev failed: file not found
Jun 12 16:31:16 rn6.abc.local bash[18369]: zone
255.168.192.in-addr.arpa/IN: not loaded due to errors.
Jun 12 16:31:16 rn6.abc.local bash[18369]:
_default/255.168.192.in-addr.arpa/IN: file not found
Jun 12 16:31:16 rn6.abc.local bash[18369]: zone 0.0.127.in-addr.arpa/IN:
loading from master file named.local failed: file not found
Jun 12 16:31:16 rn6.abc.local bash[18369]: zone 0.0.127.in-addr.arpa/IN:
not loaded due to errors.
Jun 12 16:31:16 rn6.abc.local bash[18369]:
_default/0.0.127.in-addr.arpa/IN: file not found
Jun 12 16:31:16 rn6.abc.local systemd[1]: named.service: Control process
exited, code=exited, status=1/FAILURE
Jun 12 16:31:16 rn6.abc.local systemd[1]: named.service: Failed with
result 'exit-code'.
Jun 12 16:31:16 rn6.abc.local systemd[1]: Failed to start Berkeley
Internet Name Domain (DNS).
from named.local:
zone "255.168.192.in-addr.arpa" {
type master;
# file "/var/named/chroot/var/named/slaves/abc.hosts.rev";
file "slaves/abc.hosts.rev";
allow-update { key DHCP_UPDATER; };
# allow-update { 127.0.0.1; };
};
Thank you for the help. Let me know if I did if I
missed posting enough information.
-T
___
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: 9.11 to 9.16: need directions
On 6/12/21 8:30 PM, ToddAndMargo via bind-users wrote:
# named-checkzone -t /var/named/chroot/var/named/slaves abc.local
abc.hosts.rev
abc.hosts.rev:3: ignoring out-of-zone data (255.168.192.in-addr.arpa)
abc.hosts.rev:14: ignoring out-of-zone data
abc.hosts(10.255.168.192.in-addr.arpa)
abc.hosts.rev:17: ignoring out-of-zone data
# rpm -aq bind\*
bind-export-libs-9.11.11-1.fc30.x86_64
bind-license-9.16.16-1.fc34.noarch
bind-dnssec-doc-9.16.16-1.fc34.noarch
bind-libs-9.16.16-1.fc34.x86_64
bind-utils-9.16.16-1.fc34.x86_64
bind-dnssec-utils-9.16.16-1.fc34.x86_64
bind-9.16.16-1.fc34.x86_64
bind-chroot-9.16.16-1.fc34.x86_64
Oh poop. I had the zone name wrong again. The zone
name comes directly from named.conf. Duh!
# named-checkzone -t /var/named/chroot/var/named/slaves
255.168.192.in-addr.arpa abc.hosts.rev
zone 255.168.192.in-addr.arpa/IN: loaded serial 213
OK
Now I also have
# named-checkzone -t /var/named/chroot/var/named/slaves abc.local abc.hosts
zone abc.local/IN: loaded serial 265
OK
and
# named-checkconf -l -t /var/named/chroot /etc/named.conf
abc.local IN _default master
255.168.192.in-addr.arpa IN _default master
0.0.127.in-addr.arpa IN _default master
So why am I getting file not found in the following?
# systemctl status named.service
× named.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named.service; enabled;
vendor preset: disabled)
Active: failed (Result: exit-code) since Sat 2021-06-12 16:31:16
PDT; 3h 46min ago
Process: 18368 ExecStartPre=/bin/bash -c if [ !
"$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z
"$NAMEDCONF"; else echo "Checking of zone files is >
CPU: 12ms
Jun 12 16:31:16 rn6.abc.local bash[18369]: _default/abc.local/IN: file
not found
Jun 12 16:31:16 rn6.abc.local bash[18369]: zone
255.168.192.in-addr.arpa/IN: loading from master file
slaves/abc.hosts.rev failed: file not found
Jun 12 16:31:16 rn6.abc.local bash[18369]: zone
255.168.192.in-addr.arpa/IN: not loaded due to errors.
Jun 12 16:31:16 rn6.abc.local bash[18369]:
_default/255.168.192.in-addr.arpa/IN: file not found
Jun 12 16:31:16 rn6.abc.local bash[18369]: zone 0.0.127.in-addr.arpa/IN:
loading from master file named.local failed: file not found
Jun 12 16:31:16 rn6.abc.local bash[18369]: zone 0.0.127.in-addr.arpa/IN:
not loaded due to errors.
Jun 12 16:31:16 rn6.abc.local bash[18369]:
_default/0.0.127.in-addr.arpa/IN: file not found
Jun 12 16:31:16 rn6.abc.local systemd[1]: named.service: Control process
exited, code=exited, status=1/FAILURE
Jun 12 16:31:16 rn6.abc.local systemd[1]: named.service: Failed with
result 'exit-code'.
Jun 12 16:31:16 rn6.abc.local systemd[1]: Failed to start Berkeley
Internet Name Domain (DNS).
My /etc/named.local
// generated by named-bootconf.pl
options {
# the following forwarders is Family freindly Open DNS:
# forwarders { 208.67.222.122; 208.67.220.120; };
# the following forwarders is for Open DNS
forwarders { 208.67.222.222; 208.67.220.220; };
# the following forwarders is for Google's DNS
#forwarders { 8.8.8.8; 8.8.4.4; };
directory "/var/named";
# pid-file "/var/named/chroot/run/named/named.pid";
# pid-file "/var/named/chroot/run/named/nonamed.pid";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
};
key DHCP_UPDATER {
algorithm hmac-md5;
secret cgGq509uDODGTU4J9QZwgQ==;
};
zone "abc.local" {
type master;
# file "/var/named/chroot/var/named/slaves/abc.hosts";
file "slaves/abc.hosts";
allow-update { key DHCP_UPDATER; };
# allow-update { 127.0.0.1; };
};
zone "255.168.192.in-addr.arpa" {
type master;
# file "/var/named/chroot/var/named/slaves/abc.hosts.rev";
file "slaves/abc.hosts.rev";
allow-update { key DHCP_UPDATER; };
# allow-update { 127.0.0.1; };
};
zone "0.0.127.in-addr.arpa" {
type master;
# file "/var/named/chroot/var/named/named.local";
file "named.local";
};
# logging {
# channel update_debug {
# file
"/var/named/chroot/var/named/slaves/named-update-debug.log";
# severity debug 3;
# print-category yes;
# print-severity yes;
# print-time yes;
# };
# channel security_info{
# file "slaves/named-auth.info";
# severity info;
Re: 9.11 to 9.16: need directions
On 6/12/21 10:55 PM, Ondřej Surý wrote: Most likely SELinux policy is preventing access to those files. Check the other logs. Ondřej -- Ondřej Surý — ISC (He/Him) No SE Linux error popping up. But I shut it off temporarily anyway. No symptom change. Rats! # setenforce Permissive # systemctl start named.service Job for named.service failed because the control process exited with error code. See "systemctl status named.service" and "journalctl -xeu named.service" for details. # systemctl status named.service × named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Sat 2021-06-12 23:00:31 PDT; 10s ago Process: 26835 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z "$NAMEDCONF"; else echo "Checking of zone files is d> CPU: 11ms Jun 12 23:00:31 rn6.abc.local bash[26836]: _default/abc.local/IN: file not found Jun 12 23:00:31 rn6.abc.local bash[26836]: zone 255.168.192.in-addr.arpa/IN: loading from master file slaves/abc.hosts.rev failed: file not found Jun 12 23:00:31 rn6.abc.local bash[26836]: zone 255.168.192.in-addr.arpa/IN: not loaded due to errors. Jun 12 23:00:31 rn6.abc.local bash[26836]: _default/255.168.192.in-addr.arpa/IN: file not found Jun 12 23:00:31 rn6.abc.local bash[26836]: zone 0.0.127.in-addr.arpa/IN: loading from master file named.local failed: file not found Jun 12 23:00:31 rn6.abc.local bash[26836]: zone 0.0.127.in-addr.arpa/IN: not loaded due to errors. Jun 12 23:00:31 rn6.abc.local bash[26836]: _default/0.0.127.in-addr.arpa/IN: file not found Jun 12 23:00:31 rn6.abc.local systemd[1]: named.service: Control process exited, code=exited, status=1/FAILURE Jun 12 23:00:31 rn6.abc.local systemd[1]: named.service: Failed with result 'exit-code'. Jun 12 23:00:31 rn6.abc.local systemd[1]: Failed to start Berkeley Internet Name Domain (DNS). ___ 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: 9.11 to 9.16: need directions
On 6/12/21 5:30 PM, ToddAndMargo via bind-users wrote:
Hi All,
I just upgraded from Fedora 33 to Fedora 34.
Bind was updated from 9.11 to 9.16 in Fedora 34.
It completely broke my Fedora 33 configuration.
Would someone please point me to the directions
as to how to migrate from 9.11 to 9.16?
Many thanks,
-T
Oh poop! Figured it out!
# systemctl status named-chroot.service
● named-chroot.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named-chroot.service;
enabled; vendor preset: disabled)
Active: active (running) since Sat 2021-06-12 14:49:05 PDT; 8h ago
Process: 11410 ExecStartPre=/bin/bash -c if [ !
"$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -t
/var/named/chroot -z "$NAMEDCONF"; else echo "Checki>
Process: 11446 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF}
-t /var/named/chroot $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 11452 (named)
Tasks: 14 (limit: 19025)
Memory: 141.5M
CPU: 14.612s
CGroup: /system.slice/named-chroot.service
└─11452 /usr/sbin/named -u named -c /etc/named.conf -t
/var/named/chroot
I was starting the wrong named !!!
# systemctl disable daemon_name.service
Fixed the problem
Freaking FC34 upgrade disabled named-chroot on me!
Sorry for putting your guys through all this. Thank
you all for the tips!
-T
___
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: 9.11 to 9.16: need directions
Oh but no errors and it still does not work! # host 8.8.8.8 Host 8.8.8.8.in-addr.arpa not found: 2(SERVFAIL) # host 8.8.8.8 8.8.4.4 Using domain server: Name: 8.8.4.4 Address: 8.8.4.4#53 Aliases: 8.8.8.8.in-addr.arpa domain name pointer dns.google. and nothing appeared in /var/log/messages Tears! ___ 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: 9.11 to 9.16: need directions
On 6/12/21 11:47 PM, ToddAndMargo via bind-users wrote: Oh but no errors and it still does not work! # host 8.8.8.8 Host 8.8.8.8.in-addr.arpa not found: 2(SERVFAIL) # host 8.8.8.8 8.8.4.4 Using domain server: Name: 8.8.4.4 Address: 8.8.4.4#53 Aliases: 8.8.8.8.in-addr.arpa domain name pointer dns.google. and nothing appeared in /var/log/messages Tears! Okay, now I am REALLY confused!!! # host 8.8.8.8 127.0.0.1 Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: Host 8.8.8.8.in-addr.arpa not found: 2(SERVFAIL) This is my /etc/resolv.conf (same as in FC33): # cat /etc/resolv.conf # Generated by NetworkManager search abc.local nameserver 127.0.0.1 # nameserver 8.8.8.8 Now what ?!?!?! ___ 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: 9.11 to 9.16: need directions
On 6/13/21 12:13 AM, ToddAndMargo via bind-users wrote:
On 6/12/21 11:47 PM, ToddAndMargo via bind-users wrote:
Oh but no errors and it still does not work!
# host 8.8.8.8
Host 8.8.8.8.in-addr.arpa not found: 2(SERVFAIL)
# host 8.8.8.8 8.8.4.4
Using domain server:
Name: 8.8.4.4
Address: 8.8.4.4#53
Aliases: 8.8.8.8.in-addr.arpa domain name pointer dns.google.
and nothing appeared in /var/log/messages
Tears!
Okay, now I am REALLY confused!!!
# host 8.8.8.8 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
Host 8.8.8.8.in-addr.arpa not found: 2(SERVFAIL)
This is my /etc/resolv.conf (same as in FC33):
# cat /etc/resolv.conf
# Generated by NetworkManager
search abc.local
nameserver 127.0.0.1
# nameserver 8.8.8.8
Now what ?!?!?!
A workaround i at the bottom
# host google.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
Host google.com not found: 2(SERVFAIL)
[root@rn6 etc]# systemctl status named-chroot.service
● named-chroot.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named-chroot.service;
enabled; vendor preset: disabled)
Active: active (running) since Sun 2021-06-13 01:39:12 PDT; 1min
12s ago
Process: 32167 ExecStartPre=/bin/bash -c if [ !
"$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -t
/var/named/chroot -z "$NAMEDCONF"; else echo "Checki>
Process: 32170 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF}
-t /var/named/chroot $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 32171 (named)
Tasks: 14 (limit: 19025)
Memory: 97.2M
CPU: 180ms
CGroup: /system.slice/named-chroot.service
└─32171 /usr/sbin/named -u named -c /etc/named.conf -t
/var/named/chroot
Jun 13 01:40:05 rn6.abc.local named[32171]: network unreachable
resolving 'com/DS/IN': 2001:503:c27::2:30#53
Jun 13 01:40:05 rn6.abc.local named[32171]: network unreachable
resolving 'com/DS/IN': 2001:500:1::53#53
Jun 13 01:40:05 rn6.abc.local named[32171]: network unreachable
resolving 'com/DS/IN': 2001:500:2::c#53
Jun 13 01:40:05 rn6.abc.local named[32171]: network unreachable
resolving 'com/DS/IN': 2001:500:200::b#53
Jun 13 01:40:05 rn6.abc.local named[32171]: network unreachable
resolving 'com/DS/IN': 2001:500:12::d0d#53
Jun 13 01:40:05 rn6.abc.local named[32171]: network unreachable
resolving 'com/DS/IN': 2001:500:9f::42#53
Jun 13 01:40:05 rn6.abc.local named[32171]: network unreachable
resolving 'com/DS/IN': 2001:7fd::1#53
Jun 13 01:40:05 rn6.abc.local named[32171]: validating com/DS: no valid
signature found
Jun 13 01:40:05 rn6.abc.local named[32171]: no valid RRSIG resolving
'com/DS/IN': 192.36.148.17#53
Jun 13 01:40:05 rn6.abc.local named[32171]: broken trust chain resolving
'google.com/A/IN': 208.67.220.220#53
Found in /var/log/messages:
Jun 13 01:43:12 rn6 named[32171]: validating google.com/A: bad cache hit
(com/DS)
Jun 13 01:43:12 rn6 named[32171]: broken trust chain resolving
'google.com/A/IN': 208.67.220.220#53
I added this to named.conf, options block:
dnssec-validation no;
and it fixed it.
How do I fix it without dnssec-validation no; ?
-T
# host google.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
google.com has address 172.217.6.78
google.com has IPv6 address 2607:f8b0:4005:80a::200e
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.
___
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
'managed-keys' is deprecated ??
Hi All, Fedora 34 bind 9.16 The Duck is failing me. Placing include "/etc/named.root.key"; in my bind.conf, give me the following error: # named-checkconf -l -t /var/named/chroot /etc/named.conf /etc/named.root.key:1: option 'managed-keys' is deprecated What do I use in its place? Many thanks, -T ___ 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
My FC33->FC34 bind-chroot upgrade notes
Hi All,
Thank you all for the enormous help in me getting bind-chroot
working after upgrading to Fedora 34. Here are my notes.
Hope this helps someone else.
-T
Broken bind-chroot repair after upgrading to Fedora 34:
# means root
$ means user
1) temporary workaround so you can surf the Internet for help:
Change /etc/resolv.conf to
# search your_domain
# nameserver your_IP
nameserver 208.67.222.123
2) in their "ultimate wisdom", the rpm maintainers disabled
the service after upgrading it. See the following bug I posted
on 2021-06-14:
Bind-chroot upgrade from FC3 to FC34 disables the service
breaking a server
https://bugzilla.redhat.com/show_bug.cgi?id=1972000
To repair:
# systemctl enable named-chroot.service
# systemctl start named-chroot.service
Other useful command(s):
# systemctl stopnamed-chroot.service
# systemctl status named-chroot.service
# systemctl restart named-chroot.service
3) the new version of bind-chroot enables "dns security validation" by
default.
To repair, place the following in your named.conf:
by itself at the bottom:
include "/etc/named.root.key";
add the following to your "options" block:
dnssec-validation yes;
Other useful command(s):
Validation check:
$ delv @$IP com ds
$ delv @208.67.222.123 com ds
; fully validated
...
4) check (and repair) your configurations:
named.conf:
# named-checkconf -l -t /var/named/chroot /etc/named.conf
Note: if you get the following error message,
`/etc/named.root.key:1: option 'managed-keys' is
deprecated`
it is a bug in named-checkconf.
See the following I posted on 2021-06-14. Just ignore
the message.
named-checkconf gives confusing depreciated
'managed-keys' message
https://bugzilla.redhat.com/show_bug.cgi?id=1972022
Zones:
# named-checkzone -t directory domain filename
Note: the "domain name" in the following comes from named.conf
zone, not `domainname`. For example:
zone "abc.local" {
type master;
file "slaves/rent-a-nerd.hosts";
allow-update { key DHCP_UPDATER; };
};
The "domain" is the name of the "zone". "abc.local" in the above
# named-checkzone -t /var/named/chroot/var/named/slaves
abc.local abc.hosts
zone abc.local/IN: loaded serial 265
OK
# named-checkzone -t /var/named/chroot/var/named/slaves
255.168.192.in-addr.arpa abc.hosts.rev
zone 255.168.192.in-addr.arpa/IN: loaded serial 213
OK
5) restart the bind-chroot service:
Change /etc/resolv.conf back to
search your_domain
nameserver your_IP
# nameserver 208.67.222.123
# systemctl restart named-chroot.service
check for and repair errors with:
$ systemctl status named-chroot.service
# tail -f /var/log/messages
___
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: 'managed-keys' is deprecated ??
On 6/14/21 9:30 PM, Jim Popovitch via bind-users wrote: On Tue, 2021-06-15 at 14:27 +1000, Mark Andrews wrote: https://downloads.isc.org/isc/bind9/9.16.16/doc/arm/Bv9ARM.pdf The modern-day RTFM :-) -Jim P. "Just Google it." The new RTFM. Chuckle! And ' 'managed-keys' is deprecated" is a bug. I just reported: named-checkconf gives confusing depreciated 'managed-keys' message https://bugzilla.redhat.com/show_bug.cgi?id=1972022 :'( -T ___ 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: 'managed-keys' is deprecated ??
On 15-06-2021 07:46, ToddAndMargo via bind-users wrote: On 6/14/21 9:30 PM, Jim Popovitch via bind-users wrote: On Tue, 2021-06-15 at 14:27 +1000, Mark Andrews wrote: https://downloads.isc.org/isc/bind9/9.16.16/doc/arm/Bv9ARM.pdf The modern-day RTFM :-) -Jim P. "Just Google it." The new RTFM. Chuckle! And ' 'managed-keys' is deprecated" is a bug. I just reported: named-checkconf gives confusing depreciated 'managed-keys' message https://bugzilla.redhat.com/show_bug.cgi?id=1972022 :'( -T On 6/15/21 12:26 AM, Matthijs Mekking wrote: > Hi -T, > > I cannot reproduce this confusing warning message. Please use the > absolute path /var/named/chroot/etc/named.root.key in > https://bugzilla.redhat.com/show_bug.cgi?id=1972022 > > Best regards, > > Matthijs Hi Matthijs, OH POOP!!! I have TWO named.root.key's. The one in is the good one from Fedora 34 /etc/named.root.key and the one in /var/named/chroot/etc/named.root.key is the depreciated one from Fedora 33. I manually fixed the issue. Question: was the named-chroot RPM post installation script suppose to update named.root.key in chroot, or was I suppose to do that? Many thanks, -T _______ 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: My FC33->FC34 bind-chroot upgrade notes
On 6/14/21 10:02 PM, ToddAndMargo via bind-users wrote:
Hi All,
Thank you all for the enormous help in me getting bind-chroot
working after upgrading to Fedora 34. Here are my notes.
Hope this helps someone else.
-T
Well, if at first you don't succeed, revise! See
changes to named.root.key
Broken bind-chroot repair after upgrading to Fedora 34:
# means root
$ means user
1) temporary workaround so you can surf the Internet for help:
Change /etc/resolv.conf to
# search your_domain
# nameserver your_IP
nameserver 208.67.222.123
2) in their "ultimate wisdom", the rpm maintainers disabled
the service after upgrading it. See the following bug I posted
on 2021-06-14:
Bind-chroot upgrade from FC3 to FC34 disables the service
breaking a server
https://bugzilla.redhat.com/show_bug.cgi?id=1972000
To repair:
# systemctl enable named-chroot.service
# systemctl start named-chroot.service
Other useful command(s):
# systemctl stopnamed-chroot.service
# systemctl status named-chroot.service
# systemctl restart named-chroot.service
3) the new version of bind-chroot enables "dns security validation" by
default.
Make sure you do not have two `named.root.key` kicking around. One in
/etc/named.root.key
and one in
/var/named/chroot/etc/named.root.key
The bad one is the one that starts with `managed-keys {`, which is
depreciated.
The good one starts with `trust-anchors {`
If the one in chroot is bad:
# mv /var/named/chroot/etc/named.root.key
/var/named/chroot/etc/named.root.key.deprediated
# mv /etc/named.root.key /var/named/chroot/etc/named.root.key
# ln -s /var/named/chroot/etc/named.root.key /etc/named.root.key
To repair, place the following in your named.conf:
by itself at the bottom:
include "/etc/named.root.key";
Note: the actual location is: /var/named/chroot/etc/named.root.key
add the following to your "options" block:
dnssec-validation yes;
Other useful command(s):
Validation check:
$ delv @$IP com ds
$ delv @208.67.222.123 com ds
; fully validated
...
4) check (and repair) your configurations:
named.conf:
# named-checkconf -l -t /var/named/chroot /etc/named.conf
Note: if you get the following error message,
`/etc/named.root.key:1: option 'managed-keys' is
deprecated`
you may have to seperate named.root.conf files. This will
read the one in chroot.
Zones:
# named-checkzone -t directory domain filename
Note: the "domain name" in the following comes from named.conf
zone, not `domainname`. For example:
zone "abc.local" {
type master;
file "slaves/rent-a-nerd.hosts";
allow-update { key DHCP_UPDATER; };
};
The "domain" is the name of the "zone". "abc.local" in the above
# named-checkzone -t /var/named/chroot/var/named/slaves
abc.local abc.hosts
zone abc.local/IN: loaded serial 265
OK
# named-checkzone -t /var/named/chroot/var/named/slaves
255.168.192.in-addr.arpa abc.hosts.rev
zone 255.168.192.in-addr.arpa/IN: loaded serial 213
OK
5) restart the bind-chroot service:
Change /etc/resolv.conf back to
search your_domain
nameserver your_IP
# nameserver 208.67.222.123
# systemctl restart named-chroot.service
check for and repair errors with:
$ systemctl status named-chroot.service
# tail -f /var/log/messages
___
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: My FC33->FC34 bind-chroot upgrade notes
On 6/15/21 12:51 PM, ToddAndMargo via bind-users wrote:
On 6/14/21 10:02 PM, ToddAndMargo via bind-users wrote:
Hi All,
Thank you all for the enormous help in me getting bind-chroot
working after upgrading to Fedora 34. Here are my notes.
Hope this helps someone else.
-T
Here are my revised, revised note. Ed had to
straighten me out on some boo-boos:
Broken bind-chroot repair after upgrading to Fedora 34:
# means root
$ means user
1) temporary workaround so you can surf the Internet for help:
Change /etc/resolv.conf to
# search your_domain
# nameserver your_IP
nameserver 208.67.222.123
2) in their "ultimate wisdom", the rpm maintainers disabled
the service after upgrading it. See the following bug I posted
on 2021-06-14:
Bind-chroot upgrade from FC3 to FC34 disables the service
breaking a server
https://bugzilla.redhat.com/show_bug.cgi?id=1972000
To repair:
# systemctl enable named-chroot.service
# systemctl start named-chroot.service
Other useful command(s):
# systemctl stopnamed-chroot.service
# systemctl status named-chroot.service
# systemctl restart named-chroot.service
3) position named.conf and named.root.key:
When the bind-chroot service starts, it copies the following into
the chroot directory.
Don't you do it!
cp /etc/named.conf /var/named/chroot/etc/.
cp /etc/named.root.key /var/named/chroot/etc/.
So the ones in your /etc/ directory are your masters.
To trigger this:
a) make sure /etc/named/conf and /etc/named.root.key are your masters
b) stop name-bind
# systemctl stop named-chroot
c) make sure the follow do not exist:
/var/named/chroot/etc/named.conf
/var/named/chroot/etc/named.root.key
d) restart the service
# systemctl start named-chroot
4) the new version of bind-chroot enables "dns security validation" by
default.
Make sure you do not have two `named.root.key` kicking around. One in
/etc/named.root.key
and one in
/var/named/chroot/etc/named.root.key
The bad one is the one that starts with `managed-keys {`, which is
depreciated.
The good one starts with `trust-anchors {`
If the one in chroot is bad:
# mv /var/named/chroot/etc/named.root.key
/var/named/chroot/etc/named.root.key.deprediated
# mv /etc/named.root.key /var/named/chroot/etc/named.root.key
# ln -s /var/named/chroot/etc/named.root.key /etc/named.root.key
To repair, place the following in your named.conf:
by itself at the bottom:
include "/etc/named.root.key";
Note: the actual location is: /var/named/chroot/etc/named.root.key
add the following to your "options" block:
dnssec-validation yes;
Other useful command(s):
Validation check:
$ delv @$IP com ds
$ delv @208.67.222.123 com ds
; fully validated
...
5) check (and repair) your configurations:
named.conf:
# named-checkconf -l -t /var/named/chroot /etc/named.conf
Note: if you get the following error message,
`/etc/named.root.key:1: option 'managed-keys' is
deprecated`
you may have to seperate named.root.conf files. This will
read the one in chroot.
Zones:
# named-checkzone -t directory domain filename
Note: the "domain name" in the following comes from named.conf
zone, not `domainname`. For example:
zone "abc.local" {
type master;
file "slaves/rent-a-nerd.hosts";
allow-update { key DHCP_UPDATER; };
};
The "domain" is the name of the "zone". "abc.local" in the above
# named-checkzone -t /var/named/chroot/var/named/slaves
abc.local abc.hosts
zone abc.local/IN: loaded serial 265
OK
# named-checkzone -t /var/named/chroot/var/named/slaves
255.168.192.in-addr.arpa abc.hosts.rev
zone 255.168.192.in-addr.arpa/IN: loaded serial 213
OK
6) restart the bind-chroot service:
Change /etc/resolv.conf back to
search your_domain
nameserver your_IP
# nameserver 208.67.222.123
# systemctl restart named-chroot.service
check for and repair errors with:
$ systemctl status named-chroot.service
# tail -f /var/log/messages
___
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: My FC33->FC34 bind-chroot upgrade notes
On 6/15/21 6:59 PM, ToddAndMargo via bind-users wrote:
On 6/15/21 12:51 PM, ToddAndMargo via bind-users wrote:
On 6/14/21 10:02 PM, ToddAndMargo via bind-users wrote:
Hi All,
Thank you all for the enormous help in me getting bind-chroot
working after upgrading to Fedora 34. Here are my notes.
Hope this helps someone else.
-T
Here are my revised, revised note. Ed had to
straighten me out on some boo-boos:
I hope this is the last time I have to revise this!
Broken bind-chroot repair after upgrading to Fedora 34:
# means root
$ means user
1) temporary workaround so you can surf the Internet for help:
Change /etc/resolv.conf to
# search your_domain
# nameserver your_IP
nameserver 208.67.222.123
2) in their "ultimate wisdom", the rpm maintainers disabled
the service after upgrading it.
To repair:
# systemctl enable named-chroot.service
# systemctl start named-chroot.service
Other useful command(s):
# systemctl stopnamed-chroot.service
# systemctl status named-chroot.service
# systemctl restart named-chroot.service
3) position named.conf and named.root.key:
When the bind-chroot service starts, it copies the following into
the chroot directory. Don't you do it! This will fail if it find
them there already. Then things get really confusing.
/etc/named.conf copies to /var/named/chroot/etc/.
/etc/named.root.key copies to /var/named/chroot/etc/.
The ones in your /etc directory are your masters.
When the named-chroot service is stopped. Make sure you do not have
two copies of either or both `/named/conf` and `named.root.key` kicking
around:
/etc/named.conf
/var/named/chroot/etc/named.conf <-- should not be there
when stopped
/etc/named.root.key
/var/named/chroot/etc/named.root.key <-- should not be there
when stopped
The ones in the chroot directory should have disappeared. Make sure you
only have one /etc/named.conf and /etc/named.root.key.
If you have two named.root.key's kicking around, the one that starts
with
trust-anchors {
is the good one.
To trigger the copy:
a) make sure /etc/named/conf and /etc/named.root.key are your masters
b) stop name-bind
# systemctl stop named-chroot
c) make sure the follow do not exist:
/var/named/chroot/etc/named.conf
/var/named/chroot/etc/named.root.key
d) update /etc/named.conf and /etc/named.root.key as desired
e) restart the service
# systemctl start named-chroot
4) the new version of bind-chroot enables "dns security validation" by
default.
Note: make sure /etc/named.root.key starts with `trust-anchors {`.
`managed-keys {` is depreciated.
Note: you should only have one named.root.key. /etc/named.root.key is
your master. If the named-chroot service is stopped, the one
in /var/named/chroot/etc should disappear.
To properly configure (repair), place the following in your named.conf:
add the following to your "options" block:
dnssec-validation yes;
by itself at the bottom:
include "/etc/named.root.key";
Then restart the service:
# systemctl restart bind-named.service
Other useful command(s):
Validation check:
$ delv @$IP com ds
$ delv @208.67.222.123 com ds
; fully validated
...
5) check (and repair) your configurations:
named.conf:
# named-checkconf -l -t /var/named/chroot /etc/named.conf
Zones:
# named-checkzone -t directory domain filename
Note: the "domain name" is theh "zone" name from named.conf
zone, not `domainname`. For example:
zone "abc.local" {
type master;
file "slaves/abc.hosts";
allow-update { key DHCP_UPDATER; };
};
The "domain" is the name of the "zone". "abc.local" in the above.
You should check both your forward and reverse zones.
Examples:
# named-checkzone -t /var/named/chroot/var/named/slaves
abc.local abc.hosts
zone abc.local/IN: loaded serial 265
OK
# named-checkzone -t /var/named/chroot/var/named/slaves
255.168.192.in-addr.arpa abc.hosts.rev
zone 255.168.192.in-addr.arpa/IN: loaded serial 213
OK
6) restart the bind-chroot service:
Change /etc/resolv.conf back to
search your_domain
nameserver your_IP
# nameserver 208.67.222.123
Restart the service:
# systemctl restart named-chroot.service
Check for and repair startup errors with:
$ systemctl status named-chroot.service
# tail -f /var/log/messages
__
Re: My FC33->FC34 bind-chroot upgrade notes
On 6/15/21 11:54 PM, G.W. Haywood via bind-users wrote: Hi there, On Wed, 16 Jun 2021, ToddAndMargo wrote: Re: My FC33->FC34 bind-chroot upgrade notes I hope this is the last time I have to revise this! ... Unfortunately perhaps not. :'( ... # means root $ means user ... Sometimes, in your configuration file extracts, you use '#' meaning 'this line is a comment'. I guess this is a write-up for a novice. The non-novices here have overlooked it, but I'm much closer to the novice end of the BIND user spectrum than they are and If I were a *complete* novice, I'd find these uses of '#' very confusing. Which lines? BIND is a hair puller at times. ___ 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: My FC33->FC34 bind-chroot upgrade notes
On 6/16/21 2:16 AM, Reindl Harald wrote: Am 16.06.21 um 09:31 schrieb ToddAndMargo via bind-users: ... # means root $ means user ... Sometimes, in your configuration file extracts, you use '#' meaning 'this line is a comment'. I guess this is a write-up for a novice. The non-novices here have overlooked it, but I'm much closer to the novice end of the BIND user spectrum than they are and If I were a *complete* novice, I'd find these uses of '#' very confusing. Which lines? lines starting with # -- here it is a comment sign Change /etc/resolv.conf back to search your_domain nameserver your_IP # nameserver 208.67.222.123 -- here it is meant as command running as root Then restart the service: # systemctl restart bind-named.service Does this alteration at the top make it any clearer? Note: at the command prompt, I use the following terminology: # means run as root $ means run as user Inside a file, "#" mean it is a comment ___ 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
A question on logging
Hi All,
In my named.conf
logging {
channel update_debug {
# file
"/var/named/chroot/var/named/slaves/named-update-debug.log";
file "slaves/named-update-debug.log";
severity debug 3;
print-category yes;
print-severity yes;
print-time yes;
};
channel security_info{
file "slaves/named-auth.info";
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category update { update_debug; };
category security { security_info; };
};
Questions:
1) is there some pruning of old stuff mechanism to
keep my drive from being over run with logging
data?
2) If I want to comment out the section, is there
a block comment that can be used at the top
and bottom of my logging statement that will
keep me from having to put a # in front of
every line?
Many thanks,
-T
___
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: My FC33->FC34 bind-chroot upgrade notes
On 6/16/21 12:45 PM, Richard T.A. Neal wrote: On 16 June 2021 7:31 pm, ToddAndMargo wrote: Does this alteration at the top make it any clearer? Note: at the command prompt, I use the following terminology: # means run as root $ means run as user Inside a file, "#" mean it is a comment Others might have better suggestions but the way I tend to do this is to simply prefix any commands that must be run as root with 'sudo', eg; $ sudo rndc reconfig $ tail /var/log/syslog Thus it’s hopefully clear which lines need to be run with root privileges and demonstrates using sudo to achieve this. Best, Richard. I have used su for such in the past: $ su root -c "command and parameters" to make it obvious it is a root command. I personally can't stand the sudo command, so I usually avoid it. Lately, I just use # and $, but I can see now where that would cause some confusion. ___ 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
