Subject: SP: draft-lambert-dns-bsec-00.txt

From: Terry Lambert <[email-masked]>
Date: Tue, 27 Jul 1999 10:03:38 -0700

A self-published Internet-Draft is available for anonymous
FTP.  This draft lacks a currently appropriate IETF working
group, but is DNS related, and therefore applicable to the
charter of this mailing list.

	Title		: Blind Secondary DNS Extension
	Author(s)	: T. Lambert
	Filename	: 4
	Pages		: draft-lambert-dns-bsec-00.txt
	Date		: 27-Jul-1999

Abstract

    DNS [DNSIS] is problematic for dial-up proxy servers.  Secondary
    name servers behind dial-up proxy servers can not be properly
    notified of changes to the primary name server's DNS data via the
    [DNSNOT] mechanism, since such servers are transiently connected
    to the Internet.  Changes in the location of the primary name
    server are particularly problematic for such hosts.

    To address this problem, this document introduces the concept of a
    blind secondary name server, which is not specifically configured
    as to the identity of its primary, and obtains this information
    from the root servers, if necessary.

A URL for this Internet-Draft is:
ftp://ftp.whistle.com/pub/terry/drafts/draft-lambert-dns-bsec-00.txt

Please feel free to discuss this draft in this forum and/or
send questions or comments to the author.

-- Terry Lambert
-- Whistle Communications, Inc.
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.

---

From: [email-masked]
Date: Wed, 28 Jul 1999 08:38:04 +1000

> -- Whistle Communications, Inc.
	This in not so much a protocol issue, rather it is a
	implemention issue.  I've seen the need to do this for IPv6
	for a long time now for ordinary secondaries.  I have no
	wish to type in long strings of hex digits:-)

	This just provides another case where this is useful.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: [email-masked]
Date: Wed, 28 Jul 1999 15:11:18 +1000

It was pointed out to me that I may have been a little
	terse with the response below and that that may have given
	the wrong impression.

	I think that that idea is a good one and one that should
	be followed up by implementers.  As noted below I think
	that once we start having IPv6 machines serving DNS data
	that something like this will become imperative.

	That being said I don't think that this is an area that
	the IETF needs to be involved in specifing.  Rather it
	should be left to implementors to decide how this should
	be done.  I can see several different ways which all achieve
	the same end (not specifing a IP address in a configuration).

	Others may disagree with this view.

	draft-lambert-dns-pns-00.txt on the other hand is definitly
	something that the IETF should be involved in and the merits
	of that draft should be argued out in this forum.

	Mark

---

From: Terry Lambert <[email-masked]>
Date: Wed, 28 Jul 1999 10:44:58 -0700

>         Others may disagree with this view.

I know that, in the limit, this can be glossed over by an
implementation detail specific to each implementation.  My
use of "named.boot" syntactic sugar was merely to provide
an example of how a particular implementation might go
about making this work (not a very good one; it seems I
both missed my target, and forgot to use "example.com").

The real issue I'm trying to address is requiring (or
at least strongly encouraging) that this capability be
implemented for DNS servers on transiently connected
devices, regardless of the local syntactic sugar, and
therefore in code that could make its way onto such
devices.

This includes devices like the Whistle (IBM) "InterJet",
Cobalt's "Qube", Microsoft's "Small Business Server",
etc..  Any place you would configure the WAN side of
a split horizon DNS for a transiently connected border
between a WAN and a LAN.

I agree that IPv6 addresses introduce similar problems,
and that they can be similarly resolved, but my focus
was really on transiently connected/mobile devices, and
the vagaries of ISP (re)configurations.

I think that you could make similar utility claims for
any stealth secondary, or any non-stealth secondary,
since this would significantly simplify secondary
configuration in general (hmmm... widespread use of
this prior to signature/certificate deployment could
be Bad(tm) from a security standpoint; something for
the security considerations regarding cacheing the
primary's location).

Maybe what is really needed is an RFC that dictates how
ISP's must configure their systems, but I don't think
that would go over too well in that community... 8-).

-- Terry Lambert