[TriLUG] OT: Router then Firewall

[Tanner Lovelace]

On 5/26/06, Aaron S. Joyner <aaron at joyner.ws> wrote:
> So here I am again, it's Thursday before I found the time, but that time
> has come.

Of course it would happen the day I left town for the weekend. :-)

[...]
> So this was perhaps the original interesting angle I hoped to bring up
> with all this, which really requires a thorough exploring of how DNS
> delegations work.  Consider the lame delegation scenario that was
> mentioned in this thread.  This is actually a very common problem, and
> when I joined the steering committee for TriLUG (or perhaps it was
> shortly before) I found this to be an actual problem with the trilug.org
> domain.  First, you specify ns1.trilug.org and ns1.example.org to your
> registrar.  Then, 2 years go by, and no one pays attention.  By then,
> ns1.example.org has thoroughly forgotten that they were supposed to be a
> secondary name server for trilug.org.  They reinstall the server, take
> it off line, it's building burns down, whatever.  Now, when the
> registrar hands out NS delegations for your domain, 50% of the time
> (roughly) people will try to contact ns1.example.org.  That server then
> replies that it's not authoritative for the trilug.org domain, and
> refers you back to something like a.root-servers.net or perhaps the
> .org. domain servers.  This is a "lame" delegation, because you caused
> the client to do extra work by providing an invalid delegation, and
> making it chase a dead end.  The client won't totally give up, it will
> then try the other server returned by the .org. name server.  In the
> current example, that's ns1.trilug.org, which will then give it a valid
> response for what ever trilug.org name it was looking for.
>
> So, now how can we leverage this to do interesting things?  Let's
> consider the above example again, but assume ns1.example.org is still
> your friend, and hasn't forgotten about you.  You want to move
> ns1.trilug.org from 3.3.3.3 (your old provider, General Electric) to
> 4.4.4.4 (your new provider, Level 3).  Lets assume you used Cheap Ed's
> domain registry, and they only accept change requests delivered via
> carrier-Camel to their headquarters in the middle of the Gobi desert.
> That's time prohibitive (your contract with GE is up), so you need to do
> this before the registry can be updated.  You setup your new name server
> at 4.4.4.4, change the A record in the zone file on 4.4.4.4 to point to
> the new IP (don't forget to bump the serial), then give your friends and
> example.org a call, ask them to update the named.conf masters entry to
> point to 4.4.4.4.  Now, shut off the nameserver at 3.3.3.3, and things
> will work dandily.  You might incur a couple 10s or at worst 100s of
> milliseconds of latency on the first lookup anyone does to your site
> (and every time the TTL on your NS records expires), but it will
> generally work.  Here's why.  When the random client attempts to look up
> www.trilug.org for the first time, it asks the root servers, which
> direct it to the .org. servers, which return ns1.trilug.org (3.3.3.3)
> and ns1.example.org (1.1.1.1).  Then 50% of the time that client tries
> the first address and fails to contact it.  Then that client (and also
> the other 50% on the first try) contact ns1.example.org.  It returns
> *new* authority records (and the glue to go with them) which will have a
> higher or equal TTL, and thus refresh the existing record, for
> ns1.trilug.org's A record.  All future queries will be split 50/50
> between the two name servers, and the resolver will have the correct IPs
> cached for them. These are also likely to stay cached, as every time you
> look up a record in the trilug.org zone, you get new authority records,
> and the glue to go with them, so everything stays current on a
> frequently-used name server.  Tada, life with Cheap Ed's domain registry
> has been made a little more bearable.  Once the camel arives in the Gobi
> desert, and Cheap Ed updates the A record for ns1.trilug.org in the
> .org. name server, then the riduclousness is resolved, and all queries
> flow normally and quickly.

Thinking about this, here's a way to do this where you don't ever
have to contact the registrar again.

1. Set up a master server that serves all the correct data but do NOT
inform your registrar about it.
2. Set up two (or more) slave servers that draw from the master and
tell your registrar about them.  Extra points if you make sure they
are extremely stable and very unlikely to ever change.

Now, if you want to change the IP address of your master nameserver,
you don't have to contact your registrar.  You just move it to the new IP
address and then have the slave servers update where they pull from.
This is sometimes referred to as an "Unpublished Master Server".
In this scenario, the only time you'd need to contact your registrar
would be to change the registration of the slave nameservers.  The
master could change all it wanted to without notifying the registrar.
This would probably be a good way of doing DNS for a domain run
off a cable modem or DSL line.

Cheers,
Tanner


-- 
Tanner Lovelace
clubjuggler at gmail dot com
http://wtl.wayfarer.org/
(fieldless) In fess two roundels in pale, a billet fesswise and an
increscent, all sable.