Re: 9.18 BIND not resolving .gov.bd site
Everything looks good from here in a Debian with 9.18 # nslookup mofa.gov.bd Server: 193.93.164.194 Address:193.93.164.194#53 Non-authoritative answer: Name: mofa.gov.bd Address: 103.163.210.121 Name: mofa.gov.bd Address: 103.163.210.117 # dig ns mofa.gov.bd ; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> ns mofa.gov.bd ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10354 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;mofa.gov.bd. IN NS ;; ANSWER SECTION: mofa.gov.bd.31394 IN NS ns2.bcc.gov.bd. mofa.gov.bd.31394 IN NS ns1.bcc.gov.bd. ;; ADDITIONAL SECTION: ns1.bcc.gov.bd. 31394 IN A 114.130.54.123 ns2.bcc.gov.bd. 31394 IN A 114.130.54.124 ;; Query time: 0 msec ;; SERVER: 193.93.164.194#53(193.93.164.194) (UDP) ;; WHEN: Mon Oct 30 10:24:37 EET 2023 ;; MSG SIZE rcvd: 118 On 30/10/2023 9:46, Marco M. wrote: Am 30.10.2023 um 12:25:32 Uhr schrieb Mosharaf Hossain: mofa.gov.bd.86400 IN NS ns1.bcc.gov.bd. mofa.gov.bd.86400 IN NS ns2.bcc.gov.bd. couldn't get address for 'ns1.bcc.gov.bd': not found couldn't get address for 'ns2.bcc.gov.bd': not found dig: couldn't get address for 'ns1.bcc.gov.bd': no more root@ns1:/etc/bind# I can resolve them, but only A records exist. Please try it again. dig a ns2.bcc.gov.bd -- 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
AXFR from Windows 2008R2 failing after upgrading to 9.18
I must be missing something. Any ideas why does it fail? Everything seems normal. Works well with Windows 2016. Downgrading to 9.16 works again. -- 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: AXFR from Windows 2008R2 failing after upgrading to 9.18
Nothing actually. Windows logs are clean. Unix logs also. host -l seems to work perfectly OK from the unix machine so it does not seem to be a windows problem and yet for some reason there is no zone transfer at all. On 24/5/2022 1:50, Ben Lavender wrote: Any logs? Regards Ben Lavender On Mon, 23 May 2022, 21:52 Lefteris Tsintjelis via bind-users, mailto:bind-users@lists.isc.org>> wrote: I must be missing something. Any ideas why does it fail? Everything seems normal. Works well with Windows 2016. Downgrading to 9.16 works again. -- 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: AXFR from Windows 2008R2 failing after upgrading to 9.18
I turned on all logs channels and this is the error I get: zone domain.com/IN: refresh: unexpected rcode (FORMERR) from primary 1.1.2.2#53 (source 0.0.0.0#0 tcpdump seems to also agree with the FORMERR 1.1.2.2.domain > secondary.58648: 113 FormErr- 0/0/1 (45) Regards, Lefteris On 24/5/2022 3:00, Grant Taylor via bind-users wrote: On 5/23/22 5:55 PM, Lefteris Tsintjelis via bind-users wrote: Nothing actually. Windows logs are clean. Unix logs also. #trustTheBitsOnTheWire #useTheSniffer I'd start by capturing w/ tcpdump using the `-s 0` and `-w /path/to/capture.pcapng` options. Then use Wireshark to analyze the packet capture. You may see the problem with tcpdump, especially if you turn verbosity up. But Wireshark has some much nicer decoding and display than tcpdump does. -- 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: AXFR from Windows 2008R2 failing after upgrading to 9.18
Error seems to be related to character set checking. I do have the zone
configured to ignore checking names but it doesn't seem to work.
zone "domain.com" { type secondary; primaries { 1.1.2.2; }; check-names
ignore; max-journal-size 32k; masterfile-format text; file
"/usr/local/etc/namedb/secondary/db.domain.com"; };
On 24/5/2022 4:12, Lefteris Tsintjelis via bind-users wrote:
I turned on all logs channels and this is the error I get:
zone domain.com/IN: refresh: unexpected rcode (FORMERR) from primary
1.1.2.2#53 (source 0.0.0.0#0
tcpdump seems to also agree with the FORMERR
1.1.2.2.domain > secondary.58648: 113 FormErr- 0/0/1 (45)
Regards,
Lefteris
On 24/5/2022 3:00, Grant Taylor via bind-users wrote:
On 5/23/22 5:55 PM, Lefteris Tsintjelis via bind-users wrote:
Nothing actually. Windows logs are clean. Unix logs also.
#trustTheBitsOnTheWire
#useTheSniffer
I'd start by capturing w/ tcpdump using the `-s 0` and `-w
/path/to/capture.pcapng` options. Then use Wireshark to analyze the
packet capture.
You may see the problem with tcpdump, especially if you turn verbosity
up. But Wireshark has some much nicer decoding and display than
tcpdump does.
--
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: AXFR from Windows 2008R2 failing after upgrading to 9.18
On 24/5/2022 7:55, Mark Andrews wrote:
Firstly upgrade the primary. Microsoft issued a fix for this March 2019.
Would have been the best to do that if possible for sure but
unfortunately only the workaround can be applied in this case.
Unknown EDNS options are supposed to be ignored and not produce FORMERR.
Named has stopped working around broken servers that return FORMERR to unknown
EDNS options and include the OPT record. It has also stopped working around
servers that just echo back the request (including the OPT record) when sending
FORMERR when the server doesn’t understand EDNS. These servers should be
constructing a DNS HEADER from the request with RCODE set to FORMERR and if
the request was a QUERY and they could parse the QUESTION adding that as well
as per RFC 1034. The DNS header alone is enough to send FORMERR. No where in
any RFC does it say to echo back the request when sending FORMERR.
FORMERR + OPT indicates the server understands EDNS.
You can workaround this by adding “server 1.1.2.2 { request-expire no; };” to
named.conf.
This worked really well! Thank you very much
On 24 May 2022, at 11:12, Lefteris Tsintjelis via bind-users
wrote:
I turned on all logs channels and this is the error I get:
zone domain.com/IN: refresh: unexpected rcode (FORMERR) from primary1.1.2.2#53
(source 0.0.0.0#0
tcpdump seems to also agree with the FORMERR
1.1.2.2.domain > secondary.58648: 113 FormErr- 0/0/1 (45)
On 24/5/2022 3:00, Grant Taylor via bind-users wrote:
On 5/23/22 5:55 PM, Lefteris Tsintjelis via bind-users wrote:
Nothing actually. Windows logs are clean. Unix logs also.
#trustTheBitsOnTheWire
#useTheSniffer
I'd start by capturing w/ tcpdump using the `-s 0` and `-w
/path/to/capture.pcapng` options. Then use Wireshark to analyze the packet
capture.
You may see the problem with tcpdump, especially if you turn verbosity up. But
Wireshark has some much nicer decoding and display than tcpdump does.
Regards,
Lefteris
--
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-keymgr fails to apply policy
I am using FreeBSD with bind v9.11.8. v9.11.6P1 also had the same problem.
I am using ECDSAP256SHA256 for ZSK and KSK. I have made a very simple
policy that I am trying to automate by using dnssec-keymgr in crontab.
policy default {
directory "/usr/local/etc/namedb/keys";
algorithm ECDSAP256SHA256;
pre-publish zsk 1w;
post-publish zsk 1w;
roll-period zsk 2mo;
};
zone example.com {
policy default;
};
However, every time I run:
dnssec-keymgr -K /usr/local/etc/namedb/keys -r /dev/random
I always get this message:
Unable to apply policy: example.com/ECDSAP256SHA256: unsupported operand
type(s) for +: 'float' and 'NoneType'
Any ideas what this may be?
___
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: dnssec-keymgr fails to apply policy
On 23/6/2019 20:28, Evan Hunt wrote:
On Sun, Jun 23, 2019 at 05:01:11PM +, Evan Hunt wrote:
It's a bug. I see the same result. Thanks for pointing it out, I'm
looking into it.
Ah, I see the problem. You overrode the default policy by using the name
"default", but you didn't set a "coverage" value in your new defaults, so
it choked because it didn't know how far into the future you wanted it to
generate keys. This definitely needs a clearer error message.
Here are three ways to write the policy file that would do what you want:
1) Explicitly add a "coverage" value to the "default" policy.
policy default {
directory "/usr/local/etc/namedb/keys";
algorithm ECDSAP256SHA256;
pre-publish zsk 1w;
post-publish zsk 1w;
roll-period zsk 2mo;
coverage 6mo;
};
(Side note: the zone policy for example.com in your policy file was
unnecessary, since you were setting defaults that would have been used
anyway.)
2) Explicitly inherit built-in global defaults when setting up the
"default" policy. This way you're overriding a subset of the defaults
rather than setting up a whole new set from scratch.
policy default {
policy global;
directory "/usr/local/etc/namedb/keys";
algorithm ECDSAP256SHA256;
pre-publish zsk 1w;
post-publish zsk 1w;
roll-period zsk 2mo;
};
Overriding a subset of the default and keeping everything else is
exactly what I had in mind actually. Works great now, thank you!
3) Don't reset "default", just set up a zone policy statement for the
particular zone you're interested in. This will inherit the existing
defaults, it doesn't need to be told to do so.
zone example.com {
directory "/usr/local/etc/namedb/keys";
algorithm ECDSAP256SHA256;
pre-publish zsk 1w;
post-publish zsk 1w;
roll-period zsk 2mo;
};
___
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
Allow only temporary zone updates without making them permanent
Hi,
Is it possible to apply temporary only update policy and never save or
modify anything to a zone file?
For example:
zone "example.com" {
type master;
auto-dnssec maintain;
inline-signing yes;
update-policy {
grant rndc-key temponly _acme-challenge.example.com. txt;
};
file "/etc/namedb/master/db.example.com";
};
Thank you,
Lefteris
___
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: Allow only temporary zone updates without making them permanent
That could take years, if even adopted! Perhaps something simpler like a
file permission/lock could do the job as well. Would that work though?
When I used certbot with rfc2136 validation through DNS, eventhough I
have the main zone file permission set to root, I find it changed to
that of bind. Seems like bind is capable of changing and modifying
permissions?
On 26/6/2019 6:36, Mark Andrews wrote:
> No.
>
> If https://tools.ietf.org/id/draft-pusateri-dnsop-update-timeout-02.txt ever
> get
> adopted then yes it will be possible to have updates removed automatically.
>
>> On 26 Jun 2019, at 1:25 pm, Lefteris Tsintjelis via bind-users
>> wrote:
>>
>> Hi,
>>
>> Is it possible to apply temporary only update policy and never save or
>> modify anything to a zone file?
>>
>> For example:
>>
>> zone "example.com" {
>> type master;
>> auto-dnssec maintain;
>> inline-signing yes;
>> update-policy {
>> grant rndc-key temponly _acme-challenge.example.com. txt;
>> };
>> file "/etc/namedb/master/db.example.com";
>> };
>>
>> Thank you,
>>
>> Lefteris
>> ___
>> 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
>
___
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: Allow only temporary zone updates without making them permanent
On 26/6/2019 17:39, Grant Taylor via bind-users wrote: > Or are you wanting to update the zone contents without actually updating > the zone file on disk? Yes, exactly this. That is the reason I changed the actual zone disk file permissions to root thinking that files would not be modifiable, but bind surprised me there. I did not expect to change the file ownership from root to bind! The problem started with ACME actually as it always messes up my disk zone files and have to always restore them. I would still like to use something like that in small DDNS zones also, serving just a few IPs only. Non disk writable/modifiable zones could perhaps add a small layer of extra security as well. Lefteris ___ 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: Allow only temporary zone updates without making them permanent
On 26/6/2019 20:25, Tony Finch wrote: > Lefteris Tsintjelis via bind-users wrote: >> On 26/6/2019 17:39, Grant Taylor via bind-users wrote: >>> Or are you wanting to update the zone contents without actually updating >>> the zone file on disk? >> >> Yes, exactly this. That is the reason I changed the actual zone disk >> file permissions to root thinking that files would not be modifiable, >> but bind surprised me there. I did not expect to change the file >> ownership from root to bind! The problem started with ACME actually as >> it always messes up my disk zone files and have to always restore them. >> I would still like to use something like that in small DDNS zones also, >> serving just a few IPs only. Non disk writable/modifiable zones could >> perhaps add a small layer of extra security as well. > > If you have a dynamic zone then it's best to work as if the zone file > belongs to `named`. I configure `masterfile-format raw;` which removes the > temptation to look at the files directly. Instead I use `dig axfr` or > `named-compilezone -j`. > > In most cases I keep the original source of the zone data elsewhere, e.g. > a file stored in version control or a database, and I sync up the working > copy of the zone with it source file using https://dotat.at/prog/nsdiff/ > This also means I don't have to care about serial numbers or DNSSEC > records because `named` takes care of those. > > (I have a few less complicated zones where I don't have a separate source > file and instead use `nsvi` to edit the working copy.) > > You should have secondary servers for your zone, in which case > ACME-related updates will be copied to the secondary and stored on disk > there, so suppressing writes on the primary won't make any useful > difference to how temporary the records are. Yes, I have done just about most of them already for large zones so I am not worried about loosing anything. But besides the messy ACME update file zone results, it was the idea of the unauthorized file ownership change that kind of started to worry me there as well. > There are other ways to keep temporary dynamic records separate from your > fixed data, e.g. you can delegate _acme-challenge. to a separate > dynamic zone, or to reduce the proliferation of zones, make > _acme-challenge. CNAMEs to consolidate them into one separate > dynamic zone. This is exactly what I try to do in and keep dynamic things completely separate from fixed. That is an excellent idea and takes care of the dynamic ACME problem! Thank you Lefteris ___ 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: Allow only temporary zone updates without making them permanent
On 26/6/2019 21:13, Tony Finch wrote: > It will rewrite the > zone file from scratch when it merges in the journal, which is what would > cause the change of ownership. That makes perfect sense, but I was still shocked when I first saw it specially to a file owned by root. This is the part that surprised me and worried me the most! I was under the impression that after start up, named would switch to the user configured to do so and it will no longer be able to access or change other files but its' own. Lefteris ___ 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: Allow only temporary zone updates without making them permanent
On 26/6/2019 20:25, Grant Taylor via bind-users wrote: > On 6/26/19 10:46 AM, Lefteris Tsintjelis via bind-users wrote: >> Yes, exactly this. That is the reason I changed the actual zone disk >> file permissions to root thinking that files would not be modifiable, >> but bind surprised me there. I did not expect to change the file >> ownership from root to bind! > > I'm surprised at the ownership change too. > > It may be dependent on your OS init scripts, perhaps they are changing > them. > > The only way that I see that BIND, running as something other than root, > could change them is if the user it's running as has write on the > directory and deletes & recreates new zone files as itself. But that > would surprise me too. > >> The problem started with ACME actually as it always messes up my disk >> zone files and have to always restore them. > > Is the ACME client modifying the zone file(s) directly? Or is it using > dynamic DNS (possibly via nsupdate) to request that BIND update the > zone(s)? ACME is through net and not directly. I have checked and tripled checked that a few times, as well as the init/startup scripts. It is not ACME, it is named that modifies the file and it happens right after the dynamic ACME update. Lefteris ___ 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: Allow only temporary zone updates without making them permanent
On 26/6/2019 21:57, Tony Finch wrote: > Lefteris Tsintjelis via bind-users wrote: >> >> That makes perfect sense, but I was still shocked when I first saw it >> specially to a file owned by root. This is the part that surprised me >> and worried me the most! I was under the impression that after start up, >> named would switch to the user configured to do so and it will no longer >> be able to access or change other files but its' own. > > You are right about what named does, but you are also encountering > a classic UNIX gotcha, legitimately perplexing. > > See here, and click through the notes related answers to other questions: > https://unix.stackexchange.com/questions/75395/why-am-i-able-to-delete-file-which-belongs-to-root-under-a-non-root-user > > Also have a look at the description of the sticky bit in the chmod man page. > It makes directory permissions work more like you might expect. If I set it though, and named no longer has access to modify and rewrite other files but its own, will it break things? What will happen in case of a dynamic update like ACME in this case? Will the update go through? Lefteris ___ 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: Allow only temporary zone updates without making them permanent
On 26/6/2019 22:04, Anderson, Charles R wrote: > On Wed, Jun 26, 2019 at 07:46:20PM +0300, Lefteris Tsintjelis via bind-users > wrote: >> On 26/6/2019 17:39, Grant Taylor via bind-users wrote: >>> Or are you wanting to update the zone contents without actually updating >>> the zone file on disk? >> >> Yes, exactly this. That is the reason I changed the actual zone disk >> file permissions to root thinking that files would not be modifiable, >> but bind surprised me there. I did not expect to change the file >> ownership from root to bind! The problem started with ACME actually as >> it always messes up my disk zone files and have to always restore them. >> I would still like to use something like that in small DDNS zones also, >> serving just a few IPs only. Non disk writable/modifiable zones could >> perhaps add a small layer of extra security as well. > > If Linux: > > chattr +i filename > > If FreeBSD: > > chflags schg filename Or chmod +t I had totally forgotten about that one. ___ 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: Allow only temporary zone updates without making them permanent
On 26/6/2019 22:56, Grant Taylor via bind-users wrote: > On 6/26/19 1:17 PM, Lefteris Tsintjelis via bind-users wrote: >> If I set it though, and named no longer has access to modify and >> rewrite other files but its own, will it break things? What will >> happen in case of a dynamic update like ACME in this case? Will the >> update go through? > > I think that would be HIGHLY dependent on /how/ named updates files. > > Does it try to move (rename) existing files and create /new/ files? Or > does it rewrite contents of /exiting/ files. > > I don't know these particulars. I've never had a problem allowing named > to have write access to the directory and do what it wants with the > files therein. Just to satisfy my curiosity, I will have to do more experimenting but I believe the best way to deal with this and to avoid possible trouble is to create an independent zone, just as Tony previously described. Thank you all Lefteris ___ 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: Allow only temporary zone updates without making them permanent
On 26/6/2019 20:25, Tony Finch wrote: > Lefteris Tsintjelis via bind-users wrote: >> On 26/6/2019 17:39, Grant Taylor via bind-users wrote: >>> Or are you wanting to update the zone contents without actually updating >>> the zone file on disk? >> >> Yes, exactly this. That is the reason I changed the actual zone disk >> file permissions to root thinking that files would not be modifiable, >> but bind surprised me there. I did not expect to change the file >> ownership from root to bind! The problem started with ACME actually as >> it always messes up my disk zone files and have to always restore them. >> I would still like to use something like that in small DDNS zones also, >> serving just a few IPs only. Non disk writable/modifiable zones could >> perhaps add a small layer of extra security as well. > > If you have a dynamic zone then it's best to work as if the zone file > belongs to `named`. I configure `masterfile-format raw;` which removes the > temptation to look at the files directly. Instead I use `dig axfr` or > `named-compilezone -j`. I prefer the text format and I always use masterfile-format text. I am always tempted to check if everything is OK. Probably a waste of time but I just feel safer if I can see things. > In most cases I keep the original source of the zone data elsewhere, e.g. > a file stored in version control or a database, and I sync up the working > copy of the zone with it source file using https://dotat.at/prog/nsdiff/ > This also means I don't have to care about serial numbers or DNSSEC > records because `named` takes care of those. It sounds really interesting to manage large domains. I was looking at those tools (nsdiff/nsvi) and tried to find more info. I will definitely check them out in the near future. > (I have a few less complicated zones where I don't have a separate source > file and instead use `nsvi` to edit the working copy.) I think this sounds much better for me. I like to have records organized the way I want in a zone file. It helps me and gives me a very quick map of the network. This is actually and the main reason I prefer text. > You should have secondary servers for your zone, in which case > ACME-related updates will be copied to the secondary and stored on disk > there, so suppressing writes on the primary won't make any useful > difference to how temporary the records are. Secondaries though are almost always slaves, so writing suppression doesn't really matter for them. It is the primary that only matters so if it could suspend writing for just one minute then everything would complete perfectly OK. The ACME record doesn't have to be permanently stored anywhere. > There are other ways to keep temporary dynamic records separate from your > fixed data, e.g. you can delegate _acme-challenge. to a separate > dynamic zone, or to reduce the proliferation of zones, make > _acme-challenge. CNAMEs to consolidate them into one separate > dynamic zone. Thank you! This is the "proper" way to do it. I have tested the _acme-challenge only dynamic zone as you described it and it worked perfectly well and as expected but there is a quite a lot to do for just one record for one minute in order to work properly. I am not sure about the CNAMEs. It sounds easier to implement as there is only one dynamic zone for all hosts but I am not sure how. The _acme-challenge., from what I know, is expected to be within the main domain zone in order for ACME to work properly, so how would it work in a separate dynamic one? Wouldn't ACME reject it? Lefteris ___ 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: Allow only temporary zone updates without making them permanent
On 29/6/2019 21:55, Grant Taylor via bind-users wrote: > On 6/29/19 12:30 PM, Lefteris Tsintjelis via bind-users wrote: >> Secondaries though are almost always slaves, so writing suppression >> doesn't really matter for them. It is the primary that only matters so >> if it could suspend writing for just one minute then everything would >> complete perfectly OK. The ACME record doesn't have to be permanently >> stored anywhere. > > Hypothetical scenario: Secondary (slave) does not receive a notify, > waits and polls the Primary (master) per standards DNS mechanisms. > > If the secondary (slave) has a sufficiently old serial (say it's been > offline for maintenance), it will see the new serial and do a zone > transfer, including the temporary ACME records. > > Timing and other conditions might make this unlikely to happen, but I > think that it is a possibility. Standard DNS mechanisms and poll would not work. Everything must be done within 1 minute so notify MUST be used and therefor zone serial must be increased and of course all secondaries MUST be online and respond to the notify properly and sync. When I tried it (by a mistake) with a secondary not synchronized properly (older serial) ACME failed. I suppose all this means automatically that the zone MUST be dynamic in order for named to handle all that and propagate everything properly. >> Thank you! This is the "proper" way to do it. I have tested the >> _acme-challenge only dynamic zone as you described it and it worked >> perfectly well and as expected but there is a quite a lot to do for >> just one record for one minute in order to work properly. > > This is why some people say "pick the lesser of the evils". ;-) But DNS, even with all this trouble for just one record, is the less evil!!! Using http ACME would have been hell! I deal with a few domains and various flavors of OSs and web servers and setups so you can imagine how would that one be! At least DNS is more centralized and unified for me, paradise actually compared to the http ACME verification option! :-) >> I am not sure about the CNAMEs. It sounds easier to implement as there >> is only one dynamic zone for all hosts but I am not sure how. The >> _acme-challenge., from what I know, is expected to be within the >> main domain zone in order for ACME to work properly, so how would it >> work in a separate dynamic one? Wouldn't ACME reject it? > > The _acme-challenge. record name is expected to be within the main > domain zone. But there is nothing that prevents that record from being > a CNAME to another zone. > > _acme-challenge.www.example.org is a CNAME to www.example.org.dynamic.local > _acme-challenge.www.example.net is a CNAME to www.example.net.dynamic.local > _acme-challenge.www.example.com is a CNAME to www.example.com.dynamic.local > > So the only dynamic zone is dynamic.local. Yet ACME clients can query > their expected names, follow the CNAME, and get the data they need. Yes, but that would automatically place it in a completely different domain. Isn't ACME "smart" enough to see this and fail? I have serious doubts about this but I will check it. Lefteris ___ 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: Allow only temporary zone updates without making them permanent
On 30/6/2019 0:29, Grant Taylor via bind-users wrote: > On 6/29/19 2:13 PM, Lefteris Tsintjelis via bind-users wrote: >> Standard DNS mechanisms and poll would not work. Everything must be >> done within 1 minute so notify MUST be used and therefor zone serial >> must be increased and of course all secondaries MUST be online and >> respond to the notify properly and sync. > > I think we've experienced different things with ACME clients. It is very possible as not all ACME clients behave the same way. > Yes, the update needs to be propagated to all the (responding) servers. > But I've not had any problems if it has taken five or more minutes. I > don't know what the timeout is. But It's longer than one minute. > > I've routinely manually run my ACME client, gotten the new TXT record, > published it to my master server, waiting for it to propagate to the > slaves, and then run my ACME client for Let's Encrypt to see the updated > record in DNS. > > I know I've been as slow as five minutes before. I think I've been as > slow as ten to fifteen minutes before. If you do it manually yes; if you do it automatically from a cron job, everything is timed. >> When I tried it (by a mistake) with a secondary not synchronized >> properly (older serial) ACME failed. > > Yes, incorrect data will cause ACME to fail. But that's largely > independent of timing. > >> I suppose all this means automatically that the zone MUST be dynamic >> in order for named to handle all that and propagate everything properly. > > Nonsense. > > There is nothing that states that you can't manually update your zone, > remembering to increment the serial number, and then restarting BIND or > reloading the zone. > > BIND will send notifies as it's configured to do so. Slaves will > eventually do a zone transfer as specified in the SOA record if they > miss the notify. > > My experience has been that a sequence of events needs to be completed. > > None of this /requires/ dynamic zones. Again, no it is not required but only if you do it manually. The idea here is to automate everything and, unless I am missing something, there is no other way to do this. There has to be a dynamic zone for the ACME records. Lefteris ___ 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: Allow only temporary zone updates without making them permanent
On 30/6/2019 20:34, Grant Taylor via bind-users wrote: > I think you're missing options that are outside of the box. ;-) Very true! :-) I like to make my life easier ___ 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: Bind and HTTPS?
On 11/7/2019 13:39, Tony Finch wrote: Encrypted DNS between resolvers and authoritative servers is still in the process of being standardized. It sounds like too much overhead already. Why would you want something like that? Isn't DNSSEC enough to assure integrity? Lefteris ___ 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: Bind and HTTPS?
On 11/7/2019 15:35, Tony Finch wrote: Lefteris Tsintjelis via bind-users wrote: Why would you want something like that? https://datatracker.ietf.org/wg/dprive/about/ If you are willing to sacrifice speed. DNS responses have a pretty big impact in browsing speed but I guess anyone choosing privacy through encryption over speed, must have a good reason to do so and I am sure already knows that. Lefteris ___ 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: Bind and HTTPS?
On 11/7/2019 22:56, @lbutlr wrote: On 11 Jul 2019, at 10:52, Lefteris Tsintjelis via bind-users wrote: On 11/7/2019 15:35, Tony Finch wrote: Lefteris Tsintjelis via bind-users wrote: Why would you want something like that? https://datatracker.ietf.org/wg/dprive/about/ If you are willing to sacrifice speed. Not really. Using DOH servers now doesn’t have any noticeable impact on speed of DNS. Doesn't the packet size have any impact at all just by itself, excluding packet encryption/decryption times? For me the difference was quite noticeable when I first enabled DNSSEC, specially when I first tested it with SHA256/512. Packets would easily exceed fragmentation limits and that alone is just by using DNSSEC only! I don't know what the impact of DOH would be on the packet size, but I am pretty sure it would be even worst combined with DNSSEC, would it not? Lefteris ___ 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: Bind and HTTPS?
On 12/7/2019 2:42, Mark Andrews wrote: On 12 Jul 2019, at 8:54 am, Lefteris Tsintjelis via bind-users wrote: On 11/7/2019 22:56, @lbutlr wrote: On 11 Jul 2019, at 10:52, Lefteris Tsintjelis via bind-users wrote: On 11/7/2019 15:35, Tony Finch wrote: Lefteris Tsintjelis via bind-users wrote: Why would you want something like that? https://datatracker.ietf.org/wg/dprive/about/ If you are willing to sacrifice speed. Not really. Using DOH servers now doesn’t have any noticeable impact on speed of DNS. Doesn't the packet size have any impact at all just by itself, excluding packet encryption/decryption times? For me the difference was quite noticeable when I first enabled DNSSEC, specially when I first tested it with SHA256/512. Packets would easily exceed fragmentation limits and that alone is just by using DNSSEC only! I don't know what the impact of DOH would be on the packet size, but I am pretty sure it would be even worst combined with DNSSEC, would it not? Having fragmented packets doesn’t slow down DNS noticeably as long as your firewall allows them through. Having to perform PMTUD does however and this applies to both UDP and TCP. I believe most modern firewalls allow them now days and the speeds are pretty huge for such packets so I guess fragmentation by itself may not be as noticeable, but everything all together adds up, and I mean including DNSSEC and DOH overhead. Yes, PMTUD applies to both of course and this is the biggest delay of all. Perhaps it would help if the default packet size of 4000 changed to a lower value such as 1200-1300 and use ECDSAP256SHA256 as defaults? In any case, for me, changing those two things made quite a noticeable response difference and it was not small. Lefteris ___ 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
Issue with recursive-clients set to 0
Hi, I tried to upgrade from 9.18 to 9.20 and when I use
recursive-clients set to 0 then I get the following (9.18 was working
well with this):
Oct 13 14:11:04 ns4 named[10719]: quota.c:39:
REQUIRE(__c11_atomic_load(("a->max), memory_order_relaxed) > soft)
failed
Oct 13 14:11:04 ns4 named[10719]: 0x23f2cb at
/usr/local/sbin/named
Oct 13 14:11:04 ns4 named[10719]: 0x8220a7ffa
at /usr/local/lib/libisc-9.20.2.so
Oct 13 14:11:04 ns4 named[10719]: 0x8220c5ca1 at
/usr/local/lib/libisc-9.20.2.so
Oct 13 14:11:04 ns4 named[10719]: 0x24e81b at
/usr/local/sbin/named
Oct 13 14:11:04 ns4 kernel: [914] pid 10719 (named), jid 0, uid 0:
exited on signal 6
Oct 13 14:11:04 ns4 named[10719]: 0x241c4d
at /usr/local/sbin/named
Oct 13 14:11:04 ns4 named[10719]: 0x8220a8308 at
/usr/local/lib/libisc-9.20.2.so
Oct 13 14:11:04 ns4 named[10719]: 0x8261f1a31 at
/usr/local/lib/libuv.so.1
Oct 13 14:11:04 ns4 named[10719]: 0x826203cd6 at
/usr/local/lib/libuv.so.1
Oct 13 14:11:04 ns4 named[10719]: 0x8261f2020 at
/usr/local/lib/libuv.so.1
Oct 13 14:11:04 ns4 named[10719]: 0x8220bba3d at
/usr/local/lib/libisc-9.20.2.so
Oct 13 14:11:04 ns4 named[10719]: 0x8220bb8d3 at
/usr/local/lib/libisc-9.20.2.so
Oct 13 14:11:04 ns4 named[10719]: exiting (due to assertion failure)
Oct 13 14:11:04 ns4 root[12253]: /usr/local/etc/rc.d/named: WARNING:
failed to start named
# named -V
BIND 9.20.2 (Stable Release)
running on FreeBSD amd64 13.3-RELEASE-p7 FreeBSD 13.3-RELEASE-p7 GENERIC
built by make with '--localstatedir=/var'
'--sysconfdir=/usr/local/etc/namedb' '--with-libxml2'
'--with-openssl=/usr' '--enable-dnsrps' '--with-readline=libedit'
'--disable-tracing' '--enable-dnstap' '--disable-fixed-rrset'
'--disable-geoip' '--without-maxminddb' '--without-gssapi'
'--with-libidn2=/usr/local' '--with-json-c' '--disable-largefile'
'--with-lmdb=/usr/local' '--disable-querytrace' '--enable-tcp-fastopen'
'--prefix=/usr/local' '--mandir=/usr/local/share/man'
'--disable-silent-rules' '--infodir=/usr/local/share/info/'
'--build=amd64-portbld-freebsd13.3'
'build_alias=amd64-portbld-freebsd13.3' 'CC=cc' 'CFLAGS=-O2 -pipe
-DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include
-fno-strict-aliasing ' 'LDFLAGS= -L/usr/local/lib -ljson-c
-fstack-protector-strong ' 'LIBS=-L/usr/local/lib'
'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp'
'PKG_CONFIG=pkgconf'
'PKG_CONFIG_LIBDIR=/wrkdirs/usr/ports/dns/bind920/work/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/local/share/pkgconfig:/usr/libdata/pkgconfig'
'PYTHON=/usr/local/bin/python3.11'
compiled by CLANG FreeBSD Clang 17.0.6
(https://github.com/llvm/llvm-project.git llvmorg-17.0.6-0-g6009708b4367)
compiled with OpenSSL version: OpenSSL 1.1.1w-freebsd 11 Sep 2023
linked to OpenSSL version: OpenSSL 1.1.1w-freebsd 11 Sep 2023
compiled with libuv version: 1.49.0
linked to libuv version: 1.49.0
compiled with liburcu version: 0.14.0
compiled with system jemalloc version: 2020110501
compiled with libnghttp2 version: 1.63.0
linked to libnghttp2 version: 1.63.0
compiled with libxml2 version: 2.11.9
linked to libxml2 version: 21109
compiled with json-c version: 0.18
linked to json-c version: 0.18
compiled with zlib version: 1.3.1
linked to zlib version: 1.3.1
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.1
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512
ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384
HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): no
TKEY mode 3 support (GSS-API): no
--
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
