Re: reverse resolution failing
In message , Warren Kumari wri
tes:
> Hmmm
>
> So, for many years I've wondered this. I've looked a little myself, and
> spoken to a few folk, but never gotten a really satisfactory answer --
> maybe there just isn't one
>
> You often see freaky things like the above (actually, this one is only
> somewhat freaky), where nameserver implementation behave in bizarre /
> insane manners. For many of these it seems as through the NS is simply
> bored, and misbehaving for entertainment purposes ("Whhheee! I'll reply
> to all A queries with TXT answers, lets see what they make of that!", or,
> my favorite, "Whatever folk ask, I'll reply with a cname containing the
> query name, but with alternate labels swapped...").
> For example, even if I tried (well, without much hacking) I cannot figure
> out how to duplicate Saturn's behavior
> What is it about the DNS protocol that leads to this? Do folk look at all
> the existing auth server offerings and decide "No, don't like those, I'll
> just write my own in haskel!"?
> Or is is simply that nameservers themselves are malicious bastards? Are
> they all conspiring against us? Is there some very subtle joke that we
> are not seeing?
>
> W
They want a load balancer but don't want to pay the money to get a
product that does it correctly so they look around for cheaper
alternatives which often don't cover all of the protocol.
The other thing that is common is the operator can't configure the
load balancer correctly.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: reverse resolution failing
On Feb 7, 2013, at 12:51 PM, Tony Finch wrote:
> Jim Pazarena wrote:
>>
>> while it can resolve "webmail.acrodex.com" ( 139.142.184.10 )
>> it cannot reverse resolve 139.142.184.10
>
> They are using classless reverse DNS, which is fine except that the
> nameservers for the target zone are very broken.
>
> 10.184.142.139.in-addr.arpa. CNAME 10.0-25.184.142.139.in-addr.arpa.
>
> 0-25.184.142.139.in-addr.arpa. NS pluto.acrodex.com.
> 0-25.184.142.139.in-addr.arpa. NS nova.acrodex.com.
> 0-25.184.142.139.in-addr.arpa. NS saturn.acrodex.com.
>
> Nova does not exist.
>
> Pluto refuses most questions for 10.0-25.184.142.139.in-addr.arpa except
> if you ask for a PTR, in which case it replies with a bogus question
> section containing 139.0.184.142.in-addr.arpa.
>
> Saturn works OK for most questions, and returns a PTR record if you ask
> for ANY, but if you request a PTR directly it ignores you.
Hmmm…
So, for many years I've wondered this. I've looked a little myself, and spoken
to a few folk, but never gotten a really satisfactory answer -- maybe there
just isn't one…
You often see freaky things like the above (actually, this one is only somewhat
freaky), where nameserver implementation behave in bizarre / insane manners.
For many of these it seems as through the NS is simply bored, and misbehaving
for entertainment purposes ("Whhheee! I'll reply to all A queries with TXT
answers, lets see what they make of that!", or, my favorite, "Whatever folk
ask, I'll reply with a cname containing the query name, but with alternate
labels swapped...…").
For example, even if I tried (well, without much hacking) I cannot figure out
how to duplicate Saturn's behavior…
What is it about the DNS protocol that leads to this? Do folk look at all the
existing auth server offerings and decide "No, don't like those, I'll just
write my own… in haskel!"?
Or is is simply that nameservers themselves are malicious bastards? Are they
all conspiring against us? Is there some very subtle joke that we are not
seeing?
W
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
> Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
> occasionally poor at first.
> ___
> 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
>
--
There were such things as dwarf gods. Dwarfs were not a naturally religious
species, but in a world where pit props could crack without warning and pockets
of fire damp could suddenly explode they'd seen the need for gods as the sort
of supernatural equivalent of a hard hat. Besides, when you hit your thumb with
an eight-pound hammer it's nice to be able to blaspheme. It takes a very
special and straong-minded kind of atheist to jump up and down with their hand
clasped under their other armpit and shout, "Oh,
random-fluctuations-in-the-space-time-continuum!" or "Aaargh,
primitive-and-outmoded-concept on a crutch!"
-- Terry Pratchett
___
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: IPv6 Only NS
On 2/7/2013 1:42 PM, Matt wrote: I am using Bind for caching only. Currently my VM only has IPv4 access. Is there a way to selectively forward any requests that only have IPv6 nameservers to another DNS server that is dual stacked? Hmmm... Is anyone actually publishing IPv6-accessible nameservers for their zone *exclusively*? Really? On the Internet? Can you give an example? If that's the case, there's nothing I can think of within BIND to support IPv6-to-IPv4-forwarding-failover, as you describe. Be aware that you can talk IPv6 even if you don't have IPv6 present on your local LAN or any of your next-hop gateways. Set up an IPv6-in-IPv4 tunnel to a co-operating dual-stack node, and set your static route(s) accordingly (or run a dynamic-routing-protocol daemon on the tunnel, if you're really adventurous :-). Of course, this will affect *everything* running on your VM, not just DNS. If, after accomplishing that, you still want to preference (native) IPv4 access over (tunneled) IPv6 access, hopefully your underlying OS respects RFC 6724 source/destination address selection -- in that case, you should be able to tweak the "policy table" to accomplish the desired preferencing. If it doesn't support RFC 6724, then that's a much more difficult challenge... If not is there a way to forward all requests that are not cached to a parent nameserver? Not sure what you're trying to accomplish with that. If you have forwarding set up, and the answer to a query isn't cached, you're going to forward. If it is cached, you'll answer from cache. So, how does what you ask above differ from regular BIND forwarding? Also, is there a way to specify a backup parent NS and ONLY use it if primary fails? Do you mean "NS" here? Or "forwarder"? I know of no way to manually "preference" the forwarders in a list, although you might find that the forwarder that responds fastest -- and thus gets automatically selected for the vast majority of the queries, according to its round-trip-time statistics -- is the one you would want to manually preference anyway... - Kevin ___ 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: IPv6 Only NS
In message , Matt writes: > I am using Bind for caching only. Currently my VM only has IPv4 > access. Is there a way to selectively forward any requests that only > have IPv6 nameservers to another DNS server that is dual stacked? See dual-stack-servers. > If not is there a way to forward all requests that are not cached to a > parent nameserver? Also, is there a way to specify a backup parent NS > and ONLY use it if primary fails? > ___ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: reverse resolution failing
In message <20130207184127.ga23...@fantomas.sk>, Matus UHLAR - fantomas writes: > >Jim Pazarena wrote: > >> > >> while it can resolve "webmail.acrodex.com" ( 139.142.184.10 ) > >> it cannot reverse resolve 139.142.184.10 > > On 07.02.13 17:51, Tony Finch wrote: > >10.184.142.139.in-addr.arpa. CNAME 10.0-25.184.142.139.in-addr.arpa. > > > >0-25.184.142.139.in-addr.arpa. NS pluto.acrodex.com. > >0-25.184.142.139.in-addr.arpa. NS nova.acrodex.com. > >0-25.184.142.139.in-addr.arpa. NS saturn.acrodex.com. > > > >Nova does not exist. > > > >Pluto refuses most questions for 10.0-25.184.142.139.in-addr.arpa except > >if you ask for a PTR, in which case it replies with a bogus question > >section containing 139.0.184.142.in-addr.arpa. > > > >Saturn works OK for most questions, and returns a PTR record if you ask > >for ANY, but if you request a PTR directly it ignores you. It actually returns a response with a mismatching question section. % dig 10.0-25.184.142.139.in-addr.arpa @saturn.acrodex.com +norec ptr ;; Question section mismatch: got 139.0.184.142.in-addr.arpa/PTR/IN ;; Question section mismatch: got 139.0.184.142.in-addr.arpa/PTR/IN ;; Question section mismatch: got 139.0.184.142.in-addr.arpa/PTR/IN ; <<>> DiG 9.10.0pre-alpha <<>> 10.0-25.184.142.139.in-addr.arpa @saturn.acrodex.com +norec ptr ;; global options: +cmd ;; connection timed out; no servers could be reached % > some kind of lame DNS "load balancers"? Looks like it. Something which intecepts the PTR queries and forwards other queries onto a full blown server. Mark > -- > 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. > Chernobyl was an Windows 95 beta test site. > ___ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
IPv6 Only NS
I am using Bind for caching only. Currently my VM only has IPv4 access. Is there a way to selectively forward any requests that only have IPv6 nameservers to another DNS server that is dual stacked? If not is there a way to forward all requests that are not cached to a parent nameserver? Also, is there a way to specify a backup parent NS and ONLY use it if primary fails? ___ 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: reverse resolution failing
Jim Pazarena wrote: while it can resolve "webmail.acrodex.com" ( 139.142.184.10 ) it cannot reverse resolve 139.142.184.10 On 07.02.13 17:51, Tony Finch wrote: 10.184.142.139.in-addr.arpa. CNAME 10.0-25.184.142.139.in-addr.arpa. 0-25.184.142.139.in-addr.arpa. NS pluto.acrodex.com. 0-25.184.142.139.in-addr.arpa. NS nova.acrodex.com. 0-25.184.142.139.in-addr.arpa. NS saturn.acrodex.com. Nova does not exist. Pluto refuses most questions for 10.0-25.184.142.139.in-addr.arpa except if you ask for a PTR, in which case it replies with a bogus question section containing 139.0.184.142.in-addr.arpa. Saturn works OK for most questions, and returns a PTR record if you ask for ANY, but if you request a PTR directly it ignores you. some kind of lame DNS "load balancers"? -- 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. Chernobyl was an Windows 95 beta test site. ___ 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: reverse resolution failing
tail end of dig +trace: 142.139.in-addr.arpa. 86400 IN NS ns1.clgrab.grouptelecom.net. 142.139.in-addr.arpa. 86400 IN NS ns2.toroon.grouptelecom.net. ;; Received 111 bytes from 199.71.0.63#53(199.71.0.63) in 153 ms 10.184.142.139.in-addr.arpa. 86400 IN CNAME 10.0-25.184.142.139.in-addr.arpa. 0-25.184.142.139.in-addr.arpa. 86400 IN NS saturn.acrodex.com. 0-25.184.142.139.in-addr.arpa. 86400 IN NS pluto.acrodex.com. Looks like it's been delegated rfc2317-style to saturn.acrodex.com and pluto.acrodex.com: pluto seems to work for direct queries: ga-vl-mkt2131:~ rgoodson$ dig +norec @pluto.acrodex.com 10.184.142.139.in-addr.arpa PTR ; <<>> DiG 9.8.3-P1 <<>> +norec @pluto.acrodex.com 10.184.142.139.in-addr.arpa PTR ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37966 ;; flags: qr ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;10.184.142.139.in-addr.arpa. IN PTR ;; ANSWER SECTION: 10.184.142.139.in-addr.arpa. 30459 IN CNAME 10.0-25.184.142.139.in-addr.arpa. 10.0-25.184.142.139.in-addr.arpa. 3600 IN PTR webmail.acrodex.com. ;; Query time: 129 msec ;; SERVER: 139.142.184.4#53(139.142.184.4) ;; WHEN: Thu Feb 7 11:50:33 2013 ;; MSG SIZE rcvd: 100 but I get SERVFAIL from saturn ga-vl-mkt2131:~ rgoodson$ dig +norec @saturn.acrodex.com 10.184.142.139.in-addr.arpa PTR ; <<>> DiG 9.8.3-P1 <<>> +norec @saturn.acrodex.com 10.184.142.139.in-addr.arpa PTR ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36190 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;10.184.142.139.in-addr.arpa. IN PTR ;; Query time: 90 msec ;; SERVER: 204.191.11.5#53(204.191.11.5) ;; WHEN: Thu Feb 7 11:49:48 2013 ;; MSG SIZE rcvd: 45 -- Rich Goodson Sr. Unix System Administrator Mediacom Communications 2195 Ingersoll Ave Des Moines, IA 50312 5-7109 Internal 515/246-2284 Office 515/783-1684 Cell rgood...@mediacomcc.com sudo [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo "You live" --Russian roulette in BASH On Feb 7, 2013, at 11:38 AM, Sten Carlsen wrote: > It does not resolve from my IP, probably there is no reverse entry. > > > On 07/02/13 18:31, Jim Pazarena wrote: >> my named is 9.9.0 >> >> while it can resolve "webmail.acrodex.com" ( 139.142.184.10 ) >> >> it cannot reverse resolve 139.142.184.10 >> >> (example follows). >> However, if I do a simply nslookup using goodle DNS. >> nslookup 139.142.184.10 8.8.8.8 >> IT WORKS! >> >> Can anyone suggest where I may be going wrong with this? >> my "dig" response follows. >> Many thanks! >> >> Jim >> >> mail# dig -x 139.142.184.10 >> >> ; <<>> DiG 9.9.0 <<>> -x 139.142.184.10 >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49017 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;10.184.142.139.in-addr.arpa. IN PTR >> >> ;; Query time: 125 msec >> ;; SERVER: 207.34.147.93#53(207.34.147.93) >> ;; WHEN: Thu Feb 7 09:30:12 2013 >> ;; MSG SIZE rcvd: 56 >> >> mail# >> ___ >> 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 > > -- > Best regards > > Sten Carlsen > > No improvements come from shouting: > >"MALE BOVINE MANURE!!!" > ___ > 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: reverse resolution failing
Jim Pazarena wrote: > > while it can resolve "webmail.acrodex.com" ( 139.142.184.10 ) > it cannot reverse resolve 139.142.184.10 They are using classless reverse DNS, which is fine except that the nameservers for the target zone are very broken. 10.184.142.139.in-addr.arpa. CNAME 10.0-25.184.142.139.in-addr.arpa. 0-25.184.142.139.in-addr.arpa. NS pluto.acrodex.com. 0-25.184.142.139.in-addr.arpa. NS nova.acrodex.com. 0-25.184.142.139.in-addr.arpa. NS saturn.acrodex.com. Nova does not exist. Pluto refuses most questions for 10.0-25.184.142.139.in-addr.arpa except if you ask for a PTR, in which case it replies with a bogus question section containing 139.0.184.142.in-addr.arpa. Saturn works OK for most questions, and returns a PTR record if you ask for ANY, but if you request a PTR directly it ignores you. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: reverse resolution failing
It does not resolve from my IP, probably there is no reverse entry. On 07/02/13 18:31, Jim Pazarena wrote: > my named is 9.9.0 > > while it can resolve "webmail.acrodex.com" ( 139.142.184.10 ) > > it cannot reverse resolve 139.142.184.10 > > (example follows). > However, if I do a simply nslookup using goodle DNS. > nslookup 139.142.184.10 8.8.8.8 > IT WORKS! > > Can anyone suggest where I may be going wrong with this? > my "dig" response follows. > Many thanks! > > Jim > > mail# dig -x 139.142.184.10 > > ; <<>> DiG 9.9.0 <<>> -x 139.142.184.10 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49017 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;10.184.142.139.in-addr.arpa. IN PTR > > ;; Query time: 125 msec > ;; SERVER: 207.34.147.93#53(207.34.147.93) > ;; WHEN: Thu Feb 7 09:30:12 2013 > ;; MSG SIZE rcvd: 56 > > mail# > ___ > 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 -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" ___ 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
reverse resolution failing
my named is 9.9.0 while it can resolve "webmail.acrodex.com" ( 139.142.184.10 ) it cannot reverse resolve 139.142.184.10 (example follows). However, if I do a simply nslookup using goodle DNS. nslookup 139.142.184.10 8.8.8.8 IT WORKS! Can anyone suggest where I may be going wrong with this? my "dig" response follows. Many thanks! Jim mail# dig -x 139.142.184.10 ; <<>> DiG 9.9.0 <<>> -x 139.142.184.10 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49017 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;10.184.142.139.in-addr.arpa. IN PTR ;; Query time: 125 msec ;; SERVER: 207.34.147.93#53(207.34.147.93) ;; WHEN: Thu Feb 7 09:30:12 2013 ;; MSG SIZE rcvd: 56 mail# ___ 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
