Re: reverse lookup to CNAME
On Sun, Jan 25, 2009 at 6:39 PM, Matus UHLAR - fantomas uh...@fantomas.sk wrote: 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. Ok thanks for the response. Looks like my best bet is to stick with the following. zone for local bob-www-sol-l01 IN A 1.1.1.1 metisIN CNAME bob-www-sol-l01 zone for 1.1.1 1 INPTR bob-www-sol-l01.local cheers ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.4.x vs 9.6.x - pid-file check and creation
At 09:33 26/01/2009, Mark Andrews wrote:
In message 200901260742.n0q7gjqn029...@mail46.nsc.no, Jan Arild =?iso-8859-1?
Q?Lindstr=F8m?= writes:
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.pi=
d': Permission denied
26-Jan-2009 08:14:22.728 general: exiting (due to early fatal error)
The log message should say couldn't mkdir /var/run/named.
The wrong path is being logged.
You either need to create /var/run/named with appropriate
permissions so that named can write to it or change /var/run's
It does exists as you can see from the ls output I included. And named is
owner of it and hence have full permissions on it (/var/run/named/).
Problem is that Solaris returnes EACCESS and not EEXISTS. So just running mkdir
to check if a directory exists does not work on Solaris. One gets an EACCES and
the
code fails.
permissions so that named can create /var/run/named.
Named will continue if mkdir(/var/run/named) returns EEXISTS.
Wich it will not on Solaris if you do not have the perm to create it, even
though it
exists and you have full perm on it.
?
Mark
/*
* Make the containing directory if it doesn't exist.
*/
slash = strrchr(pidfile, '/');
if (slash != NULL slash != pidfile) {
*slash = '\0';
mode = S_IRUSR | S_IWUSR | S_IXUSR; /* u=rwx */
mode |= S_IRGRP | S_IXGRP; /* g=rx */
mode |= S_IROTH | S_IXOTH; /* o=rx */
n = mkdir(pidfile, mode);
if (n == -1 errno != EEXIST) {
isc__strerror(errno, strbuf, sizeof(strbuf));
(*report)(couldn't mkdir %s': %s, filename,
strbuf);
free(pidfile);
pidfile = NULL;
return;
}
*slash = '/';
}
BIND 9.6.0-P1 truss.out:
--CUT--
25123/65: stat(/dev/urandom, 0x79D0FA00)=3D 0
25123/65: open(/dev/urandom, O_RDONLY|O_NONBLOCK) =3D 9
25123/65: fcntl(9, F_GETFL) =3D 8320
25123/65: fcntl(9, F_SETFL, FOFFMAX|FNONBLOCK)=3D 0
25123/65: setgid(21) =3D 0
25123/65: setuid(21) =3D 0
25123/65: access(., W_OK) =3D 0
25123/65: open(/var/log/namednew.log, O_WRONLY|O_APPEND|O_CREAT, 06=
66) =3D 10
25123/65: lseek(10, 0, SEEK_END) =3D 332
25123/65: close(10) =3D 0
25123/65: open(/var/log/confignew.log, O_WRONLY|O_APPEND|O_CREAT, 0=
666) =3D 10
25123/65: lseek(10, 0, SEEK_END) =3D 0
25123/65: close(10) =3D 0
25123/65: mkdir(/var/run/named, 0755) Err#13 EACC=
ES [ALL]
25123/65: stat(/var/log/namednew.log, 0x79D0F3C0) =3D 0
25123/65: open(/var/log/namednew.log, O_WRONLY|O_APPEND|O_CREAT, 06=
66) =3D 10
25123/65: lseek(10, 0, SEEK_END) =3D 332
25123/65: fstat(10, 0x79D0E540) =3D 0
25123/65: fstat(10, 0x79D0E410) =3D 0
25123/65: ioctl(10, TCGETA, 0x79D0E47C) Err#25 ENOT=
TY
25123/65: write(10, 0x10502E754, 97) =3D 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) =3D 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 inste=
ad
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
error sending response log messages
Hello everyone, I've been seeing these syslog messages for about a week on a FreeBSD server running BIND 9.4.3-P1: Jan 25 02:35:21 asimov named[145]: client 206.71.158.30#138: error sending response: permission denied Jan 25 03:43:32 asimov named[145]: client 206.71.158.30#138: error sending response: permission denied Jan 25 04:49:59 asimov named[145]: client 206.71.158.30#139: error sending response: permission denied Jan 25 05:15:40 asimov named[145]: client 66.230.160.1#139: error sending response: permission denied Jan 25 07:45:11 asimov named[145]: client 206.71.158.30#139: error sending response: permission denied Jan 25 07:56:26 asimov named[145]: client 206.71.158.30#138: error sending response: permission denied Jan 25 08:10:29 asimov named[145]: client 206.71.158.30#138: error sending response: permission denied Jan 25 08:54:34 asimov named[145]: client 206.71.158.30#138: error sending response: permission denied Jan 25 09:16:41 asimov named[145]: client 206.71.158.30#138: error sending response: permission denied Jan 25 10:03:51 asimov named[145]: client 206.71.158.30#445: error sending response: permission denied Ports 135-139 and 445 are denied by the firewall on the outside interface. It looks like it might be some kind of Windows exploit, but I've Googled and searched the BIND mailing lists, and haven't found any clues yet. Has anybody else seen this? Thanks! Andre ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: update my domaine from any where
update de mon domaine andre chaudier___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Conflicting glue records?
For someone to register a domain and listing our server name with a bogus IP, the registry has to be incredibly careless I wonder if he is seeing the same thing I was a few days ago. I had a certain *.edu host listed as a nameserver of mine with several registries (gandi for .com, arin for in-addr.arpa and nro for rDNS in 2002:: space.) Last friday mail stopped flowing from my machine to this nameserver because someone was injecting a stale A-record into gtld-servers.net (the address injected was formerly correct, but changed over a year ago). This record either hadn't appeared before or my bind ignored it up to this point. Could something have changed with bind 9.5.1-P1 that would cause it to put more value on glue/host records than it did before? This command clearly showed an A-record with an old, now incorrect ipv4 address. dig mgm.mit.edu @a.gtld-servers.net a As a quick fix I dropped the nameserver in question from gandi and nro (arin is still in the stone age and wants you to be their pen-pal, so nothing has been changed there.) The problem seems to have fixed itself within 24 hours of making the changes at the two registries mentioned. Weird huh? -wolfgang -- Wolfgang S. Rupprecht http://www.full-steam.org/ (ipv6-only) You may need to config 6to4 to see the above pages. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Newbie question about registrar DNS servers and NS records
I inherited a Bind DNS server set up for a company that runs a number of web site. I'm in the process of cleaning up the zone files and adding additional slave DNS servers and I haven't got my head around NS records yet. When a domain is registered you specify what DNS servers will be providing the zone files for the domain. If that is the case why are there NS records in my zone files that point to my own DNS servers? Is that information ever used? Thanks ___ 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
I have not copied the entire thread. 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. If I have in DNS cn IN CNAME realname and I query for cn, the DNS resolver will return realname. BIND also returns the A record for realname. Is this a requirement? If not, then mx IN 10 MX cn will result in: 1) the MX query returning cn, 2) the cn query returning realname, 3) a third (and RFC-breaking) query to get the A for realname. There are only two queries if the resolver returns the A record along with the realname of the CNAME record. -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 222, Room D209 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Collision detection by reverse DNS lookup?
I am looking to set up DHCP in an environment that does not support Dynamic DNS. There are many servers that will not be using DHCP in this environment. Ideally, I would like to do collision detection both by ping (which I know can be done) and reverse DNS lookup. I know that ping collision detection is possible. How about reverse DNS lookup? Thanks for your thoughts! John ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Conflicting glue records?
On Jan 26 2009, Wolfgang S. Rupprecht wrote: For someone to register a domain and listing our server name with a bogus IP, the registry has to be incredibly careless I wonder if he is seeing the same thing I was a few days ago. I had a certain *.edu host listed as a nameserver of mine with several registries (gandi for .com, arin for in-addr.arpa and nro for rDNS in 2002:: space.) Last friday mail stopped flowing from my machine to this nameserver because someone was injecting a stale A-record into gtld-servers.net (the address injected was formerly correct, but changed over a year ago). This record either hadn't appeared before or my bind ignored it up to this point. Could something have changed with bind 9.5.1-P1 that would cause it to put more value on glue/host records than it did before? This command clearly showed an A-record with an old, now incorrect ipv4 address. dig mgm.mit.edu @a.gtld-servers.net a As a quick fix I dropped the nameserver in question from gandi and nro (arin is still in the stone age and wants you to be their pen-pal, so nothing has been changed there.) The problem seems to have fixed itself within 24 hours of making the changes at the two registries mentioned. Weird huh? See promoting glue to answer, and the evils thereof, passim. In particular https://lists.isc.org/pipermail/bind-users/2008-December/074107.html https://lists.isc.org/pipermail/bind-users/2008-December/074164.html -- 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 26.01.09 09:19, bsfin...@anl.gov wrote: If I have in DNS cn IN CNAME realname and I query for cn, the DNS resolver will return realname. BIND also returns the A record for realname. Is this a requirement? If not, then mx IN 10 MX cn will result in: 1) the MX query returning cn, 2) the cn query returning realname, 3) a third (and RFC-breaking) query to get the A for realname. There are only two queries if the resolver returns the A record along with the realname of the CNAME record. according to RFC1035 sect. 3.3.9 MX records cause type A additional section processing for the host specified by EXCHANGE. according to RFC2181 sect 10.3. The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. It can also have other RRs, but never a CNAME RR. Additional section processing does not include CNAME records... Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. -- 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. The box said 'Requires Windows 95 or better', so I bought a Macintosh. ___ 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
Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. Above statement, belief, perception etc. has already been proven to be a fallacy (see the network trace attached to one of the previous messages). Both the CNAME and A record is in fact returned, unless the CNAME RR points to some other zone such as say smtp.googlemail.com. So within the zone SMTP requirements are in fact met when the MX RR is a CNAME. So there is no need to prevent this nor to label it as illegal. The MX RR CNAME check should be improved to include this case and not throw a message if the MX RR CNAME is resolvable within the zone. - Original Message - From: Matus UHLAR - fantomas uh...@fantomas.sk To: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:18 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On 26.01.09 09:19, bsfin...@anl.gov wrote: If I have in DNS cn IN CNAME realname and I query for cn, the DNS resolver will return realname. BIND also returns the A record for realname. Is this a requirement? If not, then mx IN 10 MX cn will result in: 1) the MX query returning cn, 2) the cn query returning realname, 3) a third (and RFC-breaking) query to get the A for realname. There are only two queries if the resolver returns the A record along with the realname of the CNAME record. according to RFC1035 sect. 3.3.9 MX records cause type A additional section processing for the host specified by EXCHANGE. according to RFC2181 sect 10.3. The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. It can also have other RRs, but never a CNAME RR. Additional section processing does not include CNAME records... Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. -- 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. The box said 'Requires Windows 95 or better', so I bought a Macintosh. ___ 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: error sending response log messages
In message 497caef2.80...@yahoo.com, Andre LeClaire writes: Hello everyone, I've been seeing these syslog messages for about a week on a FreeBSD server running BIND 9.4.3-P1: Jan 25 02:35:21 asimov named[145]: client 206.71.158.30#138: error sending response: permission denied Jan 25 03:43:32 asimov named[145]: client 206.71.158.30#138: error sending response: permission denied Jan 25 04:49:59 asimov named[145]: client 206.71.158.30#139: error sending response: permission denied Jan 25 05:15:40 asimov named[145]: client 66.230.160.1#139: error sending response: permission denied Jan 25 07:45:11 asimov named[145]: client 206.71.158.30#139: error sending response: permission denied Jan 25 07:56:26 asimov named[145]: client 206.71.158.30#138: error sending response: permission denied Jan 25 08:10:29 asimov named[145]: client 206.71.158.30#138: error sending response: permission denied Jan 25 08:54:34 asimov named[145]: client 206.71.158.30#138: error sending response: permission denied Jan 25 09:16:41 asimov named[145]: client 206.71.158.30#138: error sending response: permission denied Jan 25 10:03:51 asimov named[145]: client 206.71.158.30#445: error sending response: permission denied Ports 135-139 and 445 are denied by the firewall on the outside interface. Why do you care about what port you are sending to? Just allow named to send its replies. It looks like it might be some kind of Windows exploit, but I've Googled and searched the BIND mailing lists, and haven't found any clues yet. Has anybody else seen this? Thanks! Andre ___ 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: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: reverse lookup to CNAME
-Original Message- [ ... ] 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. Section 3.3.12 of RFC 1035 (PTR RDATA format) appears to say that no constraints are placed upon a domain-name that is the RDATA of a PTR record, that it is simple data and no special meaning or further processing is associated with it (hence implying that it is ok if that domain-name is defined as a CNAME somewhere else in the domain space). Is that not the case? Is there some other part of the DNS specification that forbids it? Ben Bridges -- 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
What are these entries in the log file - query: . IN NS +?
Folks Warning - I know just enough about Bind to be dangerous. Which is why I'm asking. I just noticed that our small scale Bind server as a lot of the following lines. 26-Jan-2009 14:28:24.004 client 76.9.16.171#23101: query: . IN NS + 26-Jan-2009 14:28:58.254 client 63.217.28.226#28035: query: . IN NS + 26-Jan-2009 14:29:00.691 client 63.217.28.226#35549: query: . IN NS + 26-Jan-2009 14:29:26.332 client 76.9.16.171#19817: query: . IN NS + As far as I can tell from the same 5 or 20 IP addresses. I haven't seen these lines before. 1) What am I doing wrong? If anything. 2) What are they? Thanks, Tony -- Tony Toews, Microsoft Access MVP Please respond only in the newsgroups so that others can read the entire thread of messages. Microsoft Access Links, Hints, Tips Accounting Systems at http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ ___ 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 Tue, 2009-01-27 at 07:43, Danny Thomas wrote: Al Stu wrote: So within the zone SMTP requirements are in fact met when the MX RR is a CNAME. you might argue the line of it being OK when additional processing includes an A record. In all the time its taken him to type his rants and raves and have his little dummy spit, he could have gone and changed the MX to be a real name, and not bored the rest of us because he cant read modern RFC's. Possible courses of action * disable the check-mx-cname in your config As was pointed out to him days ago, but yet he persists in trolling, I like most I suspect stopped reading his rants days ago. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What are these entries in the log file - query: . IN NS +?
To: comp-protocols-dns-b...@isc.org From: Tony Toews [MVP] tto...@telusplanet.net Subject: What are these entries in the log file - query: . IN NS +? Date: Mon, 26 Jan 2009 21:45:18 GMT Folks Warning - I know just enough about Bind to be dangerous. Which is why I'm asking. I just noticed that our small scale Bind server as a lot of the following lines. 26-Jan-2009 14:28:24.004 client 76.9.16.171#23101: query: . IN NS + 26-Jan-2009 14:28:58.254 client 63.217.28.226#28035: query: . IN NS + 26-Jan-2009 14:29:00.691 client 63.217.28.226#35549: query: . IN NS + 26-Jan-2009 14:29:26.332 client 76.9.16.171#19817: query: . IN NS + As far as I can tell from the same 5 or 20 IP addresses. I haven't seen these lines before. 1) What am I doing wrong? If anything. You are doing nothing wrong. 2) What are they? They look like the DDoS being discussed on the NANOG list. Have you implemented BCP38? If not, why not... Regards, Gregory Hicks - Gregory Hicks | Principal Systems Engineer | Direct: 408.569.7928 People sleep peaceably in their beds at night only because rough men stand ready to do violence on their behalf -- George Orwell The price of freedom is eternal vigilance. -- Thomas Jefferson The best we can hope for concerning the people at large is that they be properly armed. --Alexander Hamilton ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Forcing a secondary update...
Without getting into how I managed to accomplish this, I have wound up with a secondary DNS that has incorrect information in it but the serial numbers are the same as on the master. So, my question is: how can I get the secondary to sync up? I presume all I would need to do is make a single change to the zones on the master, thus changing the serial number, and causing the secondary to update. The info in the master is correct, so I really don't need to change anything, but I could add something then delete it. Is there an automated way I can do this, or batch method? There are just enough zones as to make this a real hassle if I were to do it one by one. Jeff J. ___ 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 all the time its taken him to type his rants and raves and have his little dummy spit, he could have gone and changed the MX to be a real name, ... - Noel Butler Wow, such narrow mindedness. I like most I suspect stopped reading his rants days ago. - Noel Butler And yet here you are continuing to proliferate the thread. Thank you! - Original Message - From: Noel Butler To: Danny Thomas Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 2:23 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On Tue, 2009-01-27 at 07:43, Danny Thomas wrote: Al Stu wrote: So within the zone SMTP requirements are in fact met when the MX RR is a CNAME. you might argue the line of it being OK when additional processing includes an A record. In all the time its taken him to type his rants and raves and have his little dummy spit, he could have gone and changed the MX to be a real name, and not bored the rest of us because he cant read modern RFC's. Possible courses of action * disable the check-mx-cname in your config As was pointed out to him days ago, but yet he persists in trolling, I like most I suspect stopped reading his rants days ago. -- ___ 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
In message 2d378cb064ba4d06880aed8ed81f3...@ahsnbw1, Al Stu writes: Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. Above statement, belief, perception etc. has already been proven to be a fallacy (see the network trace attached to one of the previous messages). Both the CNAME and A record is in fact returned, unless the CNAME RR points to some other zone such as say smtp.googlemail.com. Please show one vendor that follows a CNAME when processing the *additional* section. AFAIK there is no vendor that does this. Named doesn't. CNAME is followed when processing the *answer* section. So within the zone SMTP requirements are in fact met when the MX RR is a CNAME. So there is no need to prevent this nor to label it as illegal. The MX RR CNAME check should be improved to include this case and not throw a message if the MX RR CNAME is resolvable within the zone. A lot of the reason why people think they can do this is that it doesn't always blow up in their faces when they do it. When there is only one MX record and that name points to a CNAME the MX records are not looked up on the mail exchanger so things don't blow up. Have multiple MX records with different preferences and point those at CNAMEs then thing start blowing up because the higher preference mail exchanger does lookup the MX RRset and does processes it. That is when things blow up. The rules are there to prevent this situation. The message is staying. If you don't want to see it turn it off in named.conf but don't log a bug report complaining that we didn't detect the misconfiguration. Mark - Original Message - From: Matus UHLAR - fantomas uh...@fantomas.sk To: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:18 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On 26.01.09 09:19, bsfin...@anl.gov wrote: If I have in DNS cn IN CNAME realname and I query for cn, the DNS resolver will return realname. BIND also returns the A record for realname. Is this a requirement? If not, then mx IN 10 MX cn will result in: 1) the MX query returning cn, 2) the cn query returning realname, 3) a third (and RFC-breaking) query to get the A for realname. There are only two queries if the resolver returns the A record along with the realname of the CNAME record. according to RFC1035 sect. 3.3.9 MX records cause type A additional section processing for the host specified by EXCHANGE. according to RFC2181 sect 10.3. The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. It can also have other RRs, but never a CNAME RR. Additional section processing does not include CNAME records... Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. -- 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. The box said 'Requires Windows 95 or better', so I bought a Macintosh. ___ 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 -- 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: Forcing a secondary update...
On 26-Jan-2009, at 17:50, Jeff Justice wrote: Without getting into how I managed to accomplish this, I have wound up with a secondary DNS that has incorrect information in it but the serial numbers are the same as on the master. So, my question is: how can I get the secondary to sync up? I presume all I would need to do is make a single change to the zones on the master, thus changing the serial number, and causing the secondary to update. The info in the master is correct, so I really don't need to change anything, but I could add something then delete it. Is there an automated way I can do this, or batch method? There are just enough zones as to make this a real hassle if I were to do it one by one. An update to the serial number is the indicator to the master, and then to the slaves, that some change has occurred and the zone should be re-loaded or transferred.. but an actual change to the data isn't required to make that happen. You can just update the serial number on the master and tell it to reload without altering any other data... the rest will take care of itself. Matt 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: What are these entries in the log file - query: . IN NS +?
Gregory Hicks ghi...@hicks-net.net wrote: 2) What are they? They look like the DDoS being discussed on the NANOG list. Have you implemented BCP38? If not, why not... I have no idea what BCP38 is and how I can implement that. Would you be so kind as to supply links relevant to Windows 2003 Server? Thanks, Tony -- Tony Toews, Microsoft Access MVP Please respond only in the newsgroups so that others can read the entire thread of messages. Microsoft Access Links, Hints, Tips Accounting Systems at http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What are these entries in the log file - query: . IN NS +?
Noel Butler noel.but...@ausics.net wrote: This is not your config, so long as you are not answering thats fine. How do I know I'm not answering those? It's a forged request asking you to participate in a DDoS thats been going on since last Wedensday, it's best if you firewall off your replies to those IP's so you don't participate in harming the innocent victims. I doubt the current firewall, the one built into Windows 2003 Server, is capable of blocking specific IP addresses but I'll check. Tony -- Tony Toews, Microsoft Access MVP Please respond only in the newsgroups so that others can read the entire thread of messages. Microsoft Access Links, Hints, Tips Accounting Systems at http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What are these entries in the log file - query: . IN NS +?
Hi Tony, On Tue, 2009-01-27 at 09:35, Tony Toews [MVP] wrote: Noel Butler noel.but...@ausics.net wrote: This is not your config, so long as you are not answering thats fine. How do I know I'm not answering those? Since your on win, I can't help you, but whatever your packet monitor is, see if you are replying to their requests, even with a REFUSED response. It's a forged request asking you to participate in a DDoS thats been going on since last Wedensday, it's best if you firewall off your replies to those IP's so you don't participate in harming the innocent victims. I doubt the current firewall, the one built into Windows 2003 Server, is capable of blocking specific IP addresses but I'll check. In that case maybe on your router? Apply a inbound request from them on port 53 udp only, that way you wont affect real traffic (hopefully) it does seemed to have died off dramatically here now. Cheers ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disable cache in bind 9.6
At Thu, 22 Jan 2009 09:12:11 +0300, Dmitry Rybin kirg...@corbina.net wrote: +50 views of zone data + memory for 10 clients + You have a 32bit build which will give a maximum of 2G data. You are just trying to cram too much into too small a place. OK. May be you can give any recomendation? As Mark said, having 50 views, each of which contains non-negligible amount of cache, is an excessive condition. Also, since the matching view is identified by linear search for every query, it may also impact your query processing performance. So, you'd primarily consider reducing the number of views anyway. Still, I noticed cache management may not work well (even with a single view) especially when it's multi-threaded and configured with a small max-cache-size such as 16MB. (It's ironical that using a small max-cache-size could hinder cache cleaning, resulting in larger memory footprints). I'm developing a fix to this problem. Can you try the patch available at: http://www.jinmei.org/patch/bind9-lrucache.diff (should be cleanly applicable to 9.6). and let me know if it mitigates the problem? Other recommendations: - I previously suggested using a separate cache-only view and forward all recursive queries to that view. Have you tried that? If you have, didn't it work as I hoped? - BIND 9.7 will have a new option attach-cache exactly for such an extraordinary operational environment as yours: it allows multiple views to share a single cache to save memory. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ 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
How about these two? nullmx.domainmanager.com Non-authoritative answer: Name:mta.dewile.net Address: 69.59.189.80 Aliases: nullmx.domainmanager.com smtp.secureserver.net Non-authoritative answer: Name:smtp.where.secureserver.net Address: 208.109.80.149 Aliases: smtp.secureserver.net There are two reasons it does not blow up in peoples face. 1) If it is in the CNAME RR points to an A record in the same zone, both the A record and the CNAME record are returned, thus meeting the A record requirement. 2) SMTP servers are required to accept an alias and look it up. Thus there is no need for this. And no it does not matter if there are multiple MX records with different preferences values. - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 2:55 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 2d378cb064ba4d06880aed8ed81f3...@ahsnbw1, Al Stu writes: Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. Above statement, belief, perception etc. has already been proven to be a fallacy (see the network trace attached to one of the previous messages). Both the CNAME and A record is in fact returned, unless the CNAME RR points to some other zone such as say smtp.googlemail.com. Please show one vendor that follows a CNAME when processing the *additional* section. AFAIK there is no vendor that does this. Named doesn't. CNAME is followed when processing the *answer* section. So within the zone SMTP requirements are in fact met when the MX RR is a CNAME. So there is no need to prevent this nor to label it as illegal. The MX RR CNAME check should be improved to include this case and not throw a message if the MX RR CNAME is resolvable within the zone. A lot of the reason why people think they can do this is that it doesn't always blow up in their faces when they do it. When there is only one MX record and that name points to a CNAME the MX records are not looked up on the mail exchanger so things don't blow up. Have multiple MX records with different preferences and point those at CNAMEs then thing start blowing up because the higher preference mail exchanger does lookup the MX RRset and does processes it. That is when things blow up. The rules are there to prevent this situation. The message is staying. If you don't want to see it turn it off in named.conf but don't log a bug report complaining that we didn't detect the misconfiguration. Mark - Original Message - From: Matus UHLAR - fantomas uh...@fantomas.sk To: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:18 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On 26.01.09 09:19, bsfin...@anl.gov wrote: If I have in DNS cn IN CNAME realname and I query for cn, the DNS resolver will return realname. BIND also returns the A record for realname. Is this a requirement? If not, then mx IN 10 MX cn will result in: 1) the MX query returning cn, 2) the cn query returning realname, 3) a third (and RFC-breaking) query to get the A for realname. There are only two queries if the resolver returns the A record along with the realname of the CNAME record. according to RFC1035 sect. 3.3.9 MX records cause type A additional section processing for the host specified by EXCHANGE. according to RFC2181 sect 10.3. The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. It can also have other RRs, but never a CNAME RR. Additional section processing does not include CNAME records... Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. -- 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. The box said 'Requires Windows 95 or better', so I bought a Macintosh. ___ 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 -- 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What are these entries in the log file - query: . IN NS +?
In message fvhsn493t2pb75c93nm1s14lkttiu0i...@4ax.com, Tony Toews [MVP] wri tes: Gregory Hicks ghi...@hicks-net.net wrote: 2) What are they? They look like the DDoS being discussed on the NANOG list. Have you implemented BCP38? If not, why not... I have no idea what BCP38 is and how I can implement that. http://www.ietf.org/rfc/rfc3704.txt Would you be so k ind as to supply links relevant to Windows 2003 Server? Thanks, Tony -- Tony Toews, Microsoft Access MVP Please respond only in the newsgroups so that others can read the entire thread of messages. Microsoft Access Links, Hints, Tips Accounting Systems at http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ ___ 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: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What are these entries in the log file - query: . IN NS +?
In article gllha9$2ot...@sf1.isc.org, Tony Toews [MVP] tto...@telusplanet.net wrote: Gregory Hicks ghi...@hicks-net.net wrote: 2) What are they? They look like the DDoS being discussed on the NANOG list. Have you implemented BCP38? If not, why not... I have no idea what BCP38 is and how I can implement that. Would you be so kind as to supply links relevant to Windows 2003 Server? BCP38 is not something you implement, it's something that has to be implemented by the ISPs hosting the attacking systems. They have to block forged source IPs from their customers. Since there are many ISPs out there that are too lazy, incompetent, or just don't care, where probably never going to be rid of these kinds of attacks. -- 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: Forcing a secondary update...
In article glleo1$2na...@sf1.isc.org, Jeff Justice listacco...@starionline.com wrote: Without getting into how I managed to accomplish this, I have wound up with a secondary DNS that has incorrect information in it but the serial numbers are the same as on the master. So, my question is: how can I get the secondary to sync up? I presume all I would need to do is make a single change to the zones on the master, thus changing the serial number, and causing the secondary to update. The info in the master is correct, so I really don't need to change anything, but I could add something then delete it. Is there an automated way I can do this, or batch method? There are just enough zones as to make this a real hassle if I were to do it one by one. You could delete the zone files on the slave server and then restart named. When it starts up and doesn't find zone files, it will have to pull them from the master. -- 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: What are these entries in the log file - query: . IN NS +?
In article gllmur$2sh...@sf1.isc.org, Mark Andrews mark_andr...@isc.org wrote: In message fvhsn493t2pb75c93nm1s14lkttiu0i...@4ax.com, Tony Toews [MVP] wri tes: Gregory Hicks ghi...@hicks-net.net wrote: 2) What are they? They look like the DDoS being discussed on the NANOG list. Have you implemented BCP38? If not, why not... I have no idea what BCP38 is and how I can implement that. http://www.ietf.org/rfc/rfc3704.txt That's BCP84. But in either case, implementing it doesn't protect you from attacks like this, it only prevents you from being the source of attacks on others. -- 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: Forcing a secondary update...
maybe this will help http://peppyheppy.com/2008/1/18/bulk-zone-file-serial-number-increment --- On Tue, 1/27/09, Barry Margolin bar...@alum.mit.edu wrote: From: Barry Margolin bar...@alum.mit.edu Subject: Re: Forcing a secondary update... To: comp-protocols-dns-b...@isc.org Date: Tuesday, January 27, 2009, 2:12 PM In article glleo1$2na...@sf1.isc.org, Jeff Justice listacco...@starionline.com wrote: Without getting into how I managed to accomplish this, I have wound up with a secondary DNS that has incorrect information in it but the serial numbers are the same as on the master. So, my question is: how can I get the secondary to sync up? I presume all I would need to do is make a single change to the zones on the master, thus changing the serial number, and causing the secondary to update. The info in the master is correct, so I really don't need to change anything, but I could add something then delete it. Is there an automated way I can do this, or batch method? There are just enough zones as to make this a real hassle if I were to do it one by one. You could delete the zone files on the slave server and then restart named. When it starts up and doesn't find zone files, it will have to pull them from the master. -- 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 ___ 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 message 0aa37ce829ba458b9ba2d199a6d96...@ahsnbw1, Al Stu writes: How about these two? nullmx.domainmanager.com Non-authoritative answer: Name:mta.dewile.net Address: 69.59.189.80 Aliases: nullmx.domainmanager.com smtp.secureserver.net Non-authoritative answer: Name:smtp.where.secureserver.net Address: 208.109.80.149 Aliases: smtp.secureserver.net Which just goes to show you don't understand the issue. Ask the correct question and you will see a response which demonstates what people are talking about. If the server was doing what you say it does you would see the CNAME in the additional section. ; DiG 9.3.6-P1 mx secureserver.net @cns2.secureserver.net. +norec ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 21506 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;secureserver.net. IN MX ;; ANSWER SECTION: secureserver.net. 3600IN MX 0 smtp.secureserver.net. ;; AUTHORITY SECTION: secureserver.net. 3600IN NS cns2.secureserver.net. secureserver.net. 3600IN NS cns1.secureserver.net. ;; ADDITIONAL SECTION: cns1.secureserver.net. 3600IN A 208.109.255.100 cns2.secureserver.net. 3600IN A 216.69.185.100 ;; Query time: 181 msec ;; SERVER: 216.69.185.100#53(216.69.185.100) ;; WHEN: Tue Jan 27 12:54:26 2009 ;; MSG SIZE rcvd: 125 There are two reasons it does not blow up in peoples face. 1) If it is in the CNAME RR points to an A record in the same zone, both the A record and the CNAME record are returned, thus meeting the A record requirement. 2) SMTP servers are required to accept an alias and look it up. Thus there is no need for this. And no it does not matter if there are multiple MX records with different preferences values. Which just means you have not ever experienced the problems causes. MTA are not required to look up the addresses of all the mail exchangers in the MX RRset to process the MX RRset. MTA usually learn their name by gethostname() or similar and that name is not a CNAME or there is a misconfiguration. The fact that email still gets delivered in the presence of misconfigurations is good luck rather than good management. Mark - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 2:55 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 2d378cb064ba4d06880aed8ed81f3...@ahsnbw1, Al Stu writes: Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. Above statement, belief, perception etc. has already been proven to be a fallacy (see the network trace attached to one of the previous messages). Both the CNAME and A record is in fact returned, unless the CNAME RR points to some other zone such as say smtp.googlemail.com. Please show one vendor that follows a CNAME when processing the *additional* section. AFAIK there is no vendor that does this. Named doesn't. CNAME is followed when processing the *answer* section. So within the zone SMTP requirements are in fact met when the MX RR is a CNAME. So there is no need to prevent this nor to label it as illegal. The MX RR CNAME check should be improved to include this case and not throw a message if the MX RR CNAME is resolvable within the zone. A lot of the reason why people think they can do this is that it doesn't always blow up in their faces when they do it. When there is only one MX record and that name points to a CNAME the MX records are not looked up on the mail exchanger so things don't blow up. Have multiple MX records with different preferences and point those at CNAMEs then thing start blowing up because the higher preference mail exchanger does lookup the MX RRset and does processes it. That is when things blow up. The rules are there to prevent this situation. The message is staying. If you don't want to see it turn it off in named.conf but don't log a bug report complaining that we didn't detect the misconfiguration. Mark - Original Message - From: Matus UHLAR - fantomas uh...@fantomas.sk To: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:18 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On 26.01.09 09:19, bsfin...@anl.gov wrote: If I have in DNS cn IN CNAME realname and I query for cn, the DNS resolver will return realname. BIND also returns the A record for realname. Is this a requirement? If not, then mx IN 10 MX cn will result in: 1) the MX query
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On Jan 26, 2009, at 6:17 PM, Mark Andrews wrote: Which just means you have not ever experienced the problems causes. MTA are not required to look up the addresses of all the mail exchangers in the MX RRset to process the MX RRset. MTA usually learn their name by gethostname() or similar and that name is not a CNAME or there is a misconfiguration. The fact that email still gets delivered in the presence of misconfigurations is good luck rather than good management. 100% right. I refuse MX's that are cnamed, and I get emails from customers asking what is up. What is strange, and I can not figure it out, is that the admins of the DNS/email server always tell me this is the first time they have heard of it. Despite me pointing them to RFC on the matter, since it has worked in the past, they think it is my MTA that is wrong. I hate to budge on it, as this is a simple thing to understand and fix, but it seems many other email servers out there will run up and down a DNS server to find any address they can. In the end, they almost always refuse to change their DNS, and I and up making a static route for them. They change the record later, and then it breaks. I have never got why this is such a hard thing for email admins to get right, but it certainly causes me headaches. I personally wish CNAME's would just go away, keep them around, but just stop talking about them, then new to DNS users would not use them. -- Scott ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What are these entries in the log file - query: . IN NS +?
In message barmar-3c4a47.20101026012...@mara100-84.onlink.net, Barry Margolin writes: In article gllha9$2ot...@sf1.isc.org, Tony Toews [MVP] tto...@telusplanet.net wrote: Gregory Hicks ghi...@hicks-net.net wrote: 2) What are they? They look like the DDoS being discussed on the NANOG list. Have you implemented BCP38? If not, why not... I have no idea what BCP38 is and how I can implement that. Would you be so kind as to supply links relevant to Windows 2003 Server? BCP38 is not something you implement, it's something that has to be implemented by the ISPs hosting the attacking systems. They have to block forged source IPs from their customers. BCP 38 is something everyone should implement. A site shouldn't allow packets to leave with bogus source addresses. That being said there is no real expectation that home users will be implementing BCP 38 so it falls back to the ISP's implement to catch the bad packets when they reach their network. Since there are many ISPs out there that are too lazy, incompetent, or just don't care, where probably never going to be rid of these kinds of attacks. Agreed. You can however do your part by choosing ISP/IAP's that deploy BCP 38 over ones that don't. Add it to the selection criteria for a ISP/IAP. Ones that do are probably more clueful overall and you will have less problems in the end. Mark -- 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 -- 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: What are these entries in the log file - query: . IN NS +?
In message ulssn453ohc7rj6lobgkje0g0prvqd3...@4ax.com, Tony Toews [MVP] wri tes: Tony Toews [MVP] tto...@telusplanet.net wrote: How do I know I'm not answering those? Since your on win, I can't help you, but whatever your packet monitor is, see if you are replying to their requests, even with a REFUSED response. It looks like the server is replying with a refused statement. The following are the two lines that WireShark captured. Standard query NS Root Standard query response, refused Good. The attacker is trying to you as a amplifier and that is not happening. That is all one can reasonably expect. The next thing you should do is ask your ISP to chase them back to their source and if they are local to the ISP block them by implementing BCP 38 other wise to pass on the request to the peers they are getting them from. 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: What are these entries in the log file - query: . IN NS +?
Noel Butler noel.but...@ausics.net wrote: Surely windows can block access to an inbound IP request from some IP to local udp port 53 ? Not the firewall software built into Windows 2003 Server. If not, you know what my next reply will be don't you :) chuckleYeah, well switching to Linux ain't gonna happen. My friend and I have no experience with Linux and no desire to learn it. Tony -- Tony Toews, Microsoft Access MVP Please respond only in the newsgroups so that others can read the entire thread of messages. Microsoft Access Links, Hints, Tips Accounting Systems at http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What are these entries in the log file - query: . IN NS +?
On Tue, 2009-01-27 at 13:16, Tony Toews [MVP] wrote: Noel Butler noel.but...@ausics.net wrote: Surely windows can block access to an inbound IP request from some IP to local udp port 53 ? Not the firewall software built into Windows 2003 Server. Gawd... If not, you know what my next reply will be don't you :) chuckleYeah, well switching to Linux ain't gonna happen. My friend and I have no experience with Linux and no desire to learn it. LOL *whistles innocently* Tony ___ 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
If you refuse a CNAME then it is your SMTP server that is broken. The SMTP RFC's clearly state that SMTP servers are to accept and lookup a CNAME. - Original Message - From: Scott Haneda talkli...@newgeo.com To: Mark Andrews mark_andr...@isc.org Cc: Al Stu al_...@verizon.net; bind-users@lists.isc.org Sent: Monday, January 26, 2009 6:24 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On Jan 26, 2009, at 6:17 PM, Mark Andrews wrote: Which just means you have not ever experienced the problems causes. MTA are not required to look up the addresses of all the mail exchangers in the MX RRset to process the MX RRset. MTA usually learn their name by gethostname() or similar and that name is not a CNAME or there is a misconfiguration. The fact that email still gets delivered in the presence of misconfigurations is good luck rather than good management. 100% right. I refuse MX's that are cnamed, and I get emails from customers asking what is up. What is strange, and I can not figure it out, is that the admins of the DNS/email server always tell me this is the first time they have heard of it. Despite me pointing them to RFC on the matter, since it has worked in the past, they think it is my MTA that is wrong. I hate to budge on it, as this is a simple thing to understand and fix, but it seems many other email servers out there will run up and down a DNS server to find any address they can. In the end, they almost always refuse to change their DNS, and I and up making a static route for them. They change the record later, and then it breaks. I have never got why this is such a hard thing for email admins to get right, but it certainly causes me headaches. I personally wish CNAME's would just go away, keep them around, but just stop talking about them, then new to DNS users would not use them. -- Scott ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What are these entries in the log file - query: . IN NS +?
Tony Toews [MVP] tto...@telusplanet.net wrote: As far as I can tell from the same 5 or 20 IP addresses. I haven't seen these lines before. When I analyzed todays log I got three IP address. 204.15.80.50 might be smtp9.soma.ironport.com 63.217.28.226 might be Network solutions according to the below SlashDot article. 76.9.16.171 is mentioned at http://isc.sans.org/diary.html?storyid=5713 Ah, I think I see what is happening here. Searching at the below article for 63.217.28.226 http://tech.slashdot.org/tech/09/01/24/0113210.shtml shows a reply stating: The problem seems to kick in for DNS servers that arent rejecting the queries. Someone is channeling ye 'ole smurfing methods. They're requesting a list of all DNS root servers. If the server don't reject the query, a 17 byte query becomes a 50k response (or something like that) to the spoofed address. Tony -- Tony Toews, Microsoft Access MVP Please respond only in the newsgroups so that others can read the entire thread of messages. Microsoft Access Links, Hints, Tips Accounting Systems at http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ ___ 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 26, 2009, at 7:54 PM, Al Stu wrote: If you refuse a CNAME then it is your SMTP server that is broken. The SMTP RFC's clearly state that SMTP servers are to accept and lookup a CNAME. [RFC974] explicitly states that MX records shall not point to an alias defined by a CNAME. That is what I was talking about, are you saying this is not correct? As this is what I was under the impression for quite some time. -- Scott ___ 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 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. - Original Message - From: Scott Haneda talkli...@newgeo.com To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:09 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On Jan 26, 2009, at 7:54 PM, Al Stu wrote: If you refuse a CNAME then it is your SMTP server that is broken. The SMTP RFC's clearly state that SMTP servers are to accept and lookup a CNAME. [RFC974] explicitly states that MX records shall not point to an alias defined by a CNAME. That is what I was talking about, are you saying this is not correct? As this is what I was under the impression for quite some time. -- Scott ___ 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 message 3c802402a28c4b2390b088242a91f...@ahsnbw1, Al Stu writes: 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. And that is talking about the response to a MX query. The section from which you quote starts with: Issuing a Query The first step for the mailer at LOCAL is to issue a query for MX RRs for REMOTE. It is strongly urged that this step be taken every time a mailer attempts to send the message. The hope is that changes in the domain database will rapidly be used by mailers, and thus domain administrators will be able to re-route in-transit messages for defective hosts by simply changing their domain databases. and the paragraph after that which you quote is: If the response does not contain an error response, and does not contain aliases, its answer section should be a (possibly zero length) list of MX RRs for domain name REMOTE (or REMOTE's true domain name if REMOTE was a alias). The next section describes how this list is interpreted. So I would suggest that you stop taking text out of context. CNAME - MX is legal MX - CNAME is illegal Mark - Original Message - From: Scott Haneda talkli...@newgeo.com To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:09 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On Jan 26, 2009, at 7:54 PM, Al Stu wrote: If you refuse a CNAME then it is your SMTP server that is broken. The SMTP RFC's clearly state that SMTP servers are to accept and lookup a CNAME. [RFC974] explicitly states that MX records shall not point to an alias defined by a CNAME. That is what I was talking about, are you saying this is not correct? As this is what I was under the impression for quite some time. -- Scott ___ 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: 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
Yes, the response to an MX query, that is the subject here. And a CNAME is in fact permitted and specified by the RFC's to be accepted as the response to an MX lookup. If the response does not contain an error response, and does not contain aliases See there, alias is permitted. You just keep proving the my case. I am not taking it out of context. It is very explicitly stated. And the context is that of locating the target/remote host by first submitting an MX query, then submitting an A query of the MX query result. The MX query result is permitted to be and alias, which in turn when submitted for an A query results in both the A and CNAME being returned. Thus meeting the SMTP RFC requirements. - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:41 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 3c802402a28c4b2390b088242a91f...@ahsnbw1, Al Stu writes: 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. And that is talking about the response to a MX query. The section from which you quote starts with: Issuing a Query The first step for the mailer at LOCAL is to issue a query for MX RRs for REMOTE. It is strongly urged that this step be taken every time a mailer attempts to send the message. The hope is that changes in the domain database will rapidly be used by mailers, and thus domain administrators will be able to re-route in-transit messages for defective hosts by simply changing their domain databases. and the paragraph after that which you quote is: If the response does not contain an error response, and does not contain aliases, its answer section should be a (possibly zero length) list of MX RRs for domain name REMOTE (or REMOTE's true domain name if REMOTE was a alias). The next section describes how this list is interpreted. So I would suggest that you stop taking text out of context. CNAME - MX is legal MX - CNAME is illegal Mark - Original Message - From: Scott Haneda talkli...@newgeo.com To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:09 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On Jan 26, 2009, at 7:54 PM, Al Stu wrote: If you refuse a CNAME then it is your SMTP server that is broken. The SMTP RFC's clearly state that SMTP servers are to accept and lookup a CNAME. [RFC974] explicitly states that MX records shall not point to an alias defined by a CNAME. That is what I was talking about, are you saying this is not correct? As this is what I was under the impression for quite some time. -- Scott ___ 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: 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
In message b3ba5e37553642e28149093cdee78...@ahsnbw1, Al Stu writes: Yes, the response to an MX query, that is the subject here. And a CNAME is in fact permitted and specified by the RFC's to be accepted as the response to an MX lookup. No one is saying a CNAME is not permitted in response to a MX query. If the response does not contain an error response, and does not contain aliases See there, alias is permitted. You just keep proving the my case. We are saying that when you lookup the address of the mail exchanger that you shouldn't get a CNAME record. MX - CNAME is not permitted. Others have quoted similar text from more recent RFC's. RFC 974 Note that the algorithm to delete irrelevant RRs breaks if LOCAL has a alias and the alias is listed in the MX records for REMOTE. (E.g. REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This can be avoided if aliases are never used in the data section of MX RRs. I am not taking it out of context. It is very explicitly stated. And the context is that of locating the target/remote host by first submitting an MX query, then submitting an A query of the MX query result. The text you quote is ONLY talking about the MX query. There is no then submitting an A query of the MX query result at this point in the RFC. The MX query result is permitted to be and alias, which in turn when submitted for an A query results in both the A and CNAME being returned. Thus meeting the SMTP RFC requirements. - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:41 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 3c802402a28c4b2390b088242a91f...@ahsnbw1, Al Stu writes: 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. And that is talking about the response to a MX query. The section from which you quote starts with: Issuing a Query The first step for the mailer at LOCAL is to issue a query for MX RRs for REMOTE. It is strongly urged that this step be taken every time a mailer attempts to send the message. The hope is that changes in the domain database will rapidly be used by mailers, and thus domain administrators will be able to re-route in-transit messages for defective hosts by simply changing their domain databases. and the paragraph after that which you quote is: If the response does not contain an error response, and does not contain aliases, its answer section should be a (possibly zero length) list of MX RRs for domain name REMOTE (or REMOTE's true domain name if REMOTE was a alias). The next section describes how this list is interpreted. So I would suggest that you stop taking text out of context. CNAME - MX is legal MX - CNAME is illegal Mark - Original Message - From: Scott Haneda talkli...@newgeo.com To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:09 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On Jan 26, 2009, at 7:54 PM, Al Stu wrote: If you refuse a CNAME then it is your SMTP server that is broken. The SMTP RFC's clearly state that SMTP servers are to accept and lookup a CNAME. [RFC974] explicitly states that MX records shall not point to an alias defined by a CNAME. That is what I was talking about, are you saying this is not correct? As this is what I was under the impression for quite some time. -- Scott ___ 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: mark_andr...@isc.org ___ 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: 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
In article gllr91$2vq...@sf1.isc.org, Scott Haneda talkli...@newgeo.com wrote: I have never got why this is such a hard thing for email admins to get right, but it certainly causes me headaches. I personally wish CNAME's would just go away, keep them around, but just stop talking about them, then new to DNS users would not use them. Suppose you're providing an MX service, but you actually out-source the operation to a third party. You want to give your customers an MX record that points to a name in your domain, so they don't need to know about the third party (and so you have the flexibility to change your out-sourcing without requiring all customers to update their MX record). But the third party also needs the flexibility to change the IP of the server, load balancing, disaster recovery, changing ISPs, etc. So they don't want you to hard-code their IPs into your domain. CNAMEs are the simplest solution to implementing all this. customer.com. IN MX 10 mx.yourdomain.com. mx.yourdomain.com. IN CNAME mx.outsourcer.com. mx.outsourcer.com. IN A ... If the customer changes MX services, they change their MX record. If you change outsourcing companies, you change your CNAME record. And if the outsourcing company re-IPs their server, they change the A record. Everyone can perform their job without having to make any of the downstream customers adjust their records. -- 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 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
In article glm61r$5l...@sf1.isc.org, Al Stu al_...@verizon.net wrote: Yes, the response to an MX query, that is the subject here. And a CNAME is in fact permitted and specified by the RFC's to be accepted as the response to an MX lookup. No, we're talking about the response to the A query for the name that the MX points to. The section below is talking about the response to the original MX query. E.g. when sending mail to f...@mail.company.com, mail.company.com is allowed to be a CNAME. So you can have: mail.company.com. CNAME company.com. company.com. MX 10 mx.company.com. but you still aren't supposed to have: mx.company.com. CNAME mxserver.company.com. If the response does not contain an error response, and does not contain aliases See there, alias is permitted. You just keep proving the my case. I am not taking it out of context. It is very explicitly stated. And the context is that of locating the target/remote host by first submitting an MX query, then submitting an A query of the MX query result. The MX query result is permitted to be and alias, which in turn when submitted for an A query results in both the A and CNAME being returned. Thus meeting the SMTP RFC requirements. - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:41 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 3c802402a28c4b2390b088242a91f...@ahsnbw1, Al Stu writes: 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. And that is talking about the response to a MX query. The section from which you quote starts with: Issuing a Query The first step for the mailer at LOCAL is to issue a query for MX RRs for REMOTE. It is strongly urged that this step be taken every time a mailer attempts to send the message. The hope is that changes in the domain database will rapidly be used by mailers, and thus domain administrators will be able to re-route in-transit messages for defective hosts by simply changing their domain databases. and the paragraph after that which you quote is: If the response does not contain an error response, and does not contain aliases, its answer section should be a (possibly zero length) list of MX RRs for domain name REMOTE (or REMOTE's true domain name if REMOTE was a alias). The next section describes how this list is interpreted. So I would suggest that you stop taking text out of context. CNAME - MX is legal MX - CNAME is illegal Mark - Original Message - From: Scott Haneda talkli...@newgeo.com To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:09 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On Jan 26, 2009, at 7:54 PM, Al Stu wrote: If you refuse a CNAME then it is your SMTP server that is broken. The SMTP RFC's clearly state that SMTP servers are to accept and lookup a CNAME. [RFC974] explicitly states that MX records shall not point to an alias defined by a CNAME. That is what I was talking about, are you saying this is not correct? As this is what I was under the impression for quite some time. -- Scott ___ 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: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- 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 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On Jan 26, 2009, at 10:03 PM, Barry Margolin wrote: In article gllr91$2vq...@sf1.isc.org, Scott Haneda talkli...@newgeo.com wrote: 100% right. I refuse MX's that are cnamed, and I get emails from customers asking what is up. What is strange, and I can not figure it out, is that the admins of the DNS/email server always tell me this is the first time they have heard of it. So you're not following the be liberal in what you accept half of the Interoperability Principle, which is intended specifically to avoid problems due to such confusion. Because that worked so well for HTML :) I was thinking about that quote just the other day. To be honest, I think it applies well to social issues, but not technical or engineering/programming ones. The second you accept liberally, that tells the submitter that it is ok. I am hard pressed to think of one case in which liberally accepting data is a good thing. It is that very expression that defines why we have bpisometextpbi Just consider the ramifications of parsing that one simple string, which is now non trivial to parse. What is C worked this way? Just some thoughts I was having the other day. -- Scott ___ 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 26, 2009, at 10:11 PM, Barry Margolin wrote: In article gllr91$2vq...@sf1.isc.org, Scott Haneda talkli...@newgeo.com wrote: I have never got why this is such a hard thing for email admins to get right, but it certainly causes me headaches. I personally wish CNAME's would just go away, keep them around, but just stop talking about them, then new to DNS users would not use them. Suppose you're providing an MX service, but you actually out-source the operation to a third party. You want to give your customers an MX record that points to a name in your domain, so they don't need to know about the third party (and so you have the flexibility to change your out-sourcing without requiring all customers to update their MX record). But the third party also needs the flexibility to change the IP of the server, load balancing, disaster recovery, changing ISPs, etc. So they don't want you to hard-code their IPs into your domain. CNAMEs are the simplest solution to implementing all this. customer.com. IN MX 10 mx.yourdomain.com. mx.yourdomain.com. IN CNAME mx.outsourcer.com. mx.outsourcer.com. IN A ... If the customer changes MX services, they change their MX record. If you change outsourcing companies, you change your CNAME record. And if the outsourcing company re-IPs their server, they change the A record. Everyone can perform their job without having to make any of the downstream customers adjust their records. Totally valid points, I agree with them all. And it is these points that I was talking about when I suggested CNAME's go away. Not really go away, but the above case is clearly one in which the admin knows that they are doing. What my trouble is, is with the mail admins who clearly do not, and then argue about solving it. I better example is servers that do not support greylisting, and bounce on 450 code. This is pretty simple, and obvious as to why you need to try in a transient error like that. Anyway, not saying I disagree with you, I do not, but I was just venting a little. -- Scott ___ 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
The paragraph you cite regarding LOCAL has a alias and the alias is listed in the MX records for REMOTE... is a peripery issue which is handled by not doing that. No one is saying a CNAME is not permitted in response to a MX query. Well good then, we agree. The MX record data value can be a CNAME. That is what BIND is complaining about, and I in turn saying should be changed/removed. i.e. BIND should not complain about the following, but it does. It says the MX record is illegal. But it is not. srv1 300 IN A 1.2.3.4 mx1 300 IN CNAME srv1.xyz.com. @ 300 IN MX 1 mx1.xyz.com. The MX query for xyz.com delivers mx1.xyz.com which is a CNAME. The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com, 1.2.3.4, and the alias (CNAME) record of mx1.xyz.com. *** PLEASE don't copy me on replies, I'll read them in the group *** - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 10:03 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message b3ba5e37553642e28149093cdee78...@ahsnbw1, Al Stu writes: Yes, the response to an MX query, that is the subject here. And a CNAME is in fact permitted and specified by the RFC's to be accepted as the response to an MX lookup. No one is saying a CNAME is not permitted in response to a MX query. If the response does not contain an error response, and does not contain aliases See there, alias is permitted. You just keep proving the my case. We are saying that when you lookup the address of the mail exchanger that you shouldn't get a CNAME record. MX - CNAME is not permitted. Others have quoted similar text from more recent RFC's. RFC 974 Note that the algorithm to delete irrelevant RRs breaks if LOCAL has a alias and the alias is listed in the MX records for REMOTE. (E.g. REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This can be avoided if aliases are never used in the data section of MX RRs. I am not taking it out of context. It is very explicitly stated. And the context is that of locating the target/remote host by first submitting an MX query, then submitting an A query of the MX query result. The text you quote is ONLY talking about the MX query. There is no then submitting an A query of the MX query result at this point in the RFC. The MX query result is permitted to be and alias, which in turn when submitted for an A query results in both the A and CNAME being returned. Thus meeting the SMTP RFC requirements. - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:41 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 3c802402a28c4b2390b088242a91f...@ahsnbw1, Al Stu writes: 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. And that is talking about the response to a MX query. The section from which you quote starts with: Issuing a Query The first step for the mailer at LOCAL is to issue a query for MX RRs for REMOTE. It is strongly urged that this step be taken every time a mailer attempts to send the message. The hope is that changes in the domain database will rapidly be used by mailers, and thus domain administrators will be able to re-route in-transit messages for defective hosts by simply changing their domain databases. and the paragraph after that which you quote is: If the response does not contain an error response, and does not contain aliases, its answer section should be a (possibly zero length) list of MX RRs for domain name REMOTE (or REMOTE's true domain name if REMOTE was a alias). The next section describes how this list is interpreted. So I would suggest that you stop taking text out of context. CNAME - MX is legal MX - CNAME is illegal Mark - Original Message - From: Scott Haneda talkli...@newgeo.com To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:09 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On Jan 26, 2009, at 7:54 PM, Al Stu wrote: If you refuse a CNAME then it is your SMTP server that is broken. The SMTP RFC's clearly state that SMTP servers are to accept and lookup a CNAME. [RFC974] explicitly states that MX records shall not point to an alias defined by a CNAME. That is what I was talking about, are you saying this is not correct? As this is what I was under the impression for quite some time. -- Scott ___ bind-users mailing
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
In message bc7c01a4-1803-4906-bd90-93037b4ae...@newgeo.com, Scott Haneda writ es: On Jan 26, 2009, at 10:03 PM, Barry Margolin wrote: In article gllr91$2vq...@sf1.isc.org, Scott Haneda talkli...@newgeo.com wrote: 100% right. I refuse MX's that are cnamed, and I get emails from customers asking what is up. What is strange, and I can not figure it out, is that the admins of the DNS/email server always tell me this is the first time they have heard of it. So you're not following the be liberal in what you accept half of the Interoperability Principle, which is intended specifically to avoid problems due to such confusion. Because that worked so well for HTML :) I was thinking about that quote just the other day. To be honest, I think it applies well to social issues, but not technical or engineering/programming ones. The second you accept liberally, that tells the submitter that it is ok. I am hard pressed to think of one case in which liberally accepting data is a good thing. It is that very expression that defines why we have bpisometextpbi Just consider the ramifications of parsing that one simple string, which is now non trivial to parse. What is C worked this way? Just some thoughts I was having the other day. -- Scott ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Liberal in what you accepts means don't die on arbitary input. You should still reject rubbish. -- 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.4.x vs 9.6.x - pid-file check and creation
At 22:41 26/01/2009, Mark Andrews wrote:
In message 200901260955.n0q9tnvm010...@mail43.nsc.no, Jan Arild =?iso-8859-1?
Q?Lindstr=F8m?= writes:
At 09:33 26/01/2009, Mark Andrews wrote:
In message 200901260742.n0q7gjqn029...@mail46.nsc.no, Jan Arild=
=3D?iso-8859-1?
Q?Lindstr=3DF8m?=3D writes:
=20
Hi,
=20
I was going to upgrade from BIND 9.4.3 to BIND 9.6.0-P1, but run into a =
=3D
=20
strange bug in BIND 9.6.0-P1.
=20
Exact same config for 9.4.3 and 9.6.0-P1, only added new to files that=
=3D
=20
are written to (namednew.log, confignew.log and namednew.pid).
=20
OS: Solaris 10.
=20
Using:
pid-file /var/run/named/namednew.pid;
=20
.. result in the following:
=20
namednew.log:
26-Jan-2009 08:14:22.723 general: couldn't mkdir=
/var/run/named/namednew.pi=3D
d': Permission denied
26-Jan-2009 08:14:22.728 general: exiting (due to early fatal error)
The log message should say couldn't mkdir /var/run/named.
The wrong path is being logged.
You either need to create /var/run/named with appropriate
permissions so that named can write to it or change /var/run's
It does exists as you can see from the ls output I included. And named=
is
owner of it and hence have full permissions on it (/var/run/named/).
Problem is that Solaris returnes EACCESS and not EEXISTS. So just running=
mkdir=20
to check if a directory exists does not work on Solaris. One gets an EACCES=
and the=20
code fails.
What are all of the permissions involved as it should work
as demonstrated by the test below.
thing1:marka 21:31 {109} % mkdir /foo
mkdir: Failed to make directory /foo; Permission denied
thing1:marka 21:31 {110} % mkdir /tmp
mkdir: Failed to make directory /tmp; File exists
thing1:marka 21:31 {111} % uname -a
SunOS thing1 5.10 Generic_120011-14 sun4u sparc SUNW,Ultra-80
thing1:marka 21:33 {112} %
e.g.
ls -ld / /var /var/run /var/run/named
SunOS ns10.nsc.no 5.10 Generic_137111-07 sun4v sparc SUNW,Sun-Fire-T200
-bash-3.00$ id
uid=21(named) gid=21(named)
-bash-3.00$ ls -ld / /var /var/run /var/run/named /var/run/named-test
drwxr-sr-x 32 root root1024 Jan 27 07:07 /
drwxr-xr-x 47 root sys 1024 Jul 21 2008 /var
drwxr-sr-x 8 root root1216 Jan 27 07:07 /var/run
drwxr-s--- 3 namednamed245 Jan 26 14:44 /var/run/named
drwxrwsr-x 2 root root 117 Jan 27 07:07 /var/run/named-test
-bash-3.00$ mkdir / /var /var/run /var/run/named /var/run/named-test
mkdir: Failed to make directory /; File exists
mkdir: Failed to make directory /var; File exists
mkdir: Failed to make directory /var/run; File exists
mkdir: Failed to make directory /var/run/named; Permission denied
mkdir: Failed to make directory /var/run/named-test; Permission denied
I added /var/run/named-test as a test with root:root as owner.
This is strange.
ns10(root) run 509# getfacl /var
# file: /var
# owner: root
# group: sys
user::rwx
group::r-x #effective:r-x
mask:r-x
other:r-x
ns10(root) run 510# getfacl /var/run
# file: /var/run
# owner: root
# group: root
user::rwx
group::r-x #effective:r-x
mask:rwx
other:r-x
ns10(root) run 511# getfacl /var/run/named
# file: /var/run/named
# owner: named
# group: named
user::rwx
group::r-x #effective:r-x
mask:rwx
other:---
Same thing happens on a new Soalaris 10 also, where I just created the
diretory:
tproxy(root) / 499# mkdir /var/run/named
tproxy(root) / 505# su - named
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
-bash-3.00$ ls -ld / /var /var/run /var/run/named
drwxr-sr-x 33 root root1536 Jan 27 07:14 /
drwxr-xr-x 30 root sys 512 Dec 2 15:59 /var
drwxr-xr-x 8 root sys 1374 Jan 27 07:14 /var/run
drwxrwxr-x 2 root root 117 Jan 27 07:14 /var/run/named
-bash-3.00$
-bash-3.00$ mkdir / /var /var/run /var/run/named
mkdir: Failed to make directory /; File exists
mkdir: Failed to make directory /var; File exists
mkdir: Failed to make directory /var/run; File exists
mkdir: Failed to make directory /var/run/named; Permission denied
It happens on Solaris 9 also:
safe(root) jal 1225# mkdir /var/run/named
safe(root) jal 1226# su - named
Sun Microsystems Inc. SunOS 5.9 Generic May 2002
-bash-3.00$ ls -ld / /var /var/run /var/run/named
drwxr-sr-x 88 root root3072 Jan 27 07:14 /
drwxr-xr-x 39 root sys 1024 Oct 14 10:34 /var
drwxr-sr-x 8 root root1304 Jan 27 07:18 /var/run
drwxr-sr-x 2 root root 117 Jan 27 07:18 /var/run/named
-bash-3.00$ mkdir / /var /var/run /var/run/named
mkdir: Failed to make directory ; No such file or directory
