Re: [Pdns-users] BIND-Zonefiles: @ vs blank

2019-08-08 Thread Brian Candler

On 08/08/2019 14:09, Michael Loftis wrote:


we have a zonefile which got recently added TXT entries for SPF
and DMARC:

_dmarc          IN      TXT     "v=DMARC1; p=none; rua=mailto:foo
"
                IN      MX      10 mx.domain.tld.
                IN      TXT     "v=spf1 include:spf1.domain.tld ?all"

Since then, requests for the MX record were not answered any more,
adding a @ fixed it.

I'm wondering now why this happens, as in other zonefiles without TXT
records the blank substitution works.


I've always had the understanding that blank meant "reuse last" so by 
adding the _dmarc TXT record ahead of the blank records you 
inadvertently moved them to be _dmarc.ZONE


You are correct.  All three records shown above are for _dmarc.ZONE

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] BIND-Zonefiles: @ vs blank

2019-08-08 Thread Bjoern Franke
Hey,

> 
> I've always had the understanding that blank meant "reuse last" so by
> adding the _dmarc TXT record ahead of the blank records you
> inadvertently moved them to be _dmarc.ZONE
> 
> I could certainly be wrong because I haven't looked at the man page for
> bind zone files in the last decade.

Thanks for that hint. As stated in RFC 1035[1] "If an entry for an RR
begins with a blank, then the RR is assumed to be owned by the last
stated owner". When there are only blanks, it's somehow "substitute with
the domain name", so i "bricked" the entry with the dmarc TXT record.
Only an old documentation for Bind on IRIX[2] says "A blank or tab
character in the name field denotes the current domain."

Regards
Bjoern


[1]https://tools.ietf.org/html/rfc1035
[2]http://csweb.cs.wfu.edu/~torgerse/Kokua/SGI/007-2860-008/sgi_html/apa.html#LE86111-PARENT


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


[Pdns-users] PowerDNS Authoritative Server 4.1.13 Released

2019-08-08 Thread Erik Winkels via Pdns-users
Hello,

(via: 
https://blog.powerdns.com/2019/08/08/powerdns-authoritative-server-4-1-13-released/
 )

The 4.1.12 release was skipped due to a packaging issue.

This is a bugfix release for high traffic setups using the pipebackend or 
remotebackend. It contains the following changes:

- #8157: gpgsqlbackend: add missing schema file to Makefile
- #8162: stop using select() in places where FDs can be >1023

The tarball[2][3] is available at downloads.powerdns.com and packages for 
CentOS 6 and 7, Debian Jessie and Stretch, Ubuntu Trusty, Xenial and Bionic are 
available from repo.powerdns.com.

Please send us all feedback and issues you might have via the mailing list[4], 
or in case of a bug, via GitHub[5].

[1] https://doc.powerdns.com/authoritative/changelog/4.1.html#change-4.1.13
[2] https://downloads.powerdns.com/releases/pdns-4.1.13.tar.bz2
[3] https://downloads.powerdns.com/releases/pdns-4.1.13.tar.bz2.sig
[4] https://mailman.powerdns.com/mailman/listinfo/pdns-users
[5] https://github.com/PowerDNS/pdns/issues/new
--
Erik Winkels
PowerDNS.COM BV -- https://www.powerdns.com


signature.asc
Description: PGP signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] BIND-Zonefiles: @ vs blank

2019-08-08 Thread Michael Loftis
On Thu, Aug 8, 2019 at 07:01 Bjoern Franke  wrote:

> Hi,
>
> we have a zonefile which got recently added TXT entries for SPF and DMARC:
>
> _dmarc  IN  TXT "v=DMARC1; p=none; rua=mailto:foo;
> IN  MX  10 mx.domain.tld.
> IN  TXT "v=spf1 include:spf1.domain.tld ?all"
>
> Since then, requests for the MX record were not answered any more,
> adding a @ fixed it.
>
> I'm wondering now why this happens, as in other zonefiles without TXT
> records the blank substitution works.


I've always had the understanding that blank meant "reuse last" so by
adding the _dmarc TXT record ahead of the blank records you inadvertently
moved them to be _dmarc.ZONE

I could certainly be wrong because I haven't looked at the man page for
bind zone files in the last decade.



>
> Kind regards
> Bjoern
> ___
> Pdns-users mailing list
> Pdns-users@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/pdns-users
>
-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


[Pdns-users] BIND-Zonefiles: @ vs blank

2019-08-08 Thread Bjoern Franke
Hi,

we have a zonefile which got recently added TXT entries for SPF and DMARC:

_dmarc  IN  TXT "v=DMARC1; p=none; rua=mailto:foo;
IN  MX  10 mx.domain.tld.
IN  TXT "v=spf1 include:spf1.domain.tld ?all"

Since then, requests for the MX record were not answered any more,
adding a @ fixed it.

I'm wondering now why this happens, as in other zonefiles without TXT
records the blank substitution works.

Kind regards
Bjoern
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Zone Transfers

2019-08-08 Thread Curtis Maurand



On 8/8/19 3:26 AM, Mike wrote:

On 8/5/19 5:48 AM, Curtis Maurand wrote:

I scripted it.  I can't rely on pdns replication.  The supermaster
won't tell a slave to delete a zone for instance.  Adding a new zone
may or may not happen properly or in a timely manner.  Sometimes
transfers just don't happen and even if they do, the signed zones
won't work until they're rectified. Don't get me started on dnsdist.

On the subject of supermasters not being able to tell slaves to delete
zones:

     This may not be too critical - for a slave server to have knowledge
of a zone for which it should no longer be authoritative for.
Ultimately, if the internet roots don't point at your servers, nobody
will be asking your servers for data from these zones anyways, so all
you really are losing is some disk space. I wrote a script to do this
which essentially walks the whole list of zones on a slave server and
asks my (hidden) master whether it has an SOA for each one. If it
doesn't, meaning that zone has been removed, then the script removes it
from the slave. The necessity or required frequency of doing so, is
debatable. My script can blast thru ~500 zones in about 8 seconds flat
depending on latency from that slave to the hidden master.

Mike-
Good idea.  I didn't think of doing it that way.  Conversely, a good way 
to check to see if a zone has actually transferred, too.


Thanks for the idea,
--Curtis



___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


--
Best Regards Curtis Maurand
mailto:cur...@maurand.com
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Zone Transfers

2019-08-08 Thread Mike
On 8/5/19 5:48 AM, Curtis Maurand wrote:
> I scripted it.  I can't rely on pdns replication.  The supermaster
> won't tell a slave to delete a zone for instance.  Adding a new zone
> may or may not happen properly or in a timely manner.  Sometimes
> transfers just don't happen and even if they do, the signed zones
> won't work until they're rectified. Don't get me started on dnsdist.

On the subject of supermasters not being able to tell slaves to delete
zones:

    This may not be too critical - for a slave server to have knowledge
of a zone for which it should no longer be authoritative for. 
Ultimately, if the internet roots don't point at your servers, nobody
will be asking your servers for data from these zones anyways, so all
you really are losing is some disk space. I wrote a script to do this
which essentially walks the whole list of zones on a slave server and
asks my (hidden) master whether it has an SOA for each one. If it
doesn't, meaning that zone has been removed, then the script removes it
from the slave. The necessity or required frequency of doing so, is
debatable. My script can blast thru ~500 zones in about 8 seconds flat
depending on latency from that slave to the hidden master.

Mike-


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users