[Unbound-users] use-caps-for-id ignore list - feature request

[Rygl Aleš]

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

[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

Sent from my iPhone

Post by Rygl Aleš
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
_______________________________________________
Unbound-users mailing list
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users

[Simon Deziel]

Hi Paul,

Post by 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

Post by Paul
Sent from my iPhone

Post by Rygl Aleš
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
_______________________________________________
Unbound-users mailing list
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users

_______________________________________________
Unbound-users mailing list
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users

[Rygl Aleš]

Post by 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

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

[A. Schulze]

Post by Rygl Aleš
I have found out a temporary solution. I am forwarding troubled domains to a

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

[Rygl Aleš]

Post by A. Schulze

Post by Rygl Aleš
I have found out a temporary solution. I am forwarding troubled domains to a

that sound very simple but _realy_ cool!

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

[A. Schulze]

Post by 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

[W.C.A. Wijngaards]

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

Post by A. Schulze

Post by 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...

+answer
MAIL1.IPANDMORE.DE +norecurse +noall +answer ; (1 server found) ;;
global options: +cmd MAIL1.IPANDMORE.DE. 14400 IN A
213.252.2.157
-> OK
+noall +answer
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
+norecurse +noall +answer
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.
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
_______________________________________________ Unbound-users
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users