Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#6473 enhancement closed wontfix (wontfix)

twistd dns --pyzone and --bindzone should deny zone transfers by default

Reported by: Richard Wall Owned by:
Priority: normal Milestone:
Component: names Keywords:
Cc: Branch:
Author:

Description

twistd dns --pyzone --bindzone allow zone transfers from anywhere. This seems a little too permissive if twistd dns is being used for serving DNS records on a public IP address.

eg

$ dig @66.35.39.65 twistedmatrix.com AXFR

; <<>> DiG 9.9.2-rl.028.23-P2-RedHat-9.9.2-10.P2.fc18 <<>> @66.35.39.65 twistedmatrix.com AXFR
; (1 server found)
;; global options: +cmd
twistedmatrix.com.	86400	IN	SOA	ns1.twistedmatrix.com. radix.twistedmatrix.com. 2013040400 86400 900 86400 86400
mail.twistedmatrix.com.	86400	IN	A	66.35.39.65
planet.twistedmatrix.com. 86400	IN	CNAME	mag.ik.nu.
ns1.twistedmatrix.com.	86400	IN	A	66.35.39.65
glyph.twistedmatrix.com. 86400	IN	CNAME	ghs.google.com.
...
twistedmatrix.com.	86400	IN	SOA	ns1.twistedmatrix.com. radix.twistedmatrix.com. 2013040400 86400 900 86400 86400
;; Query time: 164 msec
;; SERVER: 66.35.39.65#53(66.35.39.65)
;; WHEN: Thu Apr 25 13:55:12 2013
;; XFR size: 32 records (messages 1, bytes 745)

I'd like to add a new "twistd dns_authority" plugin which includes some or all of the following features:

  • includes options for permitting zone transfers from certain hosts / networks.
  • only gives authoritative answers
  • refuses queries whose recursion_desired flag is set.

Change History (3)

comment:1 Changed 9 years ago by David Reid

  1. Changing long established default behavior is bad.
  2. Tap plugins for different configurations are not very useful. twistd wsgi would be more code, more confusing, and less useful than twistd web --wsgi.
  3. Disallowing AXFR requests has some rather negligible security benefits. The argument for it made in your linked PDF is "This is a security issue since DNS data can be used to decipher the topology of a company’s network." While this may be strictly true it does not actually make a compelling case for changing the default behavior. A command line option for restricting AXFR requests would be a better use of your time.
  4. The PDF goes on to describe an attack where an attacker pretends to be the Primary Name Server so that the secondary name server will do an AXFR against it and it can poison the domain. This attack is helped by having a complete valid AXFR result from the Primary Server but the paper then goes on to state that IP access restriction is insufficient anyway, and does not make an argument for why you should restrict AXFR on the Primary.
  5. The PDF does mention TSIG which would allow the secondary to actually authenticate responses from the primary (and vice versa) and that could actually prevent the poisoning attack, some maybe DNSSEC is a useful thing to try to support.

I'd say this ticket should be broken up into adding command line arguments to the existing dns tap for the proposed features of the dns_authority plugin and we can then close this as invalid. That doesn't mean all of the proposed command line arguments make sense (I haven't thought to hard about it), but at least we would then be able to argue their merits independent of each other.

comment:2 in reply to:  1 Changed 9 years ago by Richard Wall

Resolution: wontfix
Status: newclosed

Thanks dreid for taking time to respond. My thoughts and answers below:

Replying to dreid:

  1. Changing long established default behavior is bad.
  2. Tap plugins for different configurations are not very useful. twistd wsgi would be more code, more confusing, and less useful than twistd web --wsgi.

Lets say I add a new option for limiting zone transfers eg twistd dns --allow-transfer=192.168.0.0/24

That option only makes any sense when combined with --pyzone or --bindzone or --secondary options.

So now I have to complicate the option parsing code (and the command line completion code) to print warnings or errors when the user tries to use --allow-transfer without those options.

The same applies to --cache which only makes sense when combined with --recursive.

Alternatively I can introduce two new DNS subcommands (twistd dns_auth and twistd dns_recursive) which only support the options that apply to that mode of operation.

This then it allows us to deprecate the original twistd dns subcommand rather than changing its long established default behaviour.

I actually expect the new dns subcommands will lead to simpler and more maintainable code.

I also expect that it will allow new options to be introduced eg

  1. --forwarder: for forwarding recursive queries for certain zones to upstream recursive DNS servers.
  2. --validator: for controlling DNSSEC validation in the recursive DNS server (when DNSSEC is implemented).

...in fact there are so many desirable options that I start to realise that it will require a configuration file rather than command line arguments.

And then I start to doubt whether this belongs in Twisted at all. Should I just create a separate Twisted based DNS server project?

In which case what is the scope of twistd dns (or any of the other default twistd plugins)? Are they meant only as demos / examples?

  1. Disallowing AXFR requests has some rather negligible security benefits. The argument for it made in your linked PDF is "This is a security issue since DNS data can be used to decipher the topology of a company’s network." While this may be strictly true it does not actually make a compelling case for changing the default behavior. A command line option for restricting AXFR requests would be a better use of your time.
  2. The PDF goes on to describe an attack where an attacker pretends to be the Primary Name Server so that the secondary name server will do an AXFR against it and it can poison the domain. This attack is helped by having a complete valid AXFR result from the Primary Server but the paper then goes on to state that IP access restriction is insufficient anyway, and does not make an argument for why you should restrict AXFR on the Primary.
  3. The PDF does mention TSIG which would allow the secondary to actually authenticate responses from the primary (and vice versa) and that could actually prevent the poisoning attack, some maybe DNSSEC is a useful thing to try to support.

Yeah, that PDF does not give particular compelling reasons for restricting zone transfers. I'm not sure I can either, except that everyone else does it.

If we want twistd dns to be regarded by sys admins as a viable server for their authoritative DNS I think it has to allow them to follow basic best practice.

You mention DNSSEC, but it too has addressed the "zone enumeration" issue by introducing NSEC3 to replace the original NSEC.

With DNSSEC, I don't think you can even do split horizon DNS.

I'd say this ticket should be broken up into adding command line arguments to the existing dns tap for the proposed features of the dns_authority plugin and we can then close this as invalid. That doesn't mean all of the proposed command line arguments make sense (I haven't thought to hard about it), but at least we would then be able to argue their merits independent of each other.

I think I've convinced myself that I should just create a separate txdns project. So I'll close the ticket and post something to the mailing list asking for opinions about extending the scope of the twistd dns plugin vs creating a separate txdns project.

comment:3 Changed 9 years ago by Jean-Paul Calderone

In which case what is the scope of twistd dns (or any of the other default twistd plugins)? Are they meant only as demos / examples?

They are not meant only as demos. They should be production quality services that can be deployed in real life environments to satisfy real requirements.

Note: See TracTickets for help on using tickets.