Re: How to Setup a Name Servers visible on Internet?
Good Morning all, I changed some settings in my zones data files but still have a same complaints: has 0 SOA records, has no NS records and not loaded due to errors. please see below my zone files: File: /var/cache/bind/metropolitanbuntu.co.za ;$ORIGIN metropolitanbuntu.co.za. $TTL 3H metropolitanbuntu.co.za.IN SOA ns1.metropolitanbuntu.co.za.postmaster.metropolitanbuntu.co.za. ( 3 ; serial 8H ; refresh 2H ; retry 4W ; expire 1D) ; default_TTL ; metropolitanbuntu.co.za.IN NS ns1.metropolitanbuntu.co.za. metropolitanbuntu.co.za.IN NS ns2.metropolitanbuntu.co.za. ; metropolitanbuntu.co.za.IN MX 10 mail.metropolitanbuntu.co.za. ; metropolitanbuntu.co.za.IN TXT "Metropolitan College DNS Server." ; localhost IN A 127.0.0.1 ns1 IN A 41.134.194.90 ns2 IN A 41.134.194.91 ns1 IN A 10.0.0.80 ns2 IN A 10.0.0.82 www IN A 10.0.0.81 www IN A 10.0.0.82 mailIN A 10.0.0.84 backup IN A 10.0.0.102 ; ftp IN CNAME www img IN CNAME www * IN CNAME www imapIN CNAME mail pop IN CNAME mail pop3IN CNAME mail smtpIN CNAME mail File: /var/cache/bind/0.0.10.in-addr.arpa $TTL 38400 0.0.10.in-addr.arpa.IN SOA ns1.metropolitanbuntu.co.za. postmaster.metropolitanbuntu.co.za. ( 3 ; serial 8H ; refresh 2H ; retry 4W ; expire 1D) ; default_TTL ; 0.0.10.in-addr.arpa.IN NS ns1.metropolitanbuntu.co.za. 0.0.10.in-addr.arpa.IN NS ns2.metropolitanbuntu.co.za. ; 80 IN PTR ns1.metropolitanbuntu.co.za. 82 IN PTR ns2.metropolitanbuntu.co.za. 81 IN PTR www.metropolitanbuntu.co.za. 102 IN PTR backup.metropolitanbuntu.co.za. 108 IN PTR printer-server.metropolitanbuntu.co.za. 31 IN PTR ldap.metropolitanbuntu.co.za. File: /var/cache/bind/194.134.41.in-addr.arpa $TTL 38400 194.134.41.in-addr.arpa.IN SOA ns1.metropolitanbuntu.co.za.postmaster.metropolitanbuntu.co.za. ( 3 ; serial 3600; refresh 900 ; retry 1209600 ; expire 43200) ; default_TTL ; 194.134.41.in-addr.arpa.IN NS ns1.metropolitanbuntu.co.za. 194.134.41.in-addr.arpa.IN NS ns2.metropolitanbuntu.co.za. ; 90 IN PTR ns1.metropolitanbuntu.co.za. 91 IN PTR ns2.metropolitanbuntu.co.za. Thanks in advance On 14/06/2011 19:18, Mark Elkins wrote: > Eric, > > Did you know that UniForum SA (the CO.ZA administrators) provide free > DNS classes for people that live in South Africa? (Intro and Advanced). > > So you'd need to get over to Johannesburg and/or Cape Town and pay for > some accommodation - but the courses are free. You can see and book for > the courses via the CO.ZA Web site. Courses are run twice a year. > > > On Tue, 2011-06-14 at 14:25 +0200, eric...@kom.za.net wrote: >> On 14/06/2011 10:15, Stephane Bortzmeyer wrote: >>> On Tue, Jun 14, 2011 at 09:58:36AM +0200, >>> eric...@kom.za.net wrote >>> a message of 80 lines which said: >>> sorry for that, please see below the content for my reverse file data: File: /var/cache/bind/metropolitanbntu.co.za.inv: >>> ... 41.134.194.90. IN PTR ns1.metropolitanbuntu.co.za. >>> >>> Then, BIND is perfectly right, 41.134.194.90 does not belong to >>> 0.0.10.in-addr.arpa... >>> 10.0.0.80. IN PTR ns1.metropolitanbuntu.co.za. >>> >>> More subtle here: you should have learn about PTR records before >>> trying it (may I suggest Liu & Albitz' book?) 10.0.0.80 should have >>> been written just 80 (thus forming the name 80.0.0.10.in-addr.arpa). >>> >> Thank you in advance! >> >> I order the book and waiting for the delivery, >> >> I also fund a PDF copy on internet. >> > [outputs deleted] > -- Your Truly Eric Kom 2 Hennie Van Till, White River, 1240 eric...@kom.za.net | eric...@namekom.co.za | eric...@erickom.co.za www.kom.za.net | www.kom.za.org | www.erickom.co.za Key fingerprint: 513E E91A C243 3020 8735 09BB 2DBC 5AD7 A9DA 1EF5 0xA9DA1EF5.asc Description: application/pgp-keys signature.asc Description: OpenPGP di
Re: question about thehartford.com domain
In message <4dfa62ca.7060...@gmail.com>, David Sparro writes: > On 6/15/2011 7:41 PM, M. Meadows wrote: > > > > The DNS admins at thehartford.com seem to feel that this nameserver > > mismatch is working as expected. > > > > So I'm just wondering if anyone still feels that the nameserver mismatch > > seen with the digs in earlier parts of this email thread may present a > > problem to servers requesting name resolution for address records in the > > "thehartford.com" domain. > > > > It will be fine as long as nothing goes wrong. It may not be as robust > as they think it is because it means that depending on the state of my > cache, I may need to be able to get an answer from one of NS1 or NS2 > *AND* one of hfdns3, hfdns4, simns3, or simns4 simultaneously. > This creates an additional potential point of failure. The last sentence of this paragraph from RFC 1034 was not written for no reason. Registries and registrants need to obey it. It is not optional and failure to do so causes operational problems. As the last installation step, the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone. The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so. COM is being negligent by not ensuring that these checks get performed and mis-matches get corrected. The current COM operators took over operations well after RFC 1034 was written. They have no excuse for not doing this regardless of the costs. We shouldn't have to pay for their lack of due diligence. Mark > -- > Dave > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: question about thehartford.com domain
On 6/15/2011 7:41 PM, M. Meadows wrote: The DNS admins at thehartford.com seem to feel that this nameserver mismatch is working as expected. Here's some of the feedback we received from them when we questioned the setup: ~ We use load balancers for the majority of our internet facing URLs. We have multiple datacenters. We typically have our URLs defined in multiple datacenters. Each datacenter has a pair of redundant load balancers. Typically each URL we have is defined in each datacenter with its own address. The active load balancer in a particular datacenter 'owns' one of the NS servers you see when you lookup our authoritative name servers, ie: ns1 or ns2.thehartford.com. There is a 'floating' address shared between the active and failover load balancers that is associated with ns1 or ns2.thehartford.com. hfdns3, hfdns4, simns3, simns4 are the addresses for the specific bind processes running on the actual physical devices. NS1.thehartford.com will be shared between hfdns3 and hfdns4. NS2.thehartford.com between the simns3 and simns4 name servers. ~ So I'm just wondering if anyone still feels that the nameserver mismatch seen with the digs in earlier parts of this email thread may present a problem to servers requesting name resolution for address records in the "thehartford.com" domain. Do they understand that the in-zone NS records *override* the delegation NS records (see RFC 2181) when seen, so they're forcing the rest of the Internet to refresh all 8 records (4 NSes and 4 As) potentially as often as every 120 seconds? That seems rather inconsiderate. Also, what's the point of having load-balancer VIPs in your delegation records, if they're just going to be overwritten, in cache, with the real IPs of the BIND processes anyway? Are they really getting their money's worth from those load-balancers, which aren't used most of the time for this particular function? Load-balancer or no load-balancer, I think the Best Practice of "Under normal circumstances, your delegation records should match your in-zone records" still applies here. The only exception to that general rule is when you're migrating from one set of nameservers to another. - Kevin From: sun-g...@live.com To: mich...@rancid.berkeley.edu Subject: RE: question about thehartford.com domain Date: Wed, 15 Jun 2011 12:59:32 -0400 CC: bind-users@lists.isc.org Just wanted to say thanks to everyone for the quick feedback! We appreciate your assistance on this. Marty > Date: Wed, 15 Jun 2011 08:25:00 -0700 > From: mich...@rancid.berkeley.edu > To: sun-g...@live.com > CC: bind-users@lists.isc.org > Subject: Re: question about thehartford.com domain > > > > On Wed, 15 Jun 2011, M. Meadows wrote: > > > Question : our check of whois indicates that ns1.thehartford.com and ns2.thehartford.com are > > the authoritative nameservers for thehartford.com. A dig with a +trace for > > eftc.thehartford.com seems to indicate that they are indeed the auth nameservers. It?s > > interesting, though, that an http://www.kloth.net/services/nslookup.php lookup for > > thehartford.com query for NS records shows a non-authoritative answer of > > hfdns3.thehartford.com, hfdns4.thehartford.com, simns3.thehartford.com, simns3.thehartford.com > > and simns4.thehartford.com. We?re unsure what?s going on with that. > > Instead of doing 'dig +trace eftc.thehartford.com', do 'dig +trace ns > thehartford.com', and you'll see the problem. > > This is a classic authority mismatch, as others have pointed out. > > michael > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: question about thehartford.com domain
On 6/15/2011 7:41 PM, M. Meadows wrote: The DNS admins at thehartford.com seem to feel that this nameserver mismatch is working as expected. So I'm just wondering if anyone still feels that the nameserver mismatch seen with the digs in earlier parts of this email thread may present a problem to servers requesting name resolution for address records in the "thehartford.com" domain. It will be fine as long as nothing goes wrong. It may not be as robust as they think it is because it means that depending on the state of my cache, I may need to be able to get an answer from one of NS1 or NS2 *AND* one of hfdns3, hfdns4, simns3, or simns4 simultaneously. This creates an additional potential point of failure. -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ksk in a volume
Niobos wrote: > > However, I don't see any security-benefits in this scenario: If the attacker > gets hold of the credentials to update the zone dynamically, he can do so in > both cases (KSK online or offline). If your server is compromised, he can > add/remove records in both cases. In case of ZSK compromise, you can > generate&sign new ZSKs in both cases. In case of KSK compromise, you generate > new KSKs and upload them to the parent. The only difference is that in the > offline case, KSK compromise is a little less likely. Getting the DS in the parent updated is much more difficult than a crash ZSK rollover. The reason for protecting the KSK more than the ZSK is to avoid the pain of having to deal with someone else in case of compromise. Tony. -- f.anthony.n.finchhttp://dotat.at/ Shannon, Rockall: South or southwest 5 to 7. Rough or very rough, occasionally high for a time. Rain or showers. Moderate or good. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ksk in a volume
On 2011-06-15 15:51, Noel Rocha wrote: In this situation: - KSK signed ZSK(DNSKEY RR). - ZSK signing others RR of zone. I don't see reason for the KSK be present in operations unless add/delete RR DNSKEY. I had the same idea roughly a year ago. And while you're right, it doesn't change much in practice. I'll explain my case, and assume it applies to you as well. Since you allow dynamic updates, the ZSKs need to be online. I think we can all agree on this. In theory, you could still sign the ZSKs "manually" with the KSK once not-too-often and keep the KSK offline in between. You believe this makes your zone more secure. However, I don't see any security-benefits in this scenario: If the attacker gets hold of the credentials to update the zone dynamically, he can do so in both cases (KSK online or offline). If your server is compromised, he can add/remove records in both cases. In case of ZSK compromise, you can generate&sign new ZSKs in both cases. In case of KSK compromise, you generate new KSKs and upload them to the parent. The only difference is that in the offline case, KSK compromise is a little less likely. So in the end, I decided to leave my KSK online and have BIND automatically perform ZSK rollovers for me (KSKs are needed for this, although you could pre-calculate all needed RRSIGs during all stages of the rollover if you really want to) Greets, Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
