From: Joe Abley <jabley@hopcount.ca>
Date: Fri, 26 Mar 2010 10:06:02 -0700
>>> has someone experience in anycast ipv4 networks (to support DNS)?
>>
>> "Never been done" "Dangerous" "TCP does not work" etc etc etc.
>
> - Yes but as for DNS, anycast is essentially used for user requests (UDP)
> not to perform zone transfer(TCP).
As others have mentioned, TCP can generally be used for any DNS query, not just AXFR.
This becomes more important as DNS responses get bigger, e.g. responses from root servers due to the root zone containing DNSSEC information, see <DNSSEC Project Archive.
If your nameserver can't be reached over TCP, it's likely that there are people who can't talk to your nameserver. This means your DNS records can't be found. This is a bad thing.
Here, in glorious LOLCAPS:
ALWAYS MAKE SURE YOUR DNS SERVER CAN BE REACHED OVER TCP
TCP IS NOT JUST FOR ZONE TRANSFERS
FIX YOUR FIREWALLS
Fix your security officers!
I have talked to multiple security officers (who are generally not
really knowledgeable on networks) who had 53/tcp blocked and none have
yet agreed to change it. The last one told me that blocking 53/tcp is
"standard industry practice" as per his firewall training. Point out
what RFCs said simply bounced off of him. He said that if the protocols
would not handle blocked 53/tcp, the protocols would have to be
changed. Opening the port was simply not open to discussion.
They don't seen to really care if things are broken and seem to feel
that it is up to "the network" to accommodate their idea of normal
firewall configuration.
I will say that these were at federal government facilities. I hope the
commercial world is a bit more in touch with reality.
I have talked to multiple security officers (who are generally not
really knowledgeable on networks) who had 53/tcp blocked and none have
yet agreed to change it.
patience. when things really start to break, and the finger of fate
points at them, clue may arise.
I have talked to multiple security officers (who are generally not
really knowledgeable on networks) who had 53/tcp blocked and none
have yet agreed to change it.
patience. when things really start to break, and the finger of fate
points at them, clue may arise.
36 days until all root servers have DNSSEC data, at which point large
replies become normal.
are end user tools, i.e. a web click a button, available so they can
test if they are behind a clueless security id10t?
is there good simple end user docco they are somewhat likely to find
when things break for them?
i.e. what can we do to maximize the odds that the victim will quickly
find the perp, as opposed to calling our our tech support lines?
patience. when things really start to break, and the finger of fate
points at them, clue may arise.
When this issue was brought up on the OARC dns-operations list,
and it was suggested to make some simply factsheets (a bit like
ICANN's IPv6 http://www.icann.org/announcements/factsheet-ipv6-26oct07.pdf),
this was poo-pooed as being useless and a waste of time.
Since the final victim is the end user, I still think it's worth the
effort to try and make security officers and similar network operators
aware of the issues and what they can do to mitigate potential problems.
I must observe that these are not really the links you'd want to give your end users to check out. Their audience is very different. While the article on RIPE Labs comes close, they don't really answer the "does it work or does it not?" question with a green/red light, and they don't provide a good explanation to the audience Randy is referring to.
I must observe that these are not really the links you'd want to
give your end users to check out. Their audience is very different.
While the article on RIPE Labs comes close, they don't really answer
the "does it work or does it not?" question with a green/red light,
and they don't provide a good explanation to the audience Randy is
referring to.
Fair enough. Some simple "check your DNS reply size test [what is this ?]"
page ought to be set up, with a simple explanagtion.
"checkmydns.org" is available. If I get 5 minutes...
He said that if the protocols would not handle blocked 53/tcp, the
protocols would have to be changed. Opening the port was simply not
open to discussion.
Let me guess: They also completely blocked ICMP. I always tell these
customers to switch to IPv6 real fast and to turn of ICMPv6 to make
their networks really secure.
I will say that these were at federal government facilities. I hope the
commercial world is a bit more in touch with reality.
>>> I have talked to multiple security officers (who are generally not
>>> really knowledgeable on networks) who had 53/tcp blocked and none
>>> have yet agreed to change it.
>> patience. when things really start to break, and the finger of fate
>> points at them, clue may arise.
> 36 days until all root servers have DNSSEC data, at which point large
> replies become normal.
are end user tools, i.e. a web click a button, available so they can
test if they are behind a clueless security id10t?
no - in part because using a browser to debug DNS involves
a third app (and likly a third/forth) platform.
the nifty OARC testpoint is nearly worthless for real operations,
since its not located at/near a DNS authoritative source. the
K testpoint is good, I should prolly put back the one off B.
is there good simple end user docco they are somewhat likely to find
when things break for them?
not yet. in part because out of the few simple parts, many, many
combinations of failure can occur.
) MTU strictures:
v6/v4 tunneling
v6/v4 MTU
clamping
i.e. what can we do to maximize the odds that the victim will quickly
find the perp, as opposed to calling our our tech support lines?
thats a tough call. as tech support staff, we are almost always
an outside observer on the path btwn the victim and the perp.
troubleshooting is going to be problematic.
He said that if the protocols would not handle blocked 53/tcp, the
protocols would have to be changed. Opening the port was simply not
open to discussion.
Do they also believe that all DNS replies are less than 512 bytes?
Fair enough. Some simple "check your DNS reply size test
[what is this ?]" page ought to be set up, with a simple
explanagtion. "checkmydns.org" is available. If I get 5
minutes...
Reply sizes are a red herring. You need something that looks at the
result of ./IN/DNSKEY, ./IN/RRSIG, ./IN/NSEC. At least one of these
queries should return data, some of the time. (Unfortunately, the
test is probabilistic.)
Then you know that your resolver can receive data from the signed root
and will not cease to work when all the roots serve the signed zone.
Other tests can't tell you that.
If your resolver is DNSSEC-aware, you can force cache misses by using
random query names with a non-existing TLD. This variant of the test
is much easier to carry out.
If you are with a US Federal agency having problems like this, or any other issues with your DNSSEC deployment, please include them in the DNSSEC survey every US Federal executive agency has been tasked to submit by the Office of Management and Budget.
http://iase.disa.mil/stigs/stig/dns_stig_v4r1_20071017.pdf
If, for example, an organization placed an authoritative server in its
DMZ but limited zone transfers to servers behind the firewall, then it
could allow inbound and outbound UDP 53 to and from the DMZ name server
to allow queries, but deny TCP 53 in both directions to prohibit zone
transfers. This configuration, however, is strongly discouraged because
it may prevent legitimate DNS transactions that involve large responses
(e.g., a DNSSEC signature). In general, limitations on queries, zone
updates and transfers should be implemented in the name server's
configuration rather than through configuration of firewalls, routers,
or other communications devices.
