North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Delegating /24's from a /19
> From [email protected] Tue Mar 15 18:51:46 2005 > Date: Wed, 16 Mar 2005 11:51:33 +1100 (EST) > From: Mark Andrews <[email protected]> > To: [email protected] > Subject: Re: Delegating /24's from a /19 > Cc: > > > In article <[email protected]> you write: > > > >--==========D714B409A8D84E671065========== > >Content-Type: text/plain; charset=us-ascii; format=flowed > >Content-Transfer-Encoding: quoted-printable > >Content-Disposition: inline > > > >>>> [email protected] wrote: > >>>> > Either by doing DNS delegation on the zone boundary or by SWIP'ing > >>>> > the space to the other company. > >>>> > >>>> You can SWIP it yes, but that won't help DNS on small blocks like = > >/24's. > >>>> > >SWIPping the large block won't help. SWIPping the /24s will. > > > >>> OK, what am I missing? > >>> > >>> *ASSUMPTION*: > >>> The holder of the /16 _has_ delegated rDNS for the 32 /24s to the /19 > >>> owner. > >>> > >>> The /19 owner can, on it's nameserver, run an "authoritative" zone for > >>> the /16 -- with _its_ /24s listed explicitly, and a wildcard pointing > >>> back to the rDNS nameserver of the /16 owner. > >>> > >Absolutely. > > > >[SNIP DNS Resolution 101 tutorial] > > > >>> > >>> _AS_LONG_AS_ the 'delegated to' nameserver has the wildcard in it > >>> pointing back to the 'parent' nameserver, this seems to work just fine. > >>> Admittedly, if the upstream block owner changes the _name_ of it's > >>> nameserver(s), the 'delegated to' nameserver requires manual tweaking, > >>> but, realistically, "how often" does _that_ happen? > >> > > > >Seems perfectly reasonable to me. > > > >> This is the worst piece of "advice" I have ever seen. Did you note that it was _not_ 'advice', that I was *ASKING* "what am I missing?" > >> > >Um, why? > > Firstly he does NOT have authority for the /16 reverse. Lots > of latent problems there. Can you elucidate on these "latent problems"? > Secondly sideways delegations don't work. Education request: _when_ and/or _how_ do they "not work"? If machine A answers only for what it knows about, and refers everything else to machine B, and machine B answers for everything except what it knows that machine A knows aboud, and refers *only* those requests to machine A it appears to me that it doesn't really matter _which_ machine you send the query to -- the "right" machine will provide the _correct_ answer. > Thirdly I'm sick and tired of having to debug stupid > schemes ISP's come up with to try to avoid SWIPing the > nameservers in situations like this. They don't work > or they don't meet the customers expectations (i.e. > they have a /24 and should just be able to use x.y.z.in-addr.arpa > and have it work reliably). I see a lot of hand-waving, and a paucity of facts there -- commonly referred to as "spreading FUD". Could you describe the failure modes of the specific scheme presented -- on the assumption that it *is* implemented as described -- and explain how/why the customer's expectations are not being met; given that the customer with the /24 customer *is* using the "x.y.z.in-addr.arpa" zone on their server. > Delegation is the DNS is strictly hierachical. I take it that this means that it is "forbidden" to make "authoritative" 'blackhole' zones for _named_ domains that you don't want any contact with, too. e.g. a corporate resolver redirecting all fetches from "*.doubleclick.com" to a bitbucket server -- one that responds with an "empty" page to any http request. And that running authoritative local rDNS zones for 10/8, 172.16/12, and 192.168/16 is also not allowed. Note: this speeds up traceroute (and similar toys) considerably, when the path goes through devices numbered in RFC1918 space. One wild-card for the entire zone, unless I happen to be using some of that space internally on _my_ network. At the 'corporate' -- not ISP -- level, I have found numerous reasons to run 'authoritative' zones for name-space that was *not* hierarchically delegated to me. e.g. when management is exchanging e-mail with people in Central America, where the name server for the recipient's domain is routinely "not available" fore extended periods, yet the MX for that mail (in a different domain) is resolvable and reachable. Running a 'bogon' authoritative name-server for that domain lets management "get _their_ job done", without the failures attributable to the problem remote name-server. It works. Yes, it requires maintainence. But it _works_. unlike the alternative. > > You either SWIP the new servers or you slave the zones > from the customer. In both cases you are following the > delegation heirarchy. Note even if you slave the zones > you still have to ensure the delegation is correct. > > Mark >
|