Re: intermittent SERVFAIL for high visible domains such as *.google.com
On Mon, 2018-01-22 at 12:45 +, Tony Finch wrote: > > lame-servers is also a log category, and tends to be quite noisy > about > various problems :-) Turns out I do already have lame server logging enabled. I.e.: 20-Jan-2018 12:01:37.053 lame server resolving 'backup-ns.yn.cninfo.net' (in 'yn.cninfo.net'?): 202.98.160.68#53 20-Jan-2018 12:01:37.054 lame server resolving 'backup-ns.yn.cninfo.net' (in 'yn.cninfo.net'?): 202.98.160.68#53 But there isn't a single lame server message with "google" anywhere in it. This problem is really not looking like a lame delegation issue, wouldn't you agree? Any further ideas? Cheers, b. signature.asc Description: This is a digitally signed message part ___ 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: intermittent SERVFAIL for high visible domains such as *.google.com
Here's a new most interesting data point. All of these outages happen right after a DHCP client connect and sends a DDNS update to BIND. It would be an interesting experiment to isolate the zone that receives DDNS updates for the DHCP clients onto a separate server to see if that makes this problem go away for the main server, but I don't have another machine to run another BIND on and I don't think it's possible to run two BINDs on the same machine on different ports and have one (on port 53) delegate a zone to another running on some other port. Cheers, b. signature.asc Description: This is a digitally signed message part ___ 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: intermittent SERVFAIL for high visible domains such as *.google.com
Am 23.01.2018 um 13:25 schrieb Brian J. Murrell: Here's a new most interesting data point. All of these outages happen right after a DHCP client connect and sends a DDNS update to BIND. It would be an interesting experiment to isolate the zone that receives DDNS updates for the DHCP clients onto a separate server to see if that makes this problem go away for the main server, but I don't have another machine to run another BIND on and I don't think it's possible to run two BINDs on the same machine on different ports and have one (on port 53) delegate a zone to another running on some other port pretty sure it's possible and likely not much different than the unbound-sample below which asks a rbldnsd on port 1043 on the same machine stub-zone: name: "zone-name." stub-addr: 127.0.0.1@1053 ___ 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: intermittent SERVFAIL for high visible domains such as *.google.com
On 23 Jan 2018, at 12:25, Brian J. Murrell wrote: > I don't think it's possible > to run two BINDs on the same machine on different ports and have one > (on port 53) delegate a zone to another running on some other port. You could use different __addresses__, if you have any to spare. Best regards, Niall O'Reilly signature.asc Description: OpenPGP digital 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: intermittent SERVFAIL for high visible domains such as *.google.com
On Tue, 2018-01-23 at 13:38 +0100, Reindl Harald wrote: > > pretty sure it's possible and likely not much different than the > unbound-sample below which asks a rbldnsd on port 1043 on the same > machine > > stub-zone: > name: "zone-name." > stub-addr: 127.0.0.1@1053 That's the sort of path I was going to take with a forward zone in the main server to my DHCP-DDNS-isolation server, but in the new zone I create on the isolation server I have to list NS(es) for the new zone and while those will be on the (IP address of the) main server they will be on a different port. Of course anything doing an NS query for that new zone on that server will just get an IP address for the NS and not the port also. Maybe in such an isolated environment that doesn't matter since the only thing doing an queries to that isolated server on the alternate port will be the main server on behalf of the clients in the local network. I'll give it a shot. Cheers, b. signature.asc Description: This is a digitally signed message part ___ 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: intermittent SERVFAIL for high visible domains such as *.google.com
On Tue, 2018-01-23 at 13:38 +0100, Reindl Harald wrote: > > pretty sure it's possible and likely not much different than the > unbound-sample below which asks a rbldnsd on port 1043 on the same > machine > > stub-zone: > name: "zone-name." > stub-addr: 127.0.0.1@1053 This all falls apart because you cannot instruct the ISC DHCP server to send DDNS updates to a non-standard (!53) port. :-( I seem to have no choice but to run the isolated server on a different IP address and then have to start managing the listen-on directive in the main server to list all addresses other than the isolated server's address. :-( Cheers, b. signature.asc Description: This is a digitally signed message part ___ 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: intermittent SERVFAIL for high visible domains such as *.google.com
On 01/23/2018 05:25 AM, Brian J. Murrell wrote: It would be an interesting experiment to isolate the zone that receives DDNS updates for the DHCP clients onto a separate server to see if that makes this problem go away for the main server, but I don't have another machine to run another BIND on… Could you try disabling DDNS updates for a little while? Maybe you'll get lucky (for a given value of luck) and find that the problem continues happening even with DDNS updates disabled. Thus you will have a reasonable idea that the issue is not related to DDNS updates. …I don't think it's possible to run two BINDs on the same machine on different ports and have one (on port 53) delegate a zone to another running on some other port. I'm sure that you could do some networking magic to cause connections to $AlternateIP port 53 to be re-routed to $DifferentIP $AlternatePort. -- Grant. . . . unix || die 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: intermittent SERVFAIL for high visible domains such as *.google.com
Hi there, On Tue, 23 Jan 2018, Grant Taylor wrote: ... I'm sure that you could do some networking magic to cause connections to $AlternateIP port 53 to be re-routed to $DifferentIP $AlternatePort. http://netcat.sourceforge.net/ -- 73, Ged. ___ 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: intermittent SERVFAIL for high visible domains such as *.google.com
On Tue, 2018-01-23 at 09:53 -0700, Grant Taylor via bind-users wrote: > > Could you try disabling DDNS updates for a little while? That's effectively what I have done. I set up a second server configuration running new zone on a different IP address and pointed the DHCP server at it so that the DHCP server is no longer sending DDNS updates to the server that is having these intermittent outages. I've set up CNAME pointers from the main server to the new server for the names (of DHCP clients) that need to be resolvable as well as for a reverse zone on the new server. > Maybe you'll > get lucky (for a given value of luck) and find that the problem > continues happening even with DDNS updates disabled. Thus you will > have > a reasonable idea that the issue is not related to DDNS updates. Exactly my goal. I'm fairly sure that the problem is going to stop happening now that the server is no longer processing DDNS updates. Unfortunately it's impractical to run like this for the long term as any DHCP client that comes into the network ought to be able to be resolvable by it's name in the main zone, but that would require CNAMEs for any and every possible name that could show up in a DHCP client. Cheers, b. signature.asc Description: This is a digitally signed message part ___ 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
