Re: bind 9.11.2 - domain and subdomain with one zone does not work
Hi ?
You have delegated the domain "sub.test.local" but you have no zone
statement for this zone.
Suggest you create a db.sub.test.local zone file and update your
configuration with
zone "sub.test.local" IN {
type master;
file "db.sub.test.local";
};
And remove the following from the db.test.local zone file:
$ORIGIN sub.test.local.
localhost A 127.0.0.1
t30 A 127.0.0.2
Br Peter
On 03/04/2020 08:19, mail-list-us...@materna.de wrote:
> Good morning,
>
> we try to use in our zone files for easy including of new sub domains.
> While it worked on my test system, in production we get either NXDOMAIN or
> SERVFAIL,
> both use bind 9.11.2 from the distro. Level 10 debug with all possible logs
> enabled did gave no answer.
> Maybe someone on this list will find our problem, like in the past.
> named.conf from test system, besides of the amount of zones the same as
> production:
> ---
>
> options {
> allow-transfer { none;};
> check-names master ignore;
> check-names slave ignore;
> check-names response ignore;
> directory "/var/lib/named";
> managed-keys-directory "/var/lib/named/dyn/";
> dump-file "/var/log/named_dump.db";
> statistics-file "/var/log/named.stats";
> listen-on-v6 { any; };
> notify no;
> forward only;
> forwarders { 127.0.0.1; };
> allow-recursion { 127.0.0.1; };
> allow-query { 127.0.0.1; };
> response-policy {
> zone "testoverride" log no;
> zone "logoverride" log yes;
> };
>
> 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";
> };
>
> acl AllowDDNS { 127.0.0.1/32; };
>
> include "/etc/rndc.key";
>
> controls {
> inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
> };
>
> view public {
> zone "." in {
> type hint;
> file "db.hint";
> };
>
> zone "localhost" in {
> type master;
> file "localhost.zone";
> };
>
> zone "0.0.127.in-addr.arpa" in {
> type master;
> file "127.0.0.zone";
> };
>
> zone
> "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" IN {
> type master;
> file "127.0.0.zone";
> };
>
> zone "test.local" IN {
> type master;
> file "db.test.local";
> };
>
> zone "testoverride" {
> type master;
> file "Multistuff";
> allow-query { AllowDDNS; };
> allow-update { AllowDDNS; };
> };
>
> zone "logoverride" {
> type master;
> file "LogStuff";
> allow-query { AllowDDNS; };
> allow-update { AllowDDNS; };
> };
>
> };
>
> logging {
>
> channel default_syslog {
> # Send most of the named messages to syslog.
> syslog local2;
> severity debug;
> };
>
> channel audit_log {
> #Send the security related messages to a separate file.
> syslog local2;
> severity debug;
> print-time yes;
> };
>
> channel null {
> null;
> };
>
>
> category default { default_syslog; };
> category config { default_syslog; };
> category dispatch { default_syslog; };
> category network { default_syslog; };
> category general { default_syslog; };
> category resolver { default_syslog; };
> category cname { default_syslog; };
> category delegation-only { default_syslog; };
> category lame-servers { default_syslog; };
> category edns-disabled { default_syslog; };
> category dnssec { default_syslog; };
> category notify { default_syslog; };
> category xfer-in { default_syslog; };
> category xfer-out { default_syslog; };
> category update{ default_syslog; };
> category update-security { default_syslog; };
> category client{ default_syslog; };
> category security { default_syslog; };
> category rate-limit { default_syslog; };
> category spill { default_syslog; };
> category database { default_syslog; };
> category rpz { default_syslog; };
> category dnstap { default_syslog; };
> category queries { default_syslog; };
> category query-errors { default_syslog; };
>
>
> };
> ---
>
> The zone file:
> ---
> $ORIGIN .
> $TTL 604800 ; 1 week
> test.local IN SOA mytest.test.local. root.test.local. (
> 2020040123 ; serial
> 1800 ; refresh (30 minutes)
> 900; retry (15 minutes)
>
Can we provide recursion for forward zones in response to iterative queries?
Hi, In summary, my question is whether there is a way to configure a bind caching server to provide recursion in response to iterative queries for records in a forward type zone. The background is that we have: - AD domain controllers that are authoritative for all of 10.in-addr.arpa. in our data centers - most clients point to these for DNS resolution. - Linux bind caching resolvers in our data centers - domain controllers forward to these for anything they don’t own. - Some AWS VPCs which have been allocated subdomains of 10.in-addr.arpa. and are routable from our data centers. These have Route53 inbound endpoints which answer queries for those subdomains. - The bind caching resolvers have forwarding rules for those subdomains to the AWS inbound endpoints. The subdomains in our AWS VPCs have NS records, but the servers those point to refuse queries for records in the subdomains. The zone resolution is taken care of by the Route53 resolver service. The Route53 inbound endpoints successfully resolve queries from our data centers for those subdomains as long as the recursion desired flag is set to 1 in the query. If recursion desired is set to 0 they do not send any reply at all. We want to be able to resolve PTR records in the subdomains in the AWS VPCs from our data centers where, as I said above, the clients point to the domain controllers for DNS resolution. Because the AD domain controllers already own 10.in-addr.arpa, they refuse to allow us to configure conditional forwarding for its subdomains. So we delegated the subdomains to the inbound endpoints. Because they are delegations, the domain controllers set the recursion desired flag to 0 on the queries they send to the endpoints, and we are not getting replies from the endpoints. As a workaround we tried delegating to our linux bind caching resolvers but we ran into the same issue, that the domain controllers set recursion desired to 0. As a result, when our linux caching servers have the result in cache, the lookup is successful, but when it would require a fresh lookup it gets a reply with no answers. Hence my question, is there a way to tell our bind caching resolvers to ignore the recursion desired flag and provide recursion anyway? Thanks, Maria ___ 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
[Fwd: Re: bind 9.11.2 - domain and subdomain with one zone does not work]
Thanks for the reply. Actually my setup is just like 1) zone delegation Am 03.04.20 um 15:20 schrieb David Alexandre M. de Carvalho: > Where can I find about alternatives to point 2? in the part you quoted from me > I have a windows subdomain configured in that way, never realized there was a > better way. > Thanks and regards. which way? a) zone-delegation, 192.168.196.1 is the nameserver responsible for whatever below subzone.example.com subzone IN A 192.168.196.1 subzone IN NS subzone b) records in the same main zone file subzone IN A 192.168.1.1 www.subzone IN A 192.168.196.10 mail.subzone IN A 192.168.196.11 why so much complexity to begin with? t1 A 127.0.0.3 sub.t30 A 127.0.0.2 >> >> On 03.04.20 11:53, mail-list-us...@materna.de wrote: >>> --- >>> Well, in first place to make it human readable, if needed to look into the >>> zone. >> >> well >> 1. the above is more readablt than whay you proposed. >> >> 2. delegating subdomain (sub) to other servers via NS records and setting >>any other records in the zone is a bad idea. >> >> 3. putting localhost into any domain is useless and I discourage you from >>doing that >> >>> For some subdomains we would have entries for the subdomain itself, like >>> couple NS,TXT,A,CNAME,SRV etc. >>> So with these thoughts, the documentation gives this as a valid option and >>> it >>> worked in small scale on the testsystem, so we decieded to go this way. >>> If this needs to be changed, I need a reason besides of 'that is this way >>> more easy', >>> because these zones get generated from an automated system and I need an >>> argument to get a permission for a change request. ___ 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: bind 9.11.2 - domain and subdomain with one zone does not work
On 03.04.20 14:20, David Alexandre M. de Carvalho wrote: Where can I find about alternatives to point 2? I have a windows subdomain configured in that way, never realized there was a better way. On 03.04.20 16:35, Matus UHLAR - fantomas wrote: if you want to have subdomain with different set of nameservers, you should put it into another zone and it should have different SOA as long. so, "sub" would have NS records in "test.local." but "sub.test.local" would have own zone, own file, containing SOA, NS, MX etc records. I think I should rephrase this: You should put NS records for subdomain only if you are creating another zone. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Christian Science Programming: "Let God Debug It!". ___ 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 9.11.2 - domain and subdomain with one zone does not work
On 03.04.20 14:20, David Alexandre M. de Carvalho wrote: Where can I find about alternatives to point 2? I have a windows subdomain configured in that way, never realized there was a better way. if you want to have subdomain with different set of nameservers, you should put it into another zone and it should have different SOA as long. so, "sub" would have NS records in "test.local." but "sub.test.local" would have own zone, own file, containing SOA, NS, MX etc records. why so much complexity to begin with? t1 A 127.0.0.3 sub.t30 A 127.0.0.2 On 03.04.20 11:53, mail-list-us...@materna.de wrote: --- Well, in first place to make it human readable, if needed to look into the zone. well 1. the above is more readablt than whay you proposed. 2. delegating subdomain (sub) to other servers via NS records and setting any other records in the zone is a bad idea. 3. putting localhost into any domain is useless and I discourage you from doing that For some subdomains we would have entries for the subdomain itself, like couple NS,TXT,A,CNAME,SRV etc. So with these thoughts, the documentation gives this as a valid option and it worked in small scale on the testsystem, so we decieded to go this way. If this needs to be changed, I need a reason besides of 'that is this way more easy', because these zones get generated from an automated system and I need an argument to get a permission for a change request. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. - Have you got anything without Spam in it? - Well, there's Spam egg sausage and Spam, that's not got much Spam in it. ___ 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 9.11.2 - domain and subdomain with one zone does not work
Am 03.04.20 um 15:20 schrieb David Alexandre M. de Carvalho: > Where can I find about alternatives to point 2? in the part you quoted from me > I have a windows subdomain configured in that way, never realized there was a > better way. > Thanks and regards. which way? a) zone-delegation, 192.168.196.1 is the nameserver responsible for whatever below subzone.example.com subzone IN A 192.168.196.1 subzone IN NS subzone b) records in the same main zone file subzone IN A 192.168.1.1 www.subzone IN A 192.168.196.10 mail.subzone IN A 192.168.196.11 why so much complexity to begin with? t1 A 127.0.0.3 sub.t30 A 127.0.0.2 >> >> On 03.04.20 11:53, mail-list-us...@materna.de wrote: >>> --- >>> Well, in first place to make it human readable, if needed to look into the >>> zone. >> >> well >> 1. the above is more readablt than whay you proposed. >> >> 2. delegating subdomain (sub) to other servers via NS records and setting >>any other records in the zone is a bad idea. >> >> 3. putting localhost into any domain is useless and I discourage you from >>doing that >> >>> For some subdomains we would have entries for the subdomain itself, like >>> couple NS,TXT,A,CNAME,SRV etc. >>> So with these thoughts, the documentation gives this as a valid option and >>> it >>> worked in small scale on the testsystem, so we decieded to go this way. >>> If this needs to be changed, I need a reason besides of 'that is this way >>> more easy', >>> because these zones get generated from an automated system and I need an >>> argument to get a permission for a change request. ___ 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 9.11.2 - domain and subdomain with one zone does not work
Hi! Where can I find about alternatives to point 2? I have a windows subdomain configured in that way, never realized there was a better way. Thanks and regards. Os melhores cumprimentos David Alexandre M. de Carvalho --- Especialista de Informática Departamento de Informática Universidade da Beira Interior >>> why so much complexity to begin with? >>> >>>t1 A 127.0.0.3 >>>sub.t30 A 127.0.0.2 > > On 03.04.20 11:53, mail-list-us...@materna.de wrote: >>--- >>Well, in first place to make it human readable, if needed to look into the >>zone. > > well > 1. the above is more readablt than whay you proposed. > > 2. delegating subdomain (sub) to other servers via NS records and setting >any other records in the zone is a bad idea. > > 3. putting localhost into any domain is useless and I discourage you from >doing that > >>For some subdomains we would have entries for the subdomain itself, like >>couple NS,TXT,A,CNAME,SRV etc. >>So with these thoughts, the documentation gives this as a valid option and it >>worked in small scale on the testsystem, so we decieded to go this way. >>If this needs to be changed, I need a reason besides of 'that is this way >>more easy', >>because these zones get generated from an automated system and I need an >>argument to get a permission for a change request. > > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > Support bacteria - they're the only culture some people have. > ___ > 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: bind 9.11.2 - domain and subdomain with one zone does not work
why so much complexity to begin with? t1 A 127.0.0.3 sub.t30 A 127.0.0.2 On 03.04.20 11:53, mail-list-us...@materna.de wrote: --- Well, in first place to make it human readable, if needed to look into the zone. well 1. the above is more readablt than whay you proposed. 2. delegating subdomain (sub) to other servers via NS records and setting any other records in the zone is a bad idea. 3. putting localhost into any domain is useless and I discourage you from doing that For some subdomains we would have entries for the subdomain itself, like couple NS,TXT,A,CNAME,SRV etc. So with these thoughts, the documentation gives this as a valid option and it worked in small scale on the testsystem, so we decieded to go this way. If this needs to be changed, I need a reason besides of 'that is this way more easy', because these zones get generated from an automated system and I need an argument to get a permission for a change request. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Support bacteria - they're the only culture some people have. ___ 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 9.11.2 - domain and subdomain with one zone does not work
> why so much complexity to begin with? > >t1 A 127.0.0.3 >sub.t30 A 127.0.0.2 --- Well, in first place to make it human readable, if needed to look into the zone. For some subdomains we would have entries for the subdomain itself, like couple NS,TXT,A,CNAME,SRV etc. So with these thoughts, the documentation gives this as a valid option and it worked in small scale on the testsystem, so we decieded to go this way. If this needs to be changed, I need a reason besides of 'that is this way more easy', because these zones get generated from an automated system and I need an argument to get a permission for a change request. Sincerely ___ 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 - many doubts
Am 03.04.20 um 10:51 schrieb Timothe Litt: > The entropy problem is especially severe in many VMs. Besides Warren's > suggestion: > > Many current machines have hardware random noise sources that solve (or > at least > put a big dent) into the entropy problem. A raspberry Pi is > inexpensive, and unless you > are generating zillions of keys, will solve most of these issues. I use > entropy broker > https://www.vanheusden.com/entropybroker/ to distribute entropy from a Pi to > my network. (And you can always add another RPi.) I don't recall the > last time > I ran out of entropy - and no, I'm not talking about the "organization" > of my physical > desktop :-) https://wiki.archlinux.org/index.php/Haveged and for the doubts: keep in mind the kernel is mixing all entropy sources and even don't get compromised if one of them only returns 1 all the time ___ 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 - many doubts
The entropy problem is especially severe in many VMs. Besides Warren's suggestion: Many current machines have hardware random noise sources that solve (or at least put a big dent) into the entropy problem. A raspberry Pi is inexpensive, and unless you are generating zillions of keys, will solve most of these issues. I use entropy broker https://www.vanheusden.com/entropybroker/ to distribute entropy from a Pi to my network. (And you can always add another RPi.) I don't recall the last time I ran out of entropy - and no, I'm not talking about the "organization" of my physical desktop :-) For a while, there USB keys with entropy sources were a good choice - but with hardware sources built into most CPUs, I think their time has passed. The same low-power RPi that feeds entropy is also a great NTP server, VPN gateway and a few other things - for ~USD 40. Or any Intel or AMD cpu since ~2015 has RDRAND/RDSEED. There are some religious arguments about booby-trapped hardware sources - these days, kernels will mix all sources, so I don't get too upset. But YMMV. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. On 02-Apr-20 11:58, Warren Kumari wrote: > On Thu, Apr 2, 2020 at 11:14 AM David Alexandre M. de Carvalho > wrote: >> Hello, good afternoon. >> My first post in this list :) >> >> I'm running BIND Chroot for many years (currently version 9.8.2) on some old >> hardware running Oracle Linux 6. >> I believe it was last year when I was reading about implementing DNSSEC, and >> I think I've even tried to generate a >> keypair in the slowest server, which after more than a day, wasn't ready >> yet. Maybe I was doing something wrong, I >> honestly don't know. > You almost definitely were -- even a really really slow machine should > be able to generate keys in a small number of seconds -- you didn't > list what commands you used, but I'm going to assume you were trying > to generate an rsa key - you should be able to get a feel for how long > this takes by running: > time openssl genrsa -out private.key 2048 > or > time openssl genrsa -out private.key 4096 > (note that this is very different to running 'openssl speed rsa2048 > rsa4096', which benchmarks RSA operations, not key generations). > > I'm fairly sure that your issue was a lack of entropy -- in order to > generate crypograohically good keys, you need good a good source of > randomness. If you are running an older machine and older kernel, the > /dev/random source is blocking, and if you try and read too much from > it it will just hang until it has enough entropy to give "safe" > output. Newer kernels do a better job of mixing in external event > noise, but there are a number of modules which help with this - > haveged being the best known (http://www.issihosts.com/haveged/ ). > You could also test if this is the issue by using /dev/urandom, which > doesn't block, or 'while true; do cat > /proc/sys/kernel/random/entropy_avail; sleep 2; done' and see if the > available entropy drops to zero during key generation... > > W > >> So now I had some time and reading about this again. >> >> If I query either of my servers about my domain: >> dig @dns di.ubi.pt DNSKEY >> I do get the DNSKEY, but I have no records when querying about +dnssec. My >> topdomain (ubi.pt) doesn't have DNSSEC yet >> either. >> >> my named.conf already has the following: >> >> dnssec-enable yes; >> dnssec-validation auto; >> dnssec-lookaside auto; >> bindkeys-file "/etc/named.iscdlv.key"; >> managed-keys-directory "/var/named/dynamic"; >> >> Outside the configuration file I also have a /etc/named.root.key >> >> My questions: >> 1) Will my old servers (1GB RAM) become much slower with DNSSEC? Is it >> worth it? >> 2) I have one global "hosts" file and 3 reverse zone files, each for the >> respective IP network. Can I use the same >> Keypair in all of them? >> 3) Are the files /etc/named.root.key file and /etc/named.iscdlv.key already >> being used? I compared them to the result >> of the DNSKEY dig query but they are different. >> >> Thank you so much for your time! >> Best regards >> >> Os melhores cumprimentos >> David Alexandre M. de Carvalho >> --- >> Especialista de Informática >> Departamento de Informática >> Universidade da Beira Interior >> >> >> >> ___ >> 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 > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. >
Re: bind 9.11.2 - domain and subdomain with one zone does not work
Am 03.04.20 um 08:19 schrieb mail-list-us...@materna.de: > --- > > The zone file: > --- > $ORIGIN . > $TTL 604800 ; 1 week > test.local IN SOA mytest.test.local. root.test.local. ( > 2020040123 ; serial > 1800 ; refresh (30 minutes) > 900; retry (15 minutes) > 2592000; expire (4 weeks 2 days) > 604800 ; minimum (1 week) > ) > NS test.local. > NS test.local. > A 127.0.0.1 > MX 10 test.local. > MX 20 test.local. > TXT "AD buc" > $ORIGIN test.local. > t1A 127.0.0.3 > sub NS test.local. > NS test.local. > MX 10 test.local. > MX 20 test.local. > $ORIGIN sub.test.local. > localhost A 127.0.0.1 > t30 A 127.0.0.2 > $ORIGIN test.local. > t31 CNAME t1 why so much complexity to begin with? t1 A 127.0.0.3 sub.t30 A 127.0.0.2 ___ 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
