Re: forward only recursive server doesn't forward
On 19.10.16 21:27, Alex wrote:
I have a bind-9.10.3 server on fedora22 that is authoritative for a
few domains and their corresponding IP ranges. I'd like to set up
another domain server (rbldnsd) on a host in one of those domains as a
forward-only server.
The problem appears to be that the queries from the local box to the
subdomain being managed by the rbldnsd server are being answered by
the local bind instead of being sent to the remote machine running
rbldnsd.
In other words, I believe the issue is that the host is already
authoritative for the reverse zone, so there would be no reason for it
to forward these queries to another system.
Mark already took care of first part of your post.
zone "96/28.104.104.66.in-addr.arpa" {
type slave;
file "slaves/db.104.104.66";
masters { 64.1.1.3; };
allow-query { any; };
allow-transfer { trusted; };
};
I set up the reverse zone a long time ago, and I don't think the "zone
96/28.104.104.66.in-addr.arpa" is completely correct, but it appears
to work. I'm not sure if that's related to the problem, but would
appreciate advice there.
The domain 96/28.104.104.66.in-addr.arpa is completely correct, however the
DNS clients must know they have to search for this domain.
Thus, you must ask your ISP to delegate part of
104.104.66.in-addr.arpa to your subdomain:
96/28 IN NS your.server.name.
96 IN CNAME 96/28
97 IN CNAME 97/28
...
111 IN CNAME 111/28
--
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.
If Barbie is so popular, why do you have to buy her friends?
___
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: forward only recursive server doesn't forward
Am 20.10.2016 um 03:27 schrieb Alex: I have a bind-9.10.3 server on fedora22 that is authoritative for a few domains and their corresponding IP ranges. I'd like to set up another domain server (rbldnsd) on a host in one of those domains as a forward-only server why on another host? it just adds latency for no gain "rbldnsd -b 127.0.0.1/1053" and it runs on the same host while the sub-zone config below is for unbound i guess it's not too hard fin dthe same for named stub-zone: name: "scann.example.com." stub-addr: 127.0.0.1@1053 [root@mail-gw:~]$ netstat -l | grep 53 tcp0 0 127.0.0.1:530.0.0.0:* LISTEN 998/unbound udp0 0 127.0.0.1:1053 0.0.0.0:* 989/rbldnsd udp0 0 127.0.0.1:530.0.0.0:* 998/unbound ___ 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
DNAME + DNSSEC
Hi, I noticed some inconsistent behavior in a particular setup where a DNAME is involved and I am trying to figure out who is right and who is wrong. Players involved on the resolving side are: Google Public DNS (resolves without an error) BIND (often results in a timeout and a log-rule saying: "unrelated DNAME in answer") Unbound (results in a SERVFAIL) On the authoritative side the players are: PowerDNS BIND NSD The query-type (A yield other results than ANY) The query to test is for example: dig +dnssec -t ANY _sidn._dnssec-valcheck._1804289384.bergzand.nl I believe both bergzand.nl and bergzand.net are hosted on PowerDNS. dig +dnssec -t ANY _sidn._dnssec-valcheck._1804289384.scintilla.nl This domain is served from BIND. For testing-purposes I tried to simulate the situation in sidnlabs.nl: dig +dnssec -t ANY _sidn._dnssec-valcheck._1804289384.sidnlabs.nl sidnlabs.nl is served from BIND, but example.nl (the DNAME) is served from BIND and NSD). I guess I have these question to the reader: - Is it ok for BIND to have a timeout? - Why does Google resolve, why does UNbound result in a SERVFAIL and who is right? - Is there an authoritative server (PowerDNS perhaps?) not doing the right thing? I've been looking to long to this matter so this is the time to ask for your help. It didn't help that DNS-OARCs open BIND-resolver (184.105.193.73) broke down, having the same effect as a timeout). Thanks. -- Marco smime.p7s Description: S/MIME Cryptographic Signature ___ 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: DNAME + DNSSEC
On 20/10/2016 14:41, Marco Davids (SIDN) wrote: > For testing-purposes I tried to simulate the situation in sidnlabs.nl: > > dig +dnssec -t ANY _sidn._dnssec-valcheck._1804289384.sidnlabs.nl ERROR! That should be: dig +dnssec -t ANY _sidn._dnssec-valcheck._1804289384.dname.sidnlabs.nl -- Marco smime.p7s Description: S/MIME Cryptographic Signature ___ 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
receive_secure_serial: bad database
I haven't found a good explanation of that this log entry means: Oct 20 14:41:47 dns-s named[8311]: zone student.iastate.edu/IN/in (signed): receive_secure_serial: bad database I've found 58 log entires for this just in the last 90 minutes. Nothing before that in the last 9 days. I've also had named die several times for unknown reasons and once wasn't responding during this time as well. -- Rod Eldridge Networks & Communications IT Services, Iowa State University of Science and Technology ___ 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: receive_secure_serial: bad database
On Thu, Oct 20, 2016 at 07:47:35PM +, Eldridge, Rod A [ITNET] wrote: > I haven't found a good explanation of that this log entry means: > > Oct 20 14:41:47 dns-s named[8311]: zone student.iastate.edu/IN/in (signed): > receive_secure_serial: bad database > > I've found 58 log entires for this just in the last 90 minutes. Nothing > before that in the last 9 days. I've also had named die several times > for unknown reasons and once wasn't responding during this time as well. It looks like this is an inline-signing zone, and something's gone wrong with synchronization between the unsigned and signed versions. You may be able to correct the glitch by removing the signed version of the student.iastate.edu zone and restarting named so it gets resigned from scratch. Please preserve all the zone files first, though, so we can try to identify the error. Can you please open a ticket by mailing bind9-b...@isc.org? It would be easier to discuss it there. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: forward only recursive server doesn't forward
Hi,
>> >> I have a bind-9.10.3 server on fedora22 that is authoritative for a
>> >> few domains and their corresponding IP ranges. I'd like to set up
>> >> another domain server (rbldnsd) on a host in one of those domains as a
>> >> forward-only server.
>> >>
>> >> The problem appears to be that the queries from the local box to the
>> >> subdomain being managed by the rbldnsd server are being answered by
>> >> the local bind instead of being sent to the remote machine running
>> >> rbldnsd.
>> >
>> > Add a delegation for scann.example.com in example.com. Forward
>> > zones control *where* the queries are sent, not if queries are sent.
>>
>> I'm sorry, I don't understand. This system is already a slave for the
>> forward zone example.com. I just realized I forgot to include that in
>> my previous post:
>>
>> zone "example.com" {
>> type slave;
>> file "slaves/db.example.com";
>> masters { 64.1.1.3; };
>> allow-query { any; };
>> allow-transfer { trusted; };
>> };
>
> Add NS records for scann.example.com to example.com. This is how
> nameservers are supposed to find out which machines serve which
> zones.
>
> scann.example.com. 3600 NS .
Thank you. I have no idea how I forgot about that part. It now appears
to be working.
___
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: forward only recursive server doesn't forward
Hi,
>> zone "96/28.104.104.66.in-addr.arpa" {
>>type slave;
>>file "slaves/db.104.104.66";
>>masters { 64.1.1.3; };
>>allow-query { any; };
>>allow-transfer { trusted; };
>> };
>
>
>> I set up the reverse zone a long time ago, and I don't think the "zone
>> 96/28.104.104.66.in-addr.arpa" is completely correct, but it appears
>> to work. I'm not sure if that's related to the problem, but would
>> appreciate advice there.
>
> The domain 96/28.104.104.66.in-addr.arpa is completely correct, however the
> DNS clients must know they have to search for this domain.
>
> Thus, you must ask your ISP to delegate part of
> 104.104.66.in-addr.arpa to your subdomain:
Yes, this I knew. I think what caused me to suspect it as somehow not
being completely correct is the result from a host command:
# host 66.104.104.100
100.104.104.66.in-addr.arpa is an alias for 100.96/28.104.104.66.in-addr.arpa.
100.96/28.104.104.66.in-addr.arpa domain name pointer email.example.com.
It just doesn't look right.
Thanks,
Alex
___
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
