Re: DNS and internet
- From: ibuprofin@xxxxxxxxxxxxxxxxxxxxxx (Moe Trin)
- Date: Fri, 20 Nov 2009 18:42:30 -0600
On Fri, 20 Nov 2009, in the Usenet newsgroup alt.os.linux.redhat, in article
<4B06AABF.8010301@xxxxxxxxxxxxxxxxxx>, Reynolds McClatchey wrote:
I have a similar problem that maybe Moe can tell me (us) how to
set up DNS. My ISP (ATT) will not serve PTR records for me unless
they provide the DNS for my domain.
That's a political decision on their part. Not wise, but it's their
decision.
So aol.com and comcast.com reject SMTP for lack of reverse lookup.
I have to use another ISP who does serve PTRs for SMTP.
That's an _outgoing_ mail problem - the normal solution proposed is
to smart-host through the providers mail server OR some other service
provider. It can be fixed, but does ATT want to? Only their sales
rep knows for sure.
This is a misguided policy of ATT's and when I questioned the call
center person and explained that I used my own registrar and
administered my own DNS she responded that they could delegate the
DNS for mydomain.com to my servers.
2317 Classless IN-ADDR.ARPA delegation. H. Eidnes, G. de Groot, P.
Vixie. March 1998. (Format: TXT=17744 bytes) (Also BCP0020)
(Status: BEST CURRENT PRACTICE)
but they're probably are more interested in the fees they need you to
pay for this very complicated task. http://www.ietf.org/rfc/rfc2317.txt
(You do know how the 'in-addr.arpa' domain resolves in the same manner
as any normal domain - by referral. Until RFC2317, delegation was
handled in /24 sized chunks or binary multiples there-of.)
Does ATT have an easy http way to administer DNS that they host or
is a ticket required for every change?
I don't know how they admin their setup, but I'd NOT expect them to
be using a web interface unless the web stuff was actually only used
as a "mail to registrar" interface, with the actual zone file changes
being made by cloistered attendants in a "central" location. You
_REALLY_ don't want multiple independent editor sessions mucking with
the zone files at the same time - that's disaster city. For ``small''
setups (meaning those that are admin'ed by a single - or at most very
"few" - person[s] at a single location), they could be using a simple
wrapper script around an editor, and that script handles restarting
the name server and zone transfers and some form of file backups.
This will drastically reduce the chance of errors. The consultant who
helped set up our system years ago created a set of revision control
(RCS - actually SCCS) scripts. The script isn't picky about the
quantity of changes, but it does handle basic typ0/sanity checking and
handles both forward and reverse zone files, as well as NIS 'hosts'
file and zone transfers as needed. The version control allows a (more
or less) graceful back-out in case of errors. (I'm sure you know such
errors may be trivial, but can bring the whole house of cards down
about you with devastating results.) If you muck with the kernel
(compiling your own), I've also seen (but never studied closely) a
scheme using patch files and GNU 'make' to insert changes into the
zone files. "There's More Than One Way To Do It"... or is that
"There's more than _ten_ ways to do it wrong." I dunno ;-)
I use split brain DNS.
Is it split because of internal/external, or because of the two (or
more) upstreams/address ranges, or both? We're sorta doing something
like that because our reverse zones differ internal/external, and a
number of our internal hostnames don't resolve externally. That's a
complication _relatively_ easily (FSVO) handled by these wrapper
scripts.
How would I set the public DNS up?
Very carefully. ;-) (I'm assuming you know how to set up a basic
name server - ala the DNS-HOWTO.) If you are referring to combining
the two or more external address ranges into one forward file, that's
trivial. Somewhat more difficult is if you are trying to serve two
reverse zones that are RFC2317 delegated to you (the upstream zone
delegates to you - a one time setup on their part). That _should_
work by simply having two separate zone files for the reverse end of
things, much the same as is done when serving 2.0.192.in-addr.arpa (or
what-ever) and 127.in-addr.arpa from the same name server.
The RFC2317 delegated mechanism is much the same as a sub-domain. The
upstream isn't involved in the _contents_ of the sub-domain, and their
only function is providing the glue records that refer queries to your
server for the actual resolution.
[COMMENT: I'm really the networking guy, not the DNS guy. You may want
to be looking in the 'comp.protocols.dns.bind' (moderated) or
'comp.protocols.tcp-ip.domains'). If you are actually using the ISC
bind program that comes as part of many *nix, they also have a mailing
list that is useful.]
Old guy
.
- References:
- DNS and internet
- From: Steve
- Re: DNS and internet
- From: Reynolds McClatchey
- DNS and internet
- Prev by Date: Re: Fedora 12 wont run
- Previous by thread: Re: DNS and internet
- Next by thread: Fedora 12 wont run
- Index(es):
Relevant Pages
|
