BIND 9.4.x vs 9.6.x - pid-file check and creation
Hi,
I was going to upgrade from BIND 9.4.3 to BIND 9.6.0-P1, but run into a
strange "bug" in BIND 9.6.0-P1.
Exact same config for 9.4.3 and 9.6.0-P1, only added "new" to files that
are written to (namednew.log, confignew.log and namednew.pid).
OS: Solaris 10.
Using:
pid-file "/var/run/named/namednew.pid";
.. result in the following:
namednew.log:
26-Jan-2009 08:14:22.723 general: couldn't mkdir /var/run/named/namednew.pid':
Permission denied
26-Jan-2009 08:14:22.728 general: exiting (due to early fatal error)
BIND 9.6.0-P1 truss.out:
--CUT--
25123/65: stat("/dev/urandom", 0x79D0FA00)= 0
25123/65: open("/dev/urandom", O_RDONLY|O_NONBLOCK) = 9
25123/65: fcntl(9, F_GETFL) = 8320
25123/65: fcntl(9, F_SETFL, FOFFMAX|FNONBLOCK)= 0
25123/65: setgid(21) = 0
25123/65: setuid(21) = 0
25123/65: access(".", W_OK) = 0
25123/65: open("/var/log/namednew.log", O_WRONLY|O_APPEND|O_CREAT, 0666)
= 10
25123/65: lseek(10, 0, SEEK_END) = 332
25123/65: close(10) = 0
25123/65: open("/var/log/confignew.log", O_WRONLY|O_APPEND|O_CREAT, 0666)
= 10
25123/65: lseek(10, 0, SEEK_END) = 0
25123/65: close(10) = 0
25123/65: mkdir("/var/run/named", 0755) Err#13 EACCES
[ALL]
25123/65: stat("/var/log/namednew.log", 0x79D0F3C0) = 0
25123/65: open("/var/log/namednew.log", O_WRONLY|O_APPEND|O_CREAT, 0666)
= 10
25123/65: lseek(10, 0, SEEK_END) = 332
25123/65: fstat(10, 0x79D0E540) = 0
25123/65: fstat(10, 0x79D0E410) = 0
25123/65: ioctl(10, TCGETA, 0x79D0E47C) Err#25 ENOTTY
25123/65: write(10, 0x10502E754, 97) = 97
25123/65: 2 6 - J a n - 2 0 0 9 0 8 : 1 4 : 2 2 . 7 2 3 g e n e r
a l
25123/65: : c o u l d n ' t m k d i r / v a r / r u n / n a m e
d /
25123/65: n a m e d n e w . p i d ' : P e r m i s s i o n d e n i
e d
25123/65: \n
25123/65: write(10, 0x10502E754, 69) = 69
25123/65: 2 6 - J a n - 2 0 0 9 0 8 : 1 4 : 2 2 . 7 2 8 g e n e r
a l
25123/65: : e x i t i n g ( d u e t o e a r l y f a t a l
e r
25123/65: r o r )\n
25123/65: _exit(1)
It fails because it tries to just create the /var/run/named directory instead
of cheking if the directory exist and if it can write to it.
ns12(root) named 515# ls -la /var/run/named
total 40
drwxr-s---4 namednamed 307 Jan 26 06:51 ./
drwxr-xr-x7 root sys 1285 Jan 26 00:52 ../
-rw-r--r--1 namednamed 6 Jan 26 06:41 named.pid
So /var/run/named exists and is fully writable by user named.
User "named" should of course not be able to crate diretories below
"/var/run". Especially since many other things on Solaris 10 uses that
directory also.
If I use:
pid-file "/var/run/named/named/namednew.pid";
... everything works fine, since it now can run mkdir without getting "EACCES".
Instead it gets "EEXIST" and is OK with that.
BIND 9.6.0-P1 truss.out:
--CUT--
25404/65: stat("/dev/urandom", 0x79D0FA00)= 0
25404/65: open("/dev/urandom", O_RDONLY|O_NONBLOCK) = 9
25404/65: fcntl(9, F_GETFL) = 8320
25404/65: fcntl(9, F_SETFL, FOFFMAX|FNONBLOCK)= 0
25404/65: setgid(21) = 0
25404/65: setuid(21) = 0
25404/65: access(".", W_OK) = 0
25404/65: open("/var/log/namednew.log", O_WRONLY|O_APPEND|O_CREAT, 0666)
= 10
25404/65: lseek(10, 0, SEEK_END) = 498
25404/65: close(10) = 0
25404/65: open("/var/log/confignew.log", O_WRONLY|O_APPEND|O_CREAT, 0666)
= 10
25404/65: lseek(10, 0, SEEK_END) = 0
25404/65: close(10) = 0
25404/65: mkdir("/var/run/named/named", 0755) Err#17 EEXIST
25404/65: stat("/var/run/named/named/namednew.pid", 0x79D0F980)
Err#2 ENOENT
25404/65: unlink("/var/run/named/named/namednew.pid") Err#2 ENOENT
25404/65: open("/var/run/named/named/namednew.pid",
O_WRONLY|O_CREAT|O_EXCL, 0644) = 10
25404/65: fcntl(10, F_GETFD, 0x01A4) = 0
25404/65: getpid()= 25404 [25403]
25404/65: fstat(10, 0x79D0E9D0) = 0
25404/65: fstat(10, 0x79D0E8
RE: BIND 9.6.0-P1 on windows server 2008 32 bit hangs
Yes, I tried to downgrade to 9.50 p2 and the problem was there to. It's is looks like a bug on windows 2008 machine, isnt it? Also, you can see that there is 8 lines of the same messages. Each for 1 core CPU. -Original Message- From: Danny Mayer [mailto:ma...@gis.net] Sent: Monday, January 26, 2009 4:49 AM To: Kobi Shachar Cc: bind-users@lists.isc.org Subject: Re: BIND 9.6.0-P1 on windows server 2008 32 bit hangs Kobi Shachar wrote: > Recently I upgraded my bind machine to a new windows 2008 server web > edition 32 bit with 2 E5420 quad core CPU's. > > The server is configured with about 7000 master zone files. > > > > Since the upgrade, BIND hangs every 5-10 hours. > > I checked the logs and I saw these lines on the default log: > > > > 5-éðå-2009 07:20:03.832 client: error: UDP client handler shutting down > due to fatal receive error: host unreachable > > 25-éðå-2009 07:20:03.832 client: error: UDP client handler shutting down > due to fatal receive error: host unreachable > > 25-éðå-2009 07:20:03.832 client: error: UDP client handler shutting down > due to fatal receive error: host unreachable > > 25-éðå-2009 07:20:03.832 client: error: UDP client handler shutting down > due to fatal receive error: host unreachable > > 25-éðå-2009 07:20:03.832 client: error: UDP client handler shutting down > due to fatal receive error: host unreachable > > 25-éðå-2009 07:20:03.832 client: error: UDP client handler shutting down > due to fatal receive error: host unreachable > > 25-éðå-2009 07:20:03.833 client: error: UDP client handler shutting down > due to fatal receive error: host unreachable > > 25-éðå-2009 07:20:03.833 client: error: UDP client handler shutting down > due to fatal receive error: host unreachable > > > > After the service hangs, all the queries returned time out and there is > no answers anymore from the dns server. > > "rndc status" tells me that the service is up and running and zone > transfers are continued as usual. > > Only the DNS queries are stopped working and returning time out. > > > > Any idea? Upgrade. There were bugs in that version that were only fixed in the P1-W2 version. Either to 9.5.0-P2-W2, 9.5.1-P1 ot 9.6.0-P1. Danny ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unified Root - Domain Configuration Issue
Mark Andrews wrote: > In message <497cae4b.4020...@dougbarton.us>, Doug Barton writes: >> Joe Baptista wrote: >>> So a little more testing using firefox as an application gives us some >>> interesting results. Using the .TM TLD I entered http://tm/ into my >>> browsers. It did not work. Firefox replaced http://tm/ with >>> http://www.tm.com/ - which is not the web site I wanted to reach. >> In Firefox' titlebar enter 'about:config' (no quotes) then in the >> filter type 'keyword.enabled' and double-click that entry to toggle it >> to false. > > The correct fix for this is: > > browser.fixup.alternate.enabled -> false > > keyword.enabled -> false stop the seach engine lookup. D'oh! Forgot about the browser.fixup thing, thanks Mark. Doug ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
On 25-Jan-2009, at 23:06 , Barry Margolin wrote: In article , Matthew Pounsett wrote: In the example above, when I query for "IN A mx.xyz.com?" I do not get an address record back (A, )..instead I get a CNAME record. Requirements NOT met. Then there's something wrong with your resolver, since they're supposed to follow CNAME records automatically, and return the requested record type from the canonical name. You're right, of course. I was over simplifying my point, which was that the answer to the question asked is not an address record. I should probably know better than to do that. :) PGP.sig Description: This is a digitally signed message part ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
In article , Matthew Pounsett wrote: > In the example above, when I query for "IN A mx.xyz.com?" I do not get > an address record back (A, )..instead I get a CNAME record. > Requirements NOT met. Then there's something wrong with your resolver, since they're supposed to follow CNAME records automatically, and return the requested record type from the canonical name. There isn't even an option in the DNS spec to tell the resolver not to follow CNAMEs. The only way to avoid it is to query for the CNAME explicitly. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6.0-P1 on windows server 2008 32 bit hangs
Danny Mayer wrote: > Kobi Shachar wrote: >> Recently I upgraded my bind machine to a new windows 2008 server web >> edition 32 bit with 2 E5420 quad core CPU's. >> >> The server is configured with about 7000 master zone files. >> >> >> >> Since the upgrade, BIND hangs every 5-10 hours. >> >> I checked the logs and I saw these lines on the default log: >> >> >> >> 5-éðå-2009 07:20:03.832 client: error: UDP client handler shutting down >> due to fatal receive error: host unreachable >> >> 25-éðå-2009 07:20:03.832 client: error: UDP client handler shutting down >> due to fatal receive error: host unreachable >> >> 25-éðå-2009 07:20:03.832 client: error: UDP client handler shutting down >> due to fatal receive error: host unreachable >> >> 25-éðå-2009 07:20:03.832 client: error: UDP client handler shutting down >> due to fatal receive error: host unreachable >> >> 25-éðå-2009 07:20:03.832 client: error: UDP client handler shutting down >> due to fatal receive error: host unreachable >> >> 25-éðå-2009 07:20:03.832 client: error: UDP client handler shutting down >> due to fatal receive error: host unreachable >> >> 25-éðå-2009 07:20:03.833 client: error: UDP client handler shutting down >> due to fatal receive error: host unreachable >> >> 25-éðå-2009 07:20:03.833 client: error: UDP client handler shutting down >> due to fatal receive error: host unreachable >> >> >> >> After the service hangs, all the queries returned time out and there is >> no answers anymore from the dns server. >> >> "rndc status" tells me that the service is up and running and zone >> transfers are continued as usual. >> >> Only the DNS queries are stopped working and returning time out. >> >> >> >> Any idea? > > Upgrade. There were bugs in that version that were only fixed in the > P1-W2 version. Either to 9.5.0-P2-W2, 9.5.1-P1 ot 9.6.0-P1. > > Danny Sorry, I misread the subject line. Does this work with the BIND 9.5.0-P2-W2, 9.5.1-P1? Danny ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6.0-P1 on windows server 2008 32 bit hangs
Kobi Shachar wrote: > Recently I upgraded my bind machine to a new windows 2008 server web > edition 32 bit with 2 E5420 quad core CPU's. > > The server is configured with about 7000 master zone files. > > > > Since the upgrade, BIND hangs every 5-10 hours. > > I checked the logs and I saw these lines on the default log: > > > > 5-éðå-2009 07:20:03.832 client: error: UDP client handler shutting down > due to fatal receive error: host unreachable > > 25-éðå-2009 07:20:03.832 client: error: UDP client handler shutting down > due to fatal receive error: host unreachable > > 25-éðå-2009 07:20:03.832 client: error: UDP client handler shutting down > due to fatal receive error: host unreachable > > 25-éðå-2009 07:20:03.832 client: error: UDP client handler shutting down > due to fatal receive error: host unreachable > > 25-éðå-2009 07:20:03.832 client: error: UDP client handler shutting down > due to fatal receive error: host unreachable > > 25-éðå-2009 07:20:03.832 client: error: UDP client handler shutting down > due to fatal receive error: host unreachable > > 25-éðå-2009 07:20:03.833 client: error: UDP client handler shutting down > due to fatal receive error: host unreachable > > 25-éðå-2009 07:20:03.833 client: error: UDP client handler shutting down > due to fatal receive error: host unreachable > > > > After the service hangs, all the queries returned time out and there is > no answers anymore from the dns server. > > "rndc status" tells me that the service is up and running and zone > transfers are continued as usual. > > Only the DNS queries are stopped working and returning time out. > > > > Any idea? Upgrade. There were bugs in that version that were only fixed in the P1-W2 version. Either to 9.5.0-P2-W2, 9.5.1-P1 ot 9.6.0-P1. Danny ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNS LAN/WAN confusion
Hi all, thanks in advance for any help. It is greatly appreciated.
I'm struggling a bit with setting up master and slave name servers. My goal is
just to run my own name servers for mydomain.com. I am not concerned at all
with any internal DNS configuration. There are no workstations or anything like
that to worry about. The name servers are on different networks as you can see
from the example WAN ip addresses. My main confusion stems from what to put in
/etc/hosts and also what to use for reverse DNS. All of the examples I've seen
typically use the LAN ip of the server, but some reference the WAN ip. I've
tried various configurations, and sometimes things seem to work, but then they
flake out or some things work and some things don't. For example, if I look up
ns1.mydomain.com, I'll get the right IP, but if I on the terminal of ns1, I
cannot ping outside like google.com for instance. What I really need is for
someone to confirm or correct the way I have my various config files set up.
Below is the
contents of each config file for both the master and slave servers. Please
let me know if I have anything wrong, especially in regard to reverse dns and
/etc/hosts since changing these files seems to have the biggest impact on what
works and what doesn't. Here is the example information for my domain and
servers.
* Note: The master and slave LAN ips are similar, but they are not on the same
LAN.
The LAN ip of the master name server (ns1.mydomain.com) is 192.168.0.101
The WAN ip of the master name server (ns1.mydomain.com) is 111.122.133.144
The LAN ip of the secondary name server (ns2.mydomain.com) is 192.168.0.202
The WAN ip of the secondary name server (ns2.mydomain.com) is 222.233.244.255
The WAN ip of the mail server is 77.77.77.77
The WAN ip of mydomain.com is 88.88.88.88
## Master Name Server ##
## ns1.mydomain.com Files ##
File: /etc/hosts
127.0.0.1 localhost.localdomain localhost
111.122.133.144 ns1.mydomain.com ns1
# should ^ this be 192.168.0.101 instead?
###
File: /etc/bind/named.conf.local
zone "mydomain.com" {
type master;
file "/etc/bind/zones/mydomain.com.db";
allow-transfer { 222.233.244.255; };
};
zone "133.122.111.in-addr.arpa" {
type master;
file "/etc/bind/zones/rev.133.122.111.in-addr.arpa";
};
// Should the reverse DNS be this instead?:
// zone "0.168.192.in-addr.arpa" {
// type master;
// file "/etc/bind/zones/rev.0.168.192.in-addr.arpa";
// };
###
File: /etc/bind/zones/rev.133.122.111.in-addr.arpa (Obviously if the reverse
DNS above is wrong, then this file would be named:
/etc/bind/zones/rev.0.168.192.in-addr.arpa and the PTR would be 101 instead of
144.)
$TTL 1500
@ IN SOA ns1.mydomain.com admin.mydomain.com (
2009012324 ;serial
28800 ;refresh
3600 ;retry
604800 ;expire
38400 ) ;minimum 25 minutes
IN NS ns1.mydomain.com.
144 IN PTR ns1.mydomain.com.
###
File: /etc/bind/zones/mydomain.com.db
$TTL 1500
@ IN SOA ns1.mydomain.com. admin.mydomain.com (
2009012324 ;serial
28800 ;refresh
3600 ;retry
604800 ;expire
38400 ) ;minimum 25 minutes
mydomain.com. IN NS ns1.mydomain.com.
mydomain.com. IN NS ns2.mydomain.com.
ns1 IN A 111.122.133.144
ns2 IN A 222.233.244.255
mail IN A 77.77.77.77
mydomain.com. IN A 88.88.88.88
mydomain.com. IN MX 10 mail.mydomain.com.
###
File: /etc/bind/named.conf.options
options {
directory "/var/cache/bind";
forwarders {
123.123.123.123; // My ISP's DNS server.
};
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
###
File: /etc/resolv.conf
domain mydomain.com
search mydomain.com
nameserver 111.122.133.144
# Should ^ this be 192.168.0.101 instead?
###
File: /etc/hostname
ns1.mydomain.com
###
## Secondary Name server ###
## ns2.mydomain.com Files ##
##
Re: Unified Root - Domain Configuration Issue
In message <497cae4b.4020...@dougbarton.us>, Doug Barton writes: > Joe Baptista wrote: > > So a little more testing using firefox as an application gives us some > > interesting results. Using the .TM TLD I entered http://tm/ into my > > browsers. It did not work. Firefox replaced http://tm/ with > > http://www.tm.com/ - which is not the web site I wanted to reach. > > In Firefox' titlebar enter 'about:config' (no quotes) then in the > filter type 'keyword.enabled' and double-click that entry to toggle it > to false. The correct fix for this is: browser.fixup.alternate.enabled -> false keyword.enabled -> false stop the seach engine lookup. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
MX records are supposed to be pointed to the name the mail exhanger knows itself as. This will correspond to a A record. If I could work out a way to determine which A records don't correspond to the name by which the mail exchanger knows itself as I'd also have named issue a warning for such A records. Unfortunately there isn't a way to make such a determination. When a CNAME is used you configuration errors reported from MTA's when they try to send email to themselves. This still happens today. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
On Jan 25 2009, Chris Hills wrote: Perhaps one day MX records can be deprecated entirely in favor of SRV. Jabber got it right, and it would solve the e-mail server autodiscovery problem for clients in a generic non-proprietary manner. For example:- _smtp-server._tcp for servers, _smtp-client._tcp for clients. But would this satisfy the OP? The RDATA of an SRV record isn't meant to reference a CNAME any more than that of an MX record is. -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
Perhaps one day MX records can be deprecated entirely in favor of SRV. Jabber got it right, and it would solve the e-mail server autodiscovery problem for clients in a generic non-proprietary manner. For example:- _smtp-server._tcp for servers, _smtp-client._tcp for clients. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.6.0-P1 on windows server 2008 32 bit hangs
Recently I upgraded my bind machine to a new windows 2008 server web edition 32 bit with 2 E5420 quad core CPU's. The server is configured with about 7000 master zone files. Since the upgrade, BIND hangs every 5-10 hours. I checked the logs and I saw these lines on the default log: 5-ינו-2009 07:20:03.832 client: error: UDP client handler shutting down due to fatal receive error: host unreachable 25-ינו-2009 07:20:03.832 client: error: UDP client handler shutting down due to fatal receive error: host unreachable 25-ינו-2009 07:20:03.832 client: error: UDP client handler shutting down due to fatal receive error: host unreachable 25-ינו-2009 07:20:03.832 client: error: UDP client handler shutting down due to fatal receive error: host unreachable 25-ינו-2009 07:20:03.832 client: error: UDP client handler shutting down due to fatal receive error: host unreachable 25-ינו-2009 07:20:03.832 client: error: UDP client handler shutting down due to fatal receive error: host unreachable 25-ינו-2009 07:20:03.833 client: error: UDP client handler shutting down due to fatal receive error: host unreachable 25-ינו-2009 07:20:03.833 client: error: UDP client handler shutting down due to fatal receive error: host unreachable After the service hangs, all the queries returned time out and there is no answers anymore from the dns server. "rndc status" tells me that the service is up and running and zone transfers are continued as usual. Only the DNS queries are stopped working and returning time out. Any idea? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
Al Stu wrote: > ISC’s message that a CNAME/alias in an MX record is illegal is incorrect > and just an attempt by ISC to get people to go along with what is only a > perceived rather than actual standard/requirement, and should be removed > so as not to further the fallacy of this perceived perception of a > standard/requirement, as it is neither a standard nor a requirement, and > certainly not illegal. If you feel this is a bug in BIND, please send an e-mail to bind-b...@isc.org for consideration. Thanks, AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
No it is only two steps, see the attachment (sent in previous message). Both the CNAME and A record are returned for the mx.xyz.com DNS A request. And this does met the RFC requirements. - Original Message - From: "Matthew Pounsett" To: "Al Stu" Cc: Sent: Sunday, January 25, 2009 10:30 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal" ___ 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: reverse lookup to CNAME
> On Sat, Jan 24, 2009 at 9:21 PM, Matus UHLAR - fantomas > wrote: > > > > if metis.local is a CNAME, the PTR shouldn't point to it. On 25.01.09 10:14, John Bond wrote: > could you please explain this. Although it's good to remove irelevant part of the text you are replying to, this time you removed the relevant part. I'm pasting below... > When i tried this host did not resolve > the cname. i.e a host 1.1.1.1 returned metis.local. it did not know > to resolve metis.local as bob the host 1.1.1.1 returned that 1.1.1.1.in-addr.arpa is a CNAME to metis.local. It's not reverse record, the PTR is, and metis.local has no PTR. Even if it did, the PTR should be on 1.1.1.1.in-addr.arpa, you are putting one more unnecessary step into resolution. [pasted relevant text] > > bob-www-sol-l01 IN A 1.1.1.1 > > metisIN CNAME bob-www-sol-l01 > > > > zone for 1.1.1 > > > > 1 IN CNAME metis.local. On 23.01.09 23:06, Barry Margolin wrote: > Why don't you just use normal reverse DNS: > > zone for 1.1.1.in-addr.arpa > > 1 IN PTR metis.local. > IN PTR bob-www-sol-l01.local. accorging to the above, metis.local is a CNAME, so the reverse should point to bob-www-sol-l01.local. - pointing it to metis.local. would be incorrect. And although two or PTRs usually make no problems, it's recommended not to do that, because some SWs jsut can't handle that (even if they would all be correct). So, keep only PTR to bob-www-sol-l01.local. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
On 25-Jan-2009, at 13:15 , Al Stu wrote: Yes, blah was supposed to be srv1. I do receive both the CNAME and A records for the A mx.xyz.com query. See attached capture file. In the capture file three global search and replacements were performed to match the previous example. 1) domain name was replaced with xyz 2) server name was replaced with srv1 3) server ip address was replaced with 1.2.3.4 Requirements are met. Al, I'm sorry, but you're wrong. If you look closely at what you just typed, you'll see that's three steps.. not the two steps required by the MUST in the RFC. Your attachment didn't make it through the list manager. I suggest you paste in some dig output instead. If you do, you'll notice that the IP address you're receiving is in the ADDITIONAL section of the DNS message, which does not qualify as an ANSWER. I'm going to stop contributing to this thread now.. if you insist on ignoring the pointers people have given you to the text in the RFCs, and insist on reading your own interpretation into it, we cannot stop you. PGP.sig Description: This is a digitally signed message part ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
Attachment (hopefully) - Original Message - From: "Al Stu" To: Sent: Sunday, January 25, 2009 10:15 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal" Yes, blah was supposed to be srv1. I do receive both the CNAME and A records for the A mx.xyz.com query. See attached capture file. In the capture file three global search and replacements were performed to match the previous example. 1) domain name was replaced with xyz 2) server name was replaced with srv1 3) server ip address was replaced with 1.2.3.4 Requirements are met. - Original Message - From: "Matthew Pounsett" To: "Al Stu" Cc: Sent: Sunday, January 25, 2009 9:49 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal" ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users No. TimeSourceDestination Protocol Info 1 0.00192.168.1.16 192.168.1.1 DNS Standard query MX xyz.com Frame 1 (74 bytes on wire, 74 bytes captured) Ethernet II, Src: Usi_de:94:de (00:10:c6:de:94:de), Dst: Actionte_51:fa:72 (00:18:01:51:fa:72) Internet Protocol, Src: 192.168.1.16 (192.168.1.16), Dst: 192.168.1.1 (192.168.1.1) User Datagram Protocol, Src Port: 4482 (4482), Dst Port: domain (53) Domain Name System (query) [Response In: 2] Transaction ID: 0x0002 Flags: 0x0100 (Standard query) Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries No. TimeSourceDestination Protocol Info 2 0.063279192.168.1.1 192.168.1.16 DNS Standard query response MX 1 MX2.xyz.com MX 1 MX1.xyz.com Frame 2 (114 bytes on wire, 114 bytes captured) Ethernet II, Src: Actionte_51:fa:72 (00:18:01:51:fa:72), Dst: Usi_de:94:de (00:10:c6:de:94:de) Internet Protocol, Src: 192.168.1.1 (192.168.1.1), Dst: 192.168.1.16 (192.168.1.16) User Datagram Protocol, Src Port: domain (53), Dst Port: 4482 (4482) Domain Name System (response) [Request In: 1] [Time: 0.063279000 seconds] Transaction ID: 0x0002 Flags: 0x8180 (Standard query response, No error) Questions: 1 Answer RRs: 2 Authority RRs: 0 Additional RRs: 0 Queries Answers xyz.com: type MX, class IN, preference 1, mx MX2.xyz.com Name: xyz.com Type: MX (Mail exchange) Class: IN (0x0001) Time to live: 30 minutes Data length: 8 Preference: 1 Mail exchange: MX2.xyz.com xyz.com: type MX, class IN, preference 1, mx MX1.xyz.com Name: xyz.com Type: MX (Mail exchange) Class: IN (0x0001) Time to live: 30 minutes Data length: 8 Preference: 1 Mail exchange: MX1.xyz.com No. TimeSourceDestination Protocol Info 3 15.625151 192.168.1.16 192.168.1.1 DNS Standard query A mx1.xyz.com Frame 3 (78 bytes on wire, 78 bytes captured) Ethernet II, Src: Usi_de:94:de (00:10:c6:de:94:de), Dst: Actionte_51:fa:72 (00:18:01:51:fa:72) Internet Protocol, Src: 192.168.1.16 (192.168.1.16), Dst: 192.168.1.1 (192.168.1.1) User Datagram Protocol, Src Port: 4483 (4483), Dst Port: domain (53) Domain Name System (query) [Response In: 4] Transaction ID: 0x0003 Flags: 0x0100 (Standard query) Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries No. TimeSourceDestination Protocol Info 4 15.718055 192.168.1.1 192.168.1.16 DNS Standard query response CNAME srv1.xyz.com A 1.2.3.4 Frame 4 (120 bytes on wire, 120 bytes captured) Ethernet II, Src: Actionte_51:fa:72 (00:18:01:51:fa:72), Dst: Usi_de:94:de (00:10:c6:de:94:de) Internet Protocol, Src: 192.168.1.1 (192.168.1.1), Dst: 192.168.1.16 (192.168.1.16) User Datagram Protocol, Src Port: domain (53), Dst Port: 4483 (4483) Domain Name System (response) [Request In: 3] [Time: 0.092904000 seconds] Transaction ID: 0x0003 Flags: 0x8180 (Standard query response, No error) Questions: 1 Answer RRs: 2 Authority RRs: 0 Additional RRs: 0 Queries Answers mx1.xyz.com: type CNAME, class IN, cname srv1.xyz.com Name: mx1.xyz.com Type: CNAME (Canonical name for an alias) Class: IN (0x0001) Time to live: 30 minutes Data length: 14 Primary name: srv1.xyz.com srv1.xyz.com: type A, class IN, addr 1.2.3.4 Name: srv1.xyz.com Type: A (Host address) Class: IN (0x0001) Time to live: 30 minutes Data length: 4 Addr: 1.2.3.4 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinf
Re: Unified Root - Domain Configuration Issue
Joe Baptista wrote: > So a little more testing using firefox as an application gives us some > interesting results. Using the .TM TLD I entered http://tm/ into my > browsers. It did not work. Firefox replaced http://tm/ with > http://www.tm.com/ - which is not the web site I wanted to reach. In Firefox' titlebar enter 'about:config' (no quotes) then in the filter type 'keyword.enabled' and double-click that entry to toggle it to false. hth, Doug ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
Yes, blah was supposed to be srv1. I do receive both the CNAME and A records for the A mx.xyz.com query. See attached capture file. In the capture file three global search and replacements were performed to match the previous example. 1) domain name was replaced with xyz 2) server name was replaced with srv1 3) server ip address was replaced with 1.2.3.4 Requirements are met. - Original Message - From: "Matthew Pounsett" To: "Al Stu" Cc: Sent: Sunday, January 25, 2009 9:49 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal" ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
On 25-Jan-2009, at 12:41 , Al Stu wrote: "That domain name, when queried, MUST return at least one address record (e.g., A or RR) that gives the IP address of the SMTP server to which the message should be directed." @ 1800 IN A 1.2.3.4 srv1 1800 IN A 1.2.3.4 mx 1800 IN CNAME blah.xyz.com. @ 1800 IN MX 1 mx.xyz.com. Requirements met. In the example above, when I query for "IN A mx.xyz.com?" I do not get an address record back (A, )..instead I get a CNAME record. Requirements NOT met. I don't see the connection to srv1. Did you mean for "mx 1800 IN CNAME blah.xyz.com." to be "mx 1800 IN CNAME srv1.xyz.com."? That still doesn't meet requirements, because the record returned there as the ANSWER is a CNAME, not an A or record. I think you might be confusing the ADDITIONAL section of a DNS message with the ANSWER section. They are not the same thing. PGP.sig Description: This is a digitally signed message part ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
No I do not believe an extra step was added. Take the following example for instance. STMP server smtp.xyz.com. needs to send a message to some...@xyz.com. An MX lookup is performed for domain xyz.com. and the domain name of mx.xyz.com is returned. This is the first sentence: "When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name." Now an A lookup is performed for that domain name of mx.xyz.com. and returned are the name srv1.xyz.com with it's address of 1.2.3.4, and the alias name of mx.xyz.com is also included in the result. This is the second sentence: "That domain name, when queried, MUST return at least one address record (e.g., A or RR) that gives the IP address of the SMTP server to which the message should be directed." @ 1800 IN A 1.2.3.4 srv1 1800 IN A 1.2.3.4 mx 1800 IN CNAME blah.xyz.com. @ 1800 IN MX 1 mx.xyz.com. Requirements met. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
On Jan 25 2009, Al Stu wrote: RFC 2821 is much more recent and clearly documents in sections 3.5 and 5 that CNAME MX RR are permitted and are to be handled by SMTP MTA's. 3.6 Domains "Only resolvable, fully-qualified, domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or A RRs." 5. Address Resolution and Mail Handling "The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found instead, the resulting name is processed as if it were the initial name." These clearly refer to the case "CNAME record points to MX record", which no-one has any problems with, or at least BIND certainly doesn't. The "illegal" case is "MX record points to CNAME record", and RFC 2821 gives no sanction for that. Section 5.1 in RFC 5321 makes it even more explicit. You can, of course, turn off this particular check in BIND by specifying "check-mx-cname ignore;" in the options or zone statements. -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
On 25-Jan-2009, at 03:44 , Al Stu wrote: "When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name.That domain name, when queried, MUST return at least one address record (e.g., A or RR) that gives the IP address of the SMTP server to which the message should be directed." Correct. And when a that domain name is a CNAME pointing to an A RR the query returns not only the alias but also the real name and the IP address from the A RR. Thus meeting the requirements to "return at least one address record (e.t., A or RR)". But yet ISC seems to find it necessary to throw a message that it is "illegal", when it clearly is not. You've added an additional step in your second paragraph that is prohibited by the section you quoted in the first. The section from the RFC describes a situation where A is queried for and an MX record pointing to B is returned. When B is queried for, an address record MUST be the answer. The situation you have described is that A is queried for resulting in an MX record pointing to B. When B is queried for, a CNAME pointing to C is returned, and that when C is queried an address record is returned. Do you see the difference? The RFCs are quite clear that CNAMEs are not permitted in the RDATA for an MX. PGP.sig Description: This is a digitally signed message part ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
At 00:44 25-01-2009, Al Stu wrote: "When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name.That domain name, when queried, MUST return at least one address record (e.g., A or RR) that gives the IP address of the SMTP server to which the message should be directed." Correct. And when a that domain name is a CNAME pointing to an A RR the query returns not only the alias but also the real name and the IP address from the A RR. Thus meeting the requirements to "return at least one address record (e.t., A or RR)". But yet ISC seems to find it necessary to throw a message that it is "illegal", when it clearly is not. That's a liberal interpretation of the specifications and it's the opposite of the intent of the quoted paragraph. Implementors are expected to query for an address record only. Any other behavior such as the one described in your second paragraph is undefined. Further reading of that section elaborates on what to do if a CNAME is returned and there is a reference to RFC 2181 for a discussion of the prohibition of CNAMEs on the right-end side. RFC 974 specifies the algorithm to build the list of RRs and discusses about possible issues. It's the same algorithm in RFC 2821 and RFC 5321. The confusion about CNAMEs in MX records stems from the interpretation of the text about how CNAMEs on the left-hand side are handled and that was clarified in the latest revision of the specifications. Regards, -sm ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: reverse lookup to CNAME
On Sat, Jan 24, 2009 at 9:21 PM, Matus UHLAR - fantomas wrote: > > if metis.local is a CNAME, the PTR shouldn't point to it. > -- could you please explain this. When i tried this host did not resolve the cname. i.e a host 1.1.1.1 returned metis.local. it did not know to resolve metis.local as bob ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: reverse lookup to CNAME
On Sat, Jan 24, 2009 at 4:06 AM, Barry Margolin wrote: > Why don't you just use normal reverse DNS: > > zone for 1.1.1.in-addr.arpa > > 1 IN PTR metis.local. > IN PTR bob-www-sol-l01.local. I read there were problems having 2 PTR records for the same ip. I know its in the RFC but thought MTA's spat the dummy. i was wondering if i would be causing a simlar problem. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
"When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name.That domain name, when queried, MUST return at least one address record (e.g., A or RR) that gives the IP address of the SMTP server to which the message should be directed." Correct. And when a that domain name is a CNAME pointing to an A RR the query returns not only the alias but also the real name and the IP address from the A RR. Thus meeting the requirements to "return at least one address record (e.t., A or RR)". But yet ISC seems to find it necessary to throw a message that it is "illegal", when it clearly is not. - Original Message - From: "SM" To: Sent: Sunday, January 25, 2009 12:23 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal" At 22:11 24-01-2009, Al Stu wrote: Some people seem to think RFC 974 creates a standard which prohibits the use of CNAME/alias in MX records. But very much to the contrary RFC 974 demonstrates that CNAME/alias is permitted in MX records. RFC 974 is obsoleted by RFC 2821; the latter is obsoleted by RFC 5321. Quoting Section 5 of that RFC: "When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name. That domain name, when queried, MUST return at least one address record (e.g., A or RR) that gives the IP address of the SMTP server to which the message should be directed. Any other response, specifically including a value that will return a CNAME record when queried, lies outside the scope of this Standard. The prohibition on labels in the data that resolve to CNAMEs is discussed in more detail in RFC 2181, Section 10.3." ISC's message that a CNAME/alias in an MX record is illegal is incorrect and just an attempt by ISC to get people to go along with what is only a perceived rather than actual standard/requirement, and should be removed so as not to further the fallacy of this perceived perception of a standard/requirement, as it is neither a standard nor a requirement, and certainly not illegal. Pointing to a CNAME on the right-hand side of an MX record is incorrect and may affect mail delivery. This is not about perceived perception of a requirement (see the MUST return at least one address record in the quoted text). Regards, -sm ___ 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: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
RFC 2821 is much more recent and clearly documents in sections 3.5 and 5 that CNAME MX RR are permitted and are to be handled by SMTP MTA's. 3.6 Domains "Only resolvable, fully-qualified, domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or A RRs." 5. Address Resolution and Mail Handling "The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found instead, the resulting name is processed as if it were the initial name." This is also backed up by the older RFC 974. "There is one other special case. If the response contains an answer which is a CNAME RR, it indicates that REMOTE is actually an alias for some other domain name. The query should be repeated with the canonical domain name." So it is clear there should be no problem with using CNAME MX RR for mail systems that conform to these RFC's, and therefore no need for enforcing the use of only A RR, or even outputting an error/warning. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
At 22:11 24-01-2009, Al Stu wrote: Some people seem to think RFC 974 creates a standard which prohibits the use of CNAME/alias in MX records. But very much to the contrary RFC 974 demonstrates that CNAME/alias is permitted in MX records. RFC 974 is obsoleted by RFC 2821; the latter is obsoleted by RFC 5321. Quoting Section 5 of that RFC: "When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name. That domain name, when queried, MUST return at least one address record (e.g., A or RR) that gives the IP address of the SMTP server to which the message should be directed. Any other response, specifically including a value that will return a CNAME record when queried, lies outside the scope of this Standard. The prohibition on labels in the data that resolve to CNAMEs is discussed in more detail in RFC 2181, Section 10.3." ISC's message that a CNAME/alias in an MX record is illegal is incorrect and just an attempt by ISC to get people to go along with what is only a perceived rather than actual standard/requirement, and should be removed so as not to further the fallacy of this perceived perception of a standard/requirement, as it is neither a standard nor a requirement, and certainly not illegal. Pointing to a CNAME on the right-hand side of an MX record is incorrect and may affect mail delivery. This is not about perceived perception of a requirement (see the MUST return at least one address record in the quoted text). Regards, -sm ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
