Re: DNSDigger.com - An announcement and request for feature tips.
On Wed, Jun 17, 2009 at 02:19:22AM +0200, Jay Ess wrote a message of 19 lines which said: > DNSDigger.com - A massive reverse resolver that lets you dig deeper > into the Net. Congratulations. > 2. To ask you for feature requests. IPv6 support is certainly the first thing to add! I searched www.ietf.org and it only suggests me IPv4 addresses. How do old data expire? Searching www.langtag.net retrieves eve.generic-nic.net, a machine which was switched off two years ago. How often new data is added? Searching www.langtag.net does not retrieve www.dnsmezzo.net added on the same machine several weeks ago. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Questions about DNAME records
> -Original Message- > From: Chris Buxton [mailto:cbux...@menandmice.com] > Sent: 16 June 2009 15:40 > To: Braebaum, Neil > Cc: Bind Mailing > Subject: Re: Questions about DNAME records > > On Jun 16, 2009, at 1:37 AM, Braebaum, Neil wrote: > > What I was getting at - probably worded poorly - was say I > wanted to > > provide resolution for something like:- > > > > _service._tcp.example.com. > > > > if I'd previously created the DNAME record (example.com.IN > > DNAME example2.com.), would creating a SRV RR > record in > > example2.com.:- > > > > _service._tcp.example2.com. > > > > work as resolution for it? > > Yes. The final and complete answer will be: > > _service._tcp.example.com.IN CNAME > _service._tcp.example2.com. > _service._tcp.example2.com. IN SRV ... 4 fields here ... > > > As to the forwarding thing, what I was thinking of, is that > > example2.com. forwards out to internet DNS servers for external > > resolution > > Unfortunately, that's a nonsensical assertion. A domain does > not forward. A DNS server forwards. OK, the DNS servers that are authoritative for example2.com. > > and it just so happens that example.com. is a namespace we use > > externally. So would it work in the scenario I've given, that if I > > wanted to provide resolution for _service._tcp.example.com. (if it > > works with the DNAME scenario I've described above), would other > > records for example.com. that aren't catered for in > example2.com., be > > obtained by merit of example2.com. forwarding? Or would the DNAME > > configuration not allow it? > > A DNAME record precludes child names. That is, you cannot > have any names of the form "foo.example.com" and also have a > DNAME record named "example.com". > > > I guess what I'm wondering is that if example.com. is DNAMEd to > > example2.com. and the records aren't in example2.com. does > the enquiry > > end there, or could / would the question be dealt with by merit of > > example2.com. forwarding to internet DNS servers? > > If you have a DNAME record named example.com, then aside from > other records named example.com, there cannot be any other > records in the example.com zone. No subdomains are allowed. I think this is why I'm struggling to fully understand the DNAME usage - the example I gave above:- _service._tcp.example.com. would (effectively) be subdomain records from example.com. that I'm hoping to be able to provide responses for by using:- example.com.IN DNAME example2.com. and creating:- _service._tcp.example2.com. SRV resource records in example2.com., which you said would work above. > So if example.com is hosted on the outside, and example2.com > is internal, an internal resolver will see the external DNAME > record (and related, synthesized CNAME records) and be able > to resolve them inside example2.com (assuming it can find > example2.com). What I was hoping to do was create, or perhaps more correctly, cater for a specific and small number of records for example.com. (by DNAME'ing to example2.com.) internally, by creating a very simple zone with the DNAME to example2.com. - merely to provide answers for these resource records, that I don't want - nor are relevant - to the external use of example.com. example.com. is known on the internet, provided by a managed service DNS provided, and hosts some ecom related DNS records. I'm kind of being forced down the track of providing some resolution for some specific records (the resource records I've given examples for) internally (because of the domain name used for some email addresses), but I don't want to provide a fully authoritative zone for example.com. internally, because I don't want to have to maintain duplicate records in an internal example.com. authoritative zone, and for the external example.com. zone, and because I don't want to have to maintain or expose these resource records in my external example.com. zone. So what I was wondering was, by merit of using a DNAME record, is whether I could host the small number of resource records (that really are subdomain records from example.com.), and using a DNAME record internally, provide them in example2.com., and because the nameservers that are authoritative for example2.com. forward to internet DNS servers, whether they would in the scenario that the internal name enquired on in example.com. isn't present in example2.com. (eg say, some of the ecom related records in the external example.com. that I don't really want to have to cater for internally, too). > If there is no external version of example2.com, then you're > creating problems, because a DNAME record from a public zone > to a strictly private zone will cause resolution for the > public for names in the example.com domain (except > example.com itself) to fail. example2.com. is purely an internal namespace, and I wasn't thinking of creating a DNAME record in my external exam
Support of HIP RR (RFC 5205)
Does anybody know if (or when) BIND supports HIP (RFC5205) resource records ? The directory doc/rfc of bind 9.6.1 lists rfc5205, but named-checkzone will complain with an error: $ named-checkzone -v 9.6.1 $ named-checkzone -d example.net zone.db loading "example.net" from "zone.db" class "IN" zone.db:39: unknown RR type 'HIP' zone example.net/IN: loading from master file zone.db failed: unknown class/type Thanks Holger ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Support of HIP RR (RFC 5205)
In message , holger.zule...@arcor.net writes: > Does anybody know if (or when) BIND supports HIP (RFC5205) > resource records ? It's in BIND 9.7. BIND 9.7.0a1 is in the process of being prepared. 2565. [func] Add support for HIP record. Includes new functions dns_rdata_hip_first(), dns_rdata_hip_next() and dns_rdata_hip_current(). [RT #19384] Mark > The directory doc/rfc of bind 9.6.1 lists rfc5205, but > named-checkzone will complain with an error: > > $ named-checkzone -v > 9.6.1 > > $ named-checkzone -d example.net zone.db > loading "example.net" from "zone.db" class "IN" > zone.db:39: unknown RR type 'HIP' > zone example.net/IN: loading from master file zone.db failed: unknown > class/type > > Thanks > Holger > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
SPF/TXT records
Question: When one sets SPF/TXT record is it for the relay server/IP that sent the email to the internet or the originating one? For example we have a server (atuprd01.water.com) that can not be reached via the internet. Email originating there is relayed through our MS-Exchange server (if sent with domain water.com) or a Linux Sendmail server (if sent with domain waterinvoice.com). All email sent via exchange goes out an IP separate from incoming mail (MX) IP. All email sent via Sendmail has a separate IP from incoming mail (MX) IP. Should the SPF specify the outbound IP (e.g. 12.44.84.204 for atlsnml2.waterinvoice.com) for the Sendmail server email or the IP/name for atuprd01.water.com? Source/Headers for a test message shown below in case it helps: X-Eon-Dm: dm0208 Return-Path: Received: from atlsnml2.waterinvoice.com (12.44.84.204 [12.44.84.204]) by dm0208.mta.everyone.net (EON-INBOUND) with ESMTP id dm0208.4a317b14.3b9c1f3 for ; Wed, 17 Jun 2009 07:24:11 -0700 Received: from atuprd01.water.com (atuprd01.water.com [10.0.8.120]) by atlsnml2.waterinvoice.com (8.13.8/8.13.8) with ESMTP id n5HEUGY2009868 for ; Wed, 17 Jun 2009 10:30:16 -0400 Received: (from jligh...@localhost) by atuprd01.water.com (8.9.3 (PHNE_35484)/8.9.3) id KAA21720 for jclight...@copper.net; Wed, 17 Jun 2009 10:30:13 -0400 (EDT) Date: Wed, 17 Jun 2009 10:30:13 -0400 (EDT) From: jllight...@waterinvoice.com Message-Id: <200906171430.kaa21...@atuprd01.water.com> X-Authentication-Warning: atuprd01.water.com: jlightne set sender to jllight...@waterinvoice.com using -r To: jclight...@copper.net Subject: Test from atuprd01 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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
On 17.06.09 10:46, Jeff Lightner wrote: > When one sets SPF/TXT record is it for the relay server/IP that sent the > email to the internet or the originating one? maybe even both. If the outgoing mail relay checks for SPF, and you don't use SMTP authentication (in which case relays may not check for SPF), you need SPF for originating server to, so the relay doesn't reject the mail imediately. If the relay sends such mail to other servers, its IP should be in SPF too. I have SPF for fantomas.sk: fantomas.sk.43200 IN SPF "v=spf1 mx -all" it should be checked when someone is trying to send mail with @fantomas.sk as envelope from address. > For example we have a server (atuprd01.water.com) that can not be > reached via the internet. Email originating there is relayed through > our MS-Exchange server (if sent with domain water.com) or a Linux > Sendmail server (if sent with domain waterinvoice.com). All email sent > via exchange goes out an IP separate from incoming mail (MX) IP. All > email sent via Sendmail has a separate IP from incoming mail (MX) IP. > > Should the SPF specify the outbound IP (e.g. 12.44.84.204 for > atlsnml2.waterinvoice.com) for the Sendmail server email or the IP/name > for atuprd01.water.com? water.com should have your ms exchange's IP and waterinvoice.com should have your linux servers' IP. Watch out if there is really no email going from water.com via your linux server and no mail coming from waterinvoice.com via your exchange server... I assume -- 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. 99 percent of lawyers give the rest a bad name. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: SPF/TXT records
Right my relay might want it but if so that would be in my internal view. The Exchange and Sendmail servers only allow relay from specific locations and neither is using SPF to authenticate so far as I know. My question was more related to external view - what do people on the internet expect to see defined as SFP/TXT record to verify it is a valid email? I'm quite certain Sendmail is not sending any water.com email and that Exchange is not sending any waterinvoice.com email based on the Sendmail configuration of atuprd01.water.com - it uses a mailer table to determine which host to relay through specifically based on the domain of the email message "sender". -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Matus UHLAR - fantomas Sent: Wednesday, June 17, 2009 11:10 AM To: bind-users@lists.isc.org Subject: Re: SPF/TXT records On 17.06.09 10:46, Jeff Lightner wrote: > When one sets SPF/TXT record is it for the relay server/IP that sent the > email to the internet or the originating one? maybe even both. If the outgoing mail relay checks for SPF, and you don't use SMTP authentication (in which case relays may not check for SPF), you need SPF for originating server to, so the relay doesn't reject the mail imediately. If the relay sends such mail to other servers, its IP should be in SPF too. I have SPF for fantomas.sk: fantomas.sk.43200 IN SPF "v=spf1 mx -all" it should be checked when someone is trying to send mail with @fantomas.sk as envelope from address. > For example we have a server (atuprd01.water.com) that can not be > reached via the internet. Email originating there is relayed through > our MS-Exchange server (if sent with domain water.com) or a Linux > Sendmail server (if sent with domain waterinvoice.com). All email sent > via exchange goes out an IP separate from incoming mail (MX) IP. All > email sent via Sendmail has a separate IP from incoming mail (MX) IP. > > Should the SPF specify the outbound IP (e.g. 12.44.84.204 for > atlsnml2.waterinvoice.com) for the Sendmail server email or the IP/name > for atuprd01.water.com? water.com should have your ms exchange's IP and waterinvoice.com should have your linux servers' IP. Watch out if there is really no email going from water.com via your linux server and no mail coming from waterinvoice.com via your exchange server... I assume -- 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. 99 percent of lawyers give the rest a bad name. ___ 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
