Question about qtype=any

Unbound
1

Hi all,

When I use unbound and send a query with qtype = any

dig @localhost www.google.com any

unbound returns me the following results:

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11161

;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;www.google.com. IN ANY

;; ANSWER SECTION:

www.google.com. 604800 IN CNAME www.l.google.com.

www.l.google.com. 300 IN A 74.125.71.147

www.l.google.com. 300 IN A 74.125.71.99

www.l.google.com. 300 IN A 74.125.71.106

www.l.google.com. 300 IN A 74.125.71.105

www.l.google.com. 300 IN A 74.125.71.103

www.l.google.com. 300 IN A 74.125.71.104

I just want to know whether the A records are needed for the qtype any, cos when I send the same query to bind, it only returns me the cname answer.

Thanks.

Luo Ce

CNNIC

2

Hi Luo Ce

My personal opinion,

ANY means the client want to know all the records configured for the query name, so I don’t think it’s meaningful to give extra information.

Other opinion?

Thanks

Likun

3

Hi all,

When I use unbound and send a query with qtype = any
dig @localhost www.google.com<http://www.google.com> any
unbound returns me the following results:
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11161
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com. IN ANY

;; ANSWER SECTION:
www.google.com<http://www.google.com>. 604800 IN CNAME www.l.google.com<http://www.l.google.com>.
www.l.google.com<http://www.l.google.com>. 300 IN A 74.125.71.147
www.l.google.com<http://www.l.google.com>. 300 IN A 74.125.71.99
www.l.google.com<http://www.l.google.com>. 300 IN A 74.125.71.106
www.l.google.com<http://www.l.google.com>. 300 IN A 74.125.71.105
www.l.google.com<http://www.l.google.com>. 300 IN A 74.125.71.103
www.l.google.com<http://www.l.google.com>. 300 IN A 74.125.71.104

I just want to know whether the A records are needed for the qtype any, cos when I send the same query to bind, it only returns me the cname answer.

I believe what is happening here is that unbound is returning what the authoritative server returns for 'www.google.com/ANY', while BIND is reconstructing the answer (that is, looking at its cache and returning all RRsets that match the qname).

So, maybe a better question is: why does google's authoritative nameservers return the A records with qtype=ANY?

4

because they preferred RFC 1034, section 4.3.2, step 3a over RFC 1034, section 3.6.2
(which may not be too consistent in itself)?

-Peter

5

Not only www.google.com, I tried www.sohu.com and www.yahoo.com, the results unbound gave me all include the A records.

So the problem may not be the authoritative server, it looks like unbound continue to process the cname response and get the final A records.

; <<>> DiG 9.7.3-P1 <<>> @localhost www.sohu.com any

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55095

;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:

;www.sohu.com. IN ANY

;; ANSWER SECTION:

www.sohu.com. 600 IN CNAME d7.a.sohu.com.

d7.a.sohu.com. 300 IN CNAME frontend-tc7.a.sohu.com.

frontend-tc7.a.sohu.com. 300 IN A 61.135.181.169

frontend-tc7.a.sohu.com. 300 IN A 61.135.181.171

frontend-tc7.a.sohu.com. 300 IN A 61.135.181.167

;; AUTHORITY SECTION:

a.sohu.com. 3600 IN NS y.a.sohu.com.

a.sohu.com. 3600 IN NS x.a.sohu.com.

a.sohu.com. 3600 IN NS z.a.sohu.com.

;; ADDITIONAL SECTION:

x.a.sohu.com. 7200 IN A 121.14.0.42

y.a.sohu.com. 7200 IN A 220.181.26.169

z.a.sohu.com. 7200 IN A 61.135.179.168

; <<>> DiG 9.7.3-P1 <<>> @localhost www.yahoo.com any

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24745

;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;www.yahoo.com. IN ANY

;; ANSWER SECTION:

www.yahoo.com. 300 IN CNAME fp.wg1.b.yahoo.com.

fp.wg1.b.yahoo.com. 60 IN CNAME any-fp.wa1.b.yahoo.com.

any-fp.wa1.b.yahoo.com. 60 IN A 98.137.149.56

any-fp.wa1.b.yahoo.com. 60 IN A 72.30.2.43

6

Hi,

Yes, unbound continues processing and follows the CNAME, also for qtype
ANY. It fetches the qtype ANY at the CNAME destination for the client.

Best regards,
   Wouter

7

Hi Luo Ce,

The solution we would like to implement is that the CNAME is not
followed for qtype ANY. (and fix DNSSEC-validation of such responses).
Because it is RFC-conformant and short.

Is this OK, or does this create problems; for aliasing perhaps? Is
there some specific result you need to get from ANY queries to DNAME and
CNAME aliases? It would be good to support aliases. Or is this bug
report not because of aliasing but an error found in the lab?

Best regards,
   Wouter

8

Hi Wouter,

I found the difference when I compared the query results between unbound and bind in a non-dnssec environment, and I think it's not bad for unbound to give more information for qtype any.
If this additional information makes the DNSSEC-validation failed, the solution you want to take seems necessary.
And in my opinion, when the query response is fine and could be trusted, the DNSSEC-validation should be passed.

Regards,
Luo Ce

9

Hi Wouter,

The solution we would like to implement is that the CNAME is not
followed for qtype ANY. (and fix DNSSEC-validation of such responses).
Because it is RFC-conformant and short.

I'd argue that RFC 1034 isn't absolutely clear on this topic, see
<http://unbound.nlnetlabs.nl/pipermail/unbound-users/2011-July/001929.html&gt;

Also, when you say "not followed", would this only prevent actively chasing
the CNAME target or would it also prevent data already present in the cache
from being added to the response?

In any case, any optimization should not be seen as an encouragement to
use qtype ANY in applications -- for anything else but debugging.

-Peter

10

Sendmail uses ANY first though and that's on many many servers.

11

Sendmail has not made ANY queries for many years, though I believe it
did in the very dim and distant past.

However, qmail *does* make ANY queries in order to canonicalize mail
domains in the envelopes of outgoing messages, i.e. to replace domains
that are CNAME owner names with the corresponding CNAME target names.
This behaviour is buggy in several ways. Firstly, the current SMTP
specification does not require domains to be canonicalized. Secondly,
qmail should use an MX query not an ANY query, since it is looking up a
mail domain not performing DNS diagnostics. Thirdly, it uses a 512 byte
buffer which is too small, and it has no provision for dealing with
truncated replies.

Tony.

12

>
> Sendmail uses ANY first though and that's on many many servers.

Sendmail has not made ANY queries for many years, though I believe it
did in the very dim and distant past.

Fair enough, I'd read that was the case when troubleshooting a problem
that turned out to be service.switch causing rather unexpected
behaviour (ignoring my intention of removing a dns query and also
skipping the mx, I guess the web page was older than I thought and I
never needed to check the source code, thankfully)

However, qmail *does* make ANY queries in order to canonicalize mail
domains in the envelopes of outgoing messages, i.e. to replace domains
that are CNAME owner names with the corresponding CNAME target names.
This behaviour is buggy in several ways.

I believe djb knew this and only did this to work around bugs in
Bind? I think it was this problem that was why he may even have put in
alternative commented out code.

Firstly, the current SMTP
specification does not require domains to be canonicalized. Secondly,
qmail should use an MX query not an ANY query, since it is looking up a
mail domain not performing DNS diagnostics. Thirdly, it uses a 512 byte
buffer which is too small, and it has no provision for dealing with
truncated replies.

A modern qmail like Spamcontrol for example is patched to be compliant
with the new RFCs and larger replies.

So hopefully there aren't any servers still going and doing this any
more then. An old qmail might still be secure but incompliant with some
modern systems but an old sendmail would be a zombie on acid.

13

>Firstly, the current SMTP
> specification does not require domains to be canonicalized. Secondly,
> qmail should use an MX query not an ANY query, since it is looking up a
> mail domain not performing DNS diagnostics. Thirdly, it uses a 512 byte
> buffer which is too small, and it has no provision for dealing with
> truncated replies.

A modern qmail like Spamcontrol for example is patched to be compliant
with the new RFCs and larger replies.

So hopefully there aren't any servers still going and doing this any
more then.

If you believe this I have a nice piece of Florida swamp to sell you.

There are *lots* of old, unmaintained/unpatched qmail systems out there,
doing ANY queries with small query buffers etc.

An old qmail might still be secure but incompliant with some
modern systems but an old sendmail would be a zombie on acid.

An old unpatched qmail might be secure - but it would also be incapable
of delivering some email.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

14

Or should it really be that these systems are incapable of receiving
some email. RFCs are good things but sometimes go too far or are
enforced too strongly, like Exim blocking MX IPs or ssl enforcement (I
forget the name H?) that blocks people with a failed bios battery
(wrong time)from connecting to your website via ssl without! offering
even an authenticated override. Like that's gonna take off, especially
when you can use the header to force ssl.

If the qmail system is that old they probably don't care or talk
to these new fangled systems. I really hope there aren't any sendmail
ones still out there spamming everyone, or worse.

Atleast the admins of those qmail systems would most likely take the
slight trouble of supporting starttls if they set them up now. Your
criticising these thoughtful and caring peoples servers even if they
may have retired now and noone knows how or wants to replace that
system with some exchange crap. Years ago an advisory was put out that
mail servers should enable ssl. I understand free yahoo services saving
bandwidth/cpu. But the number of these great "brand new" servers
ignoring my ehlo starttls is astounding.