Martin wrote:
>> Did you know that it is possible to tunnel almost any other protocol
>> through DNS?
>
> Yes. However... That's only useful if you can survive a 24 hour delay or
> so for updating the TXT records. There's other tricks but they're not
> practical here.
>
> The DNS admins might get upset if people started abusing DNS records for
> broadcasting other than what is directly DNS related...
If you had to plan on a 24 hour delay, tunnelling other protocols would
be slow, to the point of being impossible. It isn't.
Wearing my DNS admin. hat for a minute....
I'm already unhappy with the way TTL is managed on virtually every domain.
When I learned DNS, a 42 day TTL (the highest possible) was common, and
a DNS server got a lot of leverage from caching. A LOT.
Later, TTL started to migrate from 42 days to about 14. It typically
takes a month to reprovision a wire, so when you know your address block
is going to change, you set TTL to 1 day, and a couple of days before
the jump, you set TTL to an hour.
Now, TTL is generally set to five minutes, left at five minutes, and
never ever changed. It's as if everyone is afraid to predict what will
happen more than five minutes into the future.
Records at the root have a two day TTL, so moving name servers takes a
couple of days for all of the caches to expire.
Here is the SOA record for ssl.berkeley.edu:
ssl.berkeley.edu. 86400 IN SOA ns1.ssl.berkeley.edu.
consult.ssl.berkeley.edu. (
2009071004 ; s/n
3600 ; refresh: 1 hour
300 ; retry: 5 min.
3628800 ; expire: 4.2 days
86400) ; TTL: 1 day
(Yes, this is BIND 4 format, it's the format used by RFC-1034/1035)
"Refresh" tells the secondary name servers to check for an update once
per hour, so if you change the zone, the secondaries will pick up the
change in one hour or less.
If the serial number has changed, the secondary will pick up the update.
The TTL tells the rest of the world "unless there is a different TTL,
cache for a day"
So a change made on the primary name server (ns1.ssl.berkeley.EDU) is
reflected on the secondaries within an hour.
Most of the data records for SETI look like this:
boinc2.ssl.berkeley.edu. 300 IN A 208.68.240.13
boinc2.ssl.berkeley.edu. 300 IN A 208.68.240.18
The "300" overrides the one day TTL.
Basically, a competent DNS implementation can have outdated information
cached for 1 hour and 5 minutes.
In a perfect world, systems would not cache longer than TTL. We don't
live in a perfect world, but enough systems follow the rule that we're okay.
For loading, I would not check for a new TXT record more than once per
hour, and if everything (uploads/downloads/reporting) are working, I
probably wouldn't check at all.
I can think of a trick to defeat the caching too. I'll leave that as an
exercise for the reader.
-- Lynn
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
