Moin!
On 17 Jul 2015, at 19:28, hellekin wrote:
authoritative servers (who never would get a request for .onion
anyway)
*** They could if there's no RFC to forbid it. Actually they could
even
with such a document, but other actors would then rightfully decline
their non-NXDOMAIN response.
RFC don't have the power to forbid anything on the Internet. Especially
if you are dealing with DNS on the recursive side you see RFC violations
every day.
*** But to participate in a discussion related to Tor (not TOR), it's
useful. I refrain to participate in discussions where I don't know
what
I'm talking about: I already have difficulties with the topics I think
I
master. That said, participating is the best way to learn :)
I know which I up to now have not participated in that discussion up to
now. My day job is helping people running DNS servers and the bandwidth
beside that is limited, but for the purpose of that discussion I think
I understood the motivation for a special name is the leakage of
requests and the possibility of getting certs as I was told and I
understand that.
I'm ok with .onion being a special name, but we should just do
that by normal DNS mechanism. What's wrong with answering REFUSED?.
*** Refused does not mean that you're dealing with a non-existent name
(3 Name Error), especially one that is NOT in DNS. It means that the
server refused to perform the request, but does not inform you of the
"specialness" of this particular .onion Special-Use Domain Name (RFC
6761).
Well one of the domains defined in RFC6761 is invalid. So lets see how
that is handled today by the authoritative name servers. Here is what is
happening when I ask the root servers
dig blafasel.invalid +dnssec +norec @k.root-servers.net
; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> blafasel.invalid +dnssec +norec
@k.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46004
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;blafasel.invalid. IN A
;; AUTHORITY SECTION:
international. 86400 IN NSEC investments. NS DS RRSIG NSEC
international. 86400 IN RRSIG NSEC 8 1 86400 20150727170000
20150717160000 1518 .
eK2BLKY9FDf+0iPm3ycygrSkjB6qRRUkPUtDt+TJhTmQXGJ0gXXZK5jD
FPrYWcSbJnGTyxJQRLnyXc9cItUGHv5I1PIzC9dZYwBuvBd//4WHC+WY
2AR86+qPRkc6Cml/E+8hRscu41Uab0+2+dLDLXgrWYUzbllQ7FaNthZG LF0=
. 86400 IN NSEC abb. NS SOA RRSIG NSEC DNSKEY
. 86400 IN RRSIG NSEC 8 0 86400 20150727170000 20150717160000 1518 .
qQrsIJPO+bBjpik6BT3VwV7quxLMrb0OkC0JuFWMsUiet/4cxCeqj6r9
dY937dcYiL/DQ1VtGUXlCcxPN6kw9hOou3lUBHzIJVrPuDdXVjFdDcMo
UPxqj18VtWr+gf/7zPNaSAPMZeS/uccTwXNUDDIBghQr72oMLWpL3DrU uzc=
. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2015071701
1800 900 604800 86400
. 86400 IN RRSIG SOA 8 0 86400 20150727170000 20150717160000 1518 .
J42c6EmUxDWXgXxxMz39iyM6AuYBNiTbxQIzrNfaebcQNFHGiEHr+xfW
M/m2xDBt857L3Uqua6SwI5Kbnv6EAxRdWR50SjYBVBKzvJU4fn0yFHDX
Mxoxv83Kjqv+34JyL6Jad+rQeHd8zEUD2hTlMAhEJgR1QocDCchanbfQ fEU=
;; Query time: 4 msec
;; SERVER: 2001:7fd::1#53(2001:7fd::1)
;; WHEN: Sat Jul 18 08:46:37 CEST 2015
;; MSG SIZE rcvd: 666
as you see you get an authenticated NXDomain as you would expect by
normal
DNS semantics. Lets ask an unrelated server for it:
dig blafasel.invalid +dnssec +norec @pri.authdns.ripe.net.
; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> blafasel.invalid +dnssec +norec
@pri.authdns.ripe.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 16928
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;blafasel.invalid. IN A
;; Query time: 20 msec
;; SERVER: 2001:67c:e0::5#53(2001:67c:e0::5)
;; WHEN: Sat Jul 18 08:46:25 CEST 2015
;; MSG SIZE rcvd: 45
As you see it gives the default answer for an authoritative server
that is not responsible for a domain. I've also seen servers
answering with referrals to the root, but I have not found one
other than the root servers that answers NXDomain.
Answering NXDomain is much harder in a DNSSEC world.
*** Well, Tor is not in the DNSSEC world, it's not even in the DNS
world, that's the point of Name Error in that case, and of the draft
in
question.
Tor might not be in the DNSSEC world every dns query that hits a server
hopefully will be in the future and as you see the special use name
invalid.
is. With that you get the expected behaviour of NXDomain even if the
recursive resolvers and stub resolvers have not been updated for the
specialness of invalid., and in the future onion.
As said I have no problem with .onion getting a special use domain name
allocation I just think it doesn't need to be more special than what we
currently have. And it would be good if we could tackle the problem with
configuration of DNS servers as it is possible with the other RFC6761
names.
So long
-Ralf
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
