Re: root hints
Joseph S D Yao writes: Just because we don't need to, doesn't mean that it's a good practtice not to. And it's so easy to create one on a system where DNS is already set up. dig ns . root.hints I disagree with this. Few files mean few risk for admin. How about the case when someone did echo root.hints by mistake? Regards. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Recursive DNS problem
Dnia 2011-01-28 10:52 bangla desh napisał(a): I believed so that com.bd is broken. It only has 1 ns server and hsbc.com.bd, whois.com.bd and even google.com.bd they are all delegate directly from bd and not from com.bd. I am wondering, is there a dns rule/standard (or RFC) that explains about delegation? For the fact that com.bd is broken - that's just how DNS works. Zone cuts are there for purpose. Most of this can be read from RFC 1034 and 1035, which form the grounds for DNS standards. Also RFC 2181 clarifies: quote A server for a zone should not return authoritative answers for queries related to names in another zone, which includes the NS, and perhaps A, records at a zone cut, unless it also happens to be a server for the other zone. /quote And a mere presence of NS records indicates a zone cut (again, RFC 2181): quote The existence of a zone cut is indicated in the parent zone by the existence of NS records specifying the origin of the child zone. /quote As for number of authorative servers per domain, I don't remember where, but at leas one RFC stated that there should be at least two, and preferably 3-7 nameservers per domain. It's quite possible that one of those I've already pointed to contains this information, but also that a different one states this information. But it was RFC for certain. Regards, Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Bind 9.7 - sanity check or a bug
Please help me to understand the following behaviour of Bind 9.7. Consider this: NS server1.test.com. NS server2.test.com. server1 A 10.0.0.1 server2 A 10.0.0.2 case 1: # nsupdate server 127.0.0.1 update delete server2.test.com A update add server2.test.com A 10.0.0.2 send quit No issues in above case. case 2: # nsupdate server 127.0.0.1 update delete server2.test.com A send update add server2.test.com A 10.0.0.2 send update failed: REFUSED quit syslog will show: updating zone 'test.com/IN': update rejected: post update name server sanity check failed In case 1 it is not giving any error. Why it is giving sanity check error in case 2 only? If this is because NS records without A records are not allowed, then it should not allow us to delete the NS A record also. While deleting NS A record also it should have given the sanity check error. Is it a bug in Bind 9.7? This issue is not seen in Bind 9.5. -Dinmadh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind 9.7 - sanity check or a bug
Please help me to understand the following behaviour of Bind 9.7. Consider this: NS server1.test.com. NS server2.test.com. server1 A 10.0.0.1 server2 A 10.0.0.2 case 1: # nsupdate server 127.0.0.1 update delete server2.test.com A update add server2.test.com A 10.0.0.2 send quit No issues in above case. case 2: # nsupdate server 127.0.0.1 update delete server2.test.com A send update add server2.test.com A 10.0.0.2 send update failed: REFUSED quit syslog will show: updating zone 'test.com/IN': update rejected: post update name server sanity check failed In case 1 it is not giving any error. Why it is giving sanity check error in case 2 only? If this is because NS records without A records are not allowed, then it should not allow us to delete the NS A record also. While deleting NS A record also it should have given the sanity check error. Is it a bug in Bind 9.7? This issue is not seen in Bind 9.5. -Dinmadh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind 9.7 - sanity check or a bug
On 28/01/11 10:50, Din Jo wrote: case 1: # nsupdate server 127.0.0.1 update delete server2.test.com http://server2.test.com A update add server2.test.com http://server2.test.com A 10.0.0.2 send quit case 2: # nsupdate server 127.0.0.1 update delete server2.test.com http://server2.test.com A send update add server2.test.com http://server2.test.com A 10.0.0.2 send update failed: REFUSED quit In case one, you are deleting the old A record and adding the new one in the same update transaction. In case two, you are sending the delete as one transaction and the add as a 2nd transaction. I'm surprised the 2nd case fails at the 2nd transaction, not the first. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind 9.7 - sanity check or a bug
In message 4d42a8df.10...@imperial.ac.uk, Phil Mayers writes: On 28/01/11 10:50, Din Jo wrote: case 1: # nsupdate server 127.0.0.1 update delete server2.test.com http://server2.test.com A update add server2.test.com http://server2.test.com A 10.0.0.2 send quit case 2: # nsupdate server 127.0.0.1 update delete server2.test.com http://server2.test.com A send update add server2.test.com http://server2.test.com A 10.0.0.2 send update failed: REFUSED quit In case one, you are deleting the old A record and adding the new one in the same update transaction. In case two, you are sending the delete as one transaction and the add as a 2nd transaction. I'm surprised the 2nd case fails at the 2nd transaction, not the first. Known bug. The version information was not passed down to the checking routines. ___ 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: Bind 9.7 - sanity check or a bug
In case two, you are sending the delete as one transaction and the add as a 2nd transaction. I'm surprised the 2nd case fails at the 2nd transaction, not the first. Known bug. The version information was not passed down to the checking routines. Interesting; can you be more specific - what version info are you referring to, and which checking routines. (Just curious) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind 9.7 - sanity check or a bug
Interesting; can you be more specific - what version info are you referring to, and which checking routines. When you update a zone, the new version of the zone has to be internally consistent. There was a bug where the consistency check was being applied against the old version of the zone before the change, not the new version of the zone resulting from the change, and consequently some valid updates were rejected. This was fixed in 9.7.3b1. The relevant routine is zone_check_ns() in zone.c. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: root hints
I have a question about the hints file. It is built in to BIND. Does bind check for updates to this periodically? If so, where does it get it from ? I assume it gets it from ftp.isc.org. Does bind contain a hardcode for that IP address? or does it use the existing hints to find the address of ftp.isc.org and then download a new ftp.isc.org? Thanks -- jack ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
On 28/01/2011 21:10, Jack Tavares wrote: I have a question about the hints file. It is built in to BIND. Does bind check for updates to this periodically? If so, where does it get it from ? I assume it gets it from ftp.isc.org. Does bind contain a hardcode for that IP address? or does it use the existing hints to find the address of ftp.isc.org and then download a new ftp.isc.org? Hi Jack, BIND has a built-in copy of the root server hints file. However, each time it starts up, it sends a query to the root servers to get an up to date copy of the root servers and their addresses. This is called a priming query. The priming query is repeated periodically to ensure that BIND has a fresh copy. Regards, Anand Buddhdev RIPE NCC ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
What's up?
Heya,how are you doing recently ? I would like to introduce you a very good company which i knew.Their website is [www.bestseller-offer.com] .They can offer you all kinds of electronical products which you need like Laptops ,GPS ,TV LED,Cell phones,ps3,MP3/4/5,motorcycles etcPlease take some time to have a check ,there must be somethings you 'd like to purchase . Hope you have a good mood in shopping from their company ! RegardsIWhat's new? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
On Fri, Jan 28, 2011 at 04:40:50PM +0800, p...@mail.nsbeta.info wrote: Joseph S D Yao writes: Just because we don't need to, doesn't mean that it's a good practtice not to. And it's so easy to create one on a system where DNS is already set up. dig ns . root.hints I disagree with this. Few files mean few risk for admin. How about the case when someone did echo root.hints by mistake? Regards. Pyh, We can agree to disagree. I admit I prefer to have more control over the configuration, and am uncomfortable with invisible parts of the configuration. I like those appliances best where I can log in the maintenance port and see the whole configuration laid out before me. It helps with debugging, too. As for echo root.hints, who leaves their configuration files writable, or does it as the super-user? That's bound to get you in trouble. Use configuration management software that leaves you with a read-only file! -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
On Fri, Jan 28, 2011 at 08:10:10PM +, Jack Tavares wrote: I have a question about the hints file. It is built in to BIND. Does bind check for updates to this periodically? If so, where does it get it from ? I assume it gets it from ftp.isc.org. Does bind contain a hardcode for that IP address? or does it use the existing hints to find the address of ftp.isc.org and then download a new ftp.isc.org? To the best of my knowledge, NO. [If you recognized the BigIP in my last posting, you were right!] -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
On Fri, Jan 28, 2011 at 09:51:13PM -0500, Joseph S D Yao wrote: On Fri, Jan 28, 2011 at 08:10:10PM +, Jack Tavares wrote: I have a question about the hints file. It is built in to BIND. Does bind check for updates to this periodically? ... To the best of my knowledge, NO. To clarify: The distinguished gentleman from RIPE is also correct. Once BIND starts, IF any of the built-in root name servers is correct [very likely on the public Internet, unlikely on any other internet], it will get the complete current list, as this should be identical on all root name servers. But the answer to your original question remains, no - it does not do a file transfer to download any file to keep its boot-time root hints list persistently current. [This does leave a security hole - if a root name server's IP changes, and a Bad Guy gets the old one; or on another internet, if the Bad Guy gets all the IP addresses in the default file. It's not just lust for control that has me using a visible root hints file.] -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: what's a valid domain name?
Barry Margolin writes: In article mailman.1559.1296265826.555.bind-us...@lists.isc.org, p...@mail.nsbeta.info wrote: I googled and found this: It's on the Internet, so it must be true. :) * A domain name can be up to 63 characters long plus a dot plus the characters used to identify the top-level domain (i.e com, info, biz, etc. * Valid characters in a domain name include letters, numbers and hyphens -. The domain name must start and end with a letter or number. So, for this domain name of www.xyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxy.com whose size is larger than 64, is not a valid domain name? And is there a RFC item for a valid domain name? RFC 1035 section 3.1 says: To simplify implementations, the total length of a domain name (i.e., label octets and label length octets) is restricted to 255 octets or less. The length of each label within a domain name is limited to 63 characters. Thanks for the kind info. Regards. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
cache server with authoritative answer
The book Pro DNS and BIND says: If the caching server obtains its data directly from an authoritative DNS, then it too will respond as authoritative. Ohterwise, if the data is supplied from its cache, the response is nonauthoritative. So this means even for a cache only server it can answer with authoritative response? I have been thinking the cache only server shouldn't do this. Regards. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
