Franck Martin | 13 Sep 11:37 2014
Picon

EDNS with IPv4 and IPv6 (DNSSEC or large answers)

I’m trying to figure out EDNS with UDP fragmentation on both IPv4 and IPv6 network.

My understanding is that UDP fragmentation is something frown upon in IPv4 and even more on IPv6 (because of
processing power needed, and security concerns)?

What is the recommended setup for EDNS?
-limit size to <1500? on both IPv4 and IPv6?
-allow UDP fragmentation on IPv4 and IPv6, how securely?

How does that play with DNSSEC large data records? I have seen that with some low TTL, bind tends not to
fallback (from 4096 to 512) fast enough often to return an answer within the time allocated.

Any good documentation, pointers?
I’m trying to figure out EDNS with UDP fragmentation on both IPv4 and IPv6 network.

My understanding is that UDP fragmentation is something frown upon in IPv4 and even more on IPv6 (because of
processing power needed, and security concerns)?

What is the recommended setup for EDNS?
-limit size to <1500? on both IPv4 and IPv6?
-allow UDP fragmentation on IPv4 and IPv6, how securely?

How does that play with DNSSEC large data records? I have seen that with some low TTL, bind tends not to
fallback (from 4096 to 512) fast enough often to return an answer within the time allocated.

Any good documentation, pointers?
Calvin Browne | 12 Sep 09:53 2014
Picon

Re: Dumb question: why is it that some, registries limit the nameservers that can be delegated to?


On 11/09/2014 19:03, dns-operations-request@... wrote:
>
> Thanks for the explanation, that helps! If we step back from the
> practise, do we think it's a good thing?

I'm of the opinion that something that can be determined
algorithmically (i.e. when glue should or shouldn't be added),
should be done exactly that way.

A separate registration process prevents this and introduces
a whole bunch of other issues, such as who owns the object,
who can operate on it, what happens when it gets orphaned,
or the parent changes registrar, what happens to
dependencies on deletion etc.

And I'm also 100% with marka on this. If the server being
delegated to can't respond for the name being delegated to,
the Registry delegating thereto is just being irresponsible.
[with delegation being separate to registration imho]

but I increasingly find myself on the losing end of these
arguments when money or market entrenchment/forces
come into play.

--Calvin

>
> One the one hand, requiring that nameservers be registered creates
> downward pressure on the number of active authoritative name server
(Continue reading)

Mark E. Jeftovic | 11 Sep 18:19 2014

is there a diagnostic tool to obtain delegated ns?


I'm going to be open sourcing a php class I wrote awhile back that we
use internally for finding the delegated nameservers for a specified domain.

This is distinct from "host -C" or doing a type=ns query because while
those will look at what are *thought* to be the NS records for the
domain (as reported by the nameservers themselves), it is not uncommon
to be at variance from what's actually delegated into the roots.

The class is just a wrapper that steps through dig +trace, but before I
clean this up, etc I'm wondering if we re-invented a wheel somewhere
along the line.

Is there already any tool specifically outputs the authoritative
nameservers as they are delegated in the rootzone for a domain?

- mark

--

-- 
Mark E. Jeftovic <markjr@...>
Founder & CEO, easyDNS Technologies Inc.
+1-(416)-535-8672 ext 225
Read my blog: http://markable.com

Paul Wouters | 11 Sep 18:07 2014
Picon

Hearing first complains about failing internal resolving due to .prod TLD


Hi,

Guess the first people are now finding out that .prod went live. I heard
from a large webhoster that their sysadmins use "db1.prod" for a
shorthand of db1.prod.corp.com. They are now attempting to go to
the  127.0.53.53 warning pit.

I had never through of "prod" being a problem. but it might actualy be
a pretty big one, along with "stag" if that is ever delegated.

Paul
Colm MacCárthaigh | 11 Sep 16:52 2014
Picon

Dumb question: why is it that some registries limit the nameservers that can be delegated to?

Many registries, if not most, don't let you delegate a zone to
arbitrary name-servers. Instead those nameservers need to be
"registered" in some way.

Typically anyone can register a name server, and it once it's done,
many zones can be delegated to that name server. A small number of
CC-TLDs also require contact details for the name servers, but I only
know of two that do that.

Registering doesn't require setting up glue, and it doesn't look it's
being done to detect cyclic dependencies between zones, which is also
the only limitation in the DNS that I can think of that require some
kind of workaround.

So why is it that name servers need to be registered? What's the
benefit of doing it? and if anyone can register a name server, what's
the point?

--

-- 
Colm
Dave Brockman | 11 Sep 14:51 2014

167.216.129.170 RDNS


Hello All,
  I am having difficulty resolving Reverse DNS for 167.216.129.170,
and I'm not entirely certain why.  If I just do a dig -x
167.216.129.170 I get:

; <<>> DiG 9.7.3 <<>> -x 167.216.129.170
;; global options: +cmd
;; connection timed out; no servers could be reached

If I dig -x +trace 167.216.129.170:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28671
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;167.216.129.170.               IN      A

;; AUTHORITY SECTION:
.                       10549   IN      SOA     a.root-servers.net.
nstld.verisign-grs.com. 2014091100 1800 900 604800 86400

and finally, if I  dig -x 167.216.129.170  <at> 8.8.8.8:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58383
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
(Continue reading)

Peter Andreev | 11 Sep 14:38 2014
Picon

Botnets, botnets everywhere

Hello,

We run a public resolver and a few days ago I noticed a lot of very
weird queries, like the following:

16:11:41.450794 IP 217.195.66.253.37426 > 62.76.76.62.53: 42580+ A?
swfjwvtkhqx.www.feile8888.com. (47)
16:11:41.450796 IP 91.209.124.75.50584 > 62.76.76.62.53: 37269+ [1au]
A? izhsccxedub.www.feile666.com. (57)

For the total amount of SLDs of 11, the only common in those queries
are random labels on the left side. One of those SLDs is an
online-shop, another is online-casino, so I concluded that our
resolver is being used to bombard NSes of corresponding SLDs with
queries.
I'd like to ask the respected community, how do you detect and protect
against such activity? Will RRL help me if all suspected queries come
with random qname?

Thank you in advance.

--

-- 
Is there any problem Exterminatus cannot solve? I have not found one yet.
Stephane Bortzmeyer | 3 Sep 09:00 2014
Picon

Validating or not validating (ICANN controlled interruption)

BIND validates "A nimportequoi.otsuka" and yields an answer with AD bit
set.

Unbound gives back the answer but without the AD bit.

[Try it yourself, 'dig  <at> unbound.odvr.dns-oarc.net A
nimportequoi.otsuka' and 'dig  <at> bind.odvr.dns-oarc.net A nimportequoi.otsuka']

In some cases (difficult to pinpoint, depending on the resolver's
state), both BIND and Unbound return SERVFAIL.

Who's right?

PS: dnsviz claims that names like eb2dz5xm4s.otsuka are "secure,
non-existent" while they elicit an answer.
Doug Barton | 3 Sep 01:44 2014
Picon

subset of gtld-servers.net goes dark after DNS server up for a while

Here is an odd one ... customer has some iterative servers that stop 
getting answers from a subset of the gtld-servers.net servers after the 
resolvers have been in operations for a while. I've not heard of that, 
but would be happy to be educated. :)

Doug
Chris Thompson | 28 Aug 14:38 2014
Picon
Picon

First new gTLD using ICANN's "Name Collision Occurrence Management Framework"

The gTLD "otsuka", created sometime in the last 24 hours, appears to be the
first to use the wildcards described at

https://www.icann.org/news/announcement-2-2014-08-01-en  https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf

That is, it contains

*.otsuka.  3600  IN  A    127.0.53.53
*.otsuka.  3600  IN  TXT  "Your DNS configuration needs immediate attention see https://icann.org/namecollision"
*.otsuka.  3600  IN  SRV  10 10 0 your-dns-needs-immediate-attention.otsuka.
*.otsuka.  3600  IN  MX   10 your-dns-needs-immediate-attention.otsuka.

and the corresponding RRSIGs.

What do people think about this business? Is anyone taking specific precautions
to detect attempts to connect to 127.0.53.53?

--

-- 
Chris Thompson               University of Cambridge Information Services,
Email: cet1@...    Roger Needham Building, 7 JJ Thomson Avenue,
Phone: +44 1223 334715       Cambridge CB3 0RB, United Kingdom.
Carsten Strotmann | 27 Aug 12:49 2014
Picon

DNSSEC "strict" mode useful?

Hello,

Would a DNSSEC "strict" mode in DNS resolver software be useful?

I define DNSSEC "strict" mode as a mode of DNS resolver operation where
only DNSSEC validated data will be returned.

Today the default mode of operation is to return data with AD flag for
validated data, SERVFAIL for validation failures, and data without AD
flag for all insecure data (no DNSSEC trust chain).

A DNS resolver in "strict" mode would never return data without AD flag
to a client. So either data + AD flag or SERVFAIL.

Use-cases:

DNSSEC "strict" mode is not to be used for generic DNS name resolution
in the public internet but

* in closed DNS environments with different parties, where by policy all
  DNS must be DNSSEC secured

* for a service in the public Internet where it is known that all DNS
  communication must be DNSSEC secured

Today such a "strict" mode configuration is possible by configuring
explicit trust anchor(s) for every domain to be secured. However this does
not scale. 

In my view it would be useful to have a configuration switch to tell a
(Continue reading)


Gmane