Yes, I have read that part of the FAQ, which concerns people asking whether they need to add escape characters manually in the DMARC record.
I do not add these myself. As shown by my examples below, the entry in the master zone is free of any escape characters. However, when an update is triggered, the escape characters are being added to the entry on the slave zone automatically. Why is this happening and how do I stop it? Chris Vaughan | Communications Officer, ICT Land and Property Information | Level 5, 1 Prince Albert Road Queens Square NSW 2000 e: chris.vaug...@lpi.nsw.gov.au | t: 02 92286884 | m: 0401 148061 | f: 02 92231271 | http://www.services.nsw.gov.au I http://www.lpi.nsw.gov.au -----Original Message----- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of bind-users-requ...@lists.isc.org Sent: Monday, 5 January 2015 11:00 PM To: bind-users@lists.isc.org Subject: bind-users Digest, Vol 2012, Issue 1 Send bind-users mailing list submissions to bind-users@lists.isc.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.isc.org/mailman/listinfo/bind-users or, via email, send a message with subject or body 'help' to bind-users-requ...@lists.isc.org You can reach the person managing the list at bind-users-ow...@lists.isc.org When replying, please edit your Subject line so it is more specific than "Re: Contents of bind-users digest..." Today's Topics: 1. Re: BIND DNSSEC Guide draft (Timothe Litt) 2. DMARC Record issue (Chris Vaughan) 3. Re: DMARC Record issue (Dave Warren) 4. Re: Unable to get AAAA for www.revk.uk from some of our servers (Phil Mayers) ---------------------------------------------------------------------- Message: 1 Date: Sun, 04 Jan 2015 16:13:40 -0500 From: Timothe Litt <l...@acm.org> To: jr...@isc.org Cc: bind-users@lists.isc.org Subject: Re: BIND DNSSEC Guide draft Message-ID: <54a9ad04.6010...@acm.org> Content-Type: text/plain; charset="windows-1252" On 31-Dec-14 21:00, Jeremy C. Reed wrote: > ISC is seeking feedback and review for our first public draft of the > BIND DNSSEC Guide. It was written in collaboration with DeepDive > Networking. I haven't had a chance to look in detail, but a quick scan resulted in several observations that I hope are useful. Also, I posted your note to dnssec-deployment, where there should be enthusiasm for the topic :-) The private network section 6.5.4 doesn't talk about how to configure views/stub zones so that authoritative (internal) zones on a shared resolver/authoritative server get validated. (point 1 in the section dismisses the possibility.) This can be done. Further, it's useful. People are much more likely to experiment on internal zones. More important, consider a typical scenario: my web server on the internal view has a different address from the external view. (Besides efficiency, some commercial routers don't do NAT on a stick - e.g. allow an internal client to NAT to an external address served by that router, which is NATed to an internal server.) So we want to train users to look for DNSSEC authentication. Unless one makes this work, a notebook on the road will authenticate, but the same notebook in the office will not. Don't bother trying to explain this to users; they'll simply ignore the distinction. Which is sort of a long way of saying: if the goal is to encourage people to adopt DNSSEC, your guide should make Private Networks and the corresponding recipes first class citizens, not a 'don't bother with this' afterthought. Both for admins to feel freer to experiment, and for users to have a consistent experience. On key rollover - this is still a major hassle. And while the recipes look pretty, the process is ugly. Key rollover really needs to be automated. There are too many steps that require too much indirection. And too many 'you could do this or you could do that' choices - that don't really matter, especially for getting started. I don't see why a person should have to change parameters, dates, manually generate keys, etc. You can work on the recipes, but I don't think they'll make the problem approachable - or safe. Computers are good at this stuff - and people aren't. It really needs something like a daily cron job with a simple config file that does all the work. Trigger based on dates, or a 'do it now' "emergency/manual" command. Key generation, date setting, permissions, etc. As for key uploads to external registrars, it can mail the new keys/DS records to the admin with 'please upload these by 'date'', and only proceed with the roll-over when it can 'dig' them. (The e-mail can - via the config file - include a hyperlink to the upload page...) For internal, it can update the trusted keys include file, rndc reconfig, etc. And the config file should come with reasonable default parameters, so it 'just works' oob. E.g. roll the zsks every 6 months and the ksks every 2 years. (Semi-random numbers, let's not fight about them.) Also, RE TLSA - I think it's better to match just the subject public key - there are several cases where this reduces management overhead. I know generating the hash for that with openssl isn't fun. But, https://www.huque.com/bin/gen_tlsa is the easiest way that I've found to generate TLSA records. And it supports SPKI selectors... So you might want to point to it. I'll try to have a closer look later. Timothe Litt ACM Distinguished Engineer -------------------------- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. On 31-Dec-14 21:00, Jeremy C. Reed wrote: > ISC is seeking feedback and review for our first public draft of the > BIND DNSSEC Guide. It was written in collaboration with DeepDive > Networking. > > The document provides introductory information on how DNSSEC works, > how to configure BIND to support some common DNSSEC features, as well > as some basic troubleshooting tips. It has lots of interesting > content, including examples of using ISC's "delv" tool and using a > common provider's web-based interface to manage DS records. > > This is a beta edition of the guide. We'd appreciate any feedback or > suggestions, good or bad. You may email me directly, or to our > bind9-bugs@ bug tracker email, or back to this list as appropriate > (such as needing further community discussion). Or you may use the > GitHub to provide feedback (or fixes). We plan to announce the first > edition of this BIND DNSSEC Guide at the end of January. > > The guide also has a recipes chapter with step-by-step examples of > some common configurations. If you have any requests or would like to > contribute some content, please let us know. > > The beta of the guide is available in HTML and PDF formats at > > http://users.isc.org/~jreed/dnssec-guide/dnssec-guide.html > http://users.isc.org/~jreed/dnssec-guide/dnssec-guide.pdf > > The docbook source for the guide is at GitHub: > https://github.com/isc-projects/isc-dnssec-guide/ > > Happy New Year! > > Jeremy C. Reed > ISC > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4942 bytes Desc: S/MIME Cryptographic Signature URL: <https://lists.isc.org/pipermail/bind-users/attachments/20150104/d9f0929f/attachment-0001.bin> ------------------------------ Message: 2 Date: Mon, 5 Jan 2015 03:30:37 +0000 From: Chris Vaughan <chris.vaug...@lpi.nsw.gov.au> To: "bind-users@lists.isc.org" <bind-users@lists.isc.org> Subject: DMARC Record issue Message-ID: <09b65d824073fa4d8643feae7bdb36c023d43...@srv-qs-mail8.lands.nsw> Content-Type: text/plain; charset="us-ascii" I have been given the task of implementing DMARC in our BIND servers due the recommendation of a security audit on our systems. Whenever I create the record in the forward server, and refresh the zone, it comes out in the slave zone with escape characters inserted in the TXT record. This occurs in every version of BIND that I have tried, from 9.7 up to 9.10. Primary test zone record: _dmarc.<domain>. IN TXT "v=DMARC1; p=reject; rua=root@dns-test-1.<domain>; aspf=s; rf=afrf; sp=reject" Slave test zone record: _dmarc TXT "v=DMARC1\; p=reject\; rua=root@dns-test-1.<domain>\; aspf=s\; rf=afrf\; sp=reject" Chris Vaughan | Communications Officer, ICT Land and Property Information | Level 5, 1 Prince Albert Road Queens Square NSW 2000 e: chris.vaug...@lpi.nsw.gov.au | t: 02 92286884 | m: 0401 148061 | f: 02 92231271 | http://www.services.nsw.gov.au I http://www.lpi.nsw.gov.au *************************************************************** This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of the NSW Government. This email message has been swept by MIMEsweeper for the presence of computer viruses. *************************************************************** Please consider the environment before printing this email. ------------------------------ Message: 3 Date: Mon, 05 Jan 2015 01:53:17 -0800 From: Dave Warren <da...@hireahit.com> To: bind-users@lists.isc.org Subject: Re: DMARC Record issue Message-ID: <54aa5f0d.7060...@hireahit.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 2015-01-04 19:30, Chris Vaughan wrote: > I have been given the task of implementing DMARC in our BIND servers due the > recommendation of a security audit on our systems. > > Whenever I create the record in the forward server, and refresh the zone, it > comes out in the slave zone with escape characters inserted in the TXT record. > > This occurs in every version of BIND that I have tried, from 9.7 up to 9.10. > > Primary test zone record: > > _dmarc.<domain>. IN TXT "v=DMARC1; p=reject; rua=root@dns-test-1.<domain>; > aspf=s; rf=afrf; sp=reject" > > Slave test zone record: > > _dmarc TXT "v=DMARC1\; p=reject\; > rua=root@dns-test-1.<domain>\; aspf=s\; rf=afrf\; sp=reject" > http://www.dmarc.org/faq.html#s_12 has some information on what is happening here. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren ------------------------------ Message: 4 Date: Mon, 05 Jan 2015 11:51:59 +0000 From: Phil Mayers <p.may...@imperial.ac.uk> To: bind-users@lists.isc.org Subject: Re: Unable to get AAAA for www.revk.uk from some of our servers Message-ID: <54aa7adf.8040...@imperial.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 24/12/14 17:08, Frank Bulk wrote: > Except queries from 96.31.0.5 and 199.120.69.24 reliably return the AAAA > while queries from 96.31.0.20 do not. And we're all the same ISP, and in > the one case, from the same /24. I don't think Google is that granular. And > we do have good IPv6 connectivity. Yes, Google are that granular. See: http://www.google.com/intl/en_ALL/ipv6/statistics/data/no_aaaa.txt ...which currently lists: 96.31.0.20/32 # AS53347 United States 96.31.0.31/32 # AS53347 United States Google have been, AFAICT, silent on the specifics of how they generate their blacklisting. Presumably it's the fairly standard approach of correlating a web-bug to a unique hostname embedded in the google search page, received http requests, and received DNS queries. Google undoubtedly then do some stats magic - that is their thing, after all - and down-score resolvers which make the AAAA query but whose clients don't finish the HTTP request, above some threshold. We had persistent problems in the past with our resolvers appearing in the Google blacklist, despite having excellent IPv6 connectivity. Google were unwilling to provide us any details that would have allowed us to identify the cause(s). We eventually stopped paying any attention to it, and the problem went away by itself. Possibly there are one or more clients with broken IPv6 using your resolvers, but without Google specifying the criteria which gets a resolver blacklisted, it's hard to know. Frankly, I wish Google would ditch the AAAA blacklist. It is hiding problems that responsible operators would like to see and fix, just so that Google don't lose eyeballs (and ad revenue) :o/ ------------------------------ _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users End of bind-users Digest, Vol 2012, Issue 1 ******************************************* *************************************************************** This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of the NSW Government. This email message has been swept by MIMEsweeper for the presence of computer viruses. *************************************************************** Please consider the environment before printing this email. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
