Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

2010-01-13 Thread Mathew J. Newton
On Mon, January 11, 2010 9:10 pm, Matthew Pounsett wrote:

 I suspect that, even though they threw an error, your registrar went ahead
 and passed on the same IPv4 address for both name servers to the registry.

I think this may have been the problem...

I went back in to the registrar's DNS control panel, cleaned everything
out and started afresh. In addition to the conventional 'delegate your
domain' control function I found that they also allow independent manual
tweaking of the glue - I think these two frontends may well have got out
of sync (my fault I'm sure for changing things too quickly) and ended up
in a bit of a mess.

The whole debacle has turned into something of a blessing in disguise
however -  I've discovered that the registrar provides a free secondary
service for domains purchased through them... and their nameserver is
dual-stacked too so all the better for my situation!

Thanks everyone for the assistance,

Mathew


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Is an IPv6-only glue/delegation record a problem in a world of IPv4?

2010-01-11 Thread Mathew J. Newton
I would be grateful if someone might be able to shed some light on an
apparent problem I've got with an experimental DNS I have setup.

Specifically, the Dig tool at http://www.kloth.net/services/dig.php seems
unable to resolve my records and I can't help but feel it's a problem at
my end rather than theirs!

The domain is v6ns.org, and the record I am attempting to query for is
ns1.v6ns.org - here's what the Kloth Dig tool gets:

[dig 'ns1.v6ns.org' 'A' +trace]

 dig: couldn't get address for 'ns1.v6ns.org': failure

 ;  DiG 9.3.2  ns1.v6ns.org A +trace
 ;; global options:  printcmd
 .  301721  IN  NS  I.ROOT-SERVERS.NET.
 .  301721  IN  NS  J.ROOT-SERVERS.NET.
 .  301721  IN  NS  K.ROOT-SERVERS.NET.
 .  301721  IN  NS  L.ROOT-SERVERS.NET.
 .  301721  IN  NS  M.ROOT-SERVERS.NET.
 .  301721  IN  NS  A.ROOT-SERVERS.NET.
 .  301721  IN  NS  B.ROOT-SERVERS.NET.
 .  301721  IN  NS  C.ROOT-SERVERS.NET.
 .  301721  IN  NS  D.ROOT-SERVERS.NET.
 .  301721  IN  NS  E.ROOT-SERVERS.NET.
 .  301721  IN  NS  F.ROOT-SERVERS.NET.
 .  301721  IN  NS  G.ROOT-SERVERS.NET.
 .  301721  IN  NS  H.ROOT-SERVERS.NET.
 ;; Received 228 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

 org.   172800  IN  NS  A2.ORG.AFILIAS-NST.INFO.
 org.   172800  IN  NS  A0.ORG.AFILIAS-NST.INFO.
 org.   172800  IN  NS  D0.ORG.AFILIAS-NST.org.
 org.   172800  IN  NS  C0.ORG.AFILIAS-NST.INFO.
 org.   172800  IN  NS  B0.ORG.AFILIAS-NST.org.
 org.   172800  IN  NS  B2.ORG.AFILIAS-NST.org.
 ;; Received 432 bytes from 192.36.148.17#53(I.ROOT-SERVERS.NET) in 8 ms

 v6ns.org.  86400   IN  NS  ns1.v6ns.org.
 v6ns.org.  86400   IN  NS  ns2.v6ns.org.
 ;; Received 150 bytes from 199.249.112.1#53(A2.ORG.AFILIAS-NST.INFO) in 4 ms

I set the domain up to experiment with IPv6, which could be why I've got a
problem...

I have a single DNS server with a IPv4 address and two IPv6 addresses. The
zone file is as follows:

$ORIGIN v6ns.org.
$TTL300
@   IN  SOA ns1.v6ns.org. dns.newtonnet.co.uk. (
2010012000  ; Serial
14400   ; Refresh
7200; Retry
950400  ; Expire
300 )   ; Negative Cache TTL

IN  NS  ns1.v6ns.org.
IN  NS  ns2.v6ns.org.

ns1 IN  2a01:348:133::a1
ns1 IN  A   77.103.161.36
ns2 IN  2a01:348:6:a1::2

The same delegation records are present as glue in the .org nameservers.

Local lookups for ns1.v6ns.org (A and  records) work fine, as they
also do from MenMice's online Dig tool. So why not Kloth's?

I can't help but feel it is given the lack of an IPv4 A record for
ns2.v6ns.org - either as glue in .org or within my own v6ns.org zone. But
should this matter? In the absence of an IPv4 A-record for the
ns2.v6ns.org delegation in .org shouldn't their Dig attempt to connect to
ns1.v6ns.org instead (yes, they are the same machine but noone else knows
this but me... and you!)?

I would be grateful for any assistance, and would be more than happy to
provide further details if the above is insufficient.

Mathew




___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

2010-01-11 Thread Rick Dicaire
On Mon, Jan 11, 2010 at 12:29 PM, Mathew J. Newton
bind-us...@newtonnet.co.uk wrote:
 The same delegation records are present as glue in the .org nameservers.

While this is not in response to your original question, I am curious.
I'm not sure if you were part of the discussion we just had on IRC
freenode #ipv6, but querying a .org TLD NS for  records for ns1
and ns2.v6ns.org return no actual  records, no errors reported,
but there seem to be  records shown in the ADDITIONAL section of
the query response.

If I understand this correctly, the lack of an ANSWER section for 
query would denote there is no ipv6 glue at the TLD?

2001:500:e::1 being a0.org.afilias-nst.info, a .org TLD NS

;  DiG 9.6.1-P2-RedHat-9.6.1-13.P2.fc12   ns1.v6ns.org
@2001:500:e::1
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 38080
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ns1.v6ns.org.  IN  

;; AUTHORITY SECTION:
v6ns.org.   86400   IN  NS  ns1.v6ns.org.
v6ns.org.   86400   IN  NS  ns2.v6ns.org.

;; ADDITIONAL SECTION:
ns1.v6ns.org.   86400   IN  A   77.103.161.36
ns2.v6ns.org.   86400   IN  A   77.103.161.36
ns1.v6ns.org.   86400   IN  2a01:348:133::a1
ns2.v6ns.org.   86400   IN  2a01:348:6:a1::2

;; Query time: 102 msec
;; SERVER: 2001:500:e::1#53(2001:500:e::1)
;; WHEN: Mon Jan 11 12:44:13 2010
;; MSG SIZE  rcvd: 150



;  DiG 9.6.1-P2-RedHat-9.6.1-13.P2.fc12   ns2.v6ns.org
@2001:500:e::1
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 377
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ns2.v6ns.org.  IN  

;; AUTHORITY SECTION:
v6ns.org.   86400   IN  NS  ns2.v6ns.org.
v6ns.org.   86400   IN  NS  ns1.v6ns.org.

;; ADDITIONAL SECTION:
ns2.v6ns.org.   86400   IN  2a01:348:6:a1::2
ns2.v6ns.org.   86400   IN  A   77.103.161.36
ns1.v6ns.org.   86400   IN  A   77.103.161.36
ns1.v6ns.org.   86400   IN  2a01:348:133::a1

;; Query time: 719 msec
;; SERVER: 2001:500:e::1#53(2001:500:e::1)
;; WHEN: Mon Jan 11 12:44:23 2010
;; MSG SIZE  rcvd: 150

An example showing glue in .com/.net:

;  DiG 9.6.1-P2-RedHat-9.6.1-13.P2.fc12   ns2.he.net
@G.GTLD-SERVERS.net
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 25892
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 9
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ns2.he.net.IN  

;; ANSWER SECTION:
ns2.he.net. 172800  IN  2001:470:200::2

;; AUTHORITY SECTION:
he.net. 172800  IN  NS  ns1.he.net.
he.net. 172800  IN  NS  ns2.he.net.
he.net. 172800  IN  NS  ns3.he.net.
he.net. 172800  IN  NS  ns4.he.net.
he.net. 172800  IN  NS  ns5.he.net.

;; ADDITIONAL SECTION:
ns1.he.net. 172800  IN  A   216.218.130.2
ns2.he.net. 172800  IN  A   216.218.131.2
ns2.he.net. 172800  IN  2001:470:200::2
ns3.he.net. 172800  IN  A   216.218.132.2
ns3.he.net. 172800  IN  2001:470:300::2
ns4.he.net. 172800  IN  A   216.66.1.2
ns4.he.net. 172800  IN  2001:470:400::2
ns5.he.net. 172800  IN  A   216.66.80.18
ns5.he.net. 172800  IN  2001:470:500::2

;; Query time: 100 msec
;; SERVER: 192.42.93.30#53(192.42.93.30)
;; WHEN: Mon Jan 11 12:54:02 2010
;; MSG SIZE  rcvd: 334


-- 
aRDy Music and Rick Dicaire present:
http://www.ardynet.com
http://www.ardynet.com:9000/ardymusic.ogg.m3u
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

2010-01-11 Thread Niobos

On 11 Jan 2010, at 18:29, Mathew J. Newton wrote:
Specifically, the Dig tool at http://www.kloth.net/services/dig.php  
seems
unable to resolve my records and I can't help but feel it's a  
problem at

my end rather than theirs!

It's their end


The domain is v6ns.org, and the record I am attempting to query for is
ns1.v6ns.org - here's what the Kloth Dig tool gets:



v6ns.org.   86400   IN  NS  ns1.v6ns.org.
v6ns.org.   86400   IN  NS  ns2.v6ns.org.
;; Received 150 bytes from 199.249.112.1#53(A2.ORG.AFILIAS-NST.INFO)  
in 4 ms

If I retry this DNS-query, I get:

;  DiG 9.4.3-P3  @A2.ORG.AFILIAS-NST.INFO ns1.v6ns.org.
; (2 servers found)
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 52072
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ns1.v6ns.org.  IN  A

;; AUTHORITY SECTION:
v6ns.org.   86400   IN  NS  ns1.v6ns.org.
v6ns.org.   86400   IN  NS  ns2.v6ns.org.

;; ADDITIONAL SECTION:
ns1.v6ns.org.   86400   IN  A   77.103.161.36
ns2.v6ns.org.   86400   IN  A   77.103.161.36
ns1.v6ns.org.   86400   IN  2a01:348:133::a1
ns2.v6ns.org.   86400   IN  2a01:348:6:a1::2

;; Query time: 28 msec
;; SERVER: 2001:500:40::1#53(2001:500:40::1)
;; WHEN: Mon Jan 11 20:26:17 2010
;; MSG SIZE  rcvd: 150

Which seems perfectly valid for a v4v6 delegation.


I set the domain up to experiment with IPv6, which could be why I've  
got a

problem...
Shouldn't, but might... I'm running a v4-v6 DNS right now and I've  
been through some trouble to get it working...


I have a single DNS server with a IPv4 address and two IPv6  
addresses. The

zone file is as follows:

$ORIGIN v6ns.org.
$TTL300
@   IN  SOA ns1.v6ns.org. dns.newtonnet.co.uk. (
   2010012000  ; Serial
   14400   ; Refresh
   7200; Retry
   950400  ; Expire
   300 )   ; Negative Cache TTL

   IN  NS  ns1.v6ns.org.
   IN  NS  ns2.v6ns.org.

ns1 IN  2a01:348:133::a1
ns1 IN  A   77.103.161.36
ns2 IN  2a01:348:6:a1::2

This is NOT how it's configured in the Glue:
ns1.v6ns.org.   86400   IN  A   77.103.161.36
ns2.v6ns.org.   86400   IN  A   77.103.161.36
ns1.v6ns.org.   86400   IN  2a01:348:133::a1
ns2.v6ns.org.   86400   IN  2a01:348:6:a1::2


Local lookups for ns1.v6ns.org (A and  records) work fine, as they
also do from MenMice's online Dig tool. So why not Kloth's?
Possibly because it's broken. It works fine here; results conform to  
the zone you listed above.



I can't help but feel it is given the lack of an IPv4 A record for
ns2.v6ns.org - either as glue in .org or within my own v6ns.org  
zone. But

should this matter? In the absence of an IPv4 A-record for the
ns2.v6ns.org delegation in .org shouldn't their Dig attempt to  
connect to
ns1.v6ns.org instead (yes, they are the same machine but noone else  
knows

this but me... and you!)?
I'm not a DNS expert, but I think it should. However, currently there  
IS a A-glue for ns2


Niobos
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

2010-01-11 Thread Mathew J. Newton


On Mon, January 11, 2010 5:57 pm, Rick Dicaire wrote:

 While this is not in response to your original question, I am curious.
 I'm not sure if you were part of the discussion we just had on IRC
 freenode #ipv6, but querying a .org TLD NS for  records for ns1
 and ns2.v6ns.org return no actual  records, no errors reported,
 but there seem to be  records shown in the ADDITIONAL section of
 the query response.

Hi Rick,

Thanks for that. I wasn't in that discussion, were you discussing this
sort of issue? (for the .org zones in particular?)

I could be wrong, but would I be right in saying that glue records being
served up under the ADDITIONAL section is perfectly valid, not least
because by definition they are no authoritative for those records and
hence can be ignored (and/or not cached)? I'm guessing here...

 If I understand this correctly, the lack of an ANSWER section for 
 query would denote there is no ipv6 glue at the TLD?

Just to clarify, I'm seeing these weird results for the A records too - I
don't know if that matters either way.

However, surely there must be some glue otherwise where are they getting
the results from?

Mathew


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

2010-01-11 Thread Mathew J. Newton
On Mon, January 11, 2010 6:27 pm, Miles Mccredie wrote:

 FWIW, this is what I'm seeing from an IPv4 only host.  Not sure if the
 unexpected source is the problem that kloth.net is seeing or whether
 it's the result of putting

 *;; reply from unexpected source: 77.103.161.36#60741, expected
 77.103.161.36#53
 ;; reply from unexpected source: 77.103.161.36#60741, expected
 77.103.161.36#53
 ;; connection timed out; no servers could be reached

It never rains but it pours?!

I too have seen that on occasion. I think it's down to my crappy D-Link
router, or rather its implementation of NAT. I've got a Cisco router sat
here waiting to take its place when I can find time to get round to it.

 FWIW, at least one of the afilias hosts had the same IPv4 address for
 ns[12].v6ns.org.

 ns1.v6ns.org.   86400   IN  A   77.103.161.36
 ns1.v6ns.org.   86400   IN  2a01:348:133::a1
 ns2.v6ns.org.   86400   IN  A   77.103.161.36
 ns2.v6ns.org.   86400   IN  2a01:348:6:a1::2

Hmm.. That's interesting. I know for a fact that my registrar wouldn't
allow me to enter two servers with the same address, however within my
zone I may have had ns[12] set with IPv4 records set for a period (a few
days ago). This makes me wonder where .org is getting its records from - a
combination of glue provided by the registrar and cached results from my
zone?

Mathew


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

2010-01-11 Thread Matthew Pounsett

On 2010/01/11, at 12:57, Rick Dicaire wrote:

 If I understand this correctly, the lack of an ANSWER section for 
 query would denote there is no ipv6 glue at the TLD?

No, that would indicate that the name server you queried is not authoritative 
for the record you queried about.  Glue, by definition, is non-authoritative 
data, and so appears in the ADDITIONAL section, as in the example you pasted.

By contrast, Verisign's servers have long included glue in the ANSWER section.  
This is widely considered to be at best suboptimal, and by many (or most) to be 
a bug.  Verisign has indicated that this behaviour is coming to an end, 
although I don't recall off the top of my head if they've announced a date.

Matt


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

2010-01-11 Thread Matthew Pounsett

On 2010/01/11, at 12:29, Mathew J. Newton wrote:

 Specifically, the Dig tool at http://www.kloth.net/services/dig.php seems
 unable to resolve my records and I can't help but feel it's a problem at
 my end rather than theirs!

The problem may be at Kloth.. but at least one of the many possible problems 
they might be having could be corrected by a slightly different configuration 
at your end.

According to RFC you must have at least two name servers on different networks 
for each delegation.  I interpret this as two name servers *per address 
protocol* that you want to support.  So, if you want to support queries from 
the v4 Internet (there may be reasons you don't) then you should have at least 
two name servers responding to queries over v4.

Koth may be having network trouble on v4 which prevents them from getting at 
77.103.161.0/24.  If that is the problem, a second v4 name server in a 
different subnet (at a different site) might present them with a path to a name 
server that can answer their query.  This is the reason why there is a 
redundancy requirement in the RFC.


That said.. there is nothing wrong with a name server that only answers using 
one address protocol or the other.  And there is functional precedent in 
infrastructure for name servers that are only on v6.  j.gtld.biz, which is 
authoritative for the us. zone only has a v6 address.  While this occasionally 
confuses an operator here and there, the DNS likes it just fine.

Matt


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

2010-01-11 Thread Matthew Pounsett

On 2010/01/11, at 14:48, Mathew J. Newton wrote:

 FWIW, at least one of the afilias hosts had the same IPv4 address for
 ns[12].v6ns.org.
 
 ns1.v6ns.org.   86400   IN  A   77.103.161.36
 ns1.v6ns.org.   86400   IN  2a01:348:133::a1
 ns2.v6ns.org.   86400   IN  A   77.103.161.36
 ns2.v6ns.org.   86400   IN  2a01:348:6:a1::2
 
 Hmm.. That's interesting. I know for a fact that my registrar wouldn't
 allow me to enter two servers with the same address, however within my
 zone I may have had ns[12] set with IPv4 records set for a period (a few
 days ago). This makes me wonder where .org is getting its records from - a
 combination of glue provided by the registrar and cached results from my
 zone?

The org. name servers are authoritative-only.. no caching takes place.

Also, the registry is contractually prevented from modifying zone data supplied 
by the registrars, which would preclude it from cloning the v4 address from one 
name server to the other.  Besides, as database objects, the relationship 
between one name server and the other would be pretty loose, and there'd be no 
reasonable way to assume that ns2.v6ns.org is authoritative for everything that 
ns1.v6ns.org is authoritative for.

I suspect that, even though they threw an error, your registrar went ahead and 
passed on the same IPv4 address for both name servers to the registry.

Matt



___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

2010-01-11 Thread Matthew Pounsett

On 2010/01/11, at 15:16, Matthew Pounsett wrote:

 By contrast, Verisign's servers have long included glue in the ANSWER 
 section.  This is widely considered to be at best suboptimal, and by many (or 
 most) to be a bug.  Verisign has indicated that this behaviour is coming to 
 an end, although I don't recall off the top of my head if they've announced a 
 date.

Following up my own email.. someone pointed me to the specific reference to the 
vague memory I had floating around in my head:

https://lists.dns-oarc.net/pipermail/dns-operations/2010-January/004838.html

To summarize, the behaviour I mentioned above is scheduled to go away on March 
1st, 2010.. at which point the com/net servers should start answering with glue 
in the ADDITIONAL section.

Matt



___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

2010-01-11 Thread Mathew J. Newton
On Mon, January 11, 2010 8:33 pm, Matthew Pounsett wrote:

 The problem may be at Kloth.. but at least one of the many possible
 problems they might be having could be corrected by a slightly different
 configuration at your end.

Thanks Matt for your (and others) continued help with this - it is much
appreciated.

 According to RFC you must have at least two name servers on different
 networks for each delegation.  I interpret this as two name servers *per
 address protocol* that you want to support.  So, if you want to support
 queries from the v4 Internet (there may be reasons you don't) then you
 should have at least two name servers responding to queries over v4.

I will do eventually. Given this is just for personal use/experimentation
I may get one of the free DNS providers to act as a secondary.

 Koth may be having network trouble on v4 which prevents them from getting
 at 77.103.161.0/24.  If that is the problem, a second v4 name server in a
 different subnet (at a different site) might present them with a path to a
 name server that can answer their query.  This is the reason why there is
 a redundancy requirement in the RFC.

I did think that, but then I can force them to use my server (using the @
option) and they resolve quite happily. It seems to be somewhere between
the .org and server and mine that they have trouble with!

 That said.. there is nothing wrong with a name server that only answers
 using one address protocol or the other.  And there is functional
 precedent in infrastructure for name servers that are only on v6.
 j.gtld.biz, which is authoritative for the us. zone only has a v6 address.
  While this occasionally confuses an operator here and there, the DNS
 likes it just fine.

That's good to know - I thought I was trying to do something that was
fundamentally forbidden!

Mathew


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users