Subject: Re: [dnsext] Err, CORRECT link for my comments...

From: Shane Kerr <[email-masked]>
Date: Tue, 07 Oct 2008 12:12:55 +0200

Nicholas,

On Tue, 2008-09-30 at 11:13 -0700, Nicholas Weaver wrote:
> The proper name and link:
> 
> http://www.ietf.org/internet-drafts/draft-weaver-dnsext-comprehensive-resolver-00.txt

In general, very cool.

As a specific comment, I think standardizing detection of entropy
stripping might be worthwhile. Perhaps there is already technology that
we can steal for this from various NAT working groups?

Also, for the idea of optimizing by not fetching all the address records
for an NS set, or fetching the NS set only after the second query,
perhaps instead one could avoid every fetching the full set of A
records, but rather fetch an additional record for each query?

So for ns.example.com, ns2.example.com, ns3.example.com, the first query
would look up ns.example.com, the second would look up ns2.example.com,
and so on.

You could even delay this sort of incremental lookups until the 2nd
query.

Actually, while your ideas of optimization seems to have come out of a
desire to minimize the costs of forgery resistance, I think the idea of
optimizing resolver performance is worthwhile outside of this context.
Maybe this can be turned into a separate draft? :)

--
Shane

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 7 Oct 2008 08:29:08 -0700

> we can steal for this from various NAT working groups?

You need to do SOME probe to some remote server in order to detect a  
NAT or other weird device, and I think the best is a DNS authoritative  
server, simply because you also want to check for 0x20, renumbering of  
transaction IDs, and other behavior that some stupid stateful  
"firewall" may remove in the name of securing your network.

The load on such an authority is rather low when targeting recursive  
resolvers: how often do those reboot or change IP?

Such load would be nontrivial but not huge if you used this technique  
for stub resolvers:  Say 100M systems, churn IP once a day: 100M  
queries/day x 200B/query = 20 GB/day.  At $.20/GB, thats $4/day in  
bandwidth cost, not huge mind you but not something you are going to  
do for free without compensation.

But this brings up a good point:  for a stub resolver, what counts is  
the behavior between the stub and its recursive resolver, it only  
needs to query the behavior between the two, so a wildcarded name  
handled by the recursive resolver would probably be a good thing.

Note also, by querying an authority (such as  
entropy.*.nettest.icir.org which is up at the moment, this is an  
experimental server so it is NOT stable however), since that gives the  
behavior of the recursive resolver, a stub resolver could use this to  
guage whether a recursive resolver is actually safe.  If a recursive  
resolver is unsafe, it could switch to its own internal recursive  
resolver, or, better yet, switch to its own recursive resolver AND  
gripe to the user.

To get a current example, this is how it returns:

entropy.nettest.icIr.org. 1     IN      CNAME    
status.pt=53495.ad=192.150.186.71.id=12321.0x20=T.nettest.icIr.org.
status.pt=53495.ad=192.150.186.71.id=12321.0x20=T.nettest.icIr.org. 1  
IN A 10.1.2.3

> You could even delay this sort of incremental lookups until the 2nd

Well, once you get one authoritative server, you don't need another  
unless there is a failure, if you are willing to tolerate slightly  
higher latency if you picked a "far" authoritative server.

This is why Paul Vixie suggested "pick most-precise" if you are  
fetching one, because although thats might not be the closest, it is  
highly likely to be the same latency order as the eventual use of the  
remote system, so if you chose the higher latency choice it isn't  
likely to impact user experience too badly.

> Maybe this can be turned into a separate draft? :)

Well, the problem is: its trying to get BACK to the performance of  
current bailywick checking.

The rules for including into the global scope in conventional  
bailywick checking are more efficient in terms of reducing queries  
(those are the base-line case), but the conventional bailywick  
checking rules enable race until win (and also may introduce some  
strange sidecases that are probably safe but I still worry about).

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 7 Oct 2008 08:52:03 -0700

On Oct 7, 2008, at 8:29 AM, Nicholas Weaver wrote:
> experimental server so it is NOT stable however), since that gives  
> the behavior of the recursive resolver, a stub resolver could use  
> this to guage whether a recursive resolver is actually safe.  If a  
> recursive resolver is unsafe, it could switch to its own internal  
> recursive resolver, or, better yet, switch to its own recursive  
> resolver AND gripe to the user.
>
>
> 1 IN A 10.1.2.3

Oh, a couple comments as everyone seems to be testing the server:

The 0x20 test is "Is it all lower or all upper or mixed case".  Thus  
there is a 1 in ~2^20 chance that an 0x20 using resolver will falsely  
be reported as not using 0x20.

The TTL is 1 second, but just in case the recursive resolver doesn't  
respect very short TTLs (I had it as 1 second because I don't  
necessarily trust 0 seconds to be abided by either), there is an  
arbitrary wildcarding in there for subdomains.

Thus
entropy.a.nettest.icir.org
entropy.b.nettest.icir.org
entropy.c.nettest.icir.org

allows back to back tests regardless of how the resolver caches the  
result.