Re: [dns-operations] DNS ANY requests / UltraDNS

2013-01-11 Thread Tony Finch
Florian Weimer f...@deneb.enyo.de wrote:

 It seems to me it's true for BIND.  You can get much more data in the
 additional section of the ANY response over TCP.  Without TCP, it is
 simply left out.

Oh right, that's standard semantics, RFC 2181 section 9. I thought you
were saying that the answer section was being truncated without setting
TC.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


Re: [dns-operations] DNS and Email

2013-01-11 Thread Warren Kumari

On Jan 10, 2013, at 11:57 PM, Brett Watson br...@the-watsons.org wrote:

 
 On Jan 10, 2013, at 9:25 PM, Noel Butler wrote:
 
 On Fri, 2013-01-11 at 10:43 +0800, Feng He wrote:
 
 And I have a question that, what is the good username for showing in the 
 whois info for domain contact email?
 
 
 dnsad...@domain.com
 hostmas...@domain.com
 
 Either of these, I think the latter is probably more common of the two.
 
 Or follow this:
 
 http://www.ietf.org/rfc/rfc2142.txt

Or the advice (full disclosure: co-author ) in SSAC SAC44 ( 
http://www.icann.org/en/committees/security/sac044.pdf ) and SAC 40 ( 
http://www.icann.org/en/groups/ssac/documents/sac-040-en.pdf ) which recommend 
(amongst other things):

Registrants should consider the benefits of using mail domains for contact 
emails that are managed separately from the domains that can be accessed from 
an individual domain registration account so that an attacker cannot interfere 
with a registrar's ability to contact the registrant. Registrants should also 
consider other measures to mitigate this threat. For example, a registrant 
could distribute its domain name registrations across multiple domain name 
registration accounts (and possibly across different registrars). Example 
Networks, Inc. could manage example.com using account “examplenetworks1” and 
example.net using account “examplenetworks2”. Email addresses for points of 
contact for example.com could then be assigned from a mail domain operated 
under example.net. Similarly, email addresses for points of contact for 
example.net could be assigned from a mail domain operated under example.com.


It is, er, [ sad | hilarious ] when your domain malfunctions and no-one can 
contact you to let you know that this has happened because the contact is 
within the busticated domain… 

W


 ___
 dns-operations mailing list
 dns-operations@lists.dns-oarc.net
 https://lists.dns-oarc.net/mailman/listinfo/dns-operations
 dns-jobs mailing list
 https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

-- 
American Non-Sequitur Society; 
we don't make sense, but we do like pizza!


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


Re: [dns-operations] RRL exposed: resolver issues with AAAA-only NS?

2013-01-11 Thread Matthew Pounsett

On 2013/01/10, at 16:53, Phil Pennock wrote:

 Anyone know of any resolvers that suffer horribly and die when presented
 with an NS host which is -only?

From the perspective of a v4-only resolver, that would look like a lame 
delegation.  Is the whole NS set v6-only, or just the one name server?  If 
it's the whole NS set it wouldn't surprise me to find a few implementations 
that become a bit pathological about trying to get the address records.  I'd 
expect those implementations to try resolving the whole NS set though, and 
give up once they found a v4 address for any of them.




___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


Re: [dns-operations] DNS ANY requests / UltraDNS

2013-01-11 Thread Florian Weimer
* Tony Finch:

 Florian Weimer f...@deneb.enyo.de wrote:

 It seems to me it's true for BIND.  You can get much more data in the
 additional section of the ANY response over TCP.  Without TCP, it is
 simply left out.

 Oh right, that's standard semantics, RFC 2181 section 9. I thought you
 were saying that the answer section was being truncated without setting
 TC.

And I'm not sure anymore that it matters because recursive resolvers
will message the additional section as needed, anyway.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


Re: [dns-operations] RRL exposed: resolver issues with AAAA-only NS?

2013-01-11 Thread Phil Pennock
On 2013-01-11 at 11:57 -0500, Matthew Pounsett wrote:
 On 2013/01/10, at 16:53, Phil Pennock wrote:
 
  Anyone know of any resolvers that suffer horribly and die when presented
  with an NS host which is -only?
 
 From the perspective of a v4-only resolver, that would look like a
 lame delegation.  Is the whole NS set v6-only, or just the one name
 server?  If it's the whole NS set it wouldn't surprise me to find a
 few implementations that become a bit pathological about trying to get
 the address records.  I'd expect those implementations to try
 resolving the whole NS set though, and give up once they found a v4
 address for any of them.

There exist a couple of domains for which the whole NS set is v6-only.
One (not mine) is a direct child of .org.  Your hypothesis is reasonable
and is close enough to mine, and is the reason I'm asking: if anyone
knows which those implementations are.

Tony: forgot about fpdns, but am apprehensive about the legal position
of sending out queries to a server that's not mine, just because they
sent resolution traffic to me.  I suspect that, if their behaviour is
such that they're abusive and I'm just trying to correlate causes and
pin down behaviour, for engineering diagnostics, I'll be okay, but I'm
still going to think about it a bit before I go that route.

-Phil
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs