Clarification
Hi, What is the bind response when queried MX record. The MX record is having prefernce value is greater than maximum of preference value [ex: 65536]. Thanks Regards, Ramesh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Clarification
On Fri, Oct 22, 2010 at 05:05:06PM +0530, rams brames...@gmail.com wrote a message of 38 lines which said: What is the bind response when queried MX record. % dig @ns3.nic.fr MX nic.fr ; DiG 9.7.1-P2 @ns3.nic.fr MX nic.fr ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 20106 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 6, ADDITIONAL: 16 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;nic.fr.IN MX ;; ANSWER SECTION: nic.fr. 172800 IN MX 30 mx3.nic.fr. nic.fr. 172800 IN MX 10 mx1.nic.fr. nic.fr. 172800 IN MX 20 mx2.nic.fr. ;; AUTHORITY SECTION: nic.fr. 172800 IN NS ns1.nic.fr. nic.fr. 172800 IN NS ns5.ext.nic.fr. nic.fr. 172800 IN NS ns4.ext.nic.fr. nic.fr. 172800 IN NS ns2.nic.fr. nic.fr. 172800 IN NS ns3.nic.fr. nic.fr. 172800 IN NS ns1.ext.nic.fr. ;; ADDITIONAL SECTION: mx1.nic.fr. 172800 IN A 192.134.4.10 mx1.nic.fr. 172800 IN 2001:660:3003:2::4:10 mx2.nic.fr. 172800 IN A 192.134.4.11 mx2.nic.fr. 172800 IN 2001:660:3003:2::4:11 mx3.nic.fr. 172800 IN A 192.134.4.11 ns1.ext.nic.fr. 172800 IN A 193.51.208.13 ns1.nic.fr. 172800 IN A 192.134.4.1 ns1.nic.fr. 172800 IN 2001:660:3003:2::4:1 ns2.nic.fr. 172800 IN A 192.93.0.4 ns2.nic.fr. 172800 IN 2001:660:3005:1::1:2 ns3.nic.fr. 172800 IN A 192.134.0.49 ns3.nic.fr. 172800 IN 2001:660:3006:1::1:1 ns4.ext.nic.fr. 172800 IN A 193.0.9.4 ns4.ext.nic.fr. 172800 IN 2001:67c:e0::4 ns5.ext.nic.fr. 172800 IN A 206.167.244.5 ;; Query time: 2 msec ;; SERVER: 2001:660:3006:1::1:1#53(2001:660:3006:1::1:1) ;; WHEN: Fri Oct 22 13:55:21 2010 ;; MSG SIZE rcvd: 519 The MX record is having prefernce value is greater than maximum of preference value [ex: 65536]. Cannot parse sentence. Can you provide an actual domain name showing the issue? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
clarification
Hi, I have a record in BIND as follows: mxdomain.com. 86400 IN MX 65536 gmail.com. When I query mxdomain.com. with type MX. What is the bind response. Is there any RFC mentioned about this . Thanks Regards, Ramesh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Loading MX record with illegal preference (Lame subject replaced: clarification
On Fri, Oct 22, 2010 at 06:01:22PM +0530, rams brames...@gmail.com wrote a message of 42 lines which said: I have a record in BIND as follows: mxdomain.com. 86400 IN MX 65536 gmail.com. I don't think you tell us the truth. Because BIND refuses to load it: % named-checkzone example large-mx.zone dns_rdata_fromtext: large-mx.zone:15: near '65536': out of range zone example/IN: loading from master file large-mx.zone failed: out of range zone example/IN: not loaded due to errors. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Loading MX record with illegal preference (Lame subject replaced: clarification
https://www.isc.org/files/arm96.html#types_of_resource_records_and_when_to_use_them Scroll down to the data type MX and it says: Identifies a mail exchange for the domain with a 16-bit preference value (lower is better) followed by the host name of the mail exchange. Described in RFC 974, RFC 1035. -- John On 10/22/2010 8:39 AM, Stephane Bortzmeyer wrote: On Fri, Oct 22, 2010 at 06:01:22PM +0530, ramsbrames...@gmail.com wrote a message of 42 lines which said: I have a record in BIND as follows: mxdomain.com. 86400 IN MX 65536 gmail.com. I don't think you tell us the truth. Because BIND refuses to load it: % named-checkzone example large-mx.zone dns_rdata_fromtext: large-mx.zone:15: near '65536': out of range zone example/IN: loading from master file large-mx.zone failed: out of range zone example/IN: not loaded due to errors. ___ 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: clarification
On Fri, 22 Oct 2010, rams wrote: I have a record in BIND as follows: mxdomain.com. 86400 IN MX 65536 gmail.com. How did you get named to load this? If your named does load it, what version of BIND are you using? You should get out of range. (See named-checkzone too.) When I query mxdomain.com. with type MX. What is the bind response. Is there any RFC mentioned about this . I didn't test with BIND 9 (because can't load it), but with BIND 10 (using a SQL database) returns SERVFAIL.___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Loading MX record with illegal preference (Lame subject replaced: clarification
On Fri, Oct 22, 2010 at 09:02:49AM -0500, Jeremy C. Reed jr...@isc.org wrote a message of 8 lines which said: Because subject was replaced I didn't find it before my response :) You should really used a threaded mail client software (which understands the In-Reply-To: header) :-) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: can't validate existing negative responses (not a zone cut) messages
On Sun, 3 Oct 2010, Chris Thompson wrote: Oct 3 16:53:10 dnssec: warning: validating @14c9cd70: 98.206.101.95.IN-ADDR.ARPA PTR: can't validate existing negative responses (not a zone cut) What do they mean, exactly? And should I be worrying about them? They all seem to refer to PTR records (not all of them for IP addresses in 95.101/16, but many of them are). BIND is trying to prove that there is a valid secure - insecure transition. It has found a cached NXDOMAIN response that has not been validated. The comment above the logger call says: /* * This shouldn't happen, since the negative * response should have been validated. Since * there's no way of validating existing * negative response blobs, give up. */ Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: clarification
On Oct 22, 2010, at 8:31 AM, rams wrote: I have a record in BIND as follows: mxdomain.com. 86400 IN MX 65536 gmail.com. When I query mxdomain.com. with type MX. What is the bind response. Is there any RFC mentioned about this . On the wire, the MX preference is carried in a 16-bit field, which cannot store 65536: the field simply isn't big enough. If you query an MX record and get a preference of 65536, the software with which you are doing the query has a bug in it and is displaying something that did not come from the server. If a zone file has a preference of 65536, dns server software (such as bind) that attempts to load the zone file should reject it as impossible to use. If you have dns server software that doesn't reject it, you will have to experiment to find out what it does with the input, which should be easy to do. It could conceivably use a legal number instead, or it simply leave out that record. RFCs merely say 65535 is the maximum allowed. Specifying what to do when reading a zone file that exceeds this maximum is one of an infinite number of possible input errors that RFCs have nothing specific about. John Wobus ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Clarification on delegated NS
In message aanlkti=nfu6avy5tnbcc2wyrp0fckh1gskgzl4o8a...@mail.gmail.com, rams writes: Hi , When I created delegated NS record. Bind 9.7.1 p3 is giving SERVFAIL , when i queried for NS delegated record with NS. Could you please clarify me or is it bug in 9.7? To see the delegation you need to make a non recursive query (+norec). dig +norec ns zone @parent You are supposed to set up the child zone *FIRST* then add the delegation that way you don't have a lame delegation. When removing a zone you remove the delegating NS records then once the NS records have cleared the cache you remove the zone from the nameservers. Similarly when changing the nameservers, you configure the new nameservers, you change the NS records, you wait for the NS records to clear caches, then remove the zone from the old servers. Mark Thanks Regards, Ramesh -- 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
