forward all but ANY requests

[Timothe Litt]

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. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20181130/328d60b9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20181130/328d60b9/attachment.bin>