cjsv@ccadfa.adfa.oz.au (Christopher JS Vance) (09/25/90)
I have a number of domains which I serve as primary: two forward domains, one reverse domain for our class B network and, of course, another reverse domain for net 127. The question I have is in regard to the specification of glue records for servers outside my domains which perform secondary service for me - each of my domains (except 127, of course) has the same list of secondary servers. When the same host is listed as a foreign secondary server in each of my domains, are the glue A records: 1) associated with the zone and host; zone 1 ------- foreign server 1 ---- glue address 1a for 1 \ \-- glue address 1b for 1 \---- foreign server 2 ---- glue address 1 for 2 zone 2 ------- foreign server 1 ---- glue address 1a for 1 \ \-- glue address 1b for 1 \---- foreign server 2 ---- glue address 1 for 2 or 2) associated only with the host. zone 1 ------- foreign server 1 ---- glue address 1a for 1 \/ \-- glue address 1b for 1 /\ zone 2 ------- foreign server 2 ---- glue address 1 for 2 In other words, should I put these glue A records into each zone, or only one? Or alternatively, how does BIND decide what A records to send with my zones when somebody transfers them. Subsidiary question: must these A records be added to a zone or is any legitimate way of holding authoritative A records for these hosts adequate (e.g., by holding a secondary of the zone they are themselves defined in)? If the first case holds, must I add glue records to the reverse domain for my own servers, too, even though the zone should only be held by sites already holding that information as part of my forward zones? -- Christopher
rickert@mp.cs.niu.edu (Neil Rickert) (09/25/90)
In article <1918@ccadfa.adfa.oz.au> cjsv@ccadfa.adfa.oz.au (Christopher JS Vance) writes: >The question I have is in regard to the specification of glue records >for servers outside my domains which perform secondary service for me - >each of my domains (except 127, of course) has the same list of >secondary servers. > >When the same host is listed as a foreign secondary server in each of my >domains, are the glue A records: > While I admit to being a non-expert, and possible mistaken on this - and doubtless I will be corrected in this case - I suspect you don't need any glue records at all. As I understand it, the only time you need glue records is when you have an NS record for a subdomain of yours and are not yourself a name server for that subdomain. Under any other circumstances the needed A-record can be found by the usual search methods starting at the root servers. If, for example you are the primary name server for BAR.EDU, and the there is to be a subdomain FOO.BAR.EDU, with SOA at HOST.FOO.BAR.EDU, then the official source about HOST.FOO.BAR.EDU, including its A-record, must be found from from HOST.FOO.BAR.EDU. This is a vicious circle, and is the case where a glue record is needed. The easiest way to provide the glue record is for you to be a secondary server for FOO.BAR.EDU, which is often the case. If the name server for FOO.BAR.EDU is in BAR.FOO.COM no glue record is needed for the usual search paths should get an A-record for BAR.FOO.COM. Actually it is my impression that in this case your nameserver probably does this search and keeps the A-record on hand anyway. It is better to not have a glue record unless absolutely necessary, for otherwise this is another record which must be kept up to date, yet for which you are technically not responsible. The conclusion is that wherever you delegate a subdomain, you should probably be a primary or secondary server yourself, in which case you need no glue record - it is already there. You should never need glue records for reverse mappings. The main need for glue records is for the root servers which handle so many subdomains they cannot possibly be secondary servers for most of them. Hope this helps. And if I am confused I hope someone corrects me. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
pvm@VENERA.ISI.EDU (Paul Mockapetris) (09/25/90)
The right way to think about this is that you want to define a zone as a data structure that "works", without regard to primary, secondary, and other zones, subzones, etc. While an incorrectly defined zone may not fail if its subzones are on the same server, or if the right data is in the cache, why take chances? Someday, someone will move the subzone, or the cache won't have the right data, ... When do you need glue data? You need glue data when the NS RRs marking a delegation refer to name servers which are within that delegation (or its descendants). For example, when the EDU zone delegates the zone ISI.EDU, it refers to servers Venera.ISI.EDU VAXA.ISI.EDU, and VAX.DARPA.MIL. Since Venera.ISI.EDU and VAXA.ISI.EDU (the servers) have names which are in the ISI.EDU zone, glue A RRs are required. Glue is not required for VAX.DARPA.MIL, since it isn't descended from ISI.EDU. Note that one upshot of all this is that you never need glue in the reverse mapping domains under IN-ADDR.ARPA part of the tree, unless you create a name server on a machine <something>.in-addr.arpa. Please don't do this anyway. There are some special cases, for example the root zone, and NS RRs that are using aliases (which you shouldn't do anyway.) As a last piece of advice, if you aren't sure, put in the glue. paul
asp@uunet.UU.NET (Andrew Partan) (09/26/90)
In article <1990Sep25.140536.16449@mp.cs.niu.edu>, rickert@mp.cs.niu.edu (Neil Rickert) writes: > It is better to not have a glue record unless absolutely necessary, for > otherwise this is another record which must be kept up to date, yet for > which you are technically not responsible. We are currently having a problem caused (I think) by someone with a glue records for uunet.uu.net with the wrong address. The only address that uunet.uu.net has is 192.48.96.2; however the address 137.39.1.2 keeps showing up. We have been trying to track this down & kill it for a while now, but can't figure out where it is coming from. The real problem is that named accepts non-authoratative updates for information that it is the authoratative server for (and thus the 'infection' gets spread). Named needs to be fixed to not do this. --asp@uunet.uu.net (Andrew Partan)
cricket@WINNIE.CORP.HP.COM ("Cricket") (09/26/90)
We are currently having a problem caused (I think) by someone with a
glue records for uunet.uu.net with the wrong address. The only address
that uunet.uu.net has is 192.48.96.2; however the address 137.39.1.2
keeps showing up.
We have been trying to track this down & kill it for a while now, but
can't figure out where it is coming from.
A very sticky problem, I agree. A friend and I tried in vain some months
ago to track down the source of an RR for aos.brl.mil with a bad dlen.
The real problem is that named accepts non-authoratative updates for
information that it is the authoratative server for (and thus the
'infection' gets spread). Named needs to be fixed to not do this.
Am I hallucinating, or do newer versions already do this? I seem to
remember a message appearing on consoles 'round here that looked like:
datagram from 15.0.200.33 port 53, fd 5, len 347
15.0.200.33 attempted update to auth zone 1 'sc.hp.com'
update failed (-10)
when glue conflicted with a server's authoritative data. (I could be
wrong - I've never personally seen the message, and I run some big
nameservers.)
cricket
hostmaster@hp.comkre@cs.mu.oz.au (Robert Elz) (09/30/90)
In article <106322@uunet.UU.NET>, asp@uunet.UU.NET (Andrew Partan) writes: > We are currently having a problem caused (I think) by someone with a > glue records for uunet.uu.net with the wrong address. Possibly, but also possibly not. > The only address > that uunet.uu.net has is 192.48.96.2; however the address 137.39.1.2 > keeps showing up. I had this problem with munnari.oz.au too, when 2 (of 4 previously) addresses were removed (actually, moved to another host, which made the problem worse). > We have been trying to track this down & kill it for a while now, but > can't figure out where it is coming from. I think you'll find that its simply the various secondaries that you have sending each other bogus info ... ie: currently munnari.oz.au (one of the secondaries) believes that uunet has the 137 address, and will almost certainly return that to uunet at some stage. As you say, BIND will simply accept that and store it when it is sent back, and then return it to munnri at some later time. I believe that the only way to kill this is to shut down every nameserver from which you might conceivably ever have your address returned to you, purge their caches, and backup zone files that contain the bad address, and then restart them all (affectively simultaneously). This is not really practical... For munnari, I created a hacked version of named (introducing some bugs along the way, so you really don't want it) which refuses to accept any info that resides in any zone for which this named is the primary server. That means that munnari will simply not believe anyone who claims to tell it what its own address is (munnari.oz.au is the primary server for the oz.au domain). This then allows everyone else to selectively purge their caches, update their backup files, etc, and theoretically should eventually result in the old addresses dying out. However, when I wanted to upgrade my named a while ago, I started the new version, without my hack in it, and it took about 30 seconds for the ancient old addresses (supposedly dead for months) to return to munnari's cache. Back to the hacked version... Bind badly needs to be taken away and quietly buried somewhere it won't be accidently discovered for a very long time - say in the middle of a nuclear waste dump... Back to the initial issue - I must say I'm a fan of adding as many glue records as possible, it does mean more update work, but it also means that we can always supply an A along with the NS, saving the requesting site from having to go and (possibly) make several queries, even in those cases where this will work. Because of this, I think its a very good idea (you might even say essential) to notify all your secondary servers, your parent servers, all servers for which you are the secondary, and the servers for the parent domains of those domains, whenever you change the IP address of a server. Or better yet - avoid changing the addresses of servers... kre ps: it would be real nice if BIND could go and discover the A records for all NS's it delegates dynamically after it is started (and then again whenever they time out) - that way the only glue records that will be useful are for those where you are delegating down, and even there, BIND should go verify those with the servers concerned, using the glue records just as hints, as it does with the list of root servers in root.cache - never returning them in an answer until after verified with their owner.
asp@uunet.UU.NET (Andrew Partan) (09/30/90)
In article <5652@munnari.oz.au>, kre@cs.mu.oz.au (Robert Elz) writes: > Because of this, I think its a very good idea (you might even say > essential) to notify all your secondary servers, your parent servers, > all servers for which you are the secondary, and the servers for the > parent domains of those domains, whenever you change the IP address > of a server. Any all of the unofficial secondary servers - most of which you may not even know about.... Speaking of wishes - it would also be nice to be able to publish an authoritative this_does_not_exist record. --asp@uunet.uu.net (Andrew Partan)
karl_kleinpaste@cis.ohio-state.edu (10/01/90)
kre@cs.mu.oz.au writes:
I believe that the only way to kill this is to shut down every nameserver
from which you might conceivably ever have your address returned to you,
purge their caches, and backup zone files that contain the bad address,
and then restart them all (affectively simultaneously).
It may not be necessary to be quite that drastic. One person here (in
the osc.edu domain) had a problem with a nameserver host having "CNAME
and other data" problems percolating around. The person responsible
for osc.edu did the following things:
[1] Change all "secondary" lines in in named.boot to primaries, that
is, lie about your status for all your secondaries.
[2] Edit all zone files (including those secondaries for about which
you will now be lying) to remove the bogus RRs.
[3] Run in this configuration for a while. "A while" was something
like a week, long enough to make sure that the min TTL of any data
that anyone else has is guaranteed to be gone. During this time,
named will not accept the bogus A RRs from elsewhere for some reason.
[4] Update all locally-maintained primary zone files for a more recent
serial number, even if no data in the zone file has changed. Change
the primaries back to secondaries. Restart named.
This apparently worked to get rid of the "CNAME and other data"
problems for oscsuna.osc.edu. I tried it once to get fid of a bogon
128.146.6.150 A RR for giza.cis.ohio-state.edu that has been
percolating around the Internet for 2 years, but seem to have botched
the job -- I think I forgot to update one zone's serial number and as
a result, it has come back to haunt me again. I'll have to try it
again soon.
--karldel@thrush.mlb.semi.harris.com (Don Lewis) (10/03/90)
In article <5652@munnari.oz.au> kre@cs.mu.oz.au (Robert Elz) writes: >In article <106322@uunet.UU.NET>, asp@uunet.UU.NET (Andrew Partan) writes: >> We are currently having a problem caused (I think) by someone with a >> glue records for uunet.uu.net with the wrong address. > >Possibly, but also possibly not. > >> The only address >> that uunet.uu.net has is 192.48.96.2; however the address 137.39.1.2 >> keeps showing up. > >> We have been trying to track this down & kill it for a while now, but >> can't figure out where it is coming from. > >I think you'll find that its simply the various secondaries that >you have sending each other bogus info ... ie: currently munnari.oz.au >(one of the secondaries) believes that uunet has the 137 address, >and will almost certainly return that to uunet at some stage. >As you say, BIND will simply accept that and store it when it is >sent back, and then return it to munnri at some later time. > >I believe that the only way to kill this is to shut down every nameserver >from which you might conceivably ever have your address returned to you, >purge their caches, and backup zone files that contain the bad address, >and then restart them all (affectively simultaneously). > I solved a similar problem a while back. Host A was the primary server for Y.Z and secondary for X.Y.Z. Host B was the primary server for X.Y.Z and secondary for Y.Z. Host C was originally a secondary for X.Y.Z, but this function was transferred to host D. The NS record for X.Y.Z that pointed to C kept propagating back and forth between A and B via zone tranfers. Since I only had access to host A, I edited the Y.Z zone file to increment the serial number, and I edited the backup zone file for X.Y.Z on host A to remove the spurious NS record pointing to C. I then restarted BIND on host A, which loaded the primary and secondary zone files which were now free of references to C. When it came time for host B to refresh its copy of the zone file for Y.Z, it got an uncontaminated copy. The next time BIND on host B was restarted, it came up clean. This is will not work if the X.Y.Z zone file is updated and BIND on host B reloads it before being restarted from scratch, or if BIND on host A somehow receives bogus delegation information for X.Y.Z in the meantime (which shouldn't happen if everything is properly configured). >Bind badly needs to be taken away and quietly buried somewhere it >won't be accidently discovered for a very long time - say in the >middle of a nuclear waste dump... Yep. >Back to the initial issue - I must say I'm a fan of adding as many glue >records as possible, it does mean more update work, but it also means >that we can always supply an A along with the NS, saving the requesting >site from having to go and (possibly) make several queries, even in >those cases where this will work. No, no, no! How many zones is a host like uunet.uu.net a secondary server for? If uunet.uu.net changed its address, the primary zone files for all of these zones would have to be updated. How long would that take, considering the diligence of many of the people in change of maintaining these files (how many name servers still believe that NIC.DDN.MIL is still a root server and still lives at 10.0.0.51?). If you are concerned about efficiency, just have BIND go ask for the addresses of these servers and cache the answers. Personally, I don't think this is that much of a win. BTW, BIND has a bug that causes it to insert the A records for the name servers of subzones into the zone transfer data if these A records are cached, even if these A records do not belong in a subzone. This information will not time out on the secondary server until the zone file on the primary is updated. > >Because of this, I think its a very good idea (you might even say >essential) to notify all your secondary servers, your parent servers, >all servers for which you are the secondary, and the servers for the >parent domains of those domains, whenever you change the IP address >of a server. Yes, it is very important that the glue records in any parent zones be correct. If not, then a host requesting the address of the server will get the *incorrect* address information from the parent and take it at face value. The secondary servers need the correct IP address in order to do zone transfers from the primary. Care must also be taken in order to avoid looping the old data between servers as illustrated above. >Or better yet - avoid changing the addresses of servers... If this were only possible. >ps: it would be real nice if BIND could go and discover the A records >for all NS's it delegates dynamically after it is started (and then >again whenever they time out) - that way the only glue records that >will be useful are for those where you are delegating down, and even >there, BIND should go verify those with the servers concerned, using >the glue records just as hints, as it does with the list of root servers >in root.cache - never returning them in an answer until after verified >with their owner. Yes. It could also return them in an answer before they were verified, but with a TTL of 0. BIND should also whine to the administrator if it finds that the glue information is different than the authoritative information. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901
del@thrush.mlb.semi.harris.com (Don Lewis) (10/03/90)
In article <9009251622.AA13093@venera.isi.edu> pvm@venera.isi.edu writes: >Note that one upshot of all this is that you never need glue in the >reverse mapping domains under IN-ADDR.ARPA part of the tree, unless >you create a name server on a machine <something>.in-addr.arpa. >Please don't do this anyway. BIND 4.8.1 (and 4.8.3 it looks like), is kind enough to include glue records in zone transfers of IN-ADDR.ARPA zones if it has the appropriate A records cached. > >There are some special cases, for example the root zone, and NS RRs >that are using aliases (which you shouldn't do anyway.) If you mean NS RRs pointing to CNAME RRs, then this is a very bad idea because it makes BIND go bezerk. It keeps looking for the A RR that goes along with the NS. It keeps making queries for the A RR for the NS, and gets a CNAME RR and the A RR for the name referred to by the CNAME. It then decides that since it doesn't yet have the A RR for the NS, it needs to ask again. > >As a last piece of advice, if you aren't sure, put in the glue. Nope. If you aren't sure, ask a wizard. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901