Nonstandard subnetting
Tom Cooper
I was recently told that DNS really doesn't like subnet masking that
doesn't fall on a byte boundary. Some of our networks have a subnet mask
with the last byte 192, others 0, still others 224, ad nauseum.
Questions:
1. Does DNS really have a problem with this?
2. If yes, why?
3. Is there an equivalent to named for Netware (as an NLM?)
Most of the nameservers will be Sun boxes running Solaris 2.x (in our
first rollout)
Thanks,
Tom Cooper
tco...@access.digex.net
Christopher Davis
DB> (modulo those using RFC 1101 netmasks encoding)
It seems like few enough people use 1101 network entries, even without the
netmask stuff (we don't subnet, so we don't use the netmask stuff).
RP records are another underused RR type, IMHO.
Just for fun, I got the list of RR assignments out of RFC1700, and I'll
make some comments on them as we go.
>> A 1 a host address [RFC1035]
>> NS 2 an authoritative name server [RFC1035]
These two get used a lot. I think just about everyone uses these. :-)
>> MD 3 a mail destination (Obsolete - use MX) [RFC1035]
>> MF 4 a mail forwarder (Obsolete - use MX) [RFC1035]
Nobody uses these, nor should they.
>> CNAME 5 the canonical name for an alias [RFC1035]
These are pretty common, especially as aliases for specific services
(ftp.foo.dom, gopher.foo.dom, www.foo.dom).
>> SOA 6 marks the start of a zone of authority [RFC1035]
These are required, after all.
>> MB 7 a mailbox domain name (EXPERIMENTAL) [RFC1035]
>> MG 8 a mail group member (EXPERIMENTAL) [RFC1035]
>> MR 9 a mail rename domain name (EXPERIMENTAL)[RFC1035]
I've never seen these used.
>> NULL 10 a null RR (EXPERIMENTAL) [RFC1035]
The name says it all on this one :)
>> WKS 11 a well known service description [RFC1035]
These are deprecated, and most sites don't bother with them any more.
>> PTR 12 a domain name pointer [RFC1035]
Required for IN-ADDR.ARPA and RFC1101 network name resolution.
>> HINFO 13 host information [RFC1035]
Becoming less common with the advent of security concerns.
>> MINFO 14 mailbox or mail list information [RFC1035]
I've never seen this used, either.
>> MX 15 mail exchange [RFC1035]
These are extremely common. I think CompuServe did us all a favor by
being the first major MX-only domain; it got a LOT of broken mailers
fixed. "What do you mean we can't mail to compuserve? Why not? Everyone
else can!"
>> TXT 16 text strings [RFC1035]
Uncommon. Sometimes used for descriptions of organizational units (as at
UIUC). Also used in conjunction with RP records. Zone transfers of these
were broken in BIND 4.9 due to a small typo.
>> RP 17 for Responsible Person [RFC1183]
Underused, as I commented above. Some organizations (RIPE, for example)
do use them, however.
>> AFSDB 18 for AFS Data Base location [RFC1183]
>> X25 19 for X.25 PSDN address [RFC1183]
>> ISDN 20 for ISDN address [RFC1183]
>> RT 21 for Route Through [RFC1183]
I don't see much use of any of these, probably because we don't run AFS.
>> NSAP 22 for NSAP address, NSAP style A record [RFC1348]
>> NSAP-PTR 23 for domain name pointer, NSAP style [RFC1348]
We also don't use NSAPs, so I don't see these much either.
>> SIG 24 for security signature [Donald Eastlake]
>> KEY 25 for security key [Donald Eastlake]
This is part of the DNS Security stuff, I think.
>> PX 26 X.400 mail mapping information [RFC1664]
I haven't seen these used.
>> GPOS 27 Geographical Position [Craig Farrell]
This has already been deprecated by the authors; there's another encoding
coming soon.
>> AAAA 28 IP6 Address [Susan Thomson]
This will presumably become quite common in several years.
29 has already been assigned to LOC, the other geographical encoding.
--
Christopher Davis * <c...@kei.com> | "It's 106 ms to Chicago, we've got a full
http://www.kei.com/homepages/ckd/ | disk of GIFs, half a meg of hypertext,
* MIME * PGP * WWW * [CKD1] * | it's dark, and we're wearing sunglasses."
| "Click it." -- <blue...@bluesbros.com>
Bryan Beecher
>
> >> RP 17 for Responsible Person [RFC1183]
>
>Underused, as I commented above. Some organizations (RIPE, for example)
>do use them, however.
Definitely underused.
However, I do like to use them for this purpose: I handle the DNS for a lot
of small organizations at UMich, and so I list myself as the contact in the
SOA record for that organization's domain. And then I use the RP record to
register the contact at the organization so I know who to contact in case
the need arises. So, I have something like this:
@ IN SOA dns.itd.umich.edu. hostmaster.umich.edu. (
nnnn nnnnn nnnnnn nnnnnn nnnnnnn )
IN NS dns.itd.umich.edu.
IN NS dns2.itd.umich.edu.
IN RP sys.admin.email.address. .
or
IN RP sys.admin.email.address. admin
admin IN TXT "The Admin (313) 76x-xxxx"
--
Bryan Beecher, U-M Information Technology Division (+1 313 747 4050)
Domain: Bryan....@umich.edu Path: ..!uunet!destroyer!bryan
Thomas A. Maufer
> >> TXT 16 text strings [RFC1035]
>
> Uncommon. Sometimes used for descriptions of organizational units (as at
> UIUC). Also used in conjunction with RP records. Zone transfers of these
> were broken in BIND 4.9 due to a small typo.
Christopher--
FYI, these are somehow used with DCE. I recall that we
had to upgrade our nameserver at Goddard from 4.8.x to
4.9.2 because of proper TXT record support that a cer-
tain group needed for DCE testing.
Tom
--
People who like this sort of thing will find this
the sort of thing they like. --Abraham Lincoln
Sam Wilson
> >> TXT 16 text strings [RFC1035]
>
> Uncommon. Sometimes used for descriptions of organizational units (as at
> UIUC). Also used in conjunction with RP records. Zone transfers of these
> were broken in BIND 4.9 due to a small typo.
Used for administrative info in Hesiod (Class HS not IN).
Sam Wilson
Network Services Division
Computing Services, The University of Edinburgh
Edinburgh, Scotland, UK
John Hascall
}How many sites actually use Hesiod for system info which would normally be
}handled by NIS/YP in a distributed environment? I'm talking here really of
}passwd and groups, the big databases; I'm assuming that no-one duplicates a YP
}hosts map with Hesiod HS TXT records rather than IN A records (that WOULD be
}silly).
We have quite a large hesiod DB:
root@vs-1# wc -l *.db
1276 cluster.db
16 config.db
28893 filsys.db
57305 gid.db
28653 group.db
28126 grplist.db
28208 passwd.db
28202 pobox.db
210 prefer.db
1334 print.db
4 rhosts.db
1006 service.db
80 sloc.db
56415 uid.db
259728 total
}We have used Hesiod as part of DECathena for 4 years, and are now actively
}moving back to NIS. With hindsight, I don't think Hesiod was ever a good idea
}for us. NIS is good at serving local clients within a site with local info.
}DNS is good for looking up a remote site's domain names. Normal system
}software (even on Ultrix with its /etc/svc.conf which should theoretically
}make getpwname etc use Hesiod) never properly understood Hesiod anyway.
For us, it has worked pretty well, I'd say. Most of our problems
with it have gone away with recent/better versions of named.
The two major problems with it, as I see it, are:
* there is too long of a period when named starts
when the socket is open, but no queries are
answered (as it loads the files into core).
[I have a planned mod for this as soon as I get time]
* DEC didn't carry Hesiod over into OSF/1's getxxyyy()
functions -- so it begins to look like a dead-end
even within DEC.
John
--
John Hascall ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer, ISU Comp Center + Ames, IA 50011 + 515/294-9551
& Hascall Systems - Unix/C/Internet Consulting, Training, Custom Programming
Peter Lister
|> Used for administrative info in Hesiod (Class HS not IN).
How many sites actually use Hesiod for system info which would normally be
handled by NIS/YP in a distributed environment? I'm talking here really of
passwd and groups, the big databases; I'm assuming that no-one duplicates a YP
hosts map with Hesiod HS TXT records rather than IN A records (that WOULD be
silly).
We have used Hesiod as part of DECathena for 4 years, and are now actively
moving back to NIS. With hindsight, I don't think Hesiod was ever a good idea
for us. NIS is good at serving local clients within a site with local info. DNS
is good for looking up a remote site's domain names. Normal system software
(even on Ultrix with its /etc/svc.conf which should theoretically make getpwname
etc use Hesiod) never properly understood Hesiod anyway. DECAthena's solution
was ypxlat which converted YP calls to Hesiod lookups on the fly, which was as
hideous as it sounds.
Can anyone give me a convincing reason why we should retain Hesiod? We're not
going to use NIS for authentication, we still have Kerberos for that, so there's
no yppasswd/yppasswdd, it's just username/group/services etc translation. We'll
still use BIND for name translation, though we may duplicate our local hosts
info in NIS if that seems faster.
Peter Lister Email: p.li...@cranfield.ac.uk
Computer Centre, Cranfield University Voice: +44 1234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL UK Fax: +44 1234 751814
--- First law of troubleshooting.... never overlook the obvious. ---
Sam Wilson
p.li...@cranfield.ac.uk wrote:
> In article <Sam.Wilson-22...@mcfadzean.ucs.ed.ac.uk>,
Sam.W...@ed.ac.uk (Sam Wilson) writes:
> |> Used for administrative info in Hesiod (Class HS not IN).
>
> How many sites actually use Hesiod for system info which would normally be
> handled by NIS/YP in a distributed environment? I'm talking here really of
> passwd and groups, the big databases;...
>
> We have used Hesiod as part of DECathena for 4 years, and are now actively
> moving back to NIS. With hindsight, I don't think Hesiod was ever a good idea
> for us. ...
>
> Can anyone give me a convincing reason why we should retain Hesiod? ...
Well, Edinburgh uses it. One of my colleagues writes:
We couldn't possibly do what we do with the automounter by using NIS. It
might be possible with NIS+ but what is the point? Hesiod works fine for
us and we plane to use it for things like accounting codes which again
are needed over multiple domains.
If anyone wants further details ask him, not me - I don't know -
Graem...@ed.ac.uk.
Andy Barclay
SA 380 (Advanced Network Administration).
We setup subnets of a class C address using 3 bits for the subnet,
and had no problems even with DNS, routing, NIS+ or any other
facility.
Therefore, I would assume that the problems with DNS and subnetting
on a non-byte boundary, are localized to some specific implementation
of BIND.
Regards,
Andy W. Barclay. an...@learnix.ca
Isn't it great now that UNIX is user-friendly!
Why it seems like just yesterday that UNIX was
responding to my commands with "huh?" or "what?"
Jeff Hakner
> References: <3ag93m$4...@access3.digex.net>
>
> I am a Sun-certified instructor and recently (last week) taught
> SA 380 (Advanced Network Administration).
Mazel Tov.
> We setup subnets of a class C address using 3 bits for the subnet,
> and had no problems even with DNS, routing, NIS+ or any other
> facility.
> Therefore, I would assume that the problems with DNS and subnetting
> on a non-byte boundary, are localized to some specific implementation
> of BIND.
I can't find the original post for this thread. The only real
problem with subnets that are not on byte boundaries is in
administering reverse lookup (PTR) domains. Since the query
is via d.c.b.a.in-addr.arpa, the subdomains of this dummy in-addr
domain fall onto byte boundaries. If you have assigned subnets
to individual zones, such as departments in your organization, and
you wish to allow each zone to be primary for reverse lookups of
their subnet, you're stuck, as far as I know. If anyone has
a workaround, please tell.
Glen A. Herrmannsfeldt
How to subdelegate an in-addr.arpa address for non-byte
aligned subnet masks.
Take as an example the net 192.1.1.x, and example subnet mask 255.255.255.240
We first define the domain for the class C net,
$origin 1.1.192.in-addr.arpa
@ SOA (usual stuff)
@ ns some.nameserver
ns some.other.nameserver
; delegate a subdomain
one ns one.nameserver
ns some.nameserver
; delegate another
two ns two.nameserver
ns some.nameserver
; CNAME pointers to subdomain one
0 CNAME 0.one
1 CNAME 1.one
; through
15 CNAME 15.one
; CNAME pointers to subdomain two
16 CNAME 16.two
17 CNAME 17.two
31 CNAME 31.two
; CNAME as many as required.
Now, in the delegated nameserver, one.namserver
$origin one.1.1.192.in-addr.arpa
@ SOA (usual stuff)
NS one.nameserver
NS some.nameserver ; secondary for us
0 PTR onenet.one.domain
1 PTR onehost.one.domain
; through
15 PTR lasthost.one.domain
And similar for the two.1.1.192.in-addr.arpa delegated domain.
I believe that if all nameservers are secondary for the domains they
are not primary for, the PTR will be resolved in one call, and returned
in one packet, though I have not checked either of these.
I do know that it workds, as I have been using this for years now, with
no known problems.
-- glen
Peter Lister
|> I am a Sun-certified instructor and recently (last week) taught
|> SA 380 (Advanced Network Administration).
Good for you.
|> We setup subnets of a class C address using 3 bits for the subnet,
|> and had no problems even with DNS, routing, NIS+ or any other
|> facility.
So how did you delegate the PTR records for each subdomain? The PTR domains are
on a byte boundary, I'm afraid.
|> Therefore, I would assume that the problems with DNS and subnetting
|> on a non-byte boundary, are localized to some specific implementation
|> of BIND.
You evidently haven't tried. It's worth noting that the problem applies not just
to sites which use subnetting per se (we don't), to anywhere which delegates
address space. We have an autonomous site connected by a remote Ethernet bridge,
which shares our IP connection, has a delgated domain name for forward
translation and to which we have delegated a quarter of our IP address space
(effectively 2 bit subnetting). I have just come across the same problem. We
effectively have to delegate 64 PTR subdomains to them, though I got bored after the first 20 or so.
Glen A. Herrmannsfeldt's solution is ingenious, but (as I understand it) reliant on a feature of named implementation. My suggest would be to generate named files from a database via a PERL script so that all 256 "byte 3" subdomains are properly delegated as required, from both client and server points of view. I may even write such a beast for my own use.
--
Andy Barclay
I got DNS working using a three bit subnet.
The real question seems to be how the in-addr.arpa resolution
worked.
Well, I cheated.
We setup all the DNS name servers to be secondaries for
the domain 1.128.in-addr.arpa.
All the servers then got information from that machine.
I humbly apologize for even insinuating that this was
workable.
However, (here comes the excuse), Who says DNS domains
have to be lined up on subnet boundaries?????
I could use 3 bits as the subnet, then have DNS domains
that line up on 8 bit (byte) boundaries.
I honestly cannot see why someone would be concerned
with having DNS sub-domains lined up within subnets of
a class C. If one does require this, just elect one
of the DNS servers to serve all 254 in-addr.arpa PTR records.
Also, it seems nobody was impressed with the "sun instructor"
comment. Sorry I mentioned it. It was irrelevant,
won't happen again.(I guess I have to learn to
proof read my stuff instead of composing it on the fly.
Jay Ashworth
>I am a Sun-certified instructor and recently (last week) taught
>SA 380 (Advanced Network Administration).
>We setup subnets of a class C address using 3 bits for the subnet,
>and had no problems even with DNS, routing, NIS+ or any other
>facility.
>Therefore, I would assume that the problems with DNS and subnetting
>on a non-byte boundary, are localized to some specific implementation
>of BIND.
I believe that what is being discussed is the difficulty in delegating the
IN-ADDR reverse resolution domains. When you subnet on other than byte
boundaries, the semantics of this delegation are undefined.
It _can_ be done, you simply have to do it for each of 256 (128?) network
numbers worst case.
Cheers,
-- jra
--
Jay R. Ashworth High Technology Systems Consulting Ashworth
Designer Linux: The Choice of a GNU Generation & Associates
ka1fjx/4 "The difference between theory and practice +1 813 790 7592
j...@baylink.com is bigger in practice than in theory" -pds NIC: jra3