Use-caps-for-id ignore list - feature request

Unbound
1

Dear all,

  We use use-caps-for-id for about 5 millions of customers without
problems on our resolvers for about a year. During this time I had to solve
just several issues of unresolvable domains because of wrong implementation of
0x20 draft. The biggest issue we had with ustream.tv but they fixed it within
couple of days. The worst thing here seems to be finding a way how report the
issue and contact people responsible for authoritative DNS servers without
registering to different services with emails and personal details (I am having
0x20 issue with alibaba.com now and their email in SOA does not work).
We have quite large setup (eight resolvers, 70 Gigs cache) and I would not
like to switch 0x20 support off just because of several sites per year.

So I would like to ask you if it would be possible to implement some kind of
unboun-control manageable list for domains that are not working correctly. The
result of validation of 0x20 would be ignored for them.

Thanks
Regards

Ales

2

That would be hard. Aren't all godaddy hosted domains (not godaddy itself) broken? That's why we had to disable this feature in fedora/RHEL

3

Hi Paul,

That would be hard. Aren't all godaddy hosted domains (not godaddy itself) broken? That's why we had to disable this feature in fedora/RHEL

Fortunately Godaddy hosted domains were fixed for some times now. Here,
I re-enabled use-caps-for-id since 2013/07/22 and didn't have any issue
since then.

Regards,
Simon

4

broken? That's why we had to disable this feature in fedora/RHEL

I have found out a temporary solution. I am forwarding troubled domains to a
another resolver without 0x20 support using forward zone:

unbound-control forward_add alibaba.com <IP>@<port>

You can try by our own, alibaba is still broken.

I have found out that even forwarding to a dummy IP solves the problem. For
some reason it turns off caps_for_id feature and a the resolver replies.

Ales

5

Rygl Aleš:

I have found out a temporary solution. I am forwarding troubled domains to a
another resolver without 0x20 support using forward zone:

that sound very simple but _realy_ cool!

we do enable 0x20 capitalisation at our enterprise level resolvers.

Last week I had an issue with a domain I could analyse in detail.
The external customer run a Debian Squeeze + bind 9.7.3 for his domain and rDNS

The rDNS was broken because we sent queries for *.In.ADr.ArpA.

The Debian servers was "protected" by a Cisco firewall.
This device had a "content inspection" for DNS enabled which broke his bind9 answers.

Unfortunately the latest 0x20 patches for unbound-1.4.22 did not catch that.

@Wouter, if you'r interested I could setup a test environment...

Andreas

6

Unfortunately it fixes just the cases where is a problem of mismatched caps in the query and response, of just in the response itself. Fox example McAfee uses DNS for some kind of virus signature identification and because they violate RFC and do not ignore caps in query. It’s because the query is forwarded as capitalized…

dig -t any 4z9p5tjmcbnblehp4557z1d136.avts.mcafee.com @8.8.8.8

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -t any 4z9p5tjmcbnblehp4557z1d136.avts.mcafee.com @8.8.8.8

;; global options: +cmd

;; Got answer:

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

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

;; QUESTION SECTION:

;4z9p5tjmcbnblehp4557z1d136.avts.mcafee.com. IN ANY

;; ANSWER SECTION:

4z9p5tjmcbnblehp4557z1d136.avts.mcafee.com. 0 IN A 127.0.4.8

4z9p5tjmcbnblehp4557z1d136.avts.mcafee.com. 0 IN TXT “Rp1Sbjuoo7B6uu6iaGW9IBzlsS584bET/uInJVnd+U0AQa1mFbiyFyPEcywTg7S+pF2vD6JohGwl8BUidVhxNLWfHd1ckC4qwDM9VNCyzV5V1wynJUSIbLigRcOlEJiyzHaNevnYW6Vo2+zHMi3mIg1mMLnAJW4tt7q31eXgfOU=”

My testing resolver on port 1053 with caps_for_id:

dig -t any 4Z9p5tjmcbnblehp4557z1d136.avts.mcafee.com @127.0.0.1 -p1053

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -t any 4Z9p5tjmcbnblehp4557z1d136.avts.mcafee.com @127.0.0.1 -p1053

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18229

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

;; QUESTION SECTION:

;4Z9p5tjmcbnblehp4557z1d136.avts.mcafee.com. IN ANY

;; AUTHORITY SECTION:

avts.mcafee.com. 600 IN SOA mcafee.com. hostmaster.mcafee.com. 1410766772 1800 600 604800 600

Ales

7

A. Schulze:

Last week I had an issue with a domain I could analyse in detail.
The external customer run a Debian Squeeze + bind 9.7.3 for his domain and rDNS

The rDNS was broken because we sent queries for *.In.ADr.ArpA.

The Debian servers was "protected" by a Cisco firewall.
This device had a "content inspection" for DNS enabled which broke his bind9 answers.

Unfortunately the latest 0x20 patches for unbound-1.4.22 did not catch that.

@Wouter, if you'r interested I could setup a test environment...

today we hit a powerdns server responding in a unexpected manner:

$ dig @ns1.ipandmore.de MAIL1.IPANDMORE.DE +norecurse +noall +answer

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @ns1.ipandmore.de MAIL1.IPANDMORE.DE +norecurse +noall +answer
; (1 server found)
;; global options: +cmd
MAIL1.IPANDMORE.DE. 14400 IN A 213.252.2.157

-> OK

$ dig @ns1.ipandmore.de 157.2.252.213.in-addr.arpa. PTR +norecurse +noall +answer

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @ns1.ipandmore.de 157.2.252.213.in-addr.arpa. PTR +norecurse +noall +answer
; (1 server found)
;; global options: +cmd
157.2.252.213.in-addr.arpa. 900 IN PTR mail1.ipandmore.de.

-> OK

BUT:
$ dig @ns1.ipandmore.de 157.2.252.213.IN-ADDR.ARPA. PTR +norecurse +noall +answer

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @ns1.ipandmore.de 157.2.252.213.IN-ADDR.ARPA. PTR +norecurse +noall +answer
; (1 server found)
;; global options: +cmd
157.2.252.213.in-addr.arpa. 900 IN PTR mail1.ipandmore.de.

-> OK?, notice the lowercase "in-addr.arpa." in the answer.

We had a similar issue in June:
http://unbound.net/pipermail/unbound-users/2014-June/003377.html

Wouter wrote a patch I'm using here to handle the situation where DNS servers don't answer
to uppercase queries at all. But that mechanism fail here because there is no timeout.

I run 1.4.22 with the attached patch.
Ideas / Updates?

Andreas

(attachments)

fix4caps.patch (16.6 KB)

8

Hi Andreas,

The servers respond with different TTLs which is why unbound
classifies the answers as different, which is why the fallback for
capsforid does not work in this case.

Best regards,
   Wouter