Re: [Pdns-users] max record length workaround

2019-03-20 Thread Steve Atkins


On Mar 20, 2019, at 19:37, Jonathan Reed  wrote:

>> TXT records are limited to strings of 255 characters or less, but can have 
>> multiple strings, They'll be concatenated in order by the DKIM validator - 
>> I'm guessing that's what you're thinking of.
> Yes, indeed.
> 
> My pub key is 400 chars long, and inserting the long string as a set into 
> records.content fails as expected.
> mysql> UPDATE records set content = '"v=DKIM1; k=rsa; p=190_char_string" 
> "200_more_chars"' where id = 1234;
> ERROR 1406 (22001): Data too long for column 'content' at row 1

There is no workaround. You’ll need to fix your database schema (that’d be 
trivial on postgresql, but I don’t know enough about mysql’s limitations to 
know whether it’ll be painful there).

> 
> Alternatively, adding a second row with the same records.name (same selector) 
> makes sense.
> mysql> UPDATE records set content = '"200_more_chars"' where id = 1235;

That won’t work, ever. It needs to be a single TXT record.

Cheers,
  Steve


> 
> However this fails also the checker, as it cannot determine that the second 
> row is a continuation of the pub key with the row proceeding it. I'm still 
> struggling with appending the pubkey to the previous record.
> 
>> On Wed, Mar 20, 2019 at 2:14 PM Steve Atkins  wrote:
>> 
>> 
>> > On Mar 20, 2019, at 5:49 PM, Jonathan Reed  wrote:
>> > 
>> > Hi,
>> > 
>> > I'm running an old version of pdns where my backend record length for 
>> > "records.name" is still varchar(255). I've read it's been extended to 64k. 
>> > However I'm trying to insert a 400 character dkim value in it by adding 
>> > multiple records for the dkim to simulate a continuation of the key 
>> > string. Short of altering the table to allow for the longer lengths, have 
>> > any of you had experience with the syntax for making long strings like 
>> > this?
>> > I've used the conventional escape char \ and tried enclosing the entire 
>> > string in a paren () but no luck. Perhaps someone else out there has had 
>> > to do this in the past?
>> 
>> records.name holds the name of the record, e.g. 
>> "whatever._domainkey.example.com", not the content, so 255 characters should 
>> be just about enough. records.content is where the content lives.
>> 
>> TXT records are limited to strings of 255 characters or less, but can have 
>> multiple strings, They'll be concatenated in order by the DKIM validator - 
>> I'm guessing that's what you're thinking of.
>> 
>> The syntax for that data in records.content is wrapping each string in the 
>> record in double quotes and separating those (two) strings with spaces - so 
>> something like '"v=DKIM1\; p=...base64 goop..." "...more base64 goop..."'
>> 
>> I'm not sure whether / why the semicolon needs to be backslash escaped. An 
>> homage to bind file format, I guess.
>> 
>> Cheers,
>>   Steve
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] max record length workaround

2019-03-20 Thread Steve Atkins


> On Mar 20, 2019, at 5:49 PM, Jonathan Reed  wrote:
> 
> Hi,
> 
> I'm running an old version of pdns where my backend record length for 
> "records.name" is still varchar(255). I've read it's been extended to 64k. 
> However I'm trying to insert a 400 character dkim value in it by adding 
> multiple records for the dkim to simulate a continuation of the key string. 
> Short of altering the table to allow for the longer lengths, have any of you 
> had experience with the syntax for making long strings like this?
> I've used the conventional escape char \ and tried enclosing the entire 
> string in a paren () but no luck. Perhaps someone else out there has had to 
> do this in the past?

records.name holds the name of the record, e.g. 
"whatever._domainkey.example.com", not the content, so 255 characters should be 
just about enough. records.content is where the content lives.

TXT records are limited to strings of 255 characters or less, but can have 
multiple strings, They'll be concatenated in order by the DKIM validator - I'm 
guessing that's what you're thinking of.

The syntax for that data in records.content is wrapping each string in the 
record in double quotes and separating those (two) strings with spaces - so 
something like '"v=DKIM1\; p=...base64 goop..." "...more base64 goop..."'

I'm not sure whether / why the semicolon needs to be backslash escaped. An 
homage to bind file format, I guess.

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


Re: [Pdns-users] PDNS Auth Zone Distribution in a Global Network?

2018-07-02 Thread Steve Atkins

> On Jun 29, 2018, at 2:23 PM, Anthony Eden  wrote:
> 
> Hello everyone,
> 
> I am considering moving some or all of DNSimple's authoritative DNS service 
> back over to PowerDNS within the next 6 months, but before I do so, I'm 
> hoping to get in touch with one or more folks from the PowerDNS community who 
> operate authoritative DNS across multiple geographic regions.
> 
> We currently have POPs in San Jose, Chicago, Virginia, Amsterdam, Tokyo, and 
> a new one coming online in Sydney. To distribute zone changes quickly (within 
> 60 seconds) from our Chicago data center we have a home grown zone 
> distribution system where notifications are sent to a zone server within each 
> data center, and that zone server in turn sends out a notice to every name 
> server in its data center. Each name server then queries the zone server for 
> the zone, and the zone server either pulls the zone from memcached and 
> returns it to the name server, which caches it in memory, or the zone server 
> queries our primary data store in Chicago to get the zone.
> 
> This system works, however as it is all home grown, it is difficult to 
> maintain and enhance. I am interested in moving away from our custom solution 
> to something off-the-shelf, and I'm looking for recommendations from other 
> operators on what is working for you.
> 
> Thanks in advance for your time and your thoughts.

I've been using PowerDNS in several locations, east and west coast of the US, 
using a PostgreSQL backend and PostgreSQL logical replication. Updates are 
pushed out fast enough that I don't see any delay, typically less than a second.

If the database backend will handle your query load it's well worth considering.

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


Re: [Pdns-users] Why the rectify-zone? increase-serial?

2018-02-06 Thread Steve Atkins

> On Feb 6, 2018, at 12:29 AM, Sander Smeenk via Pdns-users 
>  wrote:
> 
> Quoting Sander Smeenk via Pdns-users (pdns-users@mailman.powerdns.com):
> 
>> Could this not be handled by some logic that compares the serial
>> to the last-rectified serial and rectifies it on the fly when needed?
>> This might not work for super huge zones perhaps, performance wise,
>> but i dont think i would notice anything in my workload. ;-)
> 
> Heh. According to da interweps, this was 'discussed' on list earlier.
> http://powerdns.13854.n7.nabble.com/How-do-you-rectify-zones-tt8633.html#none
> But that thread just boils down to "Yea, you got to rectify-zone yourself." ;)


There is an API call to rectify a zone, so any automation / web front end
could do that as it's final operation when updating a zone, making it
transparent to the user.

On a related note, does anyone know of a good way to check whether a
zone is valid, or not? It's something I'd like to monitor, but I'm not sure
how best to do that. 

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


Re: [Pdns-users] change_date and API

2017-11-23 Thread Steve Atkins

> On Nov 23, 2017, at 12:27 PM, Eric Beck  wrote:
> 
> Greetings,
> 
> Issue: When using the API, and gmysql backend, the change_date column is
> not updated.
> 
> Ok, I know this subject as come up before, and from what I read there
> seemed to be a consensus at PowerDNS development to leave it as is.  The
> rationale as I read it was that there was low usage of the column by
> users  That may be the case in a general sense in that it's not a
> field used all the time.  But, when it is used, or when you need it, as
> in  we get requests for when was the last update performed on the
> DNS, etc.  I note that PowerAdmin updates this field.
> 
> We're currently in development and looking at either a proprietary
> interface which directly updates the pdns mysql backend, or using the
> API.  It certainly would be nice if the change_date column could be
> updated with the API.  I can't see that it's much overhead.  Am I wrong
> about that?  If we're updating a record or two let's say, in a zone,
> there's the update statement, so another update with the
> UNIX_TIMESTAMP() update for the column done immediately after it.
> 
> I personally cannot see the "value" in not doing it.
> 
>  thoughts ??? any change of heart there folks?

I don't have much of an opinion on whether the API should do it
or not, but it seems like it'd be fairly trivial to do with a database
trigger?

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


Re: [Pdns-users] CAA Records

2017-08-13 Thread Steve Atkins

> On Aug 13, 2017, at 11:10 AM, Brian Candler  wrote:
> 
> On 13/08/2017 18:40, Curtis Maurand wrote:
>> I have a ton of websites running letsencrypt.  That's great, I like it, but 
>> starting in April they started requiring CAA records.
> 
> Citation needed?
> 
> https://letsencrypt.org/docs/caa/
> 
> says that this is optional. ("If you don’t care about CAA, you generally 
> don’t have to do anything"). And I don't have any problems getting 
> letsencrypt certificates for a domain with no CAA records.

You don't need to have CAA records, but you need a nameserver that answers 
queries for CAA records. NXDOMAIN is fine.

Broken dnssec will cause those queries to fail (as they're made over dnssec if 
available).

Cheers,
  Steve

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


Re: [Pdns-users] CAA Records

2017-08-13 Thread Steve Atkins

> On Aug 13, 2017, at 10:40 AM, Curtis Maurand  wrote:
> 
> Hello,
> I have a ton of websites running letsencrypt.  That's great, I like it, but 
> starting in April they started requiring CAA records.  A new record to be 
> sure and, according to the docs, it is supported.  There is nothing in the 
> docs about how to construct the record.  
> 
> I'm running PDNS 4.04 which I compiled from the sources on Ubuntu 16.04  
> 
> I've tried adding the record directly into the database by sql. head for a 
> caa checker and no dice.
>  
> I've added the record so far as:  
> 
> deacon.xyonet.com   3600IN  CAA 0 issue "letsencrypt.org"
> 
> I've entered in this generic way.  There is no documentation that says to 
> format it any differently for pdns.
> 
> I had to change my primary DNS server late last night, should I just wait 
> another day or two for this all to settle down?   I haven't reconciled the 
> dnssec piece, yet.  Just trying to get website going after a not so very 
> smooth migration that's just been trouble all the way.
> 
> The tools that I've found (nslookup, dig, etc) so far don't allow me to query 
>  CAA records.  the pdns-util parser is telling me the record is OK, but at 
> this point, since none of the online tools can look it up, I'm thinking their 
> might be something that I'm doing wrong.
> 
> If anyone has any advice on how to proceed, that would be greatly appreciated.

You can use "dig @23.111.169.69 deacon.xyonet.com type257" if you have a dig 
too old to know about CAA.

But not having dnssec working is _the_ problem. Your domain is down as far as 
people using dnssec are concerned. CAA assumes you're using dnssec, so 
letsencrypts checker and the online tools are going to be seeing servfails as 
they'll be using dnssec-aware resolvers.

You might find http://dnsviz.net/d/deacon.xyonet.com/analyze/ useful to fix the 
dnssec problems, then https://unboundtest.com to see what your DNS looks like 
from a letsencrypt-ish resolver.

Cheers,
  Steve


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


Re: [Pdns-users] Using the API without running the DNS server

2017-04-03 Thread Steve Atkins

> On Apr 3, 2017, at 8:44 AM, j...@archer.net wrote:
> 
> Hi All…
> 
> I’m in the process of deploying a pdns cluster and am going to have 4 dns 
> servers, each with their own installation of Postgres. These will be standby 
> servers from a master version of Postgres, and on the master is where changes 
> to zones will happen.
> 
> For a bunch of reasons I think it’s best to let my front end use the API, so 
> I’ll have to install pdns on that master Postgres box. Can I configure pdns 
> so that the API works but the name server itself does not?

Not an answer to your question, but I'm using a similar setup and I've found it 
convenient to have the pdns server on the master box answer queries (on 
localhost, in my case) so I can use DNS tools to look at what the master 
believes reality is, particularly when diagnosing replication issues / lag.

Cheers,
  Steve

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


Re: [Pdns-users] SRV records - wow, hounded for payment already?

2017-03-05 Thread Steve Atkins

> On Mar 5, 2017, at 9:22 AM, NoBloat  wrote:
> 
> Wow, only a few days into trying pdns and I'm getting hounded about buying 
> support and being given a hard time about wanting to remain anonymous which 
> most anyone should want to anyhow. 
> 
> Yes, DNS records are public but I don't have to say which domains I'm working 
> on in mailing lists or forums if I don't want to and you don't have to help 
> if you don't want to. No one is forcing anyone to help anyone so why even 
> point such a lame thing out. Just don't help then.

Every post you make to a mailing list goes to hundreds or thousands of people. 
You're costing them a significant amount of time and attention.

If you're not prepared to share the information that people need to help you 
(which includes how you have replication configured, as well as the domain 
involved) then you're mostly just wasting their time - which is rude, 
unprofessional behaviour.

You might want to take a step back and think about whether if someone else were 
behaving the way you are you'd want to go out of your way to give them free 
support? And whether - as a bind expert - you'd be able to diagnose their 
misconfiguration without access to their bind configuration and without the 
ability to query their bind server? And, even if you were able, how much 
additional work that would require?

(Disclaimer: I have no connection with powerdns other than being a happy user, 
and one who has received very effective support here in the past.)

Cheers,
  Steve

> 
> As I have said, pdns is new to me, I've used to using BIND for many years. I 
> cannot jump into paying for support when I am simply trying to make a case to 
> my bosses that maybe they should consider using this product for their 
> enterprise networks, they would think I am a fool for suggesting this without 
> even playing with it for a while first to make my case.
> 
> I'll either go back to BIND if I will continuously be told such things when 
> asking for basic help or I'll find one of our devs who knows the product. I 
> just wanted to get some hands on time with it first.
> 
> 
> 
> - Original Message -
> From: "Brian Candler" 
> To: "NoBloat" , Pdns-users@mailman.powerdns.com
> Sent: Saturday, March 4, 2017 3:48:40 PM
> Subject: Re: [Pdns-users] SRV records do not transfer correctly
> 
> On 04/03/2017 18:56, NoBloat wrote:
>> I'm not sure what you mean by 'what form of replication'. What information 
>> could I give which would answer this?
> 
> Well, you could give the type of replication you have configured!
> 
> See:
> https://doc.powerdns.com/md/authoritative/modes-of-operation/
> 
> If you are using pdns with mysql backend, then I'd say the best way is 
> to use native mysql replication between the backends.
> 
> You can do zone transfers instead, but it requires more configuration, 
> as described in the page linked above.
> 
>> In terms of obfuscating, sorry but all I obfuscated was the actually domain 
>> name. The rest of the records show clearly. I cannot post private 
>> information which I do not own.
> 
> The DNS is a public database.
> 
> The support policy for powerdns is clear, and Bert pointed you to it 
> already:
> 
> https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open/
> 
> Basicaly: if you want private support, you can pay for it.  If you want free
> support, then you publish the information about the domain you are
> having problems with, without obfuscation.
> 
> Most of your questions could be answered in a few seconds if you gave the 
> actual domains
> and we could send queries to your servers.
> 
> ___
> Pdns-users mailing list
> Pdns-users@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/pdns-users

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


Re: [Pdns-users] PowerDNS Recursor does not provide correct answer to Postfix

2016-08-18 Thread Steve Atkins

> On Aug 18, 2016, at 8:11 AM, David  wrote:
> 
> On 2016-08-18 8:37 AM, Pieter Lexis wrote:
>> Hi Michael,
>> 
>> On Thu, 18 Aug 2016 14:20:25 +
>> Michael  wrote:
>> 
>>> Last week I updated to Ubuntu 16.04. So I have a new Postfix version
>>> (3.1.0) as well as a new pdns_recursor version (4.0.0-alpha2).
>>> 
>>> Since this update Postfix does not receive correct answers for a
>>> particular query anymore. Concretely, queries for A entries of
>>> Office365 mail servers.
>>> 
>>> For example if Postfix asks for the A entry of
>>> nxp-com.mail.protection.outlook.com, pdns_recursor returns to Postfix
>>> that there does not exists a A record.
>>> However, if I manually do this query with dig, I do get an correct
>>> answer. Please see the logs at the end of the mail.
>>> 
>>> Besides the queries of Office365 mail servers, the rest is working
>>> fine. I have no idea how to track down that issue? Is there any
>>> setting in pdns_recursor I have to change?
>> 
>> Postfix might be asking for DNSSEC, which is finiky in the alpha version 
>> Ubuntu pulled in. Can you install 4.0.1 from our repositories[1] and try 
>> again? 4.0.1 has about 5 months more development time in it.
>> 
> 
> Also see: https://www.mail-archive.com/mailop@mailop.org/msg01648.html for 
> more information on how Microsoft does DNS and the issues encountered with 
> Office365. (DNSSEC and EDNS issues, IIRC).
> 

Their load balancers return FORMERR in response to DNSSEC (or any EDNS, I 
presume) requests. It's been an ongoing issue (and I've seen it cause 
resolution problems previously, with pdns_recursor 3.something).

Speculation was that it was something to do with short TTLs and/or packet size 
limitations somewhere on the resolution path. I don't think anyone has looked 
at the traffic deeply enough to say for sure.

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


Re: [Pdns-users] exception building answer packet

2016-03-25 Thread Steve Atkins

> On Mar 25, 2016, at 7:15 AM, Peter van Dijk <peter.van.d...@powerdns.com> 
> wrote:
> 
> Hello Steve,
> 
> do you still have the ‘broken’ database contents from before your rectify? 
> Those would be useful in figuring out whether there’s a bug!

I have several backups that might have that data. I'm planning on building a 
test server and loading them up to see if I can replicate the problem. If I get 
a test case I'll share.

Cheers,
  Steve

> 
> Kind regards,
> -- 
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
> 
> On 25 Mar 2016, at 4:07, Steve Atkins wrote:
> 
>> pdnssec rectify-zone makes the problem go away, which fixes it for me.
>> 
>> It feels like there's still an underlying bug somewhere in the dnssec sql or 
>> surrounding code, though.
>> 
>> Cheers,
>>  Steve
>> 
>>> On Mar 24, 2016, at 7:54 PM, Steve Atkins <st...@blighty.com> wrote:
>>> 
>>> I'm using a postgresql backend, and I have several zones configured to use 
>>> dnssec.
>>> 
>>> Queries for resource records that exist work perfectly. The verisign online 
>>> checker says my dnssec is good.
>>> 
>>> If I query for a resource record that doesn't exist without using dnssec - 
>>> either one where there are no RRs with a matching name or one where there 
>>> are RRs with a matching name but none also have a matching type - I get the 
>>> expected NXDOMAIN or NOERROR result.
>>> 
>>> If I run the same query with dnssec then I get a servfail.
>>> 
>>> With log level 9, and log-dns-details and log-dns-queries on, I get this in 
>>> the log:
>>> 
>>> Mar 24 19:35:49 ns pdns[30538]: Remote 184.105.179.144 wants 
>>> 'foo.blighty.com|A', do = 1, bufsize = 1680: packetcache MISS
>>> Mar 24 19:35:49 ns pdns[30538]: Exception building answer packet (Unknown 
>>> DNS type '.blighty.com') sending out servfail
>>> 
>>> I see this with version 3.4.6 and 3.4.8. It looks like someone else had a 
>>> similar issue here: 
>>> https://mailman.powerdns.com/pipermail/pdns-users/2015-October/011747.html
>>> 
>>> It's a new installation, but the data has been around for a few years. 
>>> There are no custom SQL queries.
>>> 
>>> There is no record in the database with type '.blighty.com' - all non-null 
>>> types are expected A, TXT, PTR, etc. There are some records where the type 
>>> is null, though.
>>> 
>>> Clearly it's getting garbage from the database, but only when building a 
>>> dnssec response where there are no matching RRs.
>>> 
>>> Before I set up a testbed server to work out what's going on, does any of 
>>> this ring any bells with anyone?
>>> 
>>> Cheers,
>>> Steve
>>> 
>>> ___
>>> Pdns-users mailing list
>>> Pdns-users@mailman.powerdns.com
>>> https://mailman.powerdns.com/mailman/listinfo/pdns-users
>> 
>> ___
>> Pdns-users mailing list
>> Pdns-users@mailman.powerdns.com
>> https://mailman.powerdns.com/mailman/listinfo/pdns-users
> ___
> Pdns-users mailing list
> Pdns-users@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/pdns-users

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