On 30-Nov-18 08:14, Erich Eckner wrote: > On 30.11.18 12:26, Timothe Litt wrote: >> On 30-Nov-18 06:04, Erich Eckner wrote: >>> Hi, >>> >>> I'm running a bind9 name server (9.13.4 on debian) which forwards some >>> zone (onion.) to tor's name server. Unfortunately, tor's name server >>> only answers A and AAAA requests, but not e.g. ANY requests. >>> >>> 192.168.1.3 is running the tor dns, >>> 192.168.1.13 is running bind9 forwarding to 192.168.1.3:9053 >>> >>> $ dig +short @192.168.1.3 -p9053 3g2upl4pq6kufc4m.onion ANY >>> ;; Connection to 192.168.1.3#9053(192.168.1.3) for >>> 3g2upl4pq6kufc4m.onion failed: connection refused. >>> $ dig +short @192.168.1.3 -p9053 3g2upl4pq6kufc4m.onion A >>> 10.255.55.223 >>> $ dig +short @192.168.1.3 -p9053 3g2upl4pq6kufc4m.onion AAAA >>> febe:5163:d2b9:98aa:345b:ee04:2c32:d10e >>> $ dig +short @192.168.1.13 3g2upl4pq6kufc4m.onion ANY >>> $ dig +short @192.168.1.13 3g2upl4pq6kufc4m.onion A >>> 10.255.55.223 >>> $ dig +short @192.168.1.13 3g2upl4pq6kufc4m.onion AAAA >>> febe:5163:d2b9:98aa:345b:ee04:2c32:d10e >>> >>> Is there any option: >>> - to make bind fall back to A or AAAA when the ANY request fails (even >>> the connection fails!) or >>> - to only forward requests of certain type(s) or >>> - to answer ANY requests _always_ with A or AAAA records (not trying if >>> the ANY request can be forwarded successfully), possibly for certain >>> zones only? >>> >>> Sry, if that has been asked before, but I seem unable to find anything >>> useful on the internet, since "ANY" is not a good search term ;-) and >>> without "ANY" I only turn up how to set bind to ipv4/ipv6-only. >>> >>> regards, >>> Erich >> This reflects a common misunderstanding. >> >> A query for ANY does not return 'everything'. It returns what the >> server happens to have cached. It's a diagnostic. >> >> You have to ask explicitly for the record types that you want. >> >> Many people have fallen into the trap of thinking that an ANY query will >> return all records in the DNS, and assume that therefore it can be used >> to make fewer queries. You're not the first. >> >> Any software (or wetware) that relies on ANY for any purpose other than >> determining what's in a server's cache for diagnostic purposes is broken. >> >> >> Timothe Litt >> ACM Distinguished Engineer >> -------------------------- >> This communication may not represent the ACM or my employer's views, >> if any, on the matters discussed. > Thank you for the clarification. Indeed, I can (after querying A and > AAAA) retrieve those records via ANY requests. :-) > > Regards, > Erich
Note that this result is not guaranteed. The server is not required to cache records. The records may have a TTL less than the time between your queries. (E.g. 0) The records may be evicted from a busy cache before the TTL expires. Or the server may reboot between queries. Or... Unless you have some specific reason for finding out what is in a server's cache, you don't want to use queries for ANY. The results will seem confusing/unpredictable - and while they may "seem to work" for a while, will end up wasting a lot of your time. ANY queries are a classic "sharp tool". If used properly, they can cut the time required to diagnose a problem. If used improperly, they will cut you instead. For most people, in most circumstances, the best strategy is to never issue a ANY query. (dig is also a sharp tool; else issuing an ANY query would produce an "are you sure?" prompt :-) Timothe Litt ACM Distinguished Engineer -------------------------- This communication may not represent the ACM or my employer's views, if any, on the matters discussed.
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