Re: unbound reverse DNS problem to local stub zone
On 2014-09-01 Mon 08:58 AM |, Arthur Mesh wrote: I have the same exact symptom, unbound.conf: local-zone: 10.in-addr.arpa. nodefault Change this to: local-zone: 10.in-addr.arpa typetransparent See types under the section 'local-zone' of unbound.conf(5)
Re: unbound reverse DNS problem to local stub zone
On Sun, Jul 27, 2014 at 11:20:43AM +0200, Patrik Lundin wrote: How is/was the reverse zone configured in nsd? I am currently trying to debug an issue i've seen when the stub-zone in unbound is wider (name: 10.in-addr.arpa) than the zone in nsd (name: 0.0.10.in-addr.arpa). To me the following is seen: # dig @127.0.0.1 -x 10.0.0.1 -- works # dig @127.0.0.1 -x 10.0.0.2 -- fails # dig @127.0.0.1 -x 10.0.0.3 -- works # dig @127.0.0.1 -x 10.0.0.4 -- works Basically the first lookup works, the second ends up at IANA (as if the stub-zone configuration did not exist), and any following lookups work again. I have the same exact symptom, unbound.conf: server: interface: 127.0.0.1@53 interface: 10.10.10.1@53 verbosity: 1 do-not-query-localhost: no do-ip6: no auto-trust-anchor-file: /var/unbound/etc/root.key access-control: 0.0.0.0/0 refuse access-control: 127.0.0.0/8 allow access-control: 10.10.0.0/16 allow access-control: ::0/0 refuse access-control: ::1 allow hide-identity: yes hide-version: yes local-zone: 10.in-addr.arpa. nodefault stub-zone: name: 10.in-addr.arpa. stub-addr: 127.0.0.1@5353 # dig -p53 @127.0.0.1 -x 10.10.10.2 +short # works # dig -p53 @127.0.0.1 -x 10.10.10.1 +short # doesnt If I dig directly to nsd, via -p5353 # dig -p5353 @127.0.0.1 -x 10.10.10.2 +short # works # dig -p5353 @127.0.0.1 -x 10.10.10.1 +short # works I have no good explanation as to what's going on. I've tried this on current (as opposed to 5.5), and issue does NOT go away. On the NSD side, I have two zones zone: name: 10.10.10.in-addr.arpa. zonefile: db.10.10.10 zone: name: 11.10.10.in-addr.arpa. zonefile: db.10.10.11
Re: unbound reverse DNS problem to local stub zone
On Mon, Sep 01, 2014 at 08:58:11AM -0700, Arthur Mesh wrote: I have no good explanation as to what's going on. I've tried this on current (as opposed to 5.5), and issue does NOT go away. I decided to ask about this on unbound-users: https://unbound.nlnetlabs.nl/pipermail/unbound-users/2014-September/003504.html Regards, Patrik Lundin
Re: unbound reverse DNS problem to local stub zone
On Monday, September 1, 2014 17:58 CEST, Arthur Mesh arthurm...@gmail.com wrote: On Sun, Jul 27, 2014 at 11:20:43AM +0200, Patrik Lundin wrote: How is/was the reverse zone configured in nsd? I am currently trying to debug an issue i've seen when the stub-zone in unbound is wider (name: 10.in-addr.arpa) than the zone in nsd (name: 0.0.10.in-addr.arpa). To me the following is seen: # dig @127.0.0.1 -x 10.0.0.1 -- works # dig @127.0.0.1 -x 10.0.0.2 -- fails # dig @127.0.0.1 -x 10.0.0.3 -- works # dig @127.0.0.1 -x 10.0.0.4 -- works Basically the first lookup works, the second ends up at IANA (as if the stub-zone configuration did not exist), and any following lookups work again. I have the same exact symptom, unbound.conf: server: interface: 127.0.0.1@53 interface: 10.10.10.1@53 verbosity: 1 do-not-query-localhost: no do-ip6: no auto-trust-anchor-file: /var/unbound/etc/root.key access-control: 0.0.0.0/0 refuse access-control: 127.0.0.0/8 allow access-control: 10.10.0.0/16 allow access-control: ::0/0 refuse access-control: ::1 allow hide-identity: yes hide-version: yes local-zone: 10.in-addr.arpa. nodefault stub-zone: name: 10.in-addr.arpa. stub-addr: 127.0.0.1@5353 # dig -p53 @127.0.0.1 -x 10.10.10.2 +short # works # dig -p53 @127.0.0.1 -x 10.10.10.1 +short # doesnt If I dig directly to nsd, via -p5353 # dig -p5353 @127.0.0.1 -x 10.10.10.2 +short # works # dig -p5353 @127.0.0.1 -x 10.10.10.1 +short # works I have no good explanation as to what's going on. I've tried this on current (as opposed to 5.5), and issue does NOT go away. On the NSD side, I have two zones zone: name: 10.10.10.in-addr.arpa. zonefile: db.10.10.10 zone: name: 11.10.10.in-addr.arpa. zonefile: db.10.10.11 Not that I can explain it, but for me it helped on the unbound side to: 1. switch the local-zone from nondefault to transparent 2. make the stub-zone: name: match the zone names in nsd, for you means, create two stub zones, for each of your zones you have in nsd. Sebastian
Re: unbound reverse DNS problem to local stub zone
On Sat, Jul 26, 2014 at 07:34:16PM +0200, Sebastian Reitenbach wrote: On Saturday, July 26, 2014 17:35 CEST, Sonic sonicsm...@gmail.com wrote: On Sat, Jul 26, 2014 at 11:21 AM, Sonic sonicsm...@gmail.com wrote: If you're just using a /24 as your access-control seems to indicate try replacing the above with (this works great for me): local-zone: 0.0.10.in-addr.arpa. transparent and update the stub-zone name to read: name: 0.0.10.in-addr.arpa. And, of course you NSD zone name must be: zone: name: 0.0.10.in-addr.arpa zonefile: 10.0.0.zone (although the zonefile doesn't have to strictly be named as such) I indeed only use a /24, so I changed as you suggested, and it seems to help. But the problem was not apparrent all the time, will monitor it, if it comes back with this new configuration, hope not. Anyways, I still find it odd, that it worked only halfway with the other configuration I had before, and a simple restart of unbound fixed it. My understanding is that transparent is used when you want to override certain records in a zone with local-data configured in unbound.conf. Given that you have no such things in the pasted configuration nodefault is probably a better choice. How is/was the reverse zone configured in nsd? I am currently trying to debug an issue i've seen when the stub-zone in unbound is wider (name: 10.in-addr.arpa) than the zone in nsd (name: 0.0.10.in-addr.arpa). To me the following is seen: # dig @127.0.0.1 -x 10.0.0.1 -- works # dig @127.0.0.1 -x 10.0.0.2 -- fails # dig @127.0.0.1 -x 10.0.0.3 -- works # dig @127.0.0.1 -x 10.0.0.4 -- works Basically the first lookup works, the second ends up at IANA (as if the stub-zone configuration did not exist), and any following lookups work again. It might be considered bad to tell unbound a server is authorative for a wider zone than it actually is though, can this be the same problem you saw? Regards, Patrik Lundin
Re: unbound reverse DNS problem to local stub zone
On Sunday, July 27, 2014 11:20 CEST, Patrik Lundin patrik.lundin@gmail.com wrote: On Sat, Jul 26, 2014 at 07:34:16PM +0200, Sebastian Reitenbach wrote: On Saturday, July 26, 2014 17:35 CEST, Sonic sonicsm...@gmail.com wrote: On Sat, Jul 26, 2014 at 11:21 AM, Sonic sonicsm...@gmail.com wrote: If you're just using a /24 as your access-control seems to indicate try replacing the above with (this works great for me): local-zone: 0.0.10.in-addr.arpa. transparent and update the stub-zone name to read: name: 0.0.10.in-addr.arpa. And, of course you NSD zone name must be: zone: name: 0.0.10.in-addr.arpa zonefile: 10.0.0.zone (although the zonefile doesn't have to strictly be named as such) I indeed only use a /24, so I changed as you suggested, and it seems to help. But the problem was not apparrent all the time, will monitor it, if it comes back with this new configuration, hope not. Anyways, I still find it odd, that it worked only halfway with the other configuration I had before, and a simple restart of unbound fixed it. My understanding is that transparent is used when you want to override certain records in a zone with local-data configured in unbound.conf. Given that you have no such things in the pasted configuration nodefault is probably a better choice. How is/was the reverse zone configured in nsd? I am currently trying to debug an issue i've seen when the stub-zone in unbound is wider (name: 10.in-addr.arpa) than the zone in nsd (name: 0.0.10.in-addr.arpa). To me the following is seen: # dig @127.0.0.1 -x 10.0.0.1 -- works # dig @127.0.0.1 -x 10.0.0.2 -- fails # dig @127.0.0.1 -x 10.0.0.3 -- works # dig @127.0.0.1 -x 10.0.0.4 -- works Basically the first lookup works, the second ends up at IANA (as if the stub-zone configuration did not exist), and any following lookups work again. It might be considered bad to tell unbound a server is authorative for a wider zone than it actually is though, can this be the same problem you saw? Yes, I think that's how I had it too, but with nodefault instead of transparent. For the requests that failed, I've seen requests going out to the root DNS servers trying to resolve my private IPs. In unbound, I only had the 10.in-addr.arpa and in nsd I have 0.0.10.in-addr.arpa. I only had to change unbound configuration as suggested, which up to now seems to work reliable. And when you restart unbound, then dig for 10.0.0.2 might start working, and digging others may fail. IIRC, after a restart, the first one or two reverse records I looked up, then worked as expected, others then started to fail, that worked before. Only very seldomly, all reverse lookups worked after a restart of unbound. Sebastian Regards, Patrik Lundin
Re: unbound reverse DNS problem to local stub zone
On Sun, Jul 27, 2014 at 5:20 AM, Patrik Lundin patrik.lundin@gmail.com wrote: My understanding is that transparent is used when you want to override certain records in a zone with local-data configured in unbound.conf. Given that you have no such things in the pasted configuration nodefault is probably a better choice. From the man page: You can also selectively unblock a part of the zone by making that part transparent with a local-zone statement. This also works with the other default zones. So if you're prepared to answer queries for all of 10.0.0.0/8 maybe nodefault may be correct, and your stub-zone should be prepared to do so. But if you want to only answer queries for part of that default zone then transparent is the proper choice. I've been running unbound for years on 7 different servers using transparent as I've outlined and it has worked flawlessly. Chris
Re: unbound reverse DNS problem to local stub zone
On Sun, Jul 27, 2014 at 10:42:57AM -0400, Sonic wrote: From the man page: You can also selectively unblock a part of the zone by making that part transparent with a local-zone statement. This also works with the other default zones. Ah, nice catch! So if you're prepared to answer queries for all of 10.0.0.0/8 maybe nodefault may be correct, and your stub-zone should be prepared to do so. But if you want to only answer queries for part of that default zone then transparent is the proper choice. I was not aware this was the case, but testing proves you right. Thanks for setting me straight :). Regards, Patrik Lundin
Re: unbound reverse DNS problem to local stub zone
On Sun, Jul 27, 2014 at 12:27:54PM +0200, Sebastian Reitenbach wrote: My understanding is that transparent is used when you want to override certain records in a zone with local-data configured in unbound.conf. Given that you have no such things in the pasted configuration nodefault is probably a better choice. Disregard the above, using transparent as Chris suggested is the way to go when only unlocking part of a RFC1918 reverse zone. In unbound, I only had the 10.in-addr.arpa and in nsd I have 0.0.10.in-addr.arpa. I only had to change unbound configuration as suggested, which up to now seems to work reliable. Yeah, when the zone names match in both unbound and nsd i have seen no problems either. And when you restart unbound, then dig for 10.0.0.2 might start working, and digging others may fail. IIRC, after a restart, the first one or two reverse records I looked up, then worked as expected, others then started to fail, that worked before. Only very seldomly, all reverse lookups worked after a restart of unbound. To be clear, the order of the records did not matter, but the pattern was always the same: the first lookup after unbound started would work, the second would end up at IANA and and following lookups would work again. My current theory is that it is caching related, so im guessing if you had this running for a while the issue could walk around as the cache expired etc. But I am still unsure if this is actually a bug or if it is just undefined behaviour from doing silly things with stub-zones. The silly thing being telling unbound the server was authorative for a zone that was actually outside the zone apex of the authorative data. Regards, Patrik Lundin
Re: unbound reverse DNS problem to local stub zone
Following up on this thread given the mention it got in the recent unbound question: On Sat, May 17, 2014 at 08:04:32PM +0200, Sebastian Reitenbach wrote: # the stub zones I want to resolve via nsd on localhost stub-zone: name: ds9 stub-addr: 127.0.0.1@5353 stub-zone: name: 10.in-addr.arpa. stub-addr: 127.0.0.1@5353 My first reaction was that the first zone had no terminating . while the in-addr.arpa one had it. Not sure this makes a difference, just thought i should point it out. However, after a reboot of the box, reverse lookup of any of the configured 10.0.0.X addresses fails. When I restart unbound, then it just works as expected. This indeed looks strange, could you retry this using dig(1) instead of nslookup? I am not comfortable with that tool and it's use is discouraged because it can end up doing funky things (see http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/nslookup-flaws.html). I have about 30 hosts in that reverse zone configured. The more often I restart unbound, the better it gets with returning results. However, when I reboot the machine, then other lookups that worked before might fail, and vice versa, others may work, I cannot see a pattern. I agree this sounds very strange. Looking at the unbound logs, I see a large amounts of trying to connect to NSD, and it also gets answers of type THROWAWAY, until unbound then decides to ask the root servers. Could you share some of those logs? Using ktrace(1) might also be useful for investigating what is going on (difference in working and not working lookup for example). Is maybe my box (soekris net5501) too slow, so that NSD doesn't answer fast enough? Then, after some restarts of unbound, and queries to NSD, then NSD has all in memory and then it just works? But then I don't understand why it works without flaws for the forward zone, and also the IPv6 zone? Seems far fetched to me. Regards, Patrik Lundin
Re: unbound reverse DNS problem to local stub zone
On Sat, May 17, 2014 at 2:04 PM, Sebastian Reitenbach sebas...@l00-bugdead-prods.de wrote: local-zone: 10.in-addr.arpa. nodefault If you're just using a /24 as your access-control seems to indicate try replacing the above with (this works great for me): local-zone: 0.0.10.in-addr.arpa. transparent and update the stub-zone name to read: name: 0.0.10.in-addr.arpa.
Re: unbound reverse DNS problem to local stub zone
On Sat, Jul 26, 2014 at 11:21 AM, Sonic sonicsm...@gmail.com wrote: If you're just using a /24 as your access-control seems to indicate try replacing the above with (this works great for me): local-zone: 0.0.10.in-addr.arpa. transparent and update the stub-zone name to read: name: 0.0.10.in-addr.arpa. And, of course you NSD zone name must be: zone: name: 0.0.10.in-addr.arpa zonefile: 10.0.0.zone (although the zonefile doesn't have to strictly be named as such)
Re: unbound reverse DNS problem to local stub zone
On Saturday, July 26, 2014 17:35 CEST, Sonic sonicsm...@gmail.com wrote: On Sat, Jul 26, 2014 at 11:21 AM, Sonic sonicsm...@gmail.com wrote: If you're just using a /24 as your access-control seems to indicate try replacing the above with (this works great for me): local-zone: 0.0.10.in-addr.arpa. transparent and update the stub-zone name to read: name: 0.0.10.in-addr.arpa. And, of course you NSD zone name must be: zone: name: 0.0.10.in-addr.arpa zonefile: 10.0.0.zone (although the zonefile doesn't have to strictly be named as such) I indeed only use a /24, so I changed as you suggested, and it seems to help. But the problem was not apparrent all the time, will monitor it, if it comes back with this new configuration, hope not. Anyways, I still find it odd, that it worked only halfway with the other configuration I had before, and a simple restart of unbound fixed it. thanks, Sebastian
unbound reverse DNS problem to local stub zone
Hi, I'm new to nsd/unbound, and maybe I did something wrong, however: I run i386 snapshot, with nsd/unbound on the same host. NSD listening on port 5353 is authoritative for 1 forward zone, and two reverse zones, one IPv4 private addresses, and another IPv6 zone. The forward zone, and the reverse IPv6 zone, there is no problem. My unbound config, with the IPv6 zone removed, looks like this: server: #interface: 127.0.0.1 #interface: 127.0.0.1@5353 # listen on alternative port #interface: ::1 # want to listen on all interfaces interface: 0.0.0.0 interface: ::0 #do-ip6: no # needed to query nsd on localhost for authoritative answers do-not-query-localhost: no # want to allow queries from local subnet and localhost access-control: 0.0.0.0/0 refuse access-control: 127.0.0.0/8 allow access-control: 10.0.0.0/24 allow access-control: ::0/0 refuse access-control: ::1 allow hide-identity: yes hide-version: yes # Uncomment to enable DNSSEC validation. # #auto-trust-anchor-file: /var/unbound/db/root.key # Serve zones authoritatively from Unbound to resolver clients. # Not for external service. # #local-zone: local. static #local-data: mycomputer.local. IN A 192.0.2.51 # needed to allow resolving of private IP addresses local-zone: 10.in-addr.arpa. nodefault #local-data-ptr: 192.0.2.51 mycomputer.local # UDP EDNS reassembly buffer advertised to peers. Default 4096. # May need lowering on broken networks with fragmentation/MTU issues, # particularly if validating DNSSEC. # #edns-buffer-size: 1480 # Use TCP for forward-zone requests. Useful if you are making # DNS requests over an SSH port forwarding. # #tcp-upstream: yes # the stub zones I want to resolve via nsd on localhost stub-zone: name: ds9 stub-addr: 127.0.0.1@5353 stub-zone: name: 10.in-addr.arpa. stub-addr: 127.0.0.1@5353 However, after a reboot of the box, reverse lookup of any of the configured 10.0.0.X addresses fails. When I restart unbound, then it just works as expected. sebastia@wormhole:~/bin nslookup 10.0.0.27 Server: 127.0.0.1 Address:127.0.0.1#53 ** server can't find 27.0.0.10.in-addr.arpa.: NXDOMAIN sebastia@wormhole:~/bin sudo /etc/rc.d/unbound restart unbound(ok) unbound(ok) sebastia@wormhole:~/bin nslookup 10.0.0.27 Server: 127.0.0.1 Address:127.0.0.1#53 Non-authoritative answer: 27.0.0.10.in-addr.arpa name = wormhole.ds9. Authoritative answers can be found from: 0.0.10.in-addr.arpa nameserver = wormhole.ds9. sebastia@wormhole:~ nslookup 10.0.0.37 Server: 127.0.0.1 Address:127.0.0.1#53 ** server can't find 37.0.0.10.in-addr.arpa.: NXDOMAIN sebastia@wormhole:~ nslookup 10.0.0.27 sebastia@wormhole:~ sudo /etc/rc.d/unbound restart unbound(ok) unbound(ok) sebastia@wormhole:~ nslookup 10.0.0.37 Server: 127.0.0.1 Address:127.0.0.1#53 Non-authoritative answer: 37.0.0.10.in-addr.arpa name = communicator.ds9. Authoritative answers can be found from: 0.0.10.in-addr.arpa nameserver = wormhole.ds9. sebastia@wormhole:~ I have about 30 hosts in that reverse zone configured. The more often I restart unbound, the better it gets with returning results. However, when I reboot the machine, then other lookups that worked before might fail, and vice versa, others may work, I cannot see a pattern. Looking at the unbound logs, I see a large amounts of trying to connect to NSD, and it also gets answers of type THROWAWAY, until unbound then decides to ask the root servers. Is maybe my box (soekris net5501) too slow, so that NSD doesn't answer fast enough? Then, after some restarts of unbound, and queries to NSD, then NSD has all in memory and then it just works? But then I don't understand why it works without flaws for the forward zone, and also the IPv6 zone? Someone has an idea? Sebastian OpenBSD 5.5-current (GENERIC) #112: Fri May 16 17:59:07 MDT 2014 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD 586-class) 500 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW real mem = 536375296 (511MB) avail mem = 515190784 (491MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 20/80/26, BIOS32 rev. 0 @ 0xfac40 pcibios0 at bios0: rev 2.0 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing -
Re: DNS problem
On Fri, Dec 06, 2013 at 08:35:52PM +0100, Patrik Lundin wrote: Given the +trace output you supplied that address is not part of the trail from the DNS root, and in that case the only involvement is answering the initial equivalent of dig @216.146.35.35 . NS. For the archives: That should have been dig +norecurse @216.146.35.35 . NS since recursion is disabled when +trace is used. Regards, Patrik Lundin
Re: DNS problem
Turns out the problem was with the Internet Guide service. If the IP address from which the query was sent was on the subscriber list then the incorrect info was sent. That's why it worked from one of my networks but not the others. Thanks to all. Chris
DNS problem
This falls under the category When in doubt, ask the OpenBSD guys (and as all of my firewalls are running OpenBSD I hope this isn't too off topic). Basically, four of my networks are not getting an answer for a specific mx query from dyn.com's DNS server. Yet every other DNS cache I've queried works just fine (Google, Level3, Hurricane Electric, Comcast, etc.) and dyn's support claims there is no problem on their end and all of their tests return the proper answer just as one of my networks does. Results from the four non-working networks (two are on Comcast, one is ATT): = dig @216.146.35.35 lwtitle.com mx ; DiG 9.4.2-P2 @216.146.35.35 lwtitle.com mx ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 5502 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;lwtitle.com. IN MX ;; Query time: 29 msec ;; SERVER: 216.146.35.35#53(216.146.35.35) ;; WHEN: Fri Dec 6 11:18:05 2013 ;; MSG SIZE rcvd: 29 = Consequently mail fails to get sent to the lwtitle.com domain. I should note that if I dig with +trace the proper answer does show up: = dig @216.146.35.35 lwtitle.com mx +trace ; DiG 9.4.2-P2 @216.146.35.35 lwtitle.com mx +trace ; (1 server found) ;; global options: printcmd . 518400 IN NS a.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS m.root-servers.net. ;; Received 228 bytes from 216.146.35.35#53(216.146.35.35) in 34 ms com.172800 IN NS j.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. com.172800 IN NS h.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS l.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. com.172800 IN NS a.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS d.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. ;; Received 489 bytes from 202.12.27.33#53(m.root-servers.net) in 116 ms lwtitle.com.172800 IN NS ns21.domaincontrol.com. lwtitle.com.172800 IN NS ns22.domaincontrol.com. ;; Received 113 bytes from 192.12.94.30#53(e.gtld-servers.net) in 115 ms lwtitle.com.3600IN MX 0 lwtitle-com.mail.protection.outlook.com. lwtitle.com.3600IN NS ns22.domaincontrol.com. lwtitle.com.3600IN NS ns21.domaincontrol.com. ;; Received 133 bytes from 208.109.255.11#53(ns22.domaincontrol.com) in 32 ms = Although this doesn't help normal resolution. So I'm baffled. Any clues? Thanks, Chris
Re: DNS problem
Chris Smith obsd_m...@chrissmith.org writes: Basically, four of my networks are not getting an answer for a specific mx query from dyn.com's DNS server. but, say $ dig @216.146.35.35 bsdly.net mx works? Or do you get no answer for any queries? - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: DNS problem
On Fri, Dec 6, 2013 at 11:54 AM, Peter N. M. Hansteen pe...@bsdly.net wrote: but, say $ dig @216.146.35.35 bsdly.net mx works? Or do you get no answer for any queries? It's just that one particular query and the same domain's TXT record. There may be others but this one was found because one of my clients needed to email that company. All other queries seem to work - even the A record for that domain. And yet from one of the 4 networks I do work for the query works just fine.
Re: DNS problem
Em 06-12-2013 14:31, Chris Smith escreveu: This falls under the category When in doubt, ask the OpenBSD guys (and as all of my firewalls are running OpenBSD I hope this isn't too off topic). Basically, four of my networks are not getting an answer for a specific mx query from dyn.com's DNS server. Yet every other DNS cache I've queried works just fine (Google, Level3, Hurricane Electric, Comcast, etc.) and dyn's support claims there is no problem on their end and all of their tests return the proper answer just as one of my networks does. Results from the four non-working networks (two are on Comcast, one is ATT): = dig @216.146.35.35 lwtitle.com mx ; DiG 9.4.2-P2 @216.146.35.35 lwtitle.com mx ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 5502 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;lwtitle.com. IN MX ;; Query time: 29 msec ;; SERVER: 216.146.35.35#53(216.146.35.35) ;; WHEN: Fri Dec 6 11:18:05 2013 ;; MSG SIZE rcvd: 29 = Consequently mail fails to get sent to the lwtitle.com domain. I should note that if I dig with +trace the proper answer does show up: = dig @216.146.35.35 lwtitle.com mx +trace ; DiG 9.4.2-P2 @216.146.35.35 lwtitle.com mx +trace ; (1 server found) ;; global options: printcmd . 518400 IN NS a.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS m.root-servers.net. ;; Received 228 bytes from 216.146.35.35#53(216.146.35.35) in 34 ms com.172800 IN NS j.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. com.172800 IN NS h.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS l.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. com.172800 IN NS a.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS d.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. ;; Received 489 bytes from 202.12.27.33#53(m.root-servers.net) in 116 ms lwtitle.com.172800 IN NS ns21.domaincontrol.com. lwtitle.com.172800 IN NS ns22.domaincontrol.com. ;; Received 113 bytes from 192.12.94.30#53(e.gtld-servers.net) in 115 ms lwtitle.com.3600IN MX 0 lwtitle-com.mail.protection.outlook.com. lwtitle.com.3600IN NS ns22.domaincontrol.com. lwtitle.com.3600IN NS ns21.domaincontrol.com. ;; Received 133 bytes from 208.109.255.11#53(ns22.domaincontrol.com) in 32 ms = Although this doesn't help normal resolution. So I'm baffled. Any clues? Thanks, Chris Chris, I do not know if it is the case, but many isp's today use dns transparent proxying. That is, even if you're not using their provided dns servers, they intercept your dns connection, and they do all sort of nasty things with it, ranging from displaying ad pages for mistyped domains, to recording every dns query you make. You can try using the site www.dnsleaktest.com to see if it is your case. If it is, I suggest you to use the dnscrypt proxy, which is a implementation of dnscurve, that was made by opendns. By default it uses the opendns server, but there are others servers enabled for it and you can use one of your servers too. Try this and see if it improves your situation. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: DNS problem
On Fri, Dec 6, 2013 at 12:07 PM, Giancarlo Razzolini grazzol...@gmail.com wrote: I do not know if it is the case, but many isp's today use dns transparent proxying. You can try using the site www.dnsleaktest.com to see if it is your case. The lwtitle.com mx and lwtitle.com txt queries both fail for me here and I run unbound as a resolver on my firewall and I pass the DNS leak test. The one network of the 4 that I do get a proper answer on has an older version of OpenBSD on its firewall (4.9) while all the ones that are failing for me run a fairly current (or even -current) version. And if my ISP, and a couple of the others, were doing dns proxy and that was messing up the results it would surely mess them up for all of the DNS caches I tested. = dig @216.146.35.35 lwtitle.com mx +noall +answer ; DiG 9.4.2-P2 @216.146.35.35 lwtitle.com mx +noall +answer ; (1 server found) ;; global options: printcmd = dig @8.8.8.8 lwtitle.com mx +noall +answer ; DiG 9.4.2-P2 @8.8.8.8 lwtitle.com mx +noall +answer ; (1 server found) ;; global options: printcmd lwtitle.com.3600IN MX 0 lwtitle-com.mail.protection.outlook.com. = dig @209.244.0.3 lwtitle.com mx +noall +answer ; DiG 9.4.2-P2 @209.244.0.3 lwtitle.com mx +noall +answer ; (1 server found) ;; global options: printcmd lwtitle.com.3600IN MX 0 lwtitle-com.mail.protection.outlook.com. = dig @198.153.192.40 lwtitle.com mx +noall +answer ; DiG 9.4.2-P2 @198.153.192.40 lwtitle.com mx +noall +answer ; (1 server found) ;; global options: printcmd lwtitle.com.3600IN MX 0 lwtitle-com.mail.protection.outlook.com. = etc. Only those specific queries from some places to dyn's internet guide fail. From the network running 4.9: = dig @216.146.35.35 lwtitle.com mx +noall +answer ; DiG 9.4.2-P2 @216.146.35.35 lwtitle.com mx +noall +answer ; (1 server found) ;; global options: printcmd lwtitle.com.2181IN MX 0 lwtitle-com.mail.protection.outlook.com. = -- Chris
Re: DNS problem
Em 06-12-2013 15:42, Chris Smith escreveu: The lwtitle.com mx and lwtitle.com txt queries both fail for me here and I run unbound as a resolver on my firewall and I pass the DNS leak test. The dns leaktest only detects if the provider is actively redirecting your queries to their caching resolvers. And if even so, who is to say that they are detecting your dnsleaktest attempt and they do not try to resolve it, so your test pass, but when you query another domain they intercept it? I know it does sound too of a conspiracy theory, but these days post snowden, who can assure anything? The one network of the 4 that I do get a proper answer on has an older version of OpenBSD on its firewall (4.9) while all the ones that are failing for me run a fairly current (or even -current) version. And if my ISP, and a couple of the others, were doing dns proxy and that was messing up the results it would surely mess them up for all of the DNS caches I tested. As I said above, this is not necessarily true, they could be messing only some domains, although it is very unlikely. This seems to me a problem with the other end, even when they told you everything is ok with them. Anyway, it won't hurt if you use dnscrypt proxy. -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: DNS problem
On Fri, Dec 06, 2013 at 12:42:09PM -0500, Chris Smith wrote: The lwtitle.com mx and lwtitle.com txt queries both fail for me here and I run unbound as a resolver on my firewall and I pass the DNS leak test. Just out of curiosity: If you are running unbound on the firewall, why are you querying the troublesome resolver directly? Do you get the same result when querying the local unbound? The one network of the 4 that I do get a proper answer on has an older version of OpenBSD on its firewall (4.9) while all the ones that are failing for me run a fairly current (or even -current) version. Are you running dig from the firewall or a client behind the firewall? How about tcpdumping the traffic on all affected interfaces and comparing the results between the working location and a non-working one in order to see if anything funky is happening on the wire? Regards, Patrik Lundin
Re: DNS problem
On Fri, Dec 6, 2013 at 1:38 PM, Patrik Lundin patrik.lundin@gmail.com wrote: Just out of curiosity: If you are running unbound on the firewall, why are you querying the troublesome resolver directly? Do you get the same result when querying the local unbound? Same results from Unbound. That's why I started digging. Are you running dig from the firewall or a client behind the firewall? Have done both. Same results with NLNet's drill utility as well. How about tcpdumping the traffic on all affected interfaces and comparing the results between the working location and a non-working one in order to see if anything funky is happening on the wire? I did that also. I see nothing funky. One packet sent, one returned.
Re: DNS problem
On Fri, Dec 06, 2013 at 01:50:33PM -0500, Chris Smith wrote: Same results from Unbound. That's why I started digging. Sorry if I'm missing something, but what lead you to suspect the 216.146.35.35 machine in the first place? Given the +trace output you supplied that address is not part of the trail from the DNS root, and in that case the only involvement is answering the initial equivalent of dig @216.146.35.35 . NS. Regards, Patrik Lundin
Re: DNS problem
On Fri, Dec 6, 2013 at 2:35 PM, Patrik Lundin patrik.lundin@gmail.com wrote: Sorry if I'm missing something, but what lead you to suspect the 216.146.35.35 machine in the first place? Some of my clients use that service and for them Unbound doesn't act as a validator, just an iterator that forwards non-local queries to Dyn's Internet Guide service. Chris
Re: DNS problem
Thus said Chris Smith on Fri, 06 Dec 2013 11:31:23 -0500: Basically, four of my networks are not getting an answer for a specific mx query from dyn.com's DNS server. Yet every other DNS cache I've queried works just fine (Google, Level3, Hurricane Electric, Comcast, etc.) and dyn's support claims there is no problem on their end and all of their tests return the proper answer just as one of my networks does. Seems dyn might be doing a transparent load balancing proxy for their DNS; what else could account for the strange TTL jumping around below? Perhaps they have a bad server in the pool that you just happen to hit consistently due to some hashing. Notice the first query is 3600 (normal given that is the TTL). The second query shows it took me 3 seconds to issue the query again. But the third shows a sudden jump in time of almost 5 minutes. $ env DNSCACHEIP=216.146.35.35 dnsqr mx lwtitle.com 15 lwtitle.com: 133 bytes, 1+1+2+0 records, response, noerror query: 15 lwtitle.com answer: lwtitle.com 3600 MX 0 lwtitle-com.mail.protection.outlook.com authority: lwtitle.com 3600 NS ns22.domaincontrol.com authority: lwtitle.com 3600 NS ns21.domaincontrol.com $ env DNSCACHEIP=216.146.35.35 dnsqr mx lwtitle.com 15 lwtitle.com: 133 bytes, 1+1+2+0 records, response, noerror query: 15 lwtitle.com answer: lwtitle.com 3597 MX 0 lwtitle-com.mail.protection.outlook.com authority: lwtitle.com 3597 NS ns22.domaincontrol.com authority: lwtitle.com 3597 NS ns21.domaincontrol.com $ env DNSCACHEIP=216.146.35.35 dnsqr mx lwtitle.com 15 lwtitle.com: 133 bytes, 1+1+2+0 records, response, noerror query: 15 lwtitle.com answer: lwtitle.com 3350 MX 0 lwtitle-com.mail.protection.outlook.com authority: lwtitle.com 3350 NS ns22.domaincontrol.com authority: lwtitle.com 3350 NS ns21.domaincontrol.com Then a few more seconds passed and I see: $ env DNSCACHEIP=216.146.35.35 dnsqr mx lwtitle.com 15 lwtitle.com: 133 bytes, 1+1+2+0 records, response, noerror query: 15 lwtitle.com answer: lwtitle.com 3095 MX 0 lwtitle-com.mail.protection.outlook.com authority: lwtitle.com 3095 NS ns22.domaincontrol.com authority: lwtitle.com 3095 NS ns21.domaincontrol.com $ env DNSCACHEIP=216.146.35.35 dnsqr mx lwtitle.com 15 lwtitle.com: 133 bytes, 1+1+2+0 records, response, noerror query: 15 lwtitle.com answer: lwtitle.com 3331 MX 0 lwtitle-com.mail.protection.outlook.com authority: lwtitle.com 3331 NS ns22.domaincontrol.com authority: lwtitle.com 3331 NS ns21.domaincontrol.com Has anything changed recently with the NS records for lwtitle.com? Do you get the same results if you query one of the other well known public DNS resolvers like 8.8.8.8? Andy -- TAI64 timestamp: 400052a25f91
Re: Can't get relayd to work for DNS + problem with relayctl reload
Hello Pierre,
I noticed the same behavior on my box with current before I read this
thread. That's why I sent a bug report: 6046/system
(http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yesnumbers=6046).
Regards Uwe
Am Wed, 14 Jan 2009 15:53:50 +0100
schrieb BARDOU Pierre bardo...@mipih.fr:
Hi,
I tried to send a bug report with sendbug(1), but I am not very
familiar with it.
I hope someone will notice...
--
Cordialement,
Pierre BARDOU
De : uday [mailto:umoorjani@gmail.com]
Envoyi : mercredi 14 janvier 2009 15:52
@ : BARDOU Pierre
Cc : misc@openbsd.org; Nigel J. Taylor
Objet : Re: Can't get relayd to work for DNS + problem with relayctl
reload
pierre,
i'm seeing the same result with relayctl i don't know where it's
coming from.
um
On Wed, Jan 14, 2009 at 8:16 AM, BARDOU Pierre bardo...@mipih.fr
wrote:
Shame on me, it didn't worked because I allowed connexion to the real
IP (10.60.0.10x) and no to relayd IP (10.31.33.254).
Now it works, thanks for the help :)
But I still have the issue I reported a few monthes ago : when I use
a relay, relayctl reload fails saying command failed.
The relayd logs says nothing. Will I be forced to pkill relayd and
restart it each time ?
--
Cordialement,
Pierre BARDOU
-Message d'origine-
De : Nigel J. Taylor [mailto:njtay...@asterisk.demon.co.uk]
Envoyi : mercredi 14 janvier 2009 02:22
@ : BARDOU Pierre
Objet : Re: Can't get relayd to work for DNS
I have this in my relayd.conf, it's just an extract, only a pass in
in pf.conf
you use either relay or redirect not both at once redirect requires
an anchor in
pf.conf, relay doesn't.
dns protocol dnsudp
tcp protocol dnstcp
relay relaydnsudp {
protocol dnsudp
listen on $dns_int port domain
forward to DNSSERVERS \
check script /usr/local/bin/dnscheck
}
relay relaydnstcp {
protocol dnstcp
listen on $dns_int port domain
forward to DNSSERVERS \
check script /usr/local/bin/dnscheck
}
dnscheck script does a dig to check dns is up
#!/bin/ksh
dnsserver=$1
if ping -n -c1 -w 1 $dnsserver /dev/null 21 dig -x \
$dnsserver @$dnsserver /dev/null
then
exit 1
fi
exit 0
Regards
Nigel Taylor
BARDOU Pierre wrote:
Hello,
I am trying to setup relayd for loadbalancing on my DNS servers.
The problem is that relayd seems to handle only TCP connexions, UDP
isn't taken into account.
I found a known bug on openBSD 4.2, but I am using openBSD 4.4.
I've tried the same setup with a relay, and still have the same
problem.
Where am I mistaking ?
# pfctl -a relayd/DNS -s nat
rdr inet proto tcp from any to 10.31.33.254 port = domain
(tcp.established 600) - DNS port 53 round-robin
# cat /etc/relayd.conf
node1=10.60.0.101
node2=10.60.0.102
node3=10.60.0.103
squid_int=10.31.33.254
dns_int=10.31.33.254
# Global Options
interval 5
log updates
prefork 10
timeout 1500
table squid { $node1 , $node3 }
table DNS { $node1 , $node3 }
redirect squid {
listen on $squid_int port 3128
forward to squid mode roundrobin check tcp
}
redirect DNS {
listen on $dns_int port 53
forward to DNS mode roundrobin check tcp
}
Relay config :
dns protocol dnsfilter {
### TCP performance options
tcp { nodelay, sack, socket buffer 1024, backlog 1000 }
}
relay dns {
### listen and accept redirected connections from pf
listen on $dns_int port 53
### apply web filters
protocol dnsfilter
### forward to web server(s)
forward to DNS mode roundrobin check tcp
}
--
Cordialement,
Pierre BARDOU
CSIM - Bureau 012
Midi Picardie Informatique Hospitalihre
12 rue Michel Labrousse
BP93668
F-31036 Toulouse CEDEX 1
Til : 05 67 31 90 84
Fax : 05 34 61 51 00
Mail : bardo...@mipih.fr
--
Mit freundlichen Gruessen
Uwe Werler
OB3SI
Open Source Software Solution Integration
Hosterwitzer Str. 15
D-01259 Dresden
Fon +49 351 41722902
http://www.o3si.de
mailto:i...@o3si.de
Sitz des Unternehmens: 01259 Dresden
Der Austausch von Nachrichten mit OB3SI via E-Mail dient ausschliesslich
Informationszwecken. RechtsgeschC$ftliche ErklC$rungen dCrfen auC erhalb
gesonderter Vereinbarungen Cber dieses Medium nicht ausgetauscht werden.
Angebote jeglicher Art verstehen sich freibleibend und unterliegen den
allgemeinen GeschC$ftsbedingungen.
This message is not intended to be relied upon without subsequent
written confirmation of its contents OB3SI therefore cannot accept any
liability of any kind which may arise from any person either acting
upon the contents of the message without having had written
confirmation. Any opinions expressed in the e-mail are those of the
individual writer and not necessarily those of the Company unless
specifically stated otherwise.
This e-mail and any files transmitted with it are private and
confidential and are solely
Re: Can't get relayd to work for DNS + problem with relayctl reload
Shame on me, it didn't worked because I allowed connexion to the real IP
(10.60.0.10x) and no to relayd IP (10.31.33.254).
Now it works, thanks for the help :)
But I still have the issue I reported a few monthes ago : when I use a relay,
relayctl reload fails saying command failed.
The relayd logs says nothing. Will I be forced to pkill relayd and restart it
each time ?
--
Cordialement,
Pierre BARDOU
-Message d'origine-
De : Nigel J. Taylor [mailto:njtay...@asterisk.demon.co.uk]
Envoyi : mercredi 14 janvier 2009 02:22
@ : BARDOU Pierre
Objet : Re: Can't get relayd to work for DNS
I have this in my relayd.conf, it's just an extract, only a pass in in
pf.conf
you use either relay or redirect not both at once redirect requires an anchor
in
pf.conf, relay doesn't.
dns protocol dnsudp
tcp protocol dnstcp
relay relaydnsudp {
protocol dnsudp
listen on $dns_int port domain
forward to DNSSERVERS \
check script /usr/local/bin/dnscheck
}
relay relaydnstcp {
protocol dnstcp
listen on $dns_int port domain
forward to DNSSERVERS \
check script /usr/local/bin/dnscheck
}
dnscheck script does a dig to check dns is up
#!/bin/ksh
dnsserver=$1
if ping -n -c1 -w 1 $dnsserver /dev/null 21 dig -x \
$dnsserver @$dnsserver /dev/null
then
exit 1
fi
exit 0
Regards
Nigel Taylor
BARDOU Pierre wrote:
Hello,
I am trying to setup relayd for loadbalancing on my DNS servers.
The problem is that relayd seems to handle only TCP connexions, UDP isn't
taken into account.
I found a known bug on openBSD 4.2, but I am using openBSD 4.4.
I've tried the same setup with a relay, and still have the same problem.
Where am I mistaking ?
# pfctl -a relayd/DNS -s nat
rdr inet proto tcp from any to 10.31.33.254 port = domain (tcp.established
600) - DNS port 53 round-robin
# cat /etc/relayd.conf
node1=10.60.0.101
node2=10.60.0.102
node3=10.60.0.103
squid_int=10.31.33.254
dns_int=10.31.33.254
# Global Options
interval 5
log updates
prefork 10
timeout 1500
table squid { $node1 , $node3 }
table DNS { $node1 , $node3 }
redirect squid {
listen on $squid_int port 3128
forward to squid mode roundrobin check tcp
}
redirect DNS {
listen on $dns_int port 53
forward to DNS mode roundrobin check tcp
}
Relay config :
dns protocol dnsfilter {
### TCP performance options
tcp { nodelay, sack, socket buffer 1024, backlog 1000 }
}
relay dns {
### listen and accept redirected connections from pf
listen on $dns_int port 53
### apply web filters
protocol dnsfilter
### forward to web server(s)
forward to DNS mode roundrobin check tcp
}
--
Cordialement,
Pierre BARDOU
CSIM - Bureau 012
Midi Picardie Informatique Hospitalihre
12 rue Michel Labrousse
BP93668
F-31036 Toulouse CEDEX 1
Til : 05 67 31 90 84
Fax : 05 34 61 51 00
Mail : bardo...@mipih.fr
Re: Can't get relayd to work for DNS + problem with relayctl reload
Hi,
I tried to send a bug report with sendbug(1), but I am not very familiar with
it.
I hope someone will notice...
--
Cordialement,
Pierre BARDOU
De : uday [mailto:umoorjani@gmail.com]
Envoyi : mercredi 14 janvier 2009 15:52
@ : BARDOU Pierre
Cc : misc@openbsd.org; Nigel J. Taylor
Objet : Re: Can't get relayd to work for DNS + problem with relayctl reload
pierre,
i'm seeing the same result with relayctl i don't know where it's coming from.
um
On Wed, Jan 14, 2009 at 8:16 AM, BARDOU Pierre bardo...@mipih.fr wrote:
Shame on me, it didn't worked because I allowed connexion to the real IP
(10.60.0.10x) and no to relayd IP (10.31.33.254).
Now it works, thanks for the help :)
But I still have the issue I reported a few monthes ago : when I use a relay,
relayctl reload fails saying command failed.
The relayd logs says nothing. Will I be forced to pkill relayd and restart it
each time ?
--
Cordialement,
Pierre BARDOU
-Message d'origine-
De : Nigel J. Taylor [mailto:njtay...@asterisk.demon.co.uk]
Envoyi : mercredi 14 janvier 2009 02:22
@ : BARDOU Pierre
Objet : Re: Can't get relayd to work for DNS
I have this in my relayd.conf, it's just an extract, only a pass in in
pf.conf
you use either relay or redirect not both at once redirect requires an anchor
in
pf.conf, relay doesn't.
dns protocol dnsudp
tcp protocol dnstcp
relay relaydnsudp {
protocol dnsudp
listen on $dns_int port domain
forward to DNSSERVERS \
check script /usr/local/bin/dnscheck
}
relay relaydnstcp {
protocol dnstcp
listen on $dns_int port domain
forward to DNSSERVERS \
check script /usr/local/bin/dnscheck
}
dnscheck script does a dig to check dns is up
#!/bin/ksh
dnsserver=$1
if ping -n -c1 -w 1 $dnsserver /dev/null 21 dig -x \
$dnsserver @$dnsserver /dev/null
then
exit 1
fi
exit 0
Regards
Nigel Taylor
BARDOU Pierre wrote:
Hello,
I am trying to setup relayd for loadbalancing on my DNS servers.
The problem is that relayd seems to handle only TCP connexions, UDP isn't
taken into account.
I found a known bug on openBSD 4.2, but I am using openBSD 4.4.
I've tried the same setup with a relay, and still have the same problem.
Where am I mistaking ?
# pfctl -a relayd/DNS -s nat
rdr inet proto tcp from any to 10.31.33.254 port = domain (tcp.established
600) - DNS port 53 round-robin
# cat /etc/relayd.conf
node1=10.60.0.101
node2=10.60.0.102
node3=10.60.0.103
squid_int=10.31.33.254
dns_int=10.31.33.254
# Global Options
interval 5
log updates
prefork 10
timeout 1500
table squid { $node1 , $node3 }
table DNS { $node1 , $node3 }
redirect squid {
listen on $squid_int port 3128
forward to squid mode roundrobin check tcp
}
redirect DNS {
listen on $dns_int port 53
forward to DNS mode roundrobin check tcp
}
Relay config :
dns protocol dnsfilter {
### TCP performance options
tcp { nodelay, sack, socket buffer 1024, backlog 1000 }
}
relay dns {
### listen and accept redirected connections from pf
listen on $dns_int port 53
### apply web filters
protocol dnsfilter
### forward to web server(s)
forward to DNS mode roundrobin check tcp
}
--
Cordialement,
Pierre BARDOU
CSIM - Bureau 012
Midi Picardie Informatique Hospitalihre
12 rue Michel Labrousse
BP93668
F-31036 Toulouse CEDEX 1
Til : 05 67 31 90 84
Fax : 05 34 61 51 00
Mail : bardo...@mipih.fr
Re: Can't get relayd to work for DNS + problem with relayctl reload
pierre,
i'm seeing the same result with relayctl i don't know where it's coming
from.
um
On Wed, Jan 14, 2009 at 8:16 AM, BARDOU Pierre bardo...@mipih.fr wrote:
Shame on me, it didn't worked because I allowed connexion to the real IP
(10.60.0.10x) and no to relayd IP (10.31.33.254).
Now it works, thanks for the help :)
But I still have the issue I reported a few monthes ago : when I use a
relay,
relayctl reload fails saying command failed.
The relayd logs says nothing. Will I be forced to pkill relayd and restart
it
each time ?
--
Cordialement,
Pierre BARDOU
-Message d'origine-
De : Nigel J. Taylor [mailto:njtay...@asterisk.demon.co.uk]
Envoyi : mercredi 14 janvier 2009 02:22
@ : BARDOU Pierre
Objet : Re: Can't get relayd to work for DNS
I have this in my relayd.conf, it's just an extract, only a pass in in
pf.conf
you use either relay or redirect not both at once redirect requires an
anchor
in
pf.conf, relay doesn't.
dns protocol dnsudp
tcp protocol dnstcp
relay relaydnsudp {
protocol dnsudp
listen on $dns_int port domain
forward to DNSSERVERS \
check script /usr/local/bin/dnscheck
}
relay relaydnstcp {
protocol dnstcp
listen on $dns_int port domain
forward to DNSSERVERS \
check script /usr/local/bin/dnscheck
}
dnscheck script does a dig to check dns is up
#!/bin/ksh
dnsserver=$1
if ping -n -c1 -w 1 $dnsserver /dev/null 21 dig -x \
$dnsserver @$dnsserver /dev/null
then
exit 1
fi
exit 0
Regards
Nigel Taylor
BARDOU Pierre wrote:
Hello,
I am trying to setup relayd for loadbalancing on my DNS servers.
The problem is that relayd seems to handle only TCP connexions, UDP isn't
taken into account.
I found a known bug on openBSD 4.2, but I am using openBSD 4.4.
I've tried the same setup with a relay, and still have the same problem.
Where am I mistaking ?
# pfctl -a relayd/DNS -s nat
rdr inet proto tcp from any to 10.31.33.254 port = domain
(tcp.established
600) - DNS port 53 round-robin
# cat /etc/relayd.conf
node1=10.60.0.101
node2=10.60.0.102
node3=10.60.0.103
squid_int=10.31.33.254
dns_int=10.31.33.254
# Global Options
interval 5
log updates
prefork 10
timeout 1500
table squid { $node1 , $node3 }
table DNS { $node1 , $node3 }
redirect squid {
listen on $squid_int port 3128
forward to squid mode roundrobin check tcp
}
redirect DNS {
listen on $dns_int port 53
forward to DNS mode roundrobin check tcp
}
Relay config :
dns protocol dnsfilter {
### TCP performance options
tcp { nodelay, sack, socket buffer 1024, backlog 1000 }
}
relay dns {
### listen and accept redirected connections from pf
listen on $dns_int port 53
### apply web filters
protocol dnsfilter
### forward to web server(s)
forward to DNS mode roundrobin check tcp
}
--
Cordialement,
Pierre BARDOU
CSIM - Bureau 012
Midi Picardie Informatique Hospitalihre
12 rue Michel Labrousse
BP93668
F-31036 Toulouse CEDEX 1
Til : 05 67 31 90 84
Fax : 05 34 61 51 00
Mail : bardo...@mipih.fr
