RE: Questions about DNAME records
I'm happy with the concept of views, and have used them previously.
Ideally, though (as Chris mentioned) I don't want to have to manage zone
data for the externally used domain, both on my name servers, and those
where it's really provided - on a managed service, hosted and provided
externally.
Having never used DNAME records before, I was really just curious as to
whether I could use them to kind of simply deal with a small number of
records for purely internal usage, without interrupting our internal
resolution of the public names.
But Chris's suggestion of subdomains looks to be very useful - many
thanks for that.
Neil
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Joseph S D Yao
Sent: 19 June 2009 02:43
To: Chris Buxton
Cc: Braebaum, Neil; bind-us...@isc.org
Subject: Re: Questions about DNAME records
On Thu, Jun 18, 2009 at 02:12:07PM -0700, Chris Buxton wrote:
...
Yes, that will absolutely work. But the OP requested a
method that did
not involve managing the public data in two places.
...
Which is exactly what views are for. External data is kept
in ONE file,
as below.
named.conf:
...
acl localfolk {
localhost;
LOC.AL.NET.WORK/MASK;
...
};
view internal {
// This should match our internal networks.
match-clients { localfolk; };
// Provide recursive service to internal clients only.
recursion yes;
// Provide a complete view of the example.com zone
// including addresses of internal hosts.
zone example.com {
type master;
file zone.example.int;
};
};
view external {
// Match all clients not matched by the previous view.
match-clients { any; };
// Refuse recursive service to external clients.
recursion no;
// Provide a restricted view of the example.com zone
// containing only publicly accessible hosts.
zone example.com {
type master;
file zone.example.ext;
};
};
zone.example.ext:
$TTL1d
@ IN SOA ...
IN NS ...
// Remember to increment the SOA serial number when this is
// updated!
$INCLUDE data/example.ext.data
zone.example.int:
$TTL1d
@ IN SOA ...
IN NS ...
// Remember to increment the SOA serial number when either of
// these is updated!
$INCLUDE data/example.ext.data
$INCLUDE data/example.int.data
*
This email and its attachments are confidential to the intended recipient. If
this has come to you in error, please notify the sender immediately and delete
this email from your system. You must take no action based on this email, nor
must you copy or disclose it or any part of its contents to any person or
organisation. Please note that email communications may be monitored. The
registered office of Shop Direct Limited is First Floor, Skyways House, Speke
Road, Speke, Liverpool, L70 1AB, registered number 04730752.
Subsidiary companies of Shop Direct Limited include:
Shop Direct Group Financial Services Limited (SDGFS), Shop Direct Financial
Services Limited (SDFS) and Shop Direct Finance Company Limited (SDFC). The
registered office of SDGFS, SDFS and SDFC is Aintree Innovation Centre, Park
Lane, Netherton, Bootle, L30 1SL, registered numbers 05200103 (SDGFS), 04730706
(SDFS) and 04660974 (SDFC). SDFS and SDFC are authorised and regulated by the
Financial Services Authority in respect of arranging insurance products.
Shop Direct Contact Centres Limited (SDCC) and Shop Direct Home Shopping
Limited (SDHS). The registered office of SDCC and SDHS is First Floor, Skyways
House, Speke Road, Speke, Liverpool, L70 1AB, registered numbers 05330323
(SDCC), 04663281 (SDHS).
All companies registered in England.
*
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: SPF/TXT records
On 18.06.09 16:22, Jeffrey Collyer wrote: M$ has their own take on SPF called Sender ID, which uses a very similar record - v=spf2.0 rather than v=spf1 so be sure to read up on them both before publishing records for one or the other. It has downfalls so I recommend not even studying it, just remember that spf2 is some M$ crap... v=spf1 is just enough for now. http://www.openspf.org/SPF_vs_Sender_ID Hotmail in particular is picky about what it rejects and why. Yes, hotmail uses to reject mail for many strange reasons. But I don't recommend playing with spf2 just to get mail to hotmail, I think there are better ways to get your mail anywhere. -- 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. My mind is like a steel trap - rusty and illegal in 37 states. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Questions about DNAME records
I don't run the external domain / zone, it's provided by a managed
service - I merely tell them the contents.
That's why I'd already ruled out views. I don't want to have to
duplicate the entries for internal use of external values, nor do I want
to drag the running of the domain to my internal nameservers.
Neil
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Joseph S D Yao
Sent: 19 June 2009 02:43
To: Chris Buxton
Cc: Braebaum, Neil; bind-us...@isc.org
Subject: Re: Questions about DNAME records
On Thu, Jun 18, 2009 at 02:12:07PM -0700, Chris Buxton wrote:
...
Yes, that will absolutely work. But the OP requested a
method that did
not involve managing the public data in two places.
...
Which is exactly what views are for. External data is kept
in ONE file,
as below.
named.conf:
...
acl localfolk {
localhost;
LOC.AL.NET.WORK/MASK;
...
};
view internal {
// This should match our internal networks.
match-clients { localfolk; };
// Provide recursive service to internal clients only.
recursion yes;
// Provide a complete view of the example.com zone
// including addresses of internal hosts.
zone example.com {
type master;
file zone.example.int;
};
};
view external {
// Match all clients not matched by the previous view.
match-clients { any; };
// Refuse recursive service to external clients.
recursion no;
// Provide a restricted view of the example.com zone
// containing only publicly accessible hosts.
zone example.com {
type master;
file zone.example.ext;
};
};
zone.example.ext:
$TTL1d
@ IN SOA ...
IN NS ...
// Remember to increment the SOA serial number when this is
// updated!
$INCLUDE data/example.ext.data
zone.example.int:
$TTL1d
@ IN SOA ...
IN NS ...
// Remember to increment the SOA serial number when either of
// these is updated!
$INCLUDE data/example.ext.data
$INCLUDE data/example.int.data
--
/*
\
**
** Joe Yaoj...@tux.org - Joseph S. D. Yao
**
\*
/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
*
This email and its attachments are confidential to the intended recipient. If
this has come to you in error, please notify the sender immediately and delete
this email from your system. You must take no action based on this email, nor
must you copy or disclose it or any part of its contents to any person or
organisation. Please note that email communications may be monitored. The
registered office of Shop Direct Limited is First Floor, Skyways House, Speke
Road, Speke, Liverpool, L70 1AB, registered number 04730752.
Subsidiary companies of Shop Direct Limited include:
Shop Direct Group Financial Services Limited (SDGFS), Shop Direct Financial
Services Limited (SDFS) and Shop Direct Finance Company Limited (SDFC). The
registered office of SDGFS, SDFS and SDFC is Aintree Innovation Centre, Park
Lane, Netherton, Bootle, L30 1SL, registered numbers 05200103 (SDGFS), 04730706
(SDFS) and 04660974 (SDFC). SDFS and SDFC are authorised and regulated by the
Financial Services Authority in respect of arranging insurance products.
Shop Direct Contact Centres Limited (SDCC) and Shop Direct Home Shopping
Limited (SDHS). The registered office of SDCC and SDHS is First Floor, Skyways
House, Speke Road, Speke, Liverpool, L70 1AB, registered numbers 05330323
(SDCC), 04663281 (SDHS).
All companies registered in England.
*
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: Dynamic DNS and Slave Servers
Should running a rndc freeze and thaw on the slave server also push the data from the .jnl files directly to the tables as they do on the master server? For some weird reason, running a rndc freeze and thaw on the slave runs successfully, but it does not push the updates to the zone tables there, and the .jnl files still exist after it. This is unexpected behavior. Joseph A. Borgia, Jr. Sr. UNIX/SAN Engineer Team Rome IT - Rome Research Corporation U.S. Air Force Research Laboratory/Rome Research Site/RIOS COMM: 315-330-3952 DSN: 587-3952 FAX: 315-330-8258 -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Borgia, Joe A CTR USAF AFMC AFRL/RIOS Sent: Thursday, June 18, 2009 9:59 AM To: bind-users@lists.isc.org Subject: Dynamic DNS and Slave Servers I'm trying to learn DDNS at break-neck speed over here. I guess I'm a little surprised that there are .jnl files on my slave server. I have no allow-update statements on that server, unless maybe these files are coming from zone transfer? Also, is it normal for the master zone tables to turn into files that look like slave zone tables after you enable DDNS? Thanks, Joe Joseph A. Borgia, Jr. Sr. UNIX/SAN Engineer Team Rome IT - Rome Research Corporation U.S. Air Force Research Laboratory/Rome Research Site/RIOS COMM: 315-330-3952 DSN: 587-3952 FAX: 315-330-8258 smime.p7s Description: S/MIME cryptographic signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Dynamic DNS and Slave Servers
On Jun 19 2009, Borgia, Joe A CTR USAF AFMC AFRL/RIOS wrote: Should running a rndc freeze and thaw on the slave server also push the data from the .jnl files directly to the tables as they do on the master server? For some weird reason, running a rndc freeze and thaw on the slave runs successfully, but it does not push the updates to the zone tables there, and the .jnl files still exist after it. This is unexpected behavior. Not really. Freezing is only meaningful for zones of type master. If you use rndc freeze [zonename] and the zone is of type slave, you will get an error message rndc: 'freeze' failed: not found (by which it means, not found among the zones of type master). rndc freeze without a zone name means freeze all zones of type master, and so it is always going to run successfully, even if there aren't any. (I don't actually much like syntax like this, when leaving out an argument has such a wide-ranging effect that might not have been intended. rndc freezeall, say, would have been a better idea.) -- 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: Dynamic DNS and Slave Servers
That's exactly what I was seeing when I tried that: rndc: 'freeze' failed: not found. You folks have all been so helpful. Like one of the other posters said, we've done non-dynamic DNS for so long here (years and years) the dynamic DNS, especially when combined with a mainly Windows environment has been a little bit like black magic. And, we're being forced to implement over such a short period of time. It's been a little much to take it all in. Joseph A. Borgia, Jr. Sr. UNIX/SAN Engineer Team Rome IT - Rome Research Corporation U.S. Air Force Research Laboratory/Rome Research Site/RIOS COMM: 315-330-3952 DSN: 587-3952 FAX: 315-330-8258 -Original Message- From: Chris Thompson [mailto:c...@hermes.cam.ac.uk] On Behalf Of Chris Thompson Sent: Friday, June 19, 2009 10:25 AM To: Borgia, Joe A CTR USAF AFMC AFRL/RIOS Cc: Bind Users Mailing List Subject: RE: Dynamic DNS and Slave Servers On Jun 19 2009, Borgia, Joe A CTR USAF AFMC AFRL/RIOS wrote: Should running a rndc freeze and thaw on the slave server also push the data from the .jnl files directly to the tables as they do on the master server? For some weird reason, running a rndc freeze and thaw on the slave runs successfully, but it does not push the updates to the zone tables there, and the .jnl files still exist after it. This is unexpected behavior. Not really. Freezing is only meaningful for zones of type master. If you use rndc freeze [zonename] and the zone is of type slave, you will get an error message rndc: 'freeze' failed: not found (by which it means, not found among the zones of type master). rndc freeze without a zone name means freeze all zones of type master, and so it is always going to run successfully, even if there aren't any. (I don't actually much like syntax like this, when leaving out an argument has such a wide-ranging effect that might not have been intended. rndc freezeall, say, would have been a better idea.) -- Chris Thompson Email: c...@cam.ac.uk smime.p7s Description: S/MIME cryptographic signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Questions about DNAME records
On Fri, Jun 19, 2009 at 07:58:31AM +0100, Braebaum, Neil wrote: I'm happy with the concept of views, and have used them previously. Ideally, though (as Chris mentioned) I don't want to have to manage zone data for the externally used domain, both on my name servers, and those where it's really provided - on a managed service, hosted and provided externally. When I've used a managed service, I use a locally managed stealth server, for just the reasons you name. With views, it makes the whole thing easier to manage. How do you manage on a manged service? Some kind of klunky Web GUI? [Adjective my opinion only ... but, really!] Having never used DNAME records before, I was really just curious as to whether I could use them to kind of simply deal with a small number of records for purely internal usage, without interrupting our internal resolution of the public names. DNAME records aren't universally implemented, outside of BIND itself. Certain uses of them are deprecated, leading others to believe that DNAME records themselves are deprecated and experimental. And others just hate them period. Or I could be out of touch ... I had to double-check my memory on that one. But Chris's suggestion of subdomains looks to be very useful - many thanks for that. That is probably the best way to go. Being a literalist, for better or for worse, I just took exception to the word only. ;-) -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: SPF/TXT records
Or moreover not to bother with SPF at all as suggested in these documents?: Why you shouldn't jump on the SPF bandwagon: http://www.advogato.org/article/816.html How spammers get around SPF: http://www.circleid.com/posts/782012_spammer_get_around_spf/ -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mike Bernhardt Sent: Friday, June 19, 2009 12:37 PM To: 'Matus UHLAR - fantomas'; bind-users@lists.isc.org Subject: RE: SPF/TXT records So is the general recommendation in this group to NOT implement an empty SPF2.0 record (i.e., spf2.0/pra) just in case, as recommended in the 5-year-old openspf document referenced below? -Original Message- From: Matus UHLAR - fantomas [mailto:uh...@fantomas.sk] Sent: Friday, June 19, 2009 12:31 AM To: bind-users@lists.isc.org Subject: Re: SPF/TXT records On 18.06.09 16:22, Jeffrey Collyer wrote: M$ has their own take on SPF called Sender ID, which uses a very similar record - v=spf2.0 rather than v=spf1 so be sure to read up on them both before publishing records for one or the other. It has downfalls so I recommend not even studying it, just remember that spf2 is some M$ crap... v=spf1 is just enough for now. http://www.openspf.org/SPF_vs_Sender_ID Hotmail in particular is picky about what it rejects and why. Yes, hotmail uses to reject mail for many strange reasons. But I don't recommend playing with spf2 just to get mail to hotmail, I think there are better ways to get your mail anywhere. -- 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. My mind is like a steel trap - rusty and illegal in 37 states. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: SPF/TXT records
So is the general recommendation in this group to NOT implement an empty SPF2.0 record (i.e., spf2.0/pra) just in case, as recommended in the 5-year-old openspf document referenced below? -Original Message- From: Matus UHLAR - fantomas [mailto:uh...@fantomas.sk] Sent: Friday, June 19, 2009 12:31 AM To: bind-users@lists.isc.org Subject: Re: SPF/TXT records On 18.06.09 16:22, Jeffrey Collyer wrote: M$ has their own take on SPF called Sender ID, which uses a very similar record - v=spf2.0 rather than v=spf1 so be sure to read up on them both before publishing records for one or the other. It has downfalls so I recommend not even studying it, just remember that spf2 is some M$ crap... v=spf1 is just enough for now. http://www.openspf.org/SPF_vs_Sender_ID Hotmail in particular is picky about what it rejects and why. Yes, hotmail uses to reject mail for many strange reasons. But I don't recommend playing with spf2 just to get mail to hotmail, I think there are better ways to get your mail anywhere. -- 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. My mind is like a steel trap - rusty and illegal in 37 states. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SPF/TXT records
Hello, Do I dare comment on this? Okay, I do... RE: Advogato: If security was easy and conveinent, then everything would be secure. Someone tell Advogato! Advogato is complaining because they want an unmanagable environment of dynamic outbound relays and expect SPF, static DNS records, to keep up. Solution: SPF has syntax in place to suggest to the destination MTA that email might come from other sources. Or, just don't use SPF because it will not work in such an enivornment. Friends don't let friend forward email -- with or without SPF, but that's another story. Either way, nothing is wrong with SPF and Advogato needs to stop complaining about it when he/she is setting SPF up to fail. RE: Circlied: Yes yes yes. Welcome to real life. Jerks will be jerks and there's nothing to stop them from calling/emailing/FAXing scams to the world be abusing the same methods honest folks sue. SPF is not here to solve everything. SPF add another layer abuse prevention. No one should blindly accept email just because it passes SPF checks. I feel for any email users for a system configure as such - yuck! Solution: Use all email best practices, including filters, RBLs, monitoring logs, PTR checks, user complaints, etc., and SPF as appropriate for the administrator's environment. None of this is an attack on you, Jeff, and I would hope you realize that but I want to mention it to be sure. I realize you are sharing info on other view points and I appreciate that. In light of this, I had to share mine. Summary: SPF may, or may not, work in all environments. Everyone needs to decide on his/her own, but there's nothing wrong with SPF. Thanks. - Original Message From: Jeff Lightner jlight...@water.com To: Mike Bernhardt bernha...@bart.gov; Matus UHLAR - fantomas uh...@fantomas.sk; bind-users@lists.isc.org Sent: Friday, June 19, 2009 12:41:50 PM Subject: RE: SPF/TXT records Or moreover not to bother with SPF at all as suggested in these documents?: Why you shouldn't jump on the SPF bandwagon: http://www.advogato.org/article/816.html How spammers get around SPF: http://www.circleid.com/posts/782012_spammer_get_around_spf/ -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mike Bernhardt Sent: Friday, June 19, 2009 12:37 PM To: 'Matus UHLAR - fantomas'; bind-users@lists.isc.org Subject: RE: SPF/TXT records So is the general recommendation in this group to NOT implement an empty SPF2.0 record (i.e., spf2.0/pra) just in case, as recommended in the 5-year-old openspf document referenced below? -Original Message- From: Matus UHLAR - fantomas [mailto:uh...@fantomas.sk] Sent: Friday, June 19, 2009 12:31 AM To: bind-users@lists.isc.org Subject: Re: SPF/TXT records On 18.06.09 16:22, Jeffrey Collyer wrote: M$ has their own take on SPF called Sender ID, which uses a very similar record - v=spf2.0 rather than v=spf1 so be sure to read up on them both before publishing records for one or the other. It has downfalls so I recommend not even studying it, just remember that spf2 is some M$ crap... v=spf1 is just enough for now. http://www.openspf.org/SPF_vs_Sender_ID Hotmail in particular is picky about what it rejects and why. Yes, hotmail uses to reject mail for many strange reasons. But I don't recommend playing with spf2 just to get mail to hotmail, I think there are better ways to get your mail anywhere. -- 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. My mind is like a steel trap - rusty and illegal in 37 states. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ 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: SPF/TXT records
My comments below will be to all in general, not to anyone specific and no offence intended to anyone... RE: Advogato: Who? RE: Circlied: Who ? Ok enough of the sarcasm :) Is someone here seriously trying to use those sites as a reason to not do something, might as well reference us to mydogspewsupaftereatinglambbones.com(dunno if that's a real site, but its name has about as much credence as the ones given). Seriously if you want to show why not, reference a reputable site with reputable commentators. In relation to SPF2, if you use M$'s crap, you do have a slightly better chance of hotmail not losing your mail, so it is worth it if you provide services to anyone else other then yourself (where you *can* play god not affecting anyone else). BUT... do NOT use spf2 enforcement on your side, or you'll find a lot of mailing lists being very quiet :) Cheers ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SPF/TXT records
On Sat, Jun 20, 2009 at 07:24:41AM +1000, Noel Butler wrote: ... as the ones given). Seriously if you want to show why not, reference a reputable site with reputable commentators. ... Circleid has reputable commentators. I'm not saying that they all are, only that there exist some; I have not perused their entire list. Nor do I know who writes on the other one, but that one did seem a bit less impartial. -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SPF/TXT records
a powerfull user of domankeys and DKIM that is it ? another domain fakessh.eu is up for DK DKIM the full administrator smtp.wanadoo.fr is a spammeur script consists of a while loop surrounding a telnet session Le vendredi 19 juin 2009 à 22:38 -0400, Joseph S D Yao a écrit : On Sat, Jun 20, 2009 at 07:24:41AM +1000, Noel Butler wrote: ... as the ones given). Seriously if you want to show why not, reference a reputable site with reputable commentators. ... Circleid has reputable commentators. I'm not saying that they all are, only that there exist some; I have not perused their entire list. Nor do I know who writes on the other one, but that one did seem a bit less impartial. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
