Re: More 0x20 craziness
Stephane Bortzmeyer
George Barwood <george....@blueyonder.co.uk> wrote
a message of 61 lines which said:
> It sounds crazy,
Isn't it simply XQID?
http://www.jhsoft.com/dns-xqid.htm
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Stephane Bortzmeyer
George Barwood <george....@blueyonder.co.uk> wrote
a message of 61 lines which said:
> When sending a query to a root or 1st level server,
OK, I understand better now your idea and how it is different from
XQID. But, then, it seems it will work only with delegation-only
zones, no? It is not the case of every TLD...
This works, you get the right referral:
% dig @a-dns.pl A aNTIForgeRYstuFf-www.google.pl
; <<>> DiG 9.5.0-P2 <<>> @a-dns.pl A aNTIForgeRYstuFf-www.google.pl
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18522
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;aNTIForgeRYstuFf-www.google.pl. IN A
;; AUTHORITY SECTION:
google.pl. 86400 IN NS ns1.google.com.
google.pl. 86400 IN NS ns2.google.com.
But this does not:
% dig @a-dns.pl A ANTiForgeRYstuFF-b-dns.pl
; <<>> DiG 9.5.0-P2 <<>> @a-dns.pl A ANTiForgeRYstuFF-b-dns.pl
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4023
Alex Bligh
--On 29 August 2008 15:54:40 +0200 Stephane Bortzmeyer <bortz...@nic.fr>
wrote:
> But this does not:
> % dig @a-dns.pl A ANTiForgeRYstuFF-b-dns.pl
>
> ; <<>> DiG 9.5.0-P2 <<>> @a-dns.pl A ANTiForgeRYstuFF-b-dns.pl
> ; (1 server found)
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4023
As I read what George was suggesting, you've addressed that to the
wrong server, and the correct query would be:
$ dig @a.root-servers.net A ANTiForgeRYstuFF-b-dns.pl
; <<>> DiG 9.4.2-P1 <<>> @a.root-servers.net A ANTiForgeRYstuFF-b-dns.pl
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62848
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 9
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;ANTiForgeRYstuFF-b-dns.pl. IN A
;; AUTHORITY SECTION:
pl. 172800 IN NS B-DNS.pl.
pl. 172800 IN NS G-DNS.pl.
pl. 172800 IN NS E-DNS.pl.
pl. 172800 IN NS F-DNS.pl.
pl. 172800 IN NS H-DNS.pl.
pl. 172800 IN NS A-DNS.pl.
pl. 172800 IN NS D-DNS.pl.
;; ADDITIONAL SECTION:
A-DNS.pl. 172800 IN A 195.187.245.44
B-DNS.pl. 172800 IN A 80.50.50.10
D-DNS.pl. 172800 IN A 213.172.174.70
E-DNS.pl. 172800 IN A 213.218.118.26
F-DNS.pl. 172800 IN A 217.17.46.189
F-DNS.pl. 172800 IN AAAA 2001:1a68:0:10::189
G-DNS.pl. 172800 IN A 149.156.1.6
G-DNS.pl. 172800 IN AAAA 2001:6d8:0:1::a:6
H-DNS.pl. 172800 IN A 194.0.1.2
Alex
Stephane Bortzmeyer
Alex Bligh <al...@alex.org.uk> wrote
> As I read what George was suggesting, you've addressed that to the
> wrong server, and the correct query would be:
>
> $ dig @a.root-servers.net A ANTiForgeRYstuFF-b-dns.pl
No, I do not think I was wrong, George mentioned the root servers but
also the TLD servers.
I we limit his scheme to the root servers, it works *today* (the root
is delegation-only) but it is quite limited.
Alex Bligh
--On 29 August 2008 16:10:39 +0000 Paul Vixie <vi...@isc.org> wrote:
>> - how do we identify those without doing every (final) query twice?
>
> we don't. that's the cost.
>
>> That appears to mean twice as many queries to the real authoritative
>> servers, for every QNAME, since it's perfectly possible for
>> foo.example.com to have a different final delegation chain to
>> www.example.com.
>
> once per new QNAME per RDNS per TTL. this is a lower number than you'd
> think.
If combined with 0x20, could one only make the additional query if
(i) the original qname's case was not preserved or (ii) the qname
did not itself contain sufficient entropy (e.g. ".", "com." etc.)?
Alex
Alex Bligh
--On 29 August 2008 16:54:51 +0000 Paul Vixie <vi...@isc.org> wrote:
> i love the sound of that, except, there isn't "an" additional query in the
> sense of "the one at the end that turns out to be one too many, that we'd
> like to avoid". you literally don't know which one is going to be the one
> you'd be trying to avoid, until after you've received an answer to it.
I need to think a bit more about that. I think a query by query illustration
of how the "section by section" approach works would help illustrate it
to people in general (not just me).
> issue the first is, the goal of this part of the proposal is to make it
> possible to be very draconian in the NS RRset replacement strategy, and
> i'm pretty sure that the number of bits i'd want to be protected by is
> in the 64-or-so range when i'm about to make a predictable refill query.
>
> issue the second is, one never knows if there's a UDP port derandomizer
> somewhere in the path between an RDNS and an ADNS, so the number of 0x20
> bits needed for full confidence is really 48 or so, and that's a very
> long qname indeed.
Is it a reasonable assumption that if "the internet" (perhaps signaled
by a couple of test probes) is not behind a port derandomiser, then
no nameserver is? IE is discovery that an RDNS is "behind" a derandomiser
(NAT / ALG etc.) sufficient to use as a heuristic for needing more
entropy in the qname (under 0x20 or some other proposal), or do we
also need to consider the case where any arbitrary ADNS might have
a derandomiser in front of it? I am thinking that if we could put
in the category of "if you run an ADNS like this you deserve to get
your domains spoofed more easily", then an RDNS which could detect
whether it is behind a NAT through queries to a couple of servers
that happened to support a suitable extension could by extension apply
(or not apply) that to all servers, and hence require more bits of
entropy.
A possible nit with approaches that rely on prepending data to
the qname is that they risk shortening the maximum 'true' qname
length. I think in the real world the heaviest user here is NSEC3
(no comments about DNSSEC and 'real world' in the same sentence
please) and one presumes that this isn't a problem.
JINMEI Tatuya / 神明達哉
"Roy Arends" <r...@nominet.org.uk> wrote:
> During resolution, prepend a label with a nonce to the query. The query
> would look like <nonce>.www.example.com. Each request has a unique nonce,
> a nonce is never re-used.
>
> This continues until an authoritative answer is received (either NXDOMAIN,
> wildcard, CNAME, DNAME, anything that either terminates or restarts the
> resolution process). That authoritative answer comes most likely from a
> server that is authoritative for the www.example.com domain. (most likely,
> since in theory, the <nonce>.www.example.com name could be delegated from
> the www.example.com domain, which is most unlikely, as that would suggest
> delegation point wildcard NS RRSets).
>
> Anyway, we now have an address of a nameserver that is authoritative for
> www.example.com.
> We could send it a priming query for the authoritative nameservers (Wouter
> Wijngaards idea).
> In any case, we can now send it a query for www.example.com.
One thing I've puzzled about regarding this type of approach is its
cost-benefit tradeoff. If we can only use it in identifying
intermediate NSes, I thought our 'best current practice' (i.e.,
randomized QID + source port (+ perhaps source IP address (+ perhaps
'traditional' 0x20))) already provided reasonable security. We could
also use this to confirm possible change of already cached NS as
seemingly indicated in this thread, but for that purpose we can
actually simply fetch the authoritative NS RRset directly; then the
trust ranking concept of RFC2181 will protect us from further attacks.
Of course, the <nonce> or <random> makes the transaction even securer,
so if we can get it free, that would be wonderful; but it actually
comes with a cost, including more queries that are redundant
otherwise, handling miscellaneous corner cases or non compliant
authoritative servers, run-time cost including getting additional
entropy, and of course implementation cost (which is probably minor,
though).
So far, the tradeoff is not so obvious to me (indeed, it seems to me
the known benefit isn't worth the cost), but as no one else seems to
have the same doubt, am I missing something fundamental, or does the
benefit so obviously outweigh the cost for others?
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
Alex Bligh
--On 29 August 2008 19:41:57 +0000 Paul Vixie <vi...@isc.org> wrote:
> note that many "nameservers" just don't answer some of the queries i'm
> saying we should send to protect the authority section. the NS's for
> www.cnn.com just time out on "dig @dmtns01.turner.com.
> kjhsdfkjhsdf.www.cnn.com in a". this is clearly not a real name server,
> it's a dns middlebox of some kind, one of many that does the wrong thing.
> (i don't mind somebody who doesn't answer NS queries since these are
> always diagnostic in nature, but someone who won't send a delegation
> unless they recognize the qname is just evil.) ((thanks to dan kaminsky's
> blog for pointing out the CNN example, and to robert edmonds who shared
> it with me.))
Well, I think breaking resolution for ADNS (or more accurately middlebox
infested ADNS) which are clearly and irrefutably non-compliant is an
acceptable price given vendors have now some time to fix it, assuming
the population isn't that large - after all port randomisation broke
many dubious firewall configs and was deemed acceptable, and I suspect
the total number of broken DNS middleboxen is far smaller than this.
I'm sure cnn.com have a vested interest in making sure cnn.com continues
to resolve, and far more ability to make sure it does than your
average Joe firewall user.
Alex
JINMEI Tatuya / 神明達哉
Ray.B...@nominet.org.uk wrote:
> > but for that purpose we can actually simply fetch the authoritative
> > NS RRset directly; then the trust ranking concept of RFC2181 will
> > protect us from further attacks.
>
> The problem as I saw it is that the real authoritative NS RRset (the one
> that's in the delegated zone) has to be fetched from an IP address which
> is learnt from DNS requests which are less credible (per RFC2181 rules).
>
> Or, to put it another way, you're suggesting that we believe 5th tier
> information ("glue from a primary zone") to get 3rd tier information
> ("authoritative data included in the answer section of an authoritative
> reply").
Right, but that part is established by "identifying intermediate NSes"
(quoting my previous message) and "I thought our 'best current
practice' (i.e., randomized QID + source port (+ perhaps source IP
address (+ perhaps 'traditional' 0x20))) already provided reasonable
security" (ditto). Note that the available window for the attacker is
very limited (generally, just once per TTL) because we'd trigger the
confirmation query if we detect an update attempt with different
information.
Again, I understand the additional nonce makes this process even
securer. My question is whether the benefit outweighs its cost.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
--