bind-users Digest, Vol 2012, Issue 1: Re: DMARC Record issue

Chris Vaughan Chris.Vaughan at lpi.nsw.gov.au
Tue Jan 6 04:03:50 UTC 2015


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.Vaughan at 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-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of bind-users-request at lists.isc.org
Sent: Monday, 5 January 2015 11:00 PM
To: bind-users at lists.isc.org
Subject: bind-users Digest, Vol 2012, Issue 1

Send bind-users mailing list submissions to
	bind-users at 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-request at lists.isc.org

You can reach the person managing the list at
	bind-users-owner at 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 <litt at acm.org>
To: jreed at isc.org
Cc: bind-users at lists.isc.org
Subject: Re: BIND DNSSEC Guide draft
Message-ID: <54A9AD04.6010907 at 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.Vaughan at lpi.nsw.gov.au>
To: "bind-users at lists.isc.org" <bind-users at lists.isc.org>
Subject: DMARC Record issue
Message-ID:
	<09B65D824073FA4D8643FEAE7BDB36C023D43E96 at 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 at dns-test-1.<domain>; aspf=s; rf=afrf; sp=reject"

Slave test zone record:

_dmarc                  TXT     "v=DMARC1\; p=reject\; rua=root at 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.Vaughan at 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 <davew at hireahit.com>
To: bind-users at lists.isc.org
Subject: Re: DMARC Record issue
Message-ID: <54AA5F0D.7060207 at 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 at dns-test-1.<domain>; aspf=s; rf=afrf; sp=reject"
>
> Slave test zone record:
>
> _dmarc                  TXT     "v=DMARC1\; p=reject\; rua=root at 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.mayers at imperial.ac.uk>
To: bind-users at lists.isc.org
Subject: Re: Unable to get AAAA for www.revk.uk from some of our
	servers
Message-ID: <54AA7ADF.8040604 at 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 at 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.


More information about the bind-users mailing list