Problem lookup 168.192.in-addr.arpa since today 13:00 CEST

[netzwerghh]

Hello!
Since today (August, 9th 2008) exactly 13:00 CEST i am unable to resolve everything under 168.192.in-addr.arpa over my local caching-only bind-servers. I'm using bind-9.4.2_p1 but have the same issues with bind-9.4.2_p2.
I am able to ask for the ns for 168.in-addr.arpa but when I ask for the ns for 168.192.in-addr.arpa i get a timeout. If I directly ask one of the 192.in-addr.arpa nameservers I get an answer. So this must be an issue in the recursion algorithm of my bind.
This should not be an serious issue, but some deamons are doing a reverse-lookup before logging. So when i try to login via ssh it takes more then 10 seconds do login via the internal net. When I login over the public ip i have no problems.
Does anyone have the same issues? It quite interesting that it startet exactly at 2008-08-09 13:00:00 CEST

Thank you for your help

Dennis Körner

PS:

Here is the output of some dig commands:
ns1 ~ # dig ns 192.in-addr.arpa @cache-dns.netzwerge.de

; <<>> DiG 9.4.2-P1 <<>> ns 192.in-addr.arpa @cache-dns.netzwerge.de
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50611
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 7

;; QUESTION SECTION:
;192.in-addr.arpa. IN NS

;; ANSWER SECTION:
192.in-addr.arpa. 86400 IN NS y.arin.net.
192.in-addr.arpa. 86400 IN NS indigo.arin.net.
192.in-addr.arpa. 86400 IN NS epazote.arin.net.
192.in-addr.arpa. 86400 IN NS henna.arin.net.
192.in-addr.arpa. 86400 IN NS basil.arin.net.
192.in-addr.arpa. 86400 IN NS chia.arin.net.
192.in-addr.arpa. 86400 IN NS dill.arin.net.

;; ADDITIONAL SECTION:
dill.arin.net. 155360 IN A 192.35.51.32
basil.arin.net. 5406 IN A 192.55.83.32
henna.arin.net. 5406 IN A 192.26.92.32
indigo.arin.net. 5406 IN A 192.31.80.32
epazote.arin.net. 155360 IN A 192.41.162.32
y.arin.net. 5406 IN A 192.42.93.32
chia.arin.net. 155360 IN A 192.5.6.32

;; Query time: 192 msec
;; SERVER: 85.183.242.9#53(85.183.242.9)
;; WHEN: Sat Aug 9 19:01:14 2008
;; MSG SIZE rcvd: 291

ns1 ~ # dig ns 168.192.in-addr.arpa @cache-dns.netzwerge.de

; <<>> DiG 9.4.2-P1 <<>> ns 168.192.in-addr.arpa @cache-dns.netzwerge.de
;; global options: printcmd
;; connection timed out; no servers could be reached



EDIT: corrected zone in 168.192.in-addr.arpa.

[netzwerghh]

Seems nobody has the same issues. The problem still exists for me. I've done a workaround by adding the 168.192.in-addr.arpa zone to all of my DNS-Servers (five or six). So now they have the zone local. But it should work without that.

Dennis Körner

[doctork]

Given that whois tells me:

[netzwerghh]

Yes, I know this net-range is "special purpose" because it's the private range. That's why I use it for my management-net. And I also know, that IANA uses their blockhole-DNS-servers to resolve reverse-lookups. But the correct behavior should be a response that says "record not found". That is what blackhole is for. They give you a "not found" for every query. But I get a timeout. Blackhole is espacially to prevent timeouts and give you an defined answer "not found".